Shared publicly  - 
 
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.
Collin Winter originally shared:
 
(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.
9
2
Sip Johnson's profile photoenki wa's profile photoCosmin Negruseri's profile photoZhanyong Wan's profile photo
7 comments
 
when i was interviewing candidates at borland, one of my key tricks was to ask a question that i was reasonably certain the person could not answer.

if the candidate failed to admit that he couldn't answer it, didn't ask for help, and bullshitted, the interview was over.
 
+robert west - Err. That sounds pretty sadistic if you ask me. Lots of candidates who would be humble and honest under any other circumstances will feel compelled to bullshit under the pressure of an interview.
enki wa
 
I've asked, on and off over the many years I've been interviewing, vocab questions that are so hilariously obscure that the candidate is not expected to know them, and I'm just looking for them to say that they don't know. This exercise tends to take about a minute, and does (based on my anecdata) correlate well with performance on the remainder of the interview. That said, I've never failed anyone for trying to extemporate through, it's just the lack of a positive signal.

Whether or not they can actually solve difficult (and, well, simple) design, algorithm and coding questions is the thing I actually accept or reject a candidate on.
 
+Kenton Varda: People not admitting that they don't know something, and doing anything they can to avoid admitting it, is a problem I've seen a lot at other companies (not at Google so much). So I agree with +robert west that it's something to try to weed out. I agree that an interview scenario might not be a good setting for it, but then what would be?
 
An experienced interviewer looks for sooo many subtle signals regardless of what the specific question that is being asked is. For example I like to look at how a candidate manages white board space ... sub par candidates tend to severely under estimate (or not even try to estimate) the length of code they might have to write so they may start writing a giant function prototype in the middle of the board in giant letters and lots of white space. .... Then when time comes to actually fill in the details they start doing the arrow here, arrow there, let me shuffle and try to rearrange things to make it all fit (where as sometimes just erasing the first line and rewriting it in a more suitably chosen location and size would be much much better). There are so many other things that one looks for.
enki wa
 
I agree with +Sip Johnson 's general statement, but the specifics of 'do they know how to write code on a whiteboard' is something I consider utterly meaningless, as writing code on a whiteboard is not a skill necessary for being a successful engineer.
Add a comment...