Another good refutation of the WSJ article making bogus claims about Google interviews.

My strategy as an interviewer goes something like this:

Phone screens: I ask you to write a class that does something mundane -- typically something every programmer has dealt with before. No tricks, no obscure algorithms. Just write a complete, self-contained class with a clean interface and working, reasonable implementation. 95% of candidates can't seem to do this -- the rest, I recommend bringing on-site. (Note that the coding happens in a shared Google doc, not over the phone.)

On-site interviews: I ask you to design a completely realistic software product, probably something you use every day. We start with breaking down the task into things that could be farmed out to individual teams. Then I drill down on a specific interesting (but, again, _real_) problem that comes up in the implementation, and ask how you might solve it. There's no right answer, but some answers are clearly better than other answers.
(Ob disclaimer: these opinions are my own, I do not speak for my employer, etc)

Public service announcement: if you follow the advice of articles like the one below from the WSJ or anyone else who tells you that Google interviews ask brain teaser/lateral thinking puzzles, you will not get hired. The people giving this "advice" simply do not know what they're talking about, or they are deliberately lying to you to sell books/page views.

I spent ~20 months serving on one of Google's hiring committees, which means I saw all the questions being asked in interviews for Test Engineer and Software Engineer in Test positions. If someone had asked questions like the one from the WSJ article ("you are shrunk to the height of a nickel and thrown into a blender blah blah blah"), we would have sent the interviewer an irritated email asking them to knock it off and ask real questions.

When training engineers to interview candidates, Google's very explicit instructions are to not ask brain teaser questions or any question where there's a trick. This is why you won't get asked to sort 1 million integers in 1MB of memory: without realizing the trick, you can't make any headway; if you don't make any headway, we don't learn anything about you.

Each interviewer comes up with their own slate of questions (from their own experience, from Google's internal question database, from talking to friends, whatever), but here's what's usually on my list:

- I want to see you write real code. I'll give you an algorithm or a problem and you'll need to write functioning code in a real programming language of your choice. You can start off with an inefficient solution and iterate to make it better, that's fine, but the code will need to work. If you use a high-level language so you can take advantage of a rich standard library, your reward will usually be to code up some piece of the standard library you just used. I want proof that you understand how that function/data structure you're using works.

- I want to see you solve a vague, open-ended problem. This will generally take the form of "You know how Google Product X does Y? Design that." I want to see you go from a high-level idea to a concrete process flow, data structures, algorithms, etc. If you hand-wave too much, I'll demand more and more details to make you demonstrate you know how these things will work under the covers. If you get a solution too quickly, I'll start throwing in extra constraints: it has to be faster; it has to use less memory; it needs more throughput; it has to support Feature Z; whatever. I want to see how you react to changing requirements.

- I want to see what happens when you get stuck. I try to ask questions with seductive naive, wrong answers; if you hit the honeypot, I get to watch what happens next. Candidates who can't get out of the honeypot and back to a working solution are in trouble.

Also, pro tip: don't ever put on your resume that you're an "expert" in something unless you invented the thing in question. Saying that you're an expert means we get to ask the most nit-picky, obscure questions we can come up with (opportunities like this make for great lunch-table conversations). "Experts" risk facing the combined maniacal, sadistic glee of a dozen Google engineers.

TL;DR: Google doesn't ask lateral thinking puzzles in interviews. Spend your time writing code, solving hard problems, and thinking about the hard problems other people have solved and you'll do fine.
Shared publiclyView activity