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.

3 thoughts on “Technical Interviews

  1. Do you get them to write any code? That also addresses questions 1 and 2. Maybe even question 3, if it’s pair programming!

  2. Hi Todd,

    No – John DeRosa’s article (see link above) really struck a chord with me. An in-interview coding test is a very artificial scenario that doesn’t necessarily measure the key points you’re looking for.

    Some companies give candidates a take-home coding test, but these are labour intensive for both the candidate & the hirer and are really only viable for large companies that have a lot of eager applicants.

    Ideally developers would carry around a portfolio of code they’ve written & system architectures they’ve designed that they could give to prospective employers, but the IP arrangements for software being what they are these days, this is fairly uncommon.

  3. A take-home coding problem would be a lot better than an in-interview test. But unfortunately I think you’re right, it’s not really appropriate to ask that of candidates unless you are a Microsoft or a Google.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s