> The firm recently generated buzz in the talent industry
> when it said it had done away with the notorious brain
> teaser component of its interviews after statistics
> showed the ability to ace them had no correlation with
> success at the company.
Brain teasers have (to my knowledge) never been used in Google interviews. They're an urban legend which used to be said about Microsoft, and will no doubt be said about whatever big companies come next.
Journalists: "$COMPANY gives all its new employees wedgies!"
$COMPANY: "We do not think giving employees wedgies is useful."
Journalists: "$COMPANY generates buzz by doing away with wedgies!"
It's been a long time since my interview (2005), but I had a couple of brain teasers during my my interview. Not as many as I had at Microsoft, but definitely some. I specifically remember being asked the Two Eggs question (http://www.datagenetics.com/blog/july22012/).
The two eggs question seems fair to ask an engineer. It's an optimization problem, and could just as easily be rephrased in real world terms (e.g. branching in a hard-realtime microcontroller). The solution can be arrived at through math and reasoning.
Typically, trick questions are things like "how many golf balls fit in a bus", "you've been shrunk and dropped in a blender" , or the infamous "why are manhole covers round". These supposedly test the candidate's creativity, but actually just test whether the candidate has read a book of riddles recently.
I disagree with your categorization of "how many golf balls fit in a bus" as a trick question. That's a normal estimation problem that's highly relevant to a software engineer's daily work. (Rephrase the question as "how many users can you serve with one CPU core". Capacity planning is an entire department's worth of work.)
Adding features to your software can drastically reduce throughput per CPU core. Even simple architecture refactoring for better scalability can drastically reduce throughput per CPU core (just as you have to pick availability versus consistency, you also have to pick scalability versus throughput).
And hence, because it depends on what the software does and how it evolves, the question cannot be answered unless you stress test a CPU core. The question itself, as phrased, is even stupider than how many golf balls fit in a bus.
The question is not a literal question, just some words meant to evoke in the reader's mind the relevance of estimation to software engineering. For a detailed discussion on this subject, see Chapter 7 of Programming Pearls: http://www.cs.bell-labs.com/cm/cs/pearls/bote.html
OK, yeah, you're right. But I think care should be taken in the interview process to have topics diversity, which is another thing that bothers me with Google's interview.
I participated in Google's interview once. After 2 phone screenings with algorithmic questions I was invited to a full day on-site interview involving meetings with 5 people, all of which asked me to solve algorithmic problems. In the end I was told that I did OK at the first 3 meetings, but not so well on my last 2 (actually I was able to answer all the problems given to me, but my performance dropped at some point due to getting tired and the last 2 people probably had other questions they wanted to ask, but couldn't due to lack of time).
Personally I recognize the importance of algorithms, data-structures and reasoning about asymptotic complexity. It's stuff that some are learning since high-school and should be common knowledge for all of us.
But what about other things of importance, like actually being able to build and deliver functional software? What about things like the quality of the code you write, or being experienced in building scalable systems, or being capable of working in a team, or having personal projects? I was never asked (maybe it was just my chance to end up being interviewed only by people that cared about algorithms).
Of course, it can be said that these practices worked well until now for Google. After all, there are plenty of really capable people working there. But maybe that happened in spite of the interview process, not because of it (e.g. one reason could simply be that resumes with internal recommendations have priority and people at Google are good at networking and recommending other good people).
Please tell me you guys do capacity planning with more than just vague numbers you pull out of your ass, a whiteboard, and some guy staring at you making subjective judgments of the number you come up with.
Yes, but we don't expect someone to use actual numbers in response to a hypothetical question in an interview. The question is intended to see if you could figure out which numbers you'd really need to figure out the right estimate.
Often, the specific result of an estimate is less interesting than the user's understanding of what drives that estimate, because it determines if they understand the levers they can pull to change the outcome in the real world.
You don't want to ask the actual question about the specific application, because it gives a strong advantage to a candidate who has worked on that very specific situation in the past (and they may be able to sneak through just by regurgitating from memory.) It's better to have a scenario they're unlikely to have seen previously. As an interviewer, I'm not interested in your ability to remember solutions you received from others, I want to know how you deal with a problem you haven't seen before.
Sometimes folks call these "puzzlers" but I think they're unfairly lumped in with true "puzzlers" - crap like "why is a manhole round" where there's a right answer that depends on either experience or some specific insight. A question where you're asking a candidate to walk through their thought process on a hypothetical (but reasonable) situation isn't "puzzling" unless you just can't handle the question.
Well that was a little condescending. If you think it's vitally important to screen people for their ability to solve Fermi problems, it's no skin off my back. I was just trying to have a conversation.
Man, I don't necessarily think they should be used in technical interviews, but I really don't get the aversion to these kinds of questions - stuff like this is so much fun to think about and debate!
I personally think manhole covers should be human-cross-section-from-above-shaped.
I think what is always left out of these snippets in articles is what job roles they are referring to when they talk about the interviews. Sounds like these teasers have never been used in software engineer interviews but have been used for product management or others.
Journalists: "$COMPANY gives all its new employees wedgies!"
$COMPANY: "We do not think giving employees wedgies is useful."
Journalists: "$COMPANY generates buzz by doing away with wedgies!"