Opinion: The proof is in the programming

Otago University head of Computer Science Brendan McCane explains how to spot a good programmer

In my previous column, I discussed the advantages of hiring good programmers. Good programmers are 10 times more productive than poor programmers and therefore it is much more important to hire a good programmer than one who happens to have exactly the knowledge required for the position. That is all well and good, but how can you tell if someone is a good programmer?

First, let me identify the attributes of a good programmer. The most important attribute is a passion for programming. Good programmers love to program. They do it for money. They do it for fun. They probably even occasionally dream about programming.

Second is problem-solving ability. Good programming requires good problem-solving ability.

Third, good programmers are very thorough. Their code is well-tested and they program defensively. These are the three Ps of good programmers: passionate, problem solvers, particular (thorough). Given these attributes, is there an easy way of sorting out the good programmers from the bad? Let’s examine the usual mechanisms for sorting.

Do you need a degree to be a good programmer? No, but I think it certainly helps. I sometimes hear that the topics studied in a computer science degree at university are useless for work in the real world. After all, who ever needs to implement quicksort or a red-black tree in industry?

True, hardly anyone, so why teach those topics at all? Other than just good practice, these topics expose programmers to the notion of complexity and scalability.

Good programmers have a good understanding of the complexity of algorithms. You might think that understanding complexity is only important for advanced applications, but you would be wrong. Consider a typical website with a back-end database. Choose the wrong SQL query to return a result, and it might come at a cost of N^2 in the size of a database, whereas the right query costs only N. Not a problem if you only have a few thousand records, but what if the database has a few million or a few billion records?

What about commercial experience? Do you need x years of commercial experience to be a good programmer? No, but again it probably helps. It helps for reasons that are different to what you might think.

It isn’t the “commercial” part of “commercial experience” that is important, it is the “experience” part. Basically, the more practice you’ve had at programming, the better you are likely to be.

Commercial experience will tell you things that are harder to tell from other contexts though: how well does the person work in a team environment? can they meet deadlines? and so on. So commercial experience can be an indicator of important personality attributes, but it probably doesn’t say much about programming ability.

As such, good programmers often have a degree and always have experience (but not necessarily commercial experience).

Unfortunately, bad programmers some times have a degree too, and a bad programmer with commercial experience is still a bad programmer. So how do we tell which is which? I think the answer is fairly obvious. If you want to know if someone is a good musician, you listen to them playing. If you want a good builder, you look at what they’ve built before. If you want a good programmer, then you have to look at their programs!

There are two obvious ways of getting a look at a programmer’s programs, and in a recruitment situation, I think both should be used if possible. First, remember that good programmers usually program for fun. Therefore, they probably have programs they have written in their spare time that aren’t encumbered with commercial sensitivities (for example an open source project). If such a program is available, an interviewer can ask to have a look.

The second way is much more direct: have a programming exercise as part of the interview process. I don’t mean a blackboard exercise, and I don’t mean the interviewer asking particular questions about programming techniques (for example “Can you explain what the decorator pattern is?”) as I don’t think those reveal much. Better is to plop the interviewee in front of a computer with a non-trivial programming problem to solve.

If you want to find a great programmer, preferably ask for a solution in a language they’ve never used before. But don’t handicap the environment - let them use the same environment they would every day - reference books, internet, language help and so on.

How can you identify a good programmer? Ask them to program.