Hiring humans is a frustrating process. Trying to hire developers often even more-so, over the years I have found a few ways to make this less painful.
What Doesn’t Work
We try to gage developers skills using a lot of insanely ineffective ways. All of these techniques lack one of the most important parts of development, the human <-> machine feedback loop.
- Timed Code Puzzle: is probably the silliest of the interview styles. It creates undo stress, and unless your day to day workflow involves a timer… your interviews probably shouldn’t.
- Whiteboarding: is the most common format, and probably the least offensive one. I think that whiteboarding simple problems has very little to do with real development, but at least it is reasonable.
- Firing Squad: is where a group of developers conducts a group interview, this seems to cultivate a very toxic interview style filled with “gotcha” questions.
- Brian Teasers: is probably my personal favorite (of the ridiculous), but mostly because I love Fermi style problems. How many golfballs can fit in a schoolbus? These are irrelevant and tend to be more about the ego of the interviewer rather than finding the value of the candidate.
- Paper & Book: is overall, the “best” of the bad ideas. Given a sheet of paper and a reference book, allow the developer to write out a solution.
Prior to the interview
The job description and marching orders to recruiters must make it exceptional clear that the role is of a developer. Transforming data by writing code. The goal is to scare off any people who are not actually developers from actually trying to get the role and wasting your time.
Interview 1
Do a basic / fun interview — no coding! Talk to them about experience, talk to them about how they would attack problems I have dealt with in the past, see if they feel like a good fit. Keep it brief. If they seem like a good fit, tell them the next step in the process is to do a code sample… you don’t care how they do it. Make it a bite sized task… 4 hours averaged… and tell them you will pay them $500 for the code sample. So now it is paid work — if they are awesome, it might even be a decent hourly. Leave it very “open” in terms of what they do… testing, code style, etc — don’t specify anything. Do let them know that it will be code reviewed in front of a group, and you expect every line to be understood… do you really care if they take demo code they find online if they understand it intimately, the license is fine and they can explain 3 other ways to do it — I know I sure don’t.
Interview 2
When they come in for the 2nd interview (the long one), the first thing I do is hand them the cashiers check for $500 and thank them for that part of the process — so they know whatever else happens that is locked in. Even if things bomb out horrible, they got $500 — also, it sets a really awesome tone.
Then, do a group code review, basically ensure they understand it deeply (and they wrote it, if they steal from the internet, they look like idiots at this point… ask for alternative designs, what else did they try)… check if their style fits with yours… you will learn a TON about if they are good fit going over that code. Ask them why they did or didn’t do things — again, it is their own code, they SHOULD be super comfortable with it… even if it is crap, it should be crap they are comfortable with… their own crap. You will learn SO MUCH in this process — you can of course forgive nervousness… but are they defensive, do they take constructive criticism, does the team like them, etc.
Now, at the end of code review, give them “a tour” for them to take a break, look around, get some coffee, go outside and smoke, etc. Your team gets to chime in, in private, and most developers (who have been through code review themselves) will be more “balanced” than they would in a firing squad of quiz show format. They have written crap code, they have been reviewed harshly in front of others, they understand the balance of time, ego and quality at play.
Make an appointment with them to give them the hire / not hire decision. This is IMPORTANT, developers hate being left not knowing… if you leave them black-holed, you have burned that bridge… while they might be the second best candidate, call them and talk to them for a moment. It isn’t much effort, and it might make them consider your company again in the future… or if the best candidate gets a better offer. Remember to call the “hire” last, cause that phone call tends to go long.
That is my patent pending (joking… I realize being system for hiring developers who I love to work with (and many of them have become life long friends).
Updates
- 2015-09-22: Other companies are starting to do the same thing (with slight tweaks)
- 2014-07-04: I have gotten some feedback about $500 being far too expensive. I put forth it is exceptionally cheap, Zappos offers people $3000 to pass on the job offer. Avoiding a bad hire for $500 is an easy decision.