This is the first of a series of posts on preparing for and understanding interviews at big tech companies, drawing from my experience recruiting and interviewing for Google. I’ll be using real banned interview problems I and other Google engineers have used in interviews. I want to prepare you for the sorts of questions you’ll be asked and give you insight into how your responses will be evaluated (or at least how I personally evaluated various responses I’ve seen in the past).

Before I continue, a disclaimer: while interviewing candidates is one of my professional responsibilities, this blog represents my personal observations, my personal anecdotes, and my personal opinions. Please don’t mistake this for any sort of official statement by or about Google, Alphabet, or any other person or organization.

First, bit about me: I graduated in 2012 with a B.S. in Mathematics from Fordham and a B.S. in Computer Science Engineering from Columbia through a dual-degree program. I’ve been working at Google NYC ever since, first on the bidding automation group, and more recently on the AdWords recommendations group. It’s given me the opportunity to do a lot of fun and challenging things: write petabyte-scale data analyses, fight late-night production fires, lead multi-person projects from the ground up, implement algorithmic optimizations to core business logic. The list goes on and on, and I’ve enjoyed every minute of it.

I also volunteer an hour or two of each week for interviewing candidates for engineering positions, leading them through the classic whiteboard coding format where the candidate has 45 minutes to design and implement a solution to a technical problem. Every once in a while, my favorite interview question will leak to the public, meaning I have to dig up a new one. My loss is your gain, though: the moment a question is leaked, I’m free to share a case study on it!

Next, a bit about you. If you’re reading this, you’ve clearly got an interest in computer science and might be interested in interviewing at tech companies. While I want to make this series useful to people of all levels, I’m targeting it in particular at undergraduates and master’s students in CS or a related field. If you don’t fall into that category, don’t leave! I’d like to think there’s something here for you, too.

Interview Format

Before we dive into the questions, though, a quick introduction to how these interviews work. Keep in mind, this is all my personal perspective as an interviewer, so your mileage may vary. As always, Google recruiters are the authoritative sources, so if you have access to one, ask them first!

I interview for full-time software engineer (SWE) roles, as well as SWE internships. If you were applying for a full-time SWE position, you’d typically be given one or two 45 minute screening interviews, conducted over the phone. If you did well, you’d then be invited to travel to one of our campuses (all expenses paid) for a day of on-site interviews. This consists of four to five in-person interviews, again 45 minutes each. Plus lunch, of course.

If you were applying for a SWE internship, there’s usually no on-site interview: you’d typically be given one or two phone screens and that’s that.

After each interview is done, the interviewer writes up feedback. For entry-level technical roles, this feedback is only on your technical abilities: How well did you apply your data structures and algorithms knowledge? How well do you code? Did your solution handle all the edge cases? How close did your solution get to optimal time and space complexity for the problem? How well did you communicate your thoughts and respond to questions?

Behavioral questions are typically reserved for more senior roles like management, as well as non-technical roles like sales and operations. When I interview, I only care about your ability to solve problems and communicate as you do it. In other words, don’t spend too much time worrying about the your outfit or the strength of your handshake.

Another crucial point: you will not have access to a compiler, shell, repl, or IDE. Phone screens are conducted in a shared Google Docs document. On-site interviews give you the option of either writing by hand on a whiteboard or typing on a laptop into a text editor. You’ll have no tools except yourself and your wits.

Now What?

Now that we’ve got all that out of the way, my next post will talk about my first favorite interview question, the Knight’s Dialer…

Update: you can check out the rest of the series here: