I recently announced on Twitter that I got hired by Google!

Over the past couple of weeks, many people have asked about the interview process, and how I landed the job. Google is quite famous for it’s challenging interview process; so much so, that they’ve even published videos of mock interviews, like this one, to help potential candidates prepare.

In this post, I’m going to share my own process, and what worked for me. Of course, it should go without saying that what worked for me may not work for others, so take it all with a grain of salt.

The recruiter phone call #

After I applied for the job of Software Engineer at Google on LinkedIn, I was contacted via email by one of their recruiters, who asked to have a 10 to 15 minute quick chat. We scheduled the phone call, and an hour before the call, I read over my resume to make sure I was ready to answer anything he might ask about. I also thought about answers to questions such as “Why do you want to work at Google?”. But mostly, I tried to relax, as I was quite nervous.

The call went well, and I believe lasted much longer than 15 minutes. I remember talking a lot about my personal projects, working on open source software, including some work I did on clang-format a while back, which has been reviewed by Google employees.

Preparing for the on-site interview #

Following the call, the recruiter sent me an email with attachments to help me prepare for my on-site interview. The first was an “interview prep guide” with information similar to what you can find on the Google careers site. The second was a document with short paragraphs of interview advice from different Google engineers. The third was a PDF of Cracking the Coding Interview, a nearly 300 page book written by ex-Google engineer Gayle Laakmann.

The book became the basis for my preparation. I scheduled my on-site interview as far back as I could, which was about five weeks later, to give myself enough time to prepare. So here’s what I knew about the on-site interview process for software engineers at that point:

  • It’s an all-day thing, with multiple back-to-back interviews, usually around 45 minutes each.
  • Most of the interviews are spent solving a programming problem on a whiteboard.
  • The problems are typically “algorithms and data structure” problems.

As I had been working as a professional programmer for more than fifteen years, my ability to solve algorithm and data structure problems had gotten rather rusty. Sure, I would do problems on LeetCode from time to time, but I knew I needed a lot of practice to be able to bang out solutions in under 45 minutes, especially on a whiteboard.

So what I did was go through the book, and select problems from only the chapters I thought would be relevant, and on topics where I felt I needed practice. The book is mostly made up of interview questions broken down into chapters such as “Arrays and Strings”, “Linked Lists”, “Stacks and Queues”, and so on. In each of these chapters, the problems are sorted in order of difficulty. I figured I’d be able to do about 1 to 3 problems per week night, so for each chapter I picked one of the first, easier problems, one of the last, more difficult ones, and a middle problem in case I had time. By the way, there is a chapter on “Brain Teasers”, which although fun, is really not necessary as Google has stopped asking these types of questions.

For the following five weeks, I spent about 3 to 4 nights per week working on the problems I had selected. Along the way, I also refreshed my knowledge on common data structures and algorithms on Wikipedia. Knowing that I would have to do this on a whiteboard, I worked on these problems in a notebook with a pencil. This was extremely useful, as I developed techniques for how best to write code by hand. For example, when writing our your solution, try to leave extra whitespace between lines of code so that you can insert some later without having to erase anything. Another useful technique I practiced was to write calls to functions I hadn’t defined yet in the main algorithm; in an interview, you can explain what the function should do, and if you have time, implement it later. Not only will this save you time, but it also displays your ability to break down an algorithm into functions.

Another thing that I did was practice speaking out loud as much as possible while solving problems. This is really important, because it helps the interviewer understand where you’re going. In fact, sometimes the interviewer might interject and save you from going down the wrong path before you waste too much time. As it turns out, speaking out loud while writing code wasn’t too difficult for me, since I had been doing exactly that for quite a while on Twitch, but I remember it being really weird when I first started streaming.

The on-site interview #

Finally, the big day came for my on-site interview. I knew that it was going to be a long day, so I prepared myself both physically and mentally:

  • I went to bed relatively early the night before.
  • I had a small, light breakfast in the morning.
  • I got to the Google office about a half hour early, and sat quietly and tried to clear my mind.

I can’t go into details on the interview process itself; however, I will say that I was happy that I had prepared as much as I had. Although the problems I had to solve were new, all the practice I had done had put me in the right mind space. I was able to talk through the problems, and come up with working solutions, while keeping my eye on the clock to make sure I wouldn’t run out of time.

I will also say that the whole thing was really exhausting. Throughout, I drank a lot of water, mostly because I get really thirsty when I’m nervous. During the so-called lunch interview, I purposely ate very little, as I had with breakfast, to keep my stomach from acting up. The interviewers were all very professional and cordial, and made me feel comfortable. Overall, it was a great experience.

Closing thoughts and advice #

After a few weeks, Google let me know that they were interested in hiring me. I was - and still am - really happy! Preparing for the interview, and going through the whole process, wasn’t easy, but I felt that I had done the most I could.

Before ending this post, let me bring together some of the advice mentioned above, as well as points I haven’t mentioned yet. Hopefully, this will be useful for someone trying to get a job at Google, or anywhere, really:

  • Practice algorithm and data structure problems.
  • Practice and develop your whiteboard programming skills, including speaking your thoughts out loud throughout.
  • Ask lots of questions at the start to make sure you understand the problem, especially as they are usually intentionally vague.
  • Write actual code, not pseudo-code.
  • Remember, it’s better to write a naive, but complete, solution than a better, but incomplete, one. You can discuss ways to improve your algorithm afterwards.
  • Brush up on algorithmic complexity: you should be able to talk about the time or space complexity of your solution, and ways to improve it.
  • Watch the clock when doing problems: in 45 minutes, you’ll have about 35 minutes to solve a whiteboard problem. Spend about 5 minutes designing a solution, and 30 minutes writing code.
  • Get a good night’s sleep, eat light, and remember to breathe.
  • By design, each interview session is independent of the others, so if you mess one up, it’s okay, try to reset and nail the next one.

Thanks for taking the time to read this. I hope it will be useful to some of you out there who want to work at Google, or a place like it. If you have any questions or comments, feel free to post them below!