No Shortcuts, No Mercy: The Bloodsport Of Recruitment

One year ago I wrote an article called "Why The New Guy Can't Code," about how the industry-standard process for hiring software engineers is broken, shortsighted, and counterproductive. It remains my most-read TC post. Of course, I was far from the first to say so, and even farther from the last; every few weeks a similar rant bubbles onto the home page of Hacker News.

And yet recruiting remains broken. When I wrote that post I imagined that in the subsequent year some sharp startup would come along and turn the game on its ear — but no. A few have tried: Gitalytics, which tries to use Github data to identify good engineers; Gild, which acquired Coderloop last year and is still going strong; and especially StackOverflow Careers, which leverages the software world's most indispensable site to match employers and employees. But I think it's fair to say that all the contenders so far serve as adjuncts to the traditional recruiting process, rather than replacing it with something disruptively new.

All of which adds up to today's very weird situation: there's a desperate talent shortage across the industry, but at the same time, employers are so terrified by the prospect of ever hiring a subpar engineer that the recruiting process has become increasingly gruelling and time-consuming, even though there's little evidence that the standard interview gauntlet identifies good engineers.

Of late I'm getting more involved with recruiting myself. (My day job is at the software development shop HappyFunCorp; we're hiring.) And, pending the arrival of that hypothetical revolutionary recruiting startup, I have a modest proposal: stop worrying so much about hiring, and start putting your HR energies into firing.

There's lots of good advice out there about how to hire people. Chris Dixon's is particularly excellent, and I liked Brad Feld's followup, and Mike Lee's take too. Pithiest of all is Pat Maddox's:

1. Filter out candidates who don't have a github / blog / portfolio
2. Pair with remaining candidates

This is indeed an excellent reason to pair program. But even that only teaches you so much. My preferred solution to most of the angst of hiring is actually quite simple; once you've identified a candidate with potential, find some relatively bite-size, self-contained subproject–some nice-to-have feature, some technical debt that needs paying back–and hire them on a moderately-paid contract basis for the few weeks required to complete that task.

Then keep a close eye on their code and progress in that time. Now you have a good sense of how they work, and how well they work: and if you're not happy with what you've seen, just swing the axe and (effectively) fire them, by not offering them a longer-term position. Good candidates won't mind this extra step, because they know they'll cruise through it…and because they'd rather do actual work than spend days being interviewed.

When you change the mindset from "be paranoid about who you hire" to "try out anyone with potential, and dump them like a hot potato if they don't pan out," the recruitment process becomes vastly simpler and less stressful for all parties. Just remember to check their references. And while you're at it, verify the rest of their resume, too.