Good Hiring: Make Me Work, Not You

Pipelining the interview process

"'Tis far better to reject a good candidate than to mistakenly hire a bad one" should be tattooed on the inside of the eyelids of everyone involved in the hiring for a software development position.

For this reason, the interview process simply must be gruelling. Because of this, you're going to get a lot of candidates passing through (and failing), so the process should be pipelined to minimise the disruption to people involved. Here's what I mean:

Stage 1 is where résumés are received from external sources and vetted by a technical person with a vested interest in choosing a real superstar - i.e. a future team-mate. They should spend no more than a couple of minutes perusing a CV before it goes to the go/no-go decision - you're looking to filter out obviously-weak candidates based on skills, results, and general résumé class. Be ruthless; remember we're looking for people who are Smart, and Get Things Done - CV spelling mistakes immediately rule them out on the first clause.

Stage 2 MUST be a technical test. A killer. Candidates should come out drenched in sweat, with little drops of blood on their forehead. Test that they think like a programmer, not just copy-and-paste code snippets from the web. Test that they really know the language(s) they profess to be good at. Test they understand and can apply a design pattern - and not just Singleton. Look for methodical working, an awareness of side-effects, and evidence that even though they will probably be using pen-and-paper, they are writing clean, maintainable code - because they do it so much it's just unconcious.

Stage 3 - immediately after Stage 2, two employees (again with a vested interest in picking a superstar) go over the answers. Only if things look really, really good do you ask the candidate to explain a few things about their answers. Otherwise, they get shown the door. There is no point wasting time getting someone to explain why they are searching for something by iterating over a List when a Map is the obvious solution.

By Stage 4 things are looking pretty good. Your candidate can talk the techy talk and walk the techy walk. It's time for HR to give 'em a grilling and make sure they can talk to "normal" people, and that they are on the right page with regards to salary expectations and so on. Be aware that HR people are shockers for mistaking "borderline insane" for "very enthusiastic" - so it's a good idea to have a technical person sit in on this interview (even if they never say a word) as a sanity circuit-breaker. Very few people will get to this stage so it shouldn't be too much of a time-sink.

Stage 5 is where you can bring the candidate in one last time and actually introduce them to the team and the project. Draw the system diagram on a whiteboard, and watch for light-bulbs going off behind the candidate's eyes. "POW! I've never used that before, but I've always wanted to!" "ZING! That's a really nice way to solve that problem!" "BANG! I think there might be a better way to handle that!". By the end of the meeting they should be talking like they are a fully-fledged team member.

And if so, then they should be one.