grilling them with technical questions that must be answered correctly.
Dont hire anyone who hasnt accomplished anything. Ever.
Jon Evans is the CTO of the engineering consultancy HappyFunCorp; the award-winning author of six novels, one graphic novel, and a book of travel writing; and TechCrunchs weekend columnist since 2010.
Quickly filter out the technically inept by asking half a dozen basic technical questions Atwood calls this the FizzBuzz filter. Ideally you can do this online. Youll be amazed how many people fail. (If theyve been recommended to you, you can skip this step.)
My headline here is more aspirational than descriptive, I admit: the technical interview isnt deadyetbut it should be, and soon enough it will be. What baffles me most is why its taken so long. The whole purpose of an interview was to serve as a proxy for actual performance, because we didnt have the tools and infrastructure to easily observe and measure the latter: but now that wedo, it is the height of cargo-cult stupidity not to use them. Stop quizzing people, and start finding out what they can actually do.
Many of the comments on that year-ago post were very angry. Nobody likes to be told that theyve been screwing up the most important part of their business (and recruitment is almost certainly the most important part of your business) since Day One. But the sooner people realize that the traditional come in, answer random quiz questions, and write code on a whiteboard model is horribly broken, the better off theyll be. If you click through to and read the above, youll find that theyre mostly minor variations of a much-improved process:
You know what else is an artificial environment that doesnt translate at all well to the real world? Thats right:the entire technical interview process, as traditionally performed. Its not just brainteasers: its the fundamental concept of being brought into a room, grilled on the spot with technical questions that must be answered without any of the usual resources, and then being made to write code on a whiteboard. All this on the nonsensical pretext that its a decent measure of whether the candidate is a good software engineer.
The process has to be attractive to developers, too, in this sellers market. (I sometimes wonder how many goodengineershave been put off by Googles previous, rather insulting, hoop-jumping interview process; me and most of my techie friends, for starters, but thats probably a self-selected group.) Fortunately, better than the old way is a very low bar, and most good developers casting about for a new gig would far rather work on a real paid interesting project for a week than spend a day regurgitating code on a whiteboard.
If a developer doesnt have a portfolio they can talk to you about, not even any side or pet projectsthen dont waste your time talking to them at all.
Allow me just a little self-congratulation. Two years ago I wrote Why The New Guy Cant Code, about my contempt for the standard industry interview procedure for software engineers, condemning Microsoft and Google in particular for theirandbinary searchquestions. And lo and behold, this week Googles head of HRadmitted: Brainteasers are a complete waste of time.
Im lucky: Ive always been quite good at this arbitrary and ridiculous skill but at the same time, its requirement has always seemed so obviouslywrongto me. Nowadays, though, finally, more and more voices are being raised against this madness. I give youJeff AtwoodUdo SchroeterNelly YusupovaJosef Assad, and especiallyTreehouses recent poston how to hire developers. Oh, and, er, me,a year ago, saying much the same thing.
Above all, discuss their past projects, how they got them done, and the decisions they made en route. Maybe have them talk you through some of their code on Github. To reiterate my own line:
The Technical Interview Is Dead (And No One Should Mourn)
But wait. Lets just unpack that interview a little further:
This process is better for everyone. Employers learn far,farmore about potential employees; waste less time in interviews; and get them an excuse to pay people to do all those little beneficial things that would otherwise be back-burnered indefinitely. The only real problem is that it doesnt scale. Google, for instance, would need to find literallythousandsof one-week audition projects every year for its candidates, which is probably not realistic.
Try to establish cultural fit although be very careful that youre just talking about
GPAs are worthless as a criteria for hiring, and test scores are worthless Your ability to perform at Google is completely unrelated to how you performed when you were in school, because the skills you required in college are very different Academic environments are artificial environments. People who succeed there are sort of finely trained, theyre conditioned to succeed in that environment
Finally, if theyve gotten this far, give them an audition project. Something relatively bite-sized, self-contained, and off-critical-path, but a real project, one that will actually ship if successful. Hire them on a paid basis for a week or so to build it, and keep a close eye on their code and progress. (If you do pair programming, have them pair with your existing team.)
Talk to themin person if theyre local, voice-only if theyre notabout technical problems theyve faced, tools they use, decisions theyve made, pet peeves, etc. This is the behavioral interviewing that Googles data shows to be actually useful. Note, however, that while youre discussing technical concepts, you are
culture, eg enterprise vs. startup, and that this doesnt lead to subconsciously excluding people who arent just like you. Dont become a frat full of brogrammers.
Zcash: life on the crypto roller coaster