I’ve been developing software professionally for six years now, so I think I have just about enough experience to talk about the interview. In that time, I’ve been the interviewer many more times than I’ve been the interviewee and I’ve come to the conclusion that interviews suck.
The idea of an interview is to try and work out whether a candidate is a good fit for your team. There are usually three things that you look for when interviewing:
The problem is that an interview is very good at weeding out a lot of the obviously bad people but is really poor at sorting the average candidate from an extraordinary candidate.
And it is common knowledge that extraordinary programmers are much better value for money than their much maligned mediocre counter-parts.
So the question is, how do you find the extraordinary programmers?
When looking for a potential programmer, you should try to find someone smart. Someone who is not just smart but smarter than yourself.
The problem is, this is a really difficult thing to asses in an interview. The problem is that knowledge and smart are not equivalent.
Then someone had the idea of setting little problem questions that the candidate would have to solve right there and then in the interview. The thinking goes, if they could solve these bizarre little puzzle, then clearly they must be smart and thus a good programmer.
Completely wrong.
The problem is that the answer to the puzzle is not the answer you’d want to hear from a real developer. For example, the title of a book about the puzzle question culture at Microsoft has the title: How would you move mount Fuji?
How would I move mount Fuji?
I wouldn’t try and move it at all. Moving a mountain has never been attempted by anyone, ever. Any attempt to move a mountain would likely run vastly over budget. It’s likely the technology doesn’t even exist to do this in an environmentally friendly way; although the Russians did happen to experiment with nuclear weapons in civil engineering. Why do you want to move the mountain anyway? There’s probably an easier way to do whatever it is you want to achieve and it will almost certainly cost a lot less money.
That is the answer I’d expect from such a question but no candidate will ever give you that answer. They’ll try and solve the little brain-teaser you’ve set them because they believe that’s what they’re meant to do.
Then you get the questions that are nothing short of comical: “Why are man-holes covers round?” Well, if you don’t live in the United States, there’s a good chance they’re not. There’s literally thousands of square man-hole covers in my town alone. The cretin that came up with this question didn’t realise that you can prevent the cover falling down the manhole by simply making the cover slightly larger than the hole it covers.
The people you are hiring are not logicians, they’re engineers. You want them to think like an engineer. Being able to solve what is, in essence, nothing more than an elaborate Sudoku does not make you a great programmer. You might as well hire crossword competition winners!
Most programming applicants can barely code. It’s common knowledge that setting even simple problems, like FizzBuzz will filter out 75% of applicants. FizzBuzz is great for filtering out the crappy candidates but we want to find great candidates. Assuming your candidate passes the FizzBuzz test, what do you give them next?
There is a tendency to lurch to “Implement Quicksort on the white-board” type of problems.
Why would you get them to write code on a white-board? That isn’t how a programmer normally writes code! You can’t execute scrawl written on a white-board. Code written on a white-board is likely to be chock full of errors that nobody in that room spots.
Even if you got them to implement at their computer, I find asking these sorts of problems as odd as asking a research chemist to recite the periodic table. It may show that you’ve got an interest in chemistry but that doesn’t in any way tell you if they’re up to the job at hand.
Presumably the reason why you’d want them to implement Quicksort is that you want the candidate to be aware of the difference in run-time complexity between Quicksort and other slower sorts. Why not just ask them which sort they would use?
Ultimately, we want an engineer not a logician. If I had to choose between a person who knew nothing about run-time complexity but routinely profiled his code and a person who knew how to prove Euclid’s GCD algorithm has a worst case running time of n2 but never used a profiler - I’d take the guy who uses the profiler.
I’m not beating up on just Quicksort here, I’m taking about the whole shooting match; tree traversal algorithms, red-black trees, data structures etc. This stuff is certainly interesting but it’s not at all useful in most programming jobs.
I’ve never implemented any of these things in my career and I suspect this is true for most of the development community. If I was asked to implement it, I’d just look it up just like I’d look up any other algorithm.
So what should you give them if you want to know if they’re up to the job?
Where I work, we get them to use one of our products. We give them a couple of hours and get them to integrate with our web-services platform. They’re producing the very code our customers would be producing; they’re solving a real business problem that our customers have. This is infinitely more useful then getting them to implement something like Quicksort.
The most important attribute of a developer is their personality.
A person whose smarts are matched only by their laziness is completely useless to you. A person who lacks attention to detail is completely useless to you. A person who has no capacity to learn by their self is completely useless to you. A person who is an ass is.. well, I think you get the point. Even if they are none of these things, they could just be a poor fit for some other reason entirely unrelated to their aptitude.
This much is obvious. These are things you can’t really judge until you actually work with them. Yet this stuff is what distinguishes a great hire from a poor one - yet the interview gives you no way to assess any of these important traits.
Just like the GOTO statement, interviews are not inherently bad. Properly deployed, they are useful. The best way to use an interview is to do a final sanity check on the candidate before offering them the job on a trial period. You then use the trial period to assess the candidate’s fit with the team.
The trial period must be a trial period though. Too often, inertia sets in and there is a strong temptation to throw good money after bad. If the person stinks, it makes sense to get rid of them as fast as possible. You must have no qualms about firing someone who is sub-standard.
The interview must contain a programming test of some kind. This programming test must be relevant to what you actually develop.
A team is built around a shared sense of purpose and a shared sense of pride in what they do. Therefore, it must ultimately be the team the candidate works with who decides whether they stay or go. If anyone black- balls the individual then the candidate will have to go.
If this sounds expensive, well I guess it is. However, compared to the cost of getting hiring wrong it’s a bargain.