Applied through LinkedIn in early October, total process took about 4 months. The recruiter contacted me 4-5 weeks after my initial application. We set up a phone interview, but the earliest available date was mid-December. Phone interview was brief and pretty simple (basic data structures / algorithms stuff), and I was asked for an onsite interview just a couple hours after completing this. The onsite interview had to wait until January, however, due to the holiday schedule. Arrived at the Google office on the morning of the interview and was met (about 10 minutes late) by what turned out to be my first interviewer (an engineer, who didn't seem to know his way around the office). After 45 minutes, the interview ends abruptly and new person walks in. This is the basic pattern for the whole day (it's a 6 hour process, including lunch in the commissary): for the most part, each interview was pretty casual and the difficulty level was not nearly what I expected -- nearly all the questions were object-oriented design and basic algorithms (not even any graph theory, which I was anticipating). I felt pretty good about my performance overall, although I probably spent more time with certain problems than I should have -- it was difficult to get a sense of proper pacing since each interviewer had a vastly different demeanor and the range of problems varied from simple recall to complex problem solving. About 2 weeks after my interview, I received a call from the recruiter who simply said that I had not been selected at this time. She was polite and apologetic, but could offer no actionable feedback. Overall, my interactions with Google employees were friendly and relatively prompt. I felt the process took far too long, but I guess this is to be expected for such a large company. I also feel that the peer review system of interviewing left me almost completely in the dark about how well I performed. It is also somewhat odd that at no point in the process was I made aware of which team I was being considered for.

Direct onsite because I interviewed in the past and did well that time. From the time I sent my resume to interview day: 2 weeks. From interview day to offer over the phone: 2 weeks. The syllabus for the interviews is very clear and simple: 1) Dynamic Programming 2) Super recursion (permutation, combination,...2^n, m^n, n!...etc. type of program. (NP hard, NP programs) 3) Probability related programs 4) Graphs: BFS/DFS are usually enough 5) All basic data structures from Arrays/Lists to circular queues, BSTs, Hash tables, B-Trees, and Red-Black trees, and all basic algorithms like sorting, binary search, median,... 6) Problem solving ability at a level similar to TopCoder Division 1, 250 points. If you can consistently solve these, then you are almost sure to get in with 2-weeks brush up. 7) Review all old interview questions in Glassdoor to get a feel. If you can solve 95% of them at home (including coding them up quickly and testing them out in a debugger + editor setup), you are in good shape. 8) Practice coding--write often and write a lot. If you can think of a solution, you should be able to code it easily...without much thought. 9) Very good to have for design interview: distributed systems knowledge and practical experience. 10) Good understanding of basic discrete math, computer architecture, basic math. 11) Coursera courses and assignments give a lot of what you need to know. 12) Note that all the above except the first 2 are useful in "real life" programming too! Interview 1: Graph related question and super recursion Interview 2: Design discussion involving a distributed system with writes/reads going on at different sites in parallel. Interview 3: Array and Tree related questions Interview 4: Designing a simple class to do something. Not hard, but not easy either. You need to know basic data structures very well to consider different designs and trade-offs. Interview 5: Dynamic programming, Computer architecture and low level perf. enhancement question which requires knowledge of Trees, binary search, etc. At the end, I wasn't tired and rather enjoyed the discussions. I think the key was long term preparation and time spent doing topcoder for several years (on and off as I enjoy solving the problems). Conclusion: "It's not the best who win the race; it's the best prepared who win it."