The best way to hire a good programmer is to be invested in his or her results. It’s like getting married. You want to be careful to choose the right kind of girl, the kind of girl that you’d want to spend the rest of your life with. Just like marriage, it can make your life as close to heaven or hell as it can get on earth. Here’s how I about it.
1. An Interviewer with Skin in the Game
I insist that someone with “skin in the game” should go about the interview. In other words, this should typically be a person who will have to work closely with the new hire, like a developer on the same team. Such a person will resist the urge to close the interview process with the mediocre hire, because such a hire will have a measurably negative impact on his work.
A manager who’s only job is to fill the ranks with new hires on the other hand is likely to be less selective with the kind of people he hires. A “good enough” mentality can set in quite easily.
2. Doers not Talkers
It’s easy to get carried away with a candidate who’s personable and interesting. Such a candidate is almost certainly going to be able to present their credentials better. There is nothing inherently wrong with that, but be careful not to get carried away with glib marketing talk.
A good way of grounding an interview to reality is to ask what the candidate has done, as opposed to what he or she says she is able to do. This focuses on people who do things, as opposed to people who claim they can. A candidate with real world experience of doing things would quickly be able to talk about instances where their credentials had come to bear on a situation. They’ll be candid about mistakes and what they learned from it. The won’t be ashamed of their battle scars.
The distinction between doers and talkers applies to junior level candidates as well. I’ve had many occasions where fresh university graduates or intern applications have shown marvellous levels of active capability by demonstrating work they had completed in the past, “just for kicks”.
3. Work Together
Perhaps the most important part of a programming interview is the part where the candidate and the interviewer work together to solve a small problem. The important thing here is work together. Much get’s done in the world when two people agree, and nothing when they are at cross purposes.
It’s vital to pick problems that are easy to explain and moderately difficult to do - linked lists and recursion problems are good examples. First I try to make the candidate as comfortable as possible. It’s not easy to solve a problem when your future job might be at stake. I tell them that it’s OK to get things wrong and that there’s no penalty for asking me questions. I tell them it’s all about working together and I explain the problem.
Next I observe how the candidate goes about solving it and wait for good indicators, like the ability to understand a problem quickly, the ability to respond to suggestions with a good attitude and the ability to actually code a successful solution. I put emphasis on clarity of code, small things like intuitive variable names and good code organisation. I give encouragement.
The outcome of this part of the interview process is binary. I.e. it’s either a yes, or a no. There is no maybe. A good code interview leaves you feeling relieved knowing that all the effort you put into finding that single good candidate is worth all the ones that didn’t work out.