This is the experience of someone who lives 2,000 miles away from Google's Mountain View campus. I applied online and heard back in less than a week. The HR phone interview went well, so I got a technical phone interview.

They gave me a study sheet that lists everything you might need to know for the technical portion of the interview. This includes loads of computer science theory, algorithms, and data structures. I highly suggest studying this! It's the kind of stuff that you don't normally know offhand, but you can brush up on it pretty easily if you knew it at one point. If you have to learn these things from scratch, then you've got to do it, but I don't think you'll be successful in the interview because it's got to come like second nature.

I had plenty of time between the HR phone interview and the technical phone interview, so I spent that time diligently reviewing the things I should know. They are not out to trick you; they sincerely want you to be well prepared for the interview because even great candidates fail simply because they didn't take the time to prepare.

The phone interview went well, and I felt the interviewer really took time to read my resume and ask thoughtful questions. The questions were not too difficult, and they even gave me 5 minutes to talk about a job that interested them on my resume, which was non-technical in nature. If you know how to code and solve simple puzzles, you should do fine.

I even made some technical mistakes, like not being able to find the most efficient solution, and I struggled through a question about a hypothetical project management scenario. That question came out of left field, and I stammered and stumbled through the last few minutes giving my answer.

Three weeks later, they flew me out for two nights for the on-site interview. I should mention it wasn't a "normal" on-site interview because, apparently, it was some kind of major hiring event called a "batch day." In terms of the interview itself, it was the same as they always do, but what was abnormal was the sheer number of people they had on-site for interviews. I never found out how many there were, but in my building alone, there were close to 20 that I saw, and there were loads more candidates walking around campus during lunchtime.

The on-site consisted of 5 separate 45-minute interviews, each with a different interviewer. I say it was difficult because the questions cover advanced technical subject matter that will be difficult for the majority of engineers. However, if you're the superstar they're looking for, the questions will not be that difficult and may even be fun to solve. I think it's safe to say that if you think any of the questions are difficult, and/or you spend the whole 45 minutes writing your solution, then you're probably answering the wrong way.

They like to test if you know a CS concept by asking generic questions and seeing if you identify the proper data structures or algorithms to use. For example, if your algorithm is wasting time (and whiteboard space) to keep a collection sorted, it could be because you didn't recognize that the full ordering doesn't matter and you should be using a priority queue instead. Those kinds of identifications are major things they're looking for.

A week after the on-site, I found out the hiring committee approved me. That's when they called my references. A couple of weeks later, I spoke with various engineering managers who were interested in my skills and background. They didn't care that I had no experience doing what they do because they knew I was a skilled coder from the interview notes and I'm smart enough to figure it out on the fly. This part is not an interview; it's just a conversation about interests. They want to find out if you're going to enjoy working on their project, not if you're smart enough or have the right experience – they already vetted that in the on-site interview. In my case, I talked with 3 managers who all had different and interesting work, which made it difficult to decide, but ultimately I got to choose which project to join because they all were a great fit.

A week after being placed with a team, they wrote up my offer and put it to the VP and senior VP reviews. The waiting is the most stressful thing because, at this point, there's practically no reason they're going to reject you, but you have to wait so long for the offer to finally come. Be patient; there is light at the end of the tunnel!

After the offer was reviewed by the top execs, I got it by e-mail, set my start date, and digitally signed it. Now a relocation team is helping me move across the country to start in a month and a half!

Coding puzzle to test if you really know your favorite language and can use it to solve puzzles. They made me write code that compiles and work through "compiler" errors until it was valid.

Basic coding problem to test data structures and algorithms knowledge. Think recursion, heaps, binary search trees, that kind of stuff.

System design problem, no coding involved. I had to design a large, complex system that I never could have done by myself. I just started designing what I could, and the interviewer asked questions to guide and inform the design. By the end, I think I seemed like a genius, but I knew the interviewer was the one who knew the proper design, not me.

Very vague coding task. I was given a function signature and spent the next 5 minutes teasing out potential solutions and discussing pros and cons of each one. Eventually, I arrived at a multithreaded solution, which they then wanted me to implement on the whiteboard. I did not need to know any specific threading API, because they let me use any libraries I wanted, even if they don't exist, just as long as they make sense. This question tested my knowledge of multithreading concepts thoroughly, so this is definitely something you should review!

A very difficult-seeming coding problem. It's the type of problem that makes you crap yourself at first, but if you keep a level head, you can hopefully spot an elegant way to solve it. There is an obvious solution, but it is very painful and inefficient to implement, and there is a more subtle solution using dynamic programming that is the most efficient and easiest to implement. They will know you're a rock star when you solve the problem elegantly using the proper CS concept.