Hacker News Reader

Comment by noonespecial | Hacker News Reader

Does it seem the google folks are getting a bit myopic in their interview process? I mean, yes, they have a very focused mission depending on a very distinct kind of software but it just seems like an awful lot of the interview process is finding out if the candidate will yell "merge sort - n(log(n))" at just the right time.

Google's strength was that meandering "lets just work on what seems coolest" ethos. I'm wondering if they're not selecting out some really great talent by making the interview a test of how well a candidate can scribble some common design patterns on a white board.

I'm not saying that they should hire programmers that can't tell a merge sort from a bubble sort, but perhaps just knowing the difference and when to use them might be enough; Rather than finding out if they can write it out syntax-perfect on the spot in the interviewers favorite language.

View on HN

I maintain that being able to implement a sorting algorithm from memory is a cheap trick, and has no correlation with programming ability. I've written maybe one sorting routine since leaving college. Being able to pick the correct one for a certain situation is important, sure, but there are battle-tested implementations available for nearly every algorithm in nearly every standard library.

I'd settle for the interviewee understanding big-Oh notation and being able to explain the complexity of an algorithm, given an implementation in a language they understand. If they can do that, it means they have the skill you're really looking for: that they can detect an unnecessarily expensive algorithm. (Isn't that really what the sorting algorithm questions are all about anyway?)

I would guess that they're also about whether the candidate is the sort of person who is curious enough about the way things work to dig into a sorting algorithm and spend a free Saturday afternoon playing around with it, even though it's in nearly every standard library.

I've been through the Google interview process [I'm not going to blog about it with any sour grapes, I'll try again for a different position later.], and I realized afterwards that it was a lot like map-reduce. You're being thrown through a bunch of interviews by different people (the map phase) who then forward their reports to their hiring committee (the reduce phase). Every interviewer is seeking to do a similar kind of analysis on you: are you worthy of hiring? Then they gather it all together and grind the sausage. They probably interview thousands of people to harvest enough talent to fuel their progress, unlike other organizations that only hire to fill known needs.

They don't tell you why they approve/reject, but I imagine that they probably have a similar process on the other side if you are hired with regards to the package you're offered. Very likely, they'll seek to optimize the right amount to give you.

And yes, I do think they're probably missing out some great talent, because not everyone can scribble it out on a white board on-the-spot. But you have to be able to communicate effectively to get anywhere, even in Google.

I'm sure they get a lot of false negatives, which is arguably better than false positives as long as you can fill all positions.

Still, they're in danger of establishing an intellectual monoculture, and those tend to get wiped out when environments change.

I'm interested in seeing whether the same mix of staff and company structure can prosper in a recession.

You do realize that this is the antithesis of the core reason of why startups work, yes?

What's fundamental is that it is those few abnormal people who change the world 1000x more than the regular person. When you have near infinite money like Google, I'd be very afraid of missing out on those few people who are going to carry the company.

Reply on news.ycombinator.com