When recruiting an artist like a designer or architect, you ask to see their portfolio. When you recruit a scientist you take a look at the papers they authored. Why? Because they are all professions where the individuals brilliance matters a lot for the results they produce. That is also the case with programmers.

So why do we not spend more time looking at a candidates past programming achievements? The answer is probably due to a combination of factors:

1. Much of the code might be proprietary and therefore not available for the interviewer.
2. Most code is written in collaboration. Many programmers contributions are mostly about fixing and extending the code of others. Not always that telling of their own brilliance.
3. Real life sized programs are really hard and time consuming to read and understand.

Programming Riddles

So how do we get around this? We let the candidate program something for us. Something where the interviewer already knows the problem and as the available time is limited the amount of code produced will be to. So all is fine, isn’t it? Not really. Many times the available time is to short so we resort to creating programming riddles. In fact there are even books filled with these so you can train for them. Another sign that things aren’t perfect is that recruiters encourage candidates to spend significant time on preparations.

We resort to creating programming riddles.

Asking a programmer to solve these riddles is best case like asking a newspaper journalist to write poems, and worst case asking him to solve crossword puzzles. Although they all involve writing words the skills needed to excel are really different from writing a news article. Even if some of the skills are somewhat useful for doing journalistic work poem writing and crossword puzzle solving are still bad predictors of a good journalist. The same is true for writing real software and these interviewing riddles.

Exactly like writing poems totally miss the journalistic side of writing a news article programming riddles typically totally miss one of the absolutely hardest parts of programming: structuring code and data by creating the right abstractions.

Simulating Real Work

The solution, instead of small hard to crack riddles, is to create a simulation of what real work is like as a programmer at your company. For that you will firstly need more time. At least 3-4 hours for just one single task. The task should preferably be void of any domain specific knowledge.

The programming interview should try to emulate real work.

Instead of grading the end result, the interviewer should during the programming process spend time to find out on what grounds the candidate makes their design choices. Just make sure to also leave the candidates alone for awhile every now and then so that they get something done to. From this you will not only learn how skilled of a programmer they are but also how they are to work with:

1. Do they take instructions well?
2. Do they come and ask when the instructions are ambiguous?
3. Are they able to see benefits of doing things in another way then they are used to?

This style of programming interview will also help the candidate to get a feeling of how working with you at your company will be. It full fills the criteria of reciprocity.