On qualifying programmers – How to cut through the technobabble, voodoo and fear

So the time has come yet again to hire a programmer. My concern in this article is vetting their ability to write software. There have been many absurd pop methods of doing this like asking “golf balls in an airplane” or “you’re trapped in a blender” questions.

In electronics the path of least resistance will be taken. In philosophy Occam’s razor shows us that the least complicated statement is the likely statement. An old designer’s adage is that perfection is reached not when there is nothing left to add but there is nothing left to remove. Hopefully, my method is aligned with all of these facts and wisdom.

There is one simple thing you need to do to qualify a programmer as capable or not. Of all the programmers I’ve interviewed, and the interviews I’ve been in, only one pure and simple solution has shown me what qualifies them or not. It’s common-sense but for some reason it’s not common-practice. Are you ready?

Don’t exclude them from this test because of anything to do with your preconceived ideas about “what makes a good programmer” including employment history or education. Do filter them for some proof they can do the job in the spirit of what I’m about to tell you to do. Don’t throw out the resume solely on the fact they only have one year experience (think of every candidate you’ve seen with a decade of experience on paper who couldn’t hack it).

Once they get to the interview ask them to do their job. Pretend they’re actually on your team. Bring in a member or two from the team. Don’t sit them down at a table to fire questions off at them. Have your team work with this person on a very simple problem that can be done in about an hour. This could be refactoring a report page (this is my go-to assessment, it’s easy and it hits all levels of MVC for most websites if you’re clever about it). Your team is there to mentor and help them peer-program through the problem. Your project manager is there to scope out the change with them. This is an interactive conversation like you have with your team, not a series of checkboxes.

Do: help them find a way around the framework if they’ve been honest about having little-to-no experience with it, or you’ve done something special/unexpected with your code.

Do: feel free to talk about the users and everything your project manager would do to help you yourself scope out a solution.

Do: help them if they’re totally stuck, but don’t give a direct answer. For example, “have you tried linting?” or “You have a syntax error” is better than “Oh, you missed the closing brace on that if-statement right here – points ”

Don’t: type for them unless your only editor is Vim and they only know textmate.

Don’t: force them to code. Ask them how they would solve the problem, put the code on screen, and tell them they’re welcome to change it. Invite them to code, don’t tell them to code.

When it’s over, thank them, and have a retrospective with your team about what you liked, didn’t like, and possibly need to know more about.

That’s it. Just like testing: write the unit test for the thing you actually want to test.