I got contacted by a Google recruiter back in August 2013 who found me via some of my open source work on Github, and after a couple of phone interviews I got flown out to the Mountain View office for a day of in person interviews. I didn’t end up getting an offer, but I thought I’d share some advice on the things I wish I had studied more or done differently.
I got there in the morning and had a slight chat with the recruiter who had contacted me. He brought me to a conference room and told me about the process of what was to come. In my case there were 5 interviews with a break for lunch in the middle where a Google employee gave me a tour around the campus and spent some time talking to me. It was made clear that the lunch tour and conversation would be off the record and wasn’t part of the interview, so it was time you could relax a bit.
Each interviewer presented 1 or 2 problems, where solutions needed to be coded on a whiteboard (I used C++). I can’t go into the exact problems due to NDAs I had to sign, but it’s not very important for the purpose of this post anyway.
The first interviewer seemed very mathematically inclined and only had a single problem for me. The only thing I’ll tell you is that it was a sort of combinatorial optimization problem that involved a couple of math tricks to get the running time down. I got to the correct answer eventually, but I needed a few hints. I have a hard time deciding if this interview went well or not due to the number of hints that were given before I came to the correct solution. If this interviewer rated me badly, I wouldn’t have blamed him, my discrete math and memory of combinatorial algorithms was just too rusty to figure it out quickly. On the other hand, it all seemed mostly obvious after a few hints, and the interviewer was friendly and seemed happy that I did get to the correct answer at the end.
The second interview went great. This interviewer had two problems prepared, both of which I solved very quickly. After that he admitted that he didn’t really have anything else for me, and started asking me some generic questions about hash maps and sorting algorithms. Low stress and I can’t imagine anything I could have done better in this one.
Advice: Make sure you know all about sorting algorithms and hashmaps. Even if you don’t have to code them, an interviewer that runs out of prepared stuff might default to asking you a dozen questions on running times, hashing functions, choosing pivots in sorts, etc.
The third interview was the most stressful, but surprisingly had the least algorithmically complex problem. The problem itself was seemingly simple from an algorithm standpoint, but involved getting a lot of indexes correct and dealing with ranges of memory and whatnot without getting off by one errors or subtracting the wrong lengths from things. In addition, I made the mistake of using my own implementation of what was essentially a fixed size circular queue for part of the problem, when I should have used some more high level C++ data types (like std::queue), leaving me with even more indexes and pointers to potentially make mistakes on.
The interviewer had a thick accent and occasionally struggled to find the words to describe what he meant to me. This by itself wasn’t that big of problem, but combined with him being the type of person who gave hints and ideas often, and got frustrated by the language barrier, he would grab a sharpie and start writing bits of code on the board with mine rather than just telling me his hint.
A seemingly helpful gesture actually made the entire thing that much worse. When he would write something, it was often so different from what I was thinking that it would throw off my train of thought and I’d be left trying to figure out exactly where he was going with it. The problem given also left a certain amount of structuring and design work up to me, and when I started doing it one way, he soon suggested that I structure it differently and went so far as to take his sharpie and write out a method stub, telling me I should be able to solve the problem by implementing these methods (this was when I was already a good way through solving the problem differently). Already frustrated at my own code, I erased what I had and started from scratch doing it his way. The “assists” continued any time I would seem to be struggling or would pose rhetorical questions to myself to fill the silence and describe my thought process, and every time would leave me more stressed: derailing my train of thought and making me feel like I was doing badly.
Although Pair Programming with two keyboards is most certainly a bad idea, I’m not blaming everything on the interviewer. I wish I could go into detail about the problem, but all I can really say is that it wasn’t algorithmically complex, but I struggled far too much trying to get the little details of it worked out. dealing with all the indexes, ranges, pointers, timestamps, and some bad initial design decisions left me with a huge desire to erase everything and start from the beginning for a 3rd time, but time was not something I had left.
The interviewer snapping a picture of the whiteboard, and leaving with nothing said but “good luck”, conclude the encounter.
Whew. I’m glad I got a lunch break when I did, because the last interview left me more than frazzled, and the time to decompress a bit and wander around the campus was timely.
This interview had a few questions, all some problem solving using manipulation of standard tree data structures. Not much to say on this one, I solved the problems with almost no hints and with time to spare.
Advice: Know your trees.
This interview was a another single problem interview. I spent a lot more time than I should have realizing it was a graph problem, and then got thrown off by the interviewer suggesting that DFS wasn’t going to be useful. In hindsight, part of the solution was topological sort, and there are two common ways to implement it. One of which is based off DFS, which is the only method I knew and the direction I was going with the problem, but the interview’s comment made me stop, since he was wanting the alternative way of implementing it (that involves actual modification of the graph by deleting edges and finding nodes with no incoming edges).
Advice: If there are multiple ways to implement an algorithm, make sure you at least know the high level differences of them.
2 interviews were spectacular.
2 interviews were okay and I got to the correct solution, but only with enough hints.
1 interview went terribly.
Result: generic rejection letter about Google not having a good position for me right now.
I wasn’t actively applying places or even attempting to get a job at Google; interviewing was just an opportunity that came up through a recruiter and was too tempting to pass on, if nothing else because of the experience and practice. Even with that said, I couldn’t help being disappointed at the result and being left with a lot of second guessing on how I could have done better. I wish I could have gotten some sort of idea on how close I was. If I had just been better at combinitorics, would that have been enough to push it over the edge? Or if I had recognized a graph problem quicker? Or would have all 5 interviews have to go really well to get hired? Guess I’ll never know.
Things I wish I did different
This isn’t a long list of ways to prepare, but rather a specific list of weaknesses and mistakes I made so that perhaps others can avoid them.
- I should have reviewed more combinatorics. Not just the math, but the algorithms. Practice things like computing all the subsets of a set, all of the permutations and combinations of characters to form strings, etc.
- I should have reviewed and studied more graph algorithms. DFS and BFS alone aren’t going to cut it, and it often isn’t clear that the problem given to you is actually a graph problem at all.
- I should have tried to spend as little mental effort as possible worrying how the last interview went. I couldn’t help trying to tally how I was doing in my head as the day went on, but you should save the post-interview analysis for the flight home and not the breaks between interviews.
- Finally, and perhaps most importantly, I need to be a lot more careful about letting interviewers throw off my current train of thought. A comment like, “so what does that get you?” with a seemingly negative tone is enough to make me assume that everything I’m doing is wrong and start second guessing myself instead of carrying on with my problem solving process.
What to expect interviewing for Google
Getting an interview, and interviewing for, a software developer position at Google has an odd contrast. From my experience at least, having a good resume, open source projects, and being able to talk about things you’ve done is a requirement to attract the attention of a recruiter and get an interview. However, once you get that in person interview, no one cares anymore. Not a single person out of five asked me a question about my resume, past projects, technical proficiencies, or anything about what I’ve done and think I can do. From the moment you switch from talking to the recruiter to the first in person interviewer, it’s nothing but whiteboard coding and algorithms. Don’t expect much small talk and be well practiced with Topcoder style problems.