How to Interview a Developer

Finding the right people to work with on a project is one of the first problems you run into when trying to grow your company. It is absolutely essential that you get the process right (notice how I said the process, not the actual individual cases) because it will determine the long term viability of your team.

When starting the interview, make sure to smile. No, seriously, do it. This applies for any interview where the position you are hiring for isn't "Person to deal with hostile people". Interviews are stressful for the candidates and you can be sure that they are not going to be at their best if you don't do something to help with their nervousness. Some might argue that there is value in seeing how people deal with hostility but at the end of the day, that is not their job. What if the interviewee is an awesome coder but because you have them so nervous, they completely lose focus and perform badly? That is one crucial employee you might have lost because they lack a soft skill you could have helped them develop later on.

Next is to let them talk about technology. I have found that the best programmers are almost always deeply interested in tech. Now, their particular test and area of interest might differ, but usually, this type of deep interest indicates that their interest in being a developer is beyond "this pays well". While geniuses might be able to pull it off with just a mild interest in what they do, those are few and far in between in all job sectors.

So let them sound off, whether it is in an area of tech they are interested in or projects they have worked on. This is the free form part of the interview and will entirely depend on how the conversation goes.

The most important part of the interview is the technical questions section. Here is where you really test the interviewee. You get to see how they think by solving problems.

The first part is make sure it is a question that you are extremely familiar with. The last thing you want is to have a difficult question that is solved by the interviewee but you don't understand how it was solved, at which point you aren't really qualified to assess the performance of the interviewee. The whole point of the interview is not to find out how much of a genius the interviewee is in absolute terms but rather, it is for you to assess how good he/she is. And how can you do that if you can't even understand the question yourself? If a candidate thinks that your questions are too easy and goes through them like a champ, it might be the right call that someone with more experience than you should interview that person. Making that call is hard on the ego but all good in the long run. So, pick a technical question you are completely familiar with.

A great resource for this type of questions is Programming Challenges: The programming contest training manual. This is a great resource because it provides challenging questions from every spectrum of difficulty so that you have a really great set of random questions you can pick from. The only way an interviewee could be familiar with all possible questions is if they managed to memorize the whole thing (in which case, you have a genius on your hand and should hire immediately...kidding...kind of).

Pick 4 questions, 2 easy ones and 2 hard one's. Ask the easy question first to gauge the capability of your hire and if they do well, then ask 1 from the hard set or if they don't do well, ask another 1 from the easy set. This way, you get good coverage of many cases.

If the interviewee struggled with the first easy question, it is possible that it might just be a weak point, so probe with the second easy question. That way, you are giving a fair chance to someone who might be really good but somehow ended up on the wrong side of a question.

When helping the interviewee work through the problem, stand off and just listen to them, ask them minimal question to guide their thinking but other than that, it is their show so let them run it. Your job is to be there and observe, to react when you need to and guide if you must.

When done with the time (invariably, you will have to cut-off the interviewee because of time constraints), make sure to end it with a positive sentiment ("it was great meeting you" type statement) so that they feel more confident going into their next interview since usually these things are done in loops.

Other than these tips, there is no real 1-size-fits-all approach on how to interview. The best interviewers (which does not yet include me) usually change their approach during the interview to match what is happening.

You have to be versatile in how you spend the limited amount of time you have in there so make sure you are not too brittle with your expectation of what to do in there.