So a Google recruiter calls me and I get all excited. I'm fairly happy with my current employer, but, after all, it's Google. I talk to the recruiter and we discuss a few things like where I would like to work, etc. I ask them: - "Are you looking for any particular background - web, databases, storage, networking?" - "Oh, no no, we're just looking for generally smart people." Ok fair enough. Recruiter 1 hands me off to Recruiter 2. Recruiter 2 then hands me off to Recruiter 3 who's, finally, local to my area. Cool. Step 1: Phone interview. I talk to a "person who is around my level". They ask me to write some code using Google Docs. Pretty easy. Step 2: Round 1. Two one-hour sessions. Both times I'm given some code printouts (in language of my choice) and asked deeply technical questions. The first hour is in the form of "this code does not work, why? Ok you found a bug, fix it. Ok now when we run this, it does this, why?"... and so forth. The second hour, there's a lot more code and two interviewers at once. I was told that one of them is a "junior interviewer". The problem is, they interrupt each other asking questions as I'm trying to solve things on the board. As I try to explain a solution to interviewer 1, interviewer 2 randomly jumps in: "so what do you think the running time is?" Nice way to stress one out... At the end of that, they tell me it's ok to be a little stressed out. Step 3: Round 2. Three one-hour sessions. Now, each time, I am not given much and asked to write code on the board. I felt like I did OK with interviewers 1 and 2 but interviewer 3 was very difficult to communicate with. He would describe a board game puzzle in a very silent manner and then not really ask a question. Several times I had to ask him "uhh, I guess you would like me to write a function that does XYZ?" And then get a very subtle nod back. I wrote some stuff but couldn't tell if he was impressed, indifferent, or expected something else completely. In any case, I feel like that was the part I blew. Note that at no point were my experience, past employment accomplishments, management skills, personality, interests, or career goals ever discussed. Step 4: Wait for two weeks. After a week I emailed the recruiter and the response was "Sorry, one of the people who interviewed you had not submitted their feedback yet". I showed that to some very senior developers in my network who laughed and said "dude, that's a good sign that the organization is slowly rotting". Step 5: Get rejection voicemail. The reason being that I'm "not quite the right fit for the engineering roles we have open". Fair enough. "We're generally looking for smart people" came to mind. Thanks a lot Google! :) Step 6: Two weeks later get a phone call from Google Recruiter 4 who wants to talk to me about employment opportunities at Google! No joke! I told her I'm not "generally smart".

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."