I’ve been interviewing candidates for developer positions for over a decade now.  In my early years I was very much hit and miss in terms of finding the right people and it wasn’t until a horror hire that I realised what I was doing wrong.

Previously, and like so many other people I’ve seen, I would interview candidates by looking at their resumes, asking questions about their history and experience and basically trying to get a feel for the person and how they’d fit in the team assuming that if they could talk about programming reasonably well then they must be able to do it as well.  Then, assuming that conversation left me with a positive feeling, I would do the reference checks and make a go/no-go decision.

This resulted in a success rate of maybe 60%, though I may be flattering myself here. But 60% isn’t great especially when you consider the costs of a bad hire.  Even so, the bad hires I made I wouldn’t call shockingly bad, it’s just that they weren’t up to the standard I was aiming for.  At least that’s what I thought until I made a really, really bad hire.

This guy was special.  He was listed as being a .NET team lead, he talked about his history and skills really well, he was engaging and confident, and his references came back glowing with praise so I decided to offer him the job.  This he duly accepted and started shortly thereafter.  Now one of the things I was doing with new hires at the time was getting them to work on bugs – it helped me knock down the backlog and gave them exposure to a variety of areas across the system.  I also gave them plenty of time early on to learn the ropes and get up to speed and it would typically take a few days to get through the first few bugs and start having some ah-ha! moments with the codebase.

So anyway, this particular person starts and is given his first bug.  Quite a simple bug too and yet it took well over a week for him to get it done and even then he needed plenty of help and prodding along the way.  I was also getting complaints from the other developers that this guy was hopeless and a really bad developer which I couldn’t quite believe so I decided to take some time, sit down next to him and do some pairing.

What a shock I got.  It soon became all to apparent that the guy couldn’t program to save himself.  He… literally… couldn’t… code.  At one point I was breaking down the task to fix the bug into very, very small steps and asked him to put in a simple for loop and he just stared at the screen completely blank.  So I asked him what the syntax was for the for loop thinking he was stuck thinking about the larger problem or that he was freaking out with me being next to him growing ever more frustrated.  He couldn’t do it.  He simply couldn’t tell me the syntax.  Not even when intellisense was doing it for him.  How about a while loop?  Nope.  An if statement?  Only just. It was absolutely frightening. How could I get it so wrong?!  I couldn’t believe I’d made such a monumental screw up as to hire this guy.  I also couldn’t believe that the references about him were so great.

Then the slow realisation dawned on me that I’d been lied to. I know – I’m quick off the mark aren’t I? :-)  Imagine someone lying on their resume! The shock of it! Imagine someone getting their friends to pretend to be their former employer and giving them great references. Silly me.

So what was I to do? I remember an article I read around that time from Joel Spolsky that made me slap my forehead.  It basically says if you want to hire a developer, get them to do some code in the interview!  I couldn’t believe I’d been so short sighted as to not do this before.  Gah! Sure, people can lie on their resumes and get their friends to lie for them as well but when you see someone write code, there’s nowhere to hide.  You can either develop or you can’t.

So from that point on I got people to do a debugging exercise.  I figured if the code was there, then all I’m really doing is getting them to read code, understand it and make a few changes.  Pretty much like normal development :-) So I got one of my team to devise a small program that had a number of bugs in it.  You would fix one, uncover another, that sort of thing until you got it working; and all in about 30 lines of code.  When I was given with the code I debugged it first time in a matter of minutes and then used the time it took as a guide to estimate the skill level of the people I was interviewing (with judgement applied based on how nervous they were).  I’ve been using this same test, with various amendments for language changes and so forth for quite a few years now and it’s been a fantastic aid at helping me weed out those who can code and those who can’t.

So just recently I was asked to help another company vet some candidates for a role that didn’t need as high a calibre of person as I normally look for, just a competent one instead, so I figured my debug exercise might prove a little too challenging for the level I was looking for.  I figured that as a change I’d use something simpler try out a variation of Jeff Atwoods FizzBuzz test.  I figured that if the candidate got through that quickly enough then I could always whip out the debug exercise and see how they went with something a little tougher.  Unfortunately I never got past the FizzBuzz exercise since by the time they finished it they’d killed all the time I’d set aside for it (and maybe a little more).  Was I surprised at this? After all it is a pretty simple coding exercise. Well, as it turns out, No. Not really.

If you have a look at Atwood’s post and even the earlier Reg Braithwaite post then in them you’ll see that they both quote this statement “I’ve come to discover that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.”.

How very true.

By doing the fizzbuzz exercise for real, I merely confirmed what I already knew from my experiences with the debugging exercise. So, what’s the lesson here? I think it’s simple. Get your candidates to write some code during the interview.  You don’t need any special tools to do it either – just use a whiteboard and pseudo code if you want to.  But whatever you do, make sure they prove to you that they can actually do the job, not just talk the job.

Remember: There are plenty of developers that just simply can’t develop.  Avoid my mistakes and do what you can to avoid hiring the wrong people.