Why you should only interview hackers with side projects

Posted by Antonio 9 months, 3 weeks ago (Oct. 11, 2009)

The irascible Ted Dziuba, who I'd been reading for a while for his incisive commentary on the echo chamber of the blogotwittersphere, falls into the trap himself with his latest post on why he doesn't code in his free time, and why he finds people who make that part of the hiring criteria misguided.

First of all, I suspect he is not telling the truth. Not having met him it's hard to know, but Ted smells like the real deal, and in the era of open source software where you can easily peek under the covers of just about anything you might be using, anyone who hasn't had a side project at some point or another is probably heading for a QA job in India, or just plain took a wrong turn in the "suits and hackers" line freshman year (and is now bitterly rueing that day.)

But more importantly, everyone knows that interviewing programmers is more art than science, and that most of the big-ego style questions that the swinging dicks at Google like to ask to remind themselves of just how smart they were when they got hired ("Oh really, I couldn't clear 1580 on my SATs no matter how hard I tried!") are at best poor proxies for one of the many skills required in a great engineer. Which is why having the background of a side project to talk about (ideally one which is a real open source project that more than one person uses) provides a really rich context for assessing all of the other parts of an engineer's craft.

And I'm not saying this as some arrogant twenty-year old who is looking for a way to build a tribe of equally arrogant and uni-dimensional people, but as middle-aged overhead whose main interest is finding those rare gems that are 5x or maybe 10x better as hackers than the run-of-the-mill folks who worry about work-life balance and fixing their hogs on the weekend.

blog comments powered by Disqus