Interviews, Interviews

tl dr; This article on Hackernews.

Its a Sunday morning and you're out shopping. You're buying milk and cereal when you happen to meet this person. You start talking to him and well, he's no different from the average Indian engineer. (To be honest, it really doesn't matter if you're from an IIT or a local college in Assam. All Indian engineers are the same. Blog on that later.)

You start talking about life in the city and your respective universities and how long it's been since you left college already. Oh, he's just another one like you.

But then, he tells you he works at Google, and suddenly, you have this new-found respect for him. Till now, he was just another guy. But now? You've given him a near superhuman status because he was hired by Google.

Buuut wait. Should you be? 
Google hired him, yes. But.
Did they hire him well?
Was he really what they were looking for, or was he just another one of those people that could solve puzzles and recite red-black trees off the back of his mind?

Articles on how CS trivia interviews suck so much keep coming up on hackernews, and I'm glad they do. Because, that is the basis of selection, and it is completely terrible.

Companies need people that can build a zoo, but they hire theoretical zoologists who know the exact dimension of every toe nail of each animal known to man kind.

But then here's the thing. Google can afford to hire petrochemists to work at a petrol pump, pay them enough and keep them happy - even if all they're really doing is filling gas or fixing punctures for every other car.

I can't help but quote pjligato's posts. Here are a few.

"CS trivia interviews select for people who know the mathematics of computer science, not for people who know how to ship robust software systems on time and within budget. The two are only loosely related and mostly uncorrelated.

In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. Just because someone can recite algorithms and data structures in their sleep doesn't mean they can effectively scope, plan, or execute a complex software dev project; and conversely many of the best engineers either never learned or long ago forgot the details of the CS.

This mode of interviewing is like interviewing the contractor you're considering to remodel your bathroom by handing them a pile of iron ore and asking them to smelt high grade structural steel out of it.

So why do they do this? Lack of any better option. Their previous "brainteaser" style interview didn't work at all, and this is probably marginally better than that at finding good engineers. But more importantly, it's much cheaper and faster and less risky in terms of confidentiality than hiring candidates as temporary contractors for a real world test doing actual work, which is the only remotely effective way to tell who is actually a good engineer."

"If you can drive, you probably have a pretty good idea of whether a car or a truck or a motorcycle or a tank is the best vehicle for a particular transport application, and you can probably actually drive all of those with minimal practice. That doesn't require you to know how to build a car, a truck, a motorcycle, and a tank from scratch. That's a different skillset.

Google pays far above market rate, so they have the luxury of hiring petrochemists to work a gas pump. Even at Google, once all the shiny is stripped away, most of the projects are simple CRUD."

There really isn't a better way. Here's what Google always says. Its okay if you miss some of the good people here and there, but you can't miss hiring the best. I've thought long and hard of how hiring can be made better. There really isn't a better alternative to this when hiring 10 people out of a list of 10,000.