Photo: totalAldo via Flickr
And it wasn’t until Zacharias’s piece that I realised that it’s because I’d always used the wrong resume screening and interview approach. Because I’ve recently fielded a load of questions from entrepreneurs who also find this a hard role to recruit and hire for, here is a list of the “don’ts” that I had to learn the hard way:
Don’t braintease them
When you are hiring an engineer who is working in your app tier or further back in the stack, brainteasers are a good shorthand way to test for good hygiene. Logic, efficiency, indirection, recursion— these are all important traits that can be evaluated through a variety of classic logic problems (my favourite, the Pirate Game, tests all of them at once). Plus, you also get to see the candidate think in real time and under pressure, both good proxies for horsepower and what startup life is like late at night.
The problem with brainteasers though is that they’re algorithmic porn and in the best of cases they will fail to test for the right high level traits: tenacity, debugging ability, and the willingness to power through seemingly impossible implementation tasks. And at worse they will make you look like a clueless snob who thinks that Zuck talking about speed chess on 60 Minutes somehow relates in any way to writing the world’s most scalable PHP hack.
Don’t make them whiteboard sessions
Another classic mistake— the old “how about we think through how to implement X” where X can be a persistence layer, a protocol, a state machine, etc. You then watch the candidate sweating through pseudocode to check for design skills. Again this will work for people from the app tier on back, but taking any front-end person through this kind of thing will only result in generic discussions about the CSS box model and the pain that IE 6-X is. In other words, the crap they read on Zeldman’s blog en route to the interview.
At Tabblo we quickly hit the limits of this style of test and realised that a) the time constraint was stupid and b) what really mattered was making sure the candidate had the dogged attention to detail required to make something work across a variety of different browsers. So we settled on a “take-home test” which meant giving the candidate an assignment after the first interview with about an evening to complete (in our case it was an implementation of a dialog box which fades up on a standard page without the use of supporting libraries like jQuery). We named the test the Hausse test after a very polished candidate named John Hausse* who came in with great references spewing all the right jargon about standards-driven web development and then completely failed (for years afterwards, we asked each other if candidate X had “Haussed” his takehome).
Hiring correctly is one of the hardest things a startup can do and the engineering team is the engine room. While the mobile revolution and the resulting return to native apps may make the new front-end hiring process simpler in the fullness of time, there are still loads of web work to do. If you are in the process of that, skip the age-old stuff mentioned above and do yourself a favour by reading the above mentioned Zacharias post.
* The name has been changed to protect the innocent.