Don't just interview new developers. Audition them!

It's such a common mistake. A company claims to be "agile" (whatever that is) yet keeps the old, stale accoutrements of waterfall interviews. The developer candidate walks in, answers random questions on what can relate to extremely wide and deep subject matter, and is then judged on their ability without them ever actually demonstrating that they can do the job. Sometimes the successful candidate really can fit in with the team, sometimes not. But most importantly, good, well suited people will inevitably be dismissed as unsuitable simply because they learn the principles and not the detail.

Being a "good" software developer is no longer about memorising a spec. The ability to regurgitate arbitrary sections of a language specification parrot fashion on request, although previously useful, has been de-emphasised by the invention of radical new ways to store information. Like books. And the internet. All you need are the basic frameworks, objects and principles; i.e. you know the bare bones, but look up the detail.

Nor is software development about how you react as an individual to unexpected coding puzzles while denied even the most basic of tools to help you - if the first reaction is "I wouldn't normally solve it like this..." (or worse, "There's a smarter way but you're not letting me use it") then the entire exercise is likely to be pointless. I have lost count of the number of companies who, over the years, have handed me a pen and paper, or a whiteboard marker, and expected me to write a technically correct solution to an abstract problem. No real world example, so it's not real world coding.

Agile teams are about people and the way they interact. It is all about being able to work smart. It is about being able to write good code collaboratively, helped by tests. The recruitment process needs to put more emphasis on interactions, initiative, and ability to process unfamiliar information - the wetware aspect of development. So what if you cannot remember the exact interface to QuadCurve2D? As long as you know it exists and understand the design patterns it is based on you can look up the details.

So how to identify the right people for the job if traditional interview techniques don't work?

Simple. Audition them. Get the candidate actually doing something related to the job they have applied for. Do they look for the right things from the start? ("Where's the continuous integration server?", "Where are your tests?"). Get them down and dirty in the codebase, see their reaction. Do they get lost in the detail, or do they start to tease out the structure with tests? Code with them. Cooperate with them. Can you work with them? Does their coding behaviour fit team culture? How fast do they learn? Are they a craftsman or hacker?

You could even say you are unit testing the developer.

Auditions do require a little more effort, but in my experience they take some of the guesswork out of the traditional interview process when trying to find good people for the team.