rss feed

blog - the power of code samples in interviewing

posted by witten on May 30, 2007

My admittedly rambling post the other day about not hiring "rock star" programmers (http://coderific.com/blog/post/564) generated a fair amount of feedback, both positive and negative. So I thought I'd go a step further and outline exactly how I recommend looking for good, non-rock-star programmers. Fortunately, Giles Bowkett has already done this for me (http://gilesbowkett.blogspot.com/2007/05/programmer-interviews-two-warning-signs.html):

Giles then goes on to say:

I completely agree with this way of judging programmers. But why is this a good approach for accurately assessing the schmuck who you've brought in for an interview? Why isn't it sufficient to simply ask about the running time of heap sort and have the candidate solve a few coding problems on the whiteboard? Well, let's look at the criteria you should be using to judge any potential hire. To quote Joel (http://www.joelonsoftware.com/articles/fog0000000073.html), the criteria for getting hired at Fog Creek, and therefore implicitly the criteria the whole programming world should be using for hiring someone are:

I'd like to propose a third criterion:

It doesn't matter how smart you are and how good you are at cranking out code. If you're a complete and utter asshole, if you don't play well with others, if you're just not a good cultural fit for the organization, then you'll drag down the team rather than improve its productivity.

This is why it can be helpful to read the blog of any potential software development candidate. By doing so, you can at least somewhat get a sense for someone's personality, how they think, what their cultural proclivities are. Hell, whether they use vi or emacs. You won't get any of this information by asking a candidate about Ruby operators or how to implement Floyd's cycle detection algorithm. If you don't somehow test for a candidate's cultural fit, you could very well end up with a submarine asshole on your team that only surfaces well after their start date.

Okay, so that's one reason for reading someone's blog and/or undertaking any other means you can think of to scope out their potential "fit". But what about looking at a coder's code?

One of the most successful ways I've found to accomplish this task is to ask for a code sample before the interview, and then actually go over the code with the candidate during the interview! All you need to do is ask for some relatively small, self-contained piece of code that solves a non-trivial problem.

This is a much more realistic test for exhibiting coding prowess than some sort of artificial string manipulation problem. Additionally, and this is a hugely important point when performing any interview, it tends to put the candidate at ease to talk about their very own pre-written code, so they're not sweating bullets and thereby giving you an inaccurate reading.

When you do go over someone's code with them during an interview, here are the sorts of questions to ask:

Basically, ask all the same sorts of questions you would normally ask after a candidate solves a stupid string manipulation problem on the whiteboard, but instead ask those questions about the candidate's own pre-submitted code, written on a proper computer with the use of a proper compiler.

Now one variation on this approach I've seen is asking all candidates to submit a program to solve the exact same set of requirements, e.g. implement Tic-Tac-Toe for two players (no AI). This is dumb for many reasons, the most prominent of which is that any programmer worth his salt is not going to waste the time writing some completely new code just on the off chance that you'll bring him or her in for an interview. Only the desperate programmers will spend their time doing that. So by putting such a psychologically sizable hurdle smack in the middle of your hiring process, you're almost ensuring that you'll only get crappy candidates.

On the other hand, if you ask for a code sample of something the candidate has already written, then the good coders will be happy to send you some of their best existing work and will love to talk about it in detail during the interview. It takes very little effort to dust off some already written code and send it out, at least compared to implementing a code-sample-worthy Tic-Tac-Toe from scratch.

One objection to this whole scheme is that some candidates don't do the whole open source thing and simply don't have any code available that's not under NDA or what have you. For these candidates without any existing code to send you, you can always give them the option of a standard problem for them to code up before the interview, although for the love of all that is holy, please don't choose Tic-Tac-Toe.

2 comments

Write a comment!