During the long and often torturous journey that consisted of my attempt to work at Google, I have gained a lot of insight and mental encouragement and reassurance from a myriad of sources that shared individual encounters with the interview process. I don’t often see success stories out of them, however, and I figured it would be possible to not violate the Google NDA and also share my experience and thoughts, especially since it was a process that I repeated multiple times, and succeeded the last time.
A little background on me: I applied to both Software Engineering (twice: 2008, 2011) and Associate Product Manager (APM, four times: 2008, 2009, 2011, 2012) roles, and also was considered for what is known as the RAMP role (2010), which was very much akin to the Associate Product Marketing Manager program but with a structured 2 year rotational piece. In each of those instances, I did a technical phone interview, and in three instances I was invited for an onsite interview. My grades and GPA were pretty good, enough to be considered, and I attended great schools in the United States.
a) Practice and prepare
It seems obvious and you hear it from everyone, but above all the wonderful resources, brain teasers and sample questions available, the thing that helped me most was to practice in front of a whiteboard. It’s amazing how intimidating those things can be, so buy one if you need to, invest in a whiteboard marker, and pull up a question from GlassDoor.com and CareerCup.com. Don’t even look at the answer, and start talking to yourself about how you would solve the question. Other common resources are Programming Pearls, The Algorithm Design Manual, Programming Interviews Exposed and Puzzles for Programmers and Pros. Those were the ones I personally used.
The hardest thing I had with interviewers is sometimes they would look completely disinterested, bored or emotionless, and it can be a really disconcerting feeling. That’s why making friends with the whiteboard can be all the more useful, because you can direct your attention to it and talk to it with your ideas or solutions. This also applies to the technical phone interview – more often than not I had the impression that my interviewer had no interest in me or my ideas, and just wanted to know if I could code correctly. If you’re relaxed you can be less fazed by that.
I actually had a massage the weekend before my interview, which is not my usual thing to do. Whether or not it helped is debatable, but it might be an approach.
c) Repeat the question
One of the things I learned the painful way is that going down the wrong path after hearing a question can be really catastrophic. You’ll hear a question from your interviewer, and you’ll start with an answer, and then they’ll interrupt you with “… well, actually, I meant it this way”. Then not only do you have to restart your thinking process from scratch, but you’ve also lost some precious time and given the impression that you jump to conclusions without fully understanding them. By repeating the question, or even saying “let me make sure I understood your question correctly”, you’ll avoid the mistake and give yourself an extra couple seconds to think of the right approach to a problem.
d) If you stumble, step back and take a breath
Along the way there were several places where I stumbled pretty catastrophically, whether it was an algorithm question or a thinking exercise. Often your interviewer will try to guide you, but it’s also important to just step back from your thought train and take a deep breath. Don’t make excuses (“I am le tired”) but instead say “I think I might be going down the wrong path. Let me restart my thought process”. If you’re sitting down and are really stuck on a thinking exercise, ask to use the whiteboard to sketch out ideas. That gives you some time to think while you get to the board.
e) Think wildly and don’t assume
Image courtesy of Syd Mead
When a company hires they’re always looking for someone who has fresh ideas and new insights, instead of canned responses. One of the main tenets of brainstorming at IDEO is to “encourage wild ideas”, and as such I think it’s a pretty critical part to the interview process. If you’re asked to design a new product, don’t restrict yourself to imagining what you would use today or tomorrow, but think of what life could be 10-50 years from now. If it’s an algorithm you’re asked to write out, lay out all the assumptions that you need to make in order for it to work. Google likes questions about scale (because naturally Google does things in really really big scales) and it’s important to describe the environment you are writing your code in. Will this code to crawl everyone’s Google Plus profile work on a laptop? An Amazon ECS instance? (This wasn’t a question I got, by the way).
f) Be assertive
Lastly, be confident of your analysis and your ideas. If you think they might be wrong, don’t say them! If you do say something, be prepared to back it up with why you think that way. If it’s a random statistic you’re asked to back up, don’t blurt it out – start with numbers you know to be relatively true and build it from there. (Read Column 7 from Programming Pearls to see how to calculate the amount of water that flows out of the Mississippi). Don’t take it too far by being cocky or snobbish (like “I know more about this than you do” even if that may be true).
Good luck! And also, never give up!