Applied for a Software Engineer position. I was contacted by a recruiter for some general questions and background information. I was then instructed that I'd be receiving a call the following week from another software engineer for a technical screening. The engineer called me and went over a few technical questions regarding mainly javascript and running time (big O). I was then asked to provide 2 algorithms in code within an hour after the call. Overall the interview seemed to go well....as so I thought. I wasn't contacted until the following week of the results. I was turned down but they cannot give you any information of why you didn't meet their standards. They won't tell you if your code is wrong, where you went wrong or where you could improve as a developer. Just a standard "your skills don't meet our needs at this time" response. Kind of disappointing given that you prepare for hours upon hours of your time and energy and receive 0 feedback. How can you prepare? Well, I went over all of my old CS 101 notes, hash tables, data structures, and all the theory behind it. It can be a bit overwhelming if you haven't visited that information for over a decade. My advice is to brush up on your theory and write some practical examples along those lines, like sorting an array using Merge sort in your favorite language. Don't worry about trying to get better in your languages...you either know it now or don't know it. It's nearly impossible to prepare for everything for this position given that they don't hire a Javascript developer or C++ developer. They just hire developers in general and only the top 1% developers in the world, as they indicated. Don't bother asking about the position because you could be working on any number of projects and they will not give you any specifics. Overall, I rate the experience a 2.5 out of 5. The interview questions I got weren't terribly difficult, but I don't know where I went wrong or how I could improve since no feedback is given. That's where Google's policy needs to be revamped. The people I talked to were nice but don't expect any personality. It's very dry and straightforward and I'm not really sure if that's indicative of how people are there. The youtube video on working at Google seems like it's such a great place to work, but can't really say for sure at this time given my experience thus far with how they approach engineers.

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