Why is hiring broken? It starts at the whiteboard.
Quincy Larson

I agree with you entirely, and have been saying similar things for years.

The great irony of interviewing with Google is that the answer to so many questions they ask really is, “I have no idea. If I need to know, I’ll Google it. Before there was Google, I had a shelf of awesome reference works…which I rarely referred to, not because I’d memorized what they had to tell me, but because they were rarely actually relevant to my job!

In fact, since the chances of my ever actually having to implement my own B-Tree are exactly nil, because it’s been done three billion times in every known language and I have no need to do so, it’s a stupid question, and your smug sense of superiority in asking it is nothing more than hazing.”

OK, so that’s a bit of a long winded answer, but it’s what I wanted to say, several times, and never quite got up the courage, when I interviewed with Google. Twice. I keep hearing that they’re going to do away with that kind of interview, and I keep hearing they’re still doing it. But there are always enough people actually eager to work for Google that they’ll find what they want that way, even though it’s actually a terrible way to identify software engineering talent.

Now, I have had interviews where they asked me to sketch out solutions to a couple of real issues pertinent to their work. One where they told me the basic schema of their actual database and said, “How would you solve ${PROBLEM} efficiently given that database structure? And yes, adding to or modifying the structure is valid.” That was fine — they didn’t expect perfect, runnable code on a whiteboard; they expected ideas. That’s awesome.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.