Ich wurde zuerst per E-Mail von einem Recruiter von Google kontakiert. "Hello from Google", fast wie eine Spam-Mail... Die zwei Telefoninterviews mit Google Docs, um Code zu schreiben. Von den Algorithmen her ziemlich leicht, ungefähr genauso viel Wissen zur Syntax der Programmiersprache wie Kenntnisse zu Algorithmen. Im ersten Interview gab es ein paar Fragen zum Code (beispielsweise zum Einbau von atoi) und einige Fragen abseits des Codes (beispielsweise dazu, wie man eine Funktion schreibt, mit der sich aus einer unendlichen Zahl von Nummern Elemente mit der gleichen Wahrscheinlichkeit heraussuchen lassen); im zweiten gab es nur eine Code-Frage und eine Frage zum Design. Es hat ein/zwei Wochen gedauert, bis ich die Ergebnisse der Gespräche vorliegen hatte. Vorher hatte mir der Recruiter eine Liste mit Hinweisen für die Interviews geschickt, beim Googlen stellte sich aber heraus, dass es nur eine Kopie eine Blogbeitrags war, den jemand gemacht hatte. In diesem Post heißt es, dann man sich unter anderem mit den Details von balancierten Bäumen (vor allem B- und AVL-Bäumen) oder MapReduce auskennen sollte. Nichts davon wurde explizit abgefragt (obwohl es sicher trotzdem sinnvoll zu wissen ist). Dann gab es fünf Vor-Ort-Interviews an einem einzigen Tag. Das wurde innerhalb von einer Woche schnell organisiert. Google hat das Hotel gebucht (mir aber nicht gesagt, welches und die Bestätigung kam als Spam, wiedereinmal) Drei Interviews vor dem Mittagessen, dann Essen in der Google-Kantine, dann zwei weitere. Jedes hatte ein/zwei "große" Fragen, bei der man einen Algorithmus finden oder ein Problem lösen musste. Die Fragen waren einfacher als die Probleme, die man üblicherweise in Wettbewerben wie Projekt Euler oder IOI bearbeiten muss (weniger Mathe). Auf der anderen Seite, musste man mit sie vor Menschen und ohne Computer lösen :(

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