Peter Norvig on Google's Hiring Practices

Peter Norvig on Google's approach to hiring: “You can see how hire-above-the-min leads to a precipitous drop in skill level; one we've been able to avoid.”

I don't think I've ever seen a quantitative comparison of hiring strategies before. Of course it's a lot easier if it's possible to quantify a candidate's quality.

(Gavin: “With all the stats available, it would be cool if google could actually point to the person/hire who brought the overall intelligence down.”)

I like to interview programmer candidates. Maybe it's like having a standard geeky conversation except that the context demands that both interviewer and interviewee have extra special focus on the conversation and try harder than usual to be smart (except that there's also pressure not to be an arrogant asshole—take that, nerd!). Ever since Will gave me a neat programming exercise as part of the hiring process at Intell/Agent, I've been a big fan of using take-home programming assignments as the best way to get a feel for the person's grasp of programming. The exercise I use is actually an exact copy of the one Will gave me in 1995 or so, including the Lisp data files. For the past few years I've mostly been involved in hiring C++ programmers, so I throw in some C++ code to read the data.

The exercise takes a good programmer somewhere around 5 or 6 hours, which I think is substantial enough to get a good feel for the candidate's design skills as well as their raw coding ability. The instructions for the assignment and the data include some minor inconsistencies and areas of vagueness which were not originally intended, but which have explicitly not been fixed, so I get to see how people deal with that too (emailing me with questions is a great response, as just one example). HR departments have, at times, not wanted to ask candidates to spend so much effort and time on the exercise, which I think is pretty misguided. It's too hard to judge someone's coding ability without seeing significant chunks of code, and it's not common for people to have a significant chunk of code that isn't legally encumbered in some way that prevents them from showing it to other people (working on an open source project might be one way to solve this problem, but I wonder if there are other good solutions, too).

I used to ask candidates what they don't like about their favorite programming languages, but too often people didn't have any good answers. Which kind of blows my mind, and depressed me enough to create a pain barrier to even asking. Don't forget, every language sucks, man, and if you don't realize that you better start wondering why not. As Steve Yegge says,

The very best Ruby programmers, as with any language, are the ones who can think outside Ruby; i.e., they know its limitations as well as its strengths. It’s extremely uncommon for average programmers or language novices to be able to speak intelligently about their favorite language’s weaknesses, because the language books and tutorials rarely focus on the weaknesses.

One of these days I'll finish my “20 True Reasons Lisp Sucks” post.

Posted by jjwiseman at April 03, 2006 12:35 PM

