I teach interview training classes at Google and I've done over 180 interviews here. I strongly believe that the more candidates know about what to expect, the better it is for the candidates and for Google: it helps remove the "noise" of nervousness and lets us get at candidates' abilities.
Generally you should be prepared to:
– write lots of code
– that demonstrates that you can apply algorithmic knowledge to solve
– problems that may or may not be well-defined
In addition, especially if you're more senior, you should expect to be asked some high-level design questions that will attempt to get at your knowledge of how to scale applications, your sense of what's hard about some arbitrary large-scale problem and/or how to suss out the hard parts. These don't necessarily presume experience in exactly these areas but what they're trying to get at is: can you break things down and choose problems to attack systematically.
The basic thing I'm looking for when I'm interviewing is not a bag of buzzwords the candidate uses or the experience that's on their resume or their self-described "biggest weakness" — what I want to know is: does the candidate know how computers work, and can they use that knowledge to write code or design systems to solve problems well. Maybe sometimes a candidate doesn't know the "perfect" data structure for a problem, but if he or she can build up that data structure from first principles, that is extremely valuable. Or, maybe the candidate has a wealth of experience but can quickly see what's relevant and discard that which isn't.
As I mentioned above, you'll be writing lots of code on a whiteboard. You'll probably be nervous. Coding on a whiteboard is unnatural and a specific skill that's orthogonal to day-to-day software engineer tasks, so I recommend practicing it. Again, it's about eliminating the "noise" of writing too big or too small or getting your hands messy from erasing with them or whatever so that the interviewer can see the signal of how you're solving the problem.
Get together with some friends, Google "Google Interview Questions," and ask each other questions. Get used to not only coding on the whiteboard, but thinking on the whiteboard — draw pictures, pseudocode, etc. — anything that can give your interviewer an idea of what you're thinking. This will let him or her give you hints, maybe nudge you if you're on the right (or wrong) track, and just give them data, which is way more valuable than silence, even if you've got a crystalline vision in your head — if the interviewer doesn't know that, it doesn't help you. And the more you practice the more natural the interview itself will feel.
One note: if you've heard a particular question before, just tell the interviewer. You'll get points for honesty, the interviewer may have you solve it anyway, and you won't run the risk of getting called out for not mentioning it.
There are lots of great resources out there. Gayle's book is great. Also see:
Steve Yegge's excellent advice: http://steve-yegge.blogspot.com/…
MIT's course: http://courses.csail.mit.edu/iap…
The last thing I would say, and it's hard to implement, is have fun. Sometimes you'll get a question and an interviewer that just "click" with you: run with that! Hopefully some of the questions you get asked will just be neat and you'll enjoy solving them. Look forward to that, even if you get a question or interviewer that you don't "click" with. In the course of 90 minutes during my interviews here I went from thinking "oh my god I'm the biggest moran in the world what am I doing here" to "oh wow I didn't know I could have this much fun with a whiteboard and another nerd!"