Technical Interviews

I’ve recently been doing a few technical interviews with candidates for software developer positions. I haven't done any in a long time and I'd assumed I'd go back and trot out some of the old technical ‘trivia’ questions (“In .NET, is a string a value type or a reference type?” etc). Alternatively, perhaps I’d get organised and do some whiteboard code problems like Joel suggests — however, I came across a rebuttal from John DeRosa that convinced me this approach isn't all it's cracked up to be.

Aaron Swartz suggests you’re only trying to answer three questions in a job interview:

1. Have they done this job in the past?
2. Are they smart?
3. Could I work with them?

I would opine those are in increasing order of importance: experience is easy to gain, skills can be improved up to a limit, but if someone’s a tosser they’re probably always going to be a tosser.

The questions I found I ended up being more useful were the ones along the lines of:

• “What would you have done differently in your last project if you had the chance to do it again/were in charge?”
• “What is your favourite programming language? What do you like about it? Is there anything you would change about it?”
• “What level of documentation do you think is appropriate for a typical software project?”
• “What tools do you think are important for software teams?”
• “Do you like beer?”

The goal is to get the candidate talking about him/herself and have more of a conversational interaction with them. It’s easy to embellish a job history, but much more difficult to give a plausible retrospective analysis of your role on a fictitious project, so question 1 is covered by going over recent work the candidate has done. Question 2 is fairly easy to pick up on during a bit of to & fro — challenging one or two statements they make gives you a good feel for whether they’re parroting conventional wisdom or they’ve acquired a good understanding of the subject. It’s also always a good idea to teach them something and see whether they internalise or dismiss it, as per one of Aaron’s suggestions.

Lastly, a conversation is the only way you're going to be able to assess the answer to question 3. This is obviously a subjective call, but you know yourself & your team and you should get a good feel over 60-90 minutes as to whether they'll fit into the team. I can’t stress enough how much more important cultural fit is than any other consideration. Software development is a team sport.