Interviewing

Part I:

Peter Norvig is Director of Research at Google. He’s known for publishing high quality reference and textbooks on AI. His Common Lisp code is widely respected.

From Coders At Work [Seibel 2009, Apress, New York; pp.321-22]

On the topic of hiring the best people for Google:

Norvig: … One of the interesting things we found, when trying to predict how well somebody we’ve hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of your intereviews, that was a really good indicator of success.

Seibel: But you had to do well enough on something else that you actually got hired?

Norvig: Right, so that’s the thing. Ninty-nine percent of the poeple who got a one in one of their intereviews we didn’t hire. But the rest of them, in order for us to hire them somebody else had to be so passionate that they pounded on the table and said, “I have to hire this person because I see something in him that’s so great, and this guy who thought he was no good is wrong, and I’ve got to stand up for him and put my reputation on the line.”

Highlighting the just relevent bits:

“…one of the best indicators of success within the company was getting the worst possible score on one of your interviews…”

Part II:

Take a stand and refuse stupid interview questions.

At a job interview several years ago and despite about 20 years experience, I was asked to write a Fibonacci function. I declined on grounds that it’s easily accessible in textbooks or a quick internet search and therefore a waste of time for an interview.

Yes, I still got the job.

Earlier in my career, having been asked the now infamous man hole cover question¹, I gave a more complete explanation than the “two reasons” that the interviewer was expecting, based upon my knowledge from a technical drawing class in high school. I didn’t get that job.

Having been on both sides of the table, I appreciate the challenges of asking equivalent questions to equivalent candidates, which is required when headcount surpasses a certain size.

But “equivalent” is contextual.

With each month of a tech company’s existence, their landscape changes: e.g., Today, we’re building features A, B and C. Tomorrow, we’re building for stability. Next month, we’ll be adding capacity. In six months, we expect to add partnerships for growth, which implies systems integration. Etc.

So please stick to the issues at hand.

The trade secret argument doesn’t fly. If a business is hiring for specific skills, they should ask focused questions within the subject matter, and this can easily be done without revealing proprietary details. e.g., You don’t have to say how big of a distributed database, which might reveal business objectives or strategy. The interviewer can instead get the candidate talking about factors/issues at various levels of scalability, performance, cost, etc.

If you’re hiring generalists, ask candiates what they know about various offerings within the niche for which the business has a need.

As the interviewee, if asked a meaningless logic puzzle, politely request to move on to more relevant topics.

For situations where recruiters “filter” technical candidates as some kind of gatekeeper, that’s a warning sign. It usually means that the company is growing faster than is sustainable for their size, are delegating too much of this important task which indicates an utter lack of respect, or perhaps are more interested in attaining some 100th monkey self-fulfilling prophecy² than achieving anything useful.

So I call for taking a stand: Please refuse stupid interview questions.

1. See also: If Richard Feynman applied for a job at Microsoft. Another posting there included a line item, “MS rarely asks logic/riddle questions anymore. They’re not a good indicator of a good employee.”

2. The Hundredth Corporate Monkey