As arguably the most desirable tech company to work for, Google is surrounded by myths about the "impossible Google puzzles." But most of these are just that: myths. As any Google insider will tell you, Google has no interest in discovering what you would do if you were nickle-sized and stuck in a blender. Seriously. None. Zippo. Zilch. Those are just myths perpetuated by people who have neither worked for nor interviewed at Google but who really, really want you to share their article. It's link bait, essentially. What does Google ask Software Engineers?

The questions usually fall into a few categories:

Data Structures and Algorithms: These questions can be very challenging, but typically do not rely on "advanced algorithms." It's very rare for an interviewer to ask you about Red/Black Tree. They could, of course, but tend not to because (1) it tests knowledge and memorization, which is not something they especially care about and (2) your interviewers, typically being at least a few years out of school, probably do not remember this knowledge.
Coding: This may involve coding an algorithm that you just designed, or it may be to code a pretty straight-forward method. Remember that even simple problems can be tricky to code.
Scalability: It's very likely that at least one of your interviewers will ask you a question like "design a system to search a billion documents." These questions do not require advanced knowledge in distributed systems; just good instincts. How would do this if there were just one computer involved? Now how do you scale that to many computers?
Behavioral / Experience Questions: Almost all of your interviewers will probably ask you about some elements of your prior experience. You should be prepared to speak about anything from your resume.

You do not need to know MapReduce, BigTable, or any specific language or technology. Google is looking for aptitude, not some specific bit of knowledge. After all, if you're smart and motivated, you can learn whatever new things you need to know.

That said, it can be helpful if you know Java (or C#), since those are almost universally understood. You want to be sure that you can "communicate" in a mutually understood language.

But, hey, don't believe me. Check out the Google Interview Questions on CareerCup and assess this for yourself.

What should I expect ______ [phone screen / onsite / internship / full time] interview?

It's tempting to want an easy answer, like "your first phone screen will focus on coding, and your second one will focus on scalability, and your third will ...". But that's just not how interviews work. [Read: The Interview Factory: Where Do Questions Come From and Who Picks Them?]

There's no giant system determining what will be asked when. There's no one telling interviewers what to ask when. If your friend's first interview happened to be data structure based and his second interview was coding based, that's purely coincidence.

Here's what actually happens: most interviewers have a set of five(ish) "favorite" questions. If your first interviewer focused on data structures, that's just because that's what that interviewer happened to ask. If you got that interviewer during an onsite interview, the same thing would have happen.

The difference between one interview and the next one is based on the interviewer changing, not based on anything else. There is no "system" for interviews. It's all basically random.

What is Google looking for?

At Google, interviewers do not make the actual hire / no hire decision. They write up a summary of the interview and your performance and pass that on to a hiring committee. The hiring committee tends to focus on your analytical skills (i.e., intelligence) and coding skills.

Personality is rarely a significant factor unless you come off as arrogant. Arrogance can and will get you rejected.

Experience is also usually not a major factor because this was already assessed before you got an interview. If you didn't have the right experience, they wouldn't have interviewed you.

How are you evaluated?

You are evaluated relative to other candidates on the same question.

That is, I don't think "gee, Alex took 5 minutes to solve this problem, and Pat took 15 minutes to solve this other (different) problem. Alex must be smarter than Pat." That would be stupid. What if Alex got a much easier problem?

Or, another way to think about it is this: the interviewer recommends an offer if you're in the top 20% of candidates who were asked the same question. (The exact percentage its debatable, but the idea is correct.) For this reason, it doesn't matter if you're asked an easy question or a hard question. After all, the same number of people are in the top 20% regardless of how easy or hard the question is.

The following factors generally come into play:

How long did it take you to solve a question?
How optimal was your algorithm?
Did you think through the trade-offs in your algorithm?
Was your code reasonably bug free?
Did you test your code?
If you made mistakes, were you able to fix them?
... and many others.

And again, all of those factors are relative to other candidates. "Reasonably bug free," for example, means fewer / less critical bugs than other candidates.

How should I prepare?

Practice on REAL interview questions. Do not look at blogs, top 10 lists, newspaper articles, etc for Google interview questions. Those questions are hyped up and, frequently, were never asked at Google (or any other tech company). They were picked because people would think they were ridiculous, not because they were authentic. CareerCup has hundreds of Google Interview Questions - use those. (Or, better yet, check out Cracking the Coding Interview.)
Read Cracking the Coding Interview. Sure, I'm biased since I wrote it and all. But the reviews (5 stars with 47 reviews right now) speak for themselves. Honestly, it's a really great investment into your future and you'll see plenty of people in the reviews saying how much it helped them.
Practice coding on paper. In your interview, you won't get a compiler - and that means no code completion, syntax highlighting, auto-generated code, etc. You'll be surprised by how much you forget as soon as you're in front of a whiteboard. Prepare for this by doing your practice coding on a piece of paper (or a whiteboard, if you happen to have one of those lying around).
Push yourself! Interview questions are designed to be hard; don't just flip to a problem's solution just because you're having some trouble. You need to learn how to really push yourself on a problem, and that starts with preparation.
Do a mock interview. CareerCup offers mock interviews with interviewers at Google / Microsoft / Amazon, but if you can't / don't want to pay CareerCup - that's fine. Grab a friend and swap mock interviews.

If you haven't ever done a technical interview before, I would strongly advise not walking into these blind. An interview is just too important to blow because you weren't sure what to expect. Check out CareerCup's interview videos, or get a friend with some "big company" interview experience to do a mock interview for you.

What should I do in my interview?

Be confident. I know, I know. Easier said than done. But do your best. Remember that if you're struggling to solve a question, this does not mean that you're doing poorly. It could just mean that it's a tough problem.
Talk out loud. When you get a problem, talk out loud and show your interviewer how you're approaching it. They want to see how you're thinking about it. Plus, it'll show more progress (rather than them thinking that you're stumped) and it'll give them the chance to guide you if you get on the wrong track.
Push yourself. Don't give up just because the problem is hard - in fact, that's probably the worst thing you can do.
Analyze the trade-offs. Once you get a solution, discuss the trade-offs with your interview. Think about both the space and run-time complexity. Then see if you can do better.
Write good, clean code. Show your interviewer that you are a person who cares about writing good, clean code. Use other functions. Define your own data structures. And so on.
Test your code. You don't check in code without testing in real life, so why would you do this in an interview? Test your code and, if/when you find bugs, fix them carefully. That is, you should actually understand where the bug is coming from rather than making random changes until your code works.

What else should I know?

Your interview performance is impossible to judge (by yourself). If you think you failed (or aced) your interview, you really have no idea.
Not hearing back from your recruiter quickly does not mean you were rejected. Delays can mean many things, but they do not mean rejection. Follow up with your recruiter if you haven't heard back quickly.
A brief guide to tech internships
If you're having trouble getting interviews (or even if you're not), clean up your resume.
The best way to get a Google interview, or any tech company interview, is to build something cool. Or build many cool things. This is especially important if you're a bit younger. Building some programs on your own time is a great way to improve your coding skills and add experience.

There is so, so much more to say on this.

If you found this useful, I encourage you to check out my book, Cracking the Coding Interview: 150 Programming Questions and Solutions. I go into these in much more detail, including more concrete ways to solve tricky algorithm problems, top 10 mistakes candidates make, how to handle behavioral /experience questions, what good coding looks like, and, of course, 150 problems and solutions.

Discuss on Hacker News