The Tech Interview is Dead.
-
Hear Hear! (or is that "Here Here"?? :confused:) http://techcrunch.com/2013/06/22/the-technical-interview-is-dead/[^] I think his breakdown of the interview process is pretty spot on. -EM
emartinho wrote:
interview process
Personally, I never thought very highly of the google interview process. I know of one person that claimed to be a "software tester" with years of experience that was absolutely convinced that something like, "The button has the wrong text" was a valid bug report. No mention of which button or what was wrong with the text or anything else that could possibly be a clue as to what he was babbling about. But he was a "test guru" he was.... and google hired someone like that.
-
It was Colossal Cavern for us!
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
Never heard of that one but unless we were given them on magnetic tapes, they weren't games we'd ever hear about. I used to like the Prime error messages, all of which were prefixed E$. Our favourite was the one for a bad unit number, E$BUNT. Some people we dealt with in support were called bunts.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
-
pkfox wrote:
a three month contract which ran for 21 years.
It took you 21 years to do a 3 month job? :omg:
It was broke, so I fixed it.
-
First computer I ever got to "type into" as opposed to punch cards for was a Prime 400. Then a GEC4070 a week or so later, and IBM 360/195 the week after that and a FR80 graphics processor just after that. They wouldn't let me near the Cray II. :sigh: Industrial training on Uni courses was fun in those days!
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
I'm old too. My first 'terminal' was on a ICL 2900 back in 82. From there I just had fun with one of the earliest PC's, a Commodore Pet(I mean 'Personal Computer', not IBM clone). This was the main Wind-Tunnel workhorse, and the guys had it singing all sorts of tunes through custom hardware interfaces. Imagine real-time pressure distributions from a DOS system? They used it for typing their theses too. I used the good old secretary. She made nicer tea. I got the job in competition with Aeroscrape up in Manchester; Cranfield bribed me away with more money and free flying lessons. Serious perk. As for software, I had a lovely time in Basic; I integrated aircraft performance equations with aircraft component mass equations, then wrote an algorithm that allowed the user to request a basic outline and performance; the programme chased it's tail. If it converged, bingo, you had a design.
-
I'm old too. My first 'terminal' was on a ICL 2900 back in 82. From there I just had fun with one of the earliest PC's, a Commodore Pet(I mean 'Personal Computer', not IBM clone). This was the main Wind-Tunnel workhorse, and the guys had it singing all sorts of tunes through custom hardware interfaces. Imagine real-time pressure distributions from a DOS system? They used it for typing their theses too. I used the good old secretary. She made nicer tea. I got the job in competition with Aeroscrape up in Manchester; Cranfield bribed me away with more money and free flying lessons. Serious perk. As for software, I had a lovely time in Basic; I integrated aircraft performance equations with aircraft component mass equations, then wrote an algorithm that allowed the user to request a basic outline and performance; the programme chased it's tail. If it converged, bingo, you had a design.
Simon O'Riordan from UK wrote:
I'm old too.
No, no, no - we are as old as the woman we feel. Reminds me: must trade Herself in on two 25 year olds...
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
Simon O'Riordan from UK wrote:
I'm old too.
No, no, no - we are as old as the woman we feel. Reminds me: must trade Herself in on two 25 year olds...
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
Right now that makes me ageless.
-
Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess, except for one guy who was highly predictive because he only interviewed people for a very specialized area, where he happened to be the world’s leading expert. (here[^]) Which - to quote a a Scott Adams corollary - suggests it's virtually impossible to hire someone smarter than you, except by accident.
His list of "Interview steps" can be somewhat bend to fit my experiences: - request simple "live coding" to weed out the inept - get them to discuss technology with you - discuss what they did before - do they fit the club? - You really can tell only after a "real" project However, there are some obvious problems with that. "I could tell you but then I'd have to kill you" candidates might not be able to discuss their previous work (might actually be common in certain industries). Cultural fit is tricky, it requires great social skills and tolerance from the inverviewer. A company like google might get away with expecting an "audit" project, most smaller companies will lose good candidates that way. But hey, noone said interviewing would be any easy from the other side!
Yeah, at my interviews I like to see some real code. Particularly if it looks like it didn't come from a book. If I get a sense about the person I'm formally interviewing may have the right stuff, I drag them back to my office and we have an informal chitchat on what they like to do and I show them some of my code and we talk about it. This lets me separate the BSers and @sskissers you normally get in the formal interview from the real deal. I think I've been very successful in this style. One person, who's previous work experience was driving a barcode reader, caught my interest and he turned out to be excellent. Maybe it was that he reminded me of me at that age. I don't believe in quizzing for syntax, that always changes, I want people who understand the concepts behind the syntax. I don't like tests, I'd rather see them use their own methods to solve problems, and you won't see that in an interview. I know I never perform well when people try to dictate my methods, so why should I expect others to be different? Certainly I look for people I think I can work with, but my overriding criteria is, "Does it work?" and can I trust people that say their code works? In a programming team I look to see what each person does best and then leave them to it. I don't expect everyone to be interchangeable. I'll challenge them to move outside their comfort levels, but never on a critical piece of code.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
Yeah, at my interviews I like to see some real code. Particularly if it looks like it didn't come from a book. If I get a sense about the person I'm formally interviewing may have the right stuff, I drag them back to my office and we have an informal chitchat on what they like to do and I show them some of my code and we talk about it. This lets me separate the BSers and @sskissers you normally get in the formal interview from the real deal. I think I've been very successful in this style. One person, who's previous work experience was driving a barcode reader, caught my interest and he turned out to be excellent. Maybe it was that he reminded me of me at that age. I don't believe in quizzing for syntax, that always changes, I want people who understand the concepts behind the syntax. I don't like tests, I'd rather see them use their own methods to solve problems, and you won't see that in an interview. I know I never perform well when people try to dictate my methods, so why should I expect others to be different? Certainly I look for people I think I can work with, but my overriding criteria is, "Does it work?" and can I trust people that say their code works? In a programming team I look to see what each person does best and then leave them to it. I don't expect everyone to be interchangeable. I'll challenge them to move outside their comfort levels, but never on a critical piece of code.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
BrainiacV wrote:
This lets me separate the BSers and @sskissers
I found it amazing and sobering with what coding skilles people can make it through a formal technical interview. A trivial problem (i.e. with a complexity of roughly FizzBuzz) is usually sufficient. The latest modification (only tried once, successfully) was instead of "write a function that does X" *handing them a function (printout in that case, though google in reach seems ok) and asking "tell me what it does, and what's wrong with it".
BrainiacV wrote:
I don't expect everyone to be interchangeable.
I think everyone should be allowed and able to change every line of code - that's your insurance against wolf attacks. However, this still allows for personal responsibility for particular modules, and placing people where their expertise is can improve throughput a lot. Conway noted that the structure of software follows the structure of the organization writing it. I'd go even further: Often, software structure follows individual skills.
-
I've got years of real experience and in the last year I decided to look around for a new position. I've been at my current position for over 12 years. I ended up having some technical interviews and I have discerned a pattern of them. When you interview for a C++ position you will always get judged on how you understand elements of the language you will never use in real work. I have a special sarcastic fondness for the questions regarding dynamic casting of polymorphic nested classes with a common function. Second comes the sarcastic fondness for the design pattern questions. I've decided that in the future I will just cut to the finish line and tell them "Listen, I've got the experience to research my work and do it the best way possible. I haven't memorized the API of the STL and I suck at templates. If you have me write live code I will probably make a mistake and anyway no one works that way on the job so why do you wish it?" Having said all that I will show them my online catalog of open source work on fairly large projects and tell them they need to gauge me based on my portfolio.
Andy Bantly wrote:
When you interview for a C++ position you will always get judged on how you understand elements of the language you will never use in real work
Not necessarily. There are some code bases that use those features. When combined with earlier questions about more basic aspects, its also a way of measuring the depth of knowledge the candidate has.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Andy Bantly wrote:
When you interview for a C++ position you will always get judged on how you understand elements of the language you will never use in real work
Not necessarily. There are some code bases that use those features. When combined with earlier questions about more basic aspects, its also a way of measuring the depth of knowledge the candidate has.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
There are some code bases that use those features.
And there are some code bases that use embedded assembly as well. However miniscule esoteric data says nothing about what a programmer will normally be doing day to day. And that is what matters.
