Interviewing for Google’s SRE

(This is article was actually written around half a year ago when I did my interview and I got hired. It is solely my own view of the interview process I had. This is by no means a guide or similar, so take it with a pinch of salt. And of course, your mileage may vary)

Recently I had the opportunity to do an interview at Google’s office for Site Reliability Engineer role (SRE) (around May 2019). I was really scared on how hard it could be, how much I could be asked to do and I couldn’t sleep much past 5am. In the end it was a really nice day, had a lot of good moments and I loved to be able to chat to so many Googlers in the day.

You might be asking yourself if is it hard to do one of these interviews. Well, yes, it’s by far the hardest I ever had to date. But also it looks like one of the most fair interviews processes you can have which is really good.

I was scared that I could get asked things like “balance a binary tree” or “explain Dijkstra or A* algorithms”. While this might be the case for other interviews at Google (because, well, I only had one) but this wasn’t the case for me. And for every problem I was asked for, they never assumed that I knew what they were talking about, so they explained always in layman’s terms the rules of the game.

I’m not going to disclose any of the actual questions or specifics of my process, because those might be reused and the point is that you should be able to be capable of creating the algorithms from scratch and understand them, instead of regurgitating an answer that was studied earlier. I will give similar examples that are publicly available that I feel are on the same complexity level; but not too similar.

Google strives to get the best engineers, so their interview is intended to gather as much data as possible to make a hiring decision. As with almost any other company if they have doubts, they will not hire. So gathering more data means less doubt, so this leads to have a fair process. The price to pay is having a hard interview process in order to get the best from each candidate.

The atmosphere there has been at all times really friendly and relaxed. The offices have breaking design, I didn’t feel being an at office at all; it’s like a place I could party there with friends all day.

So don’t worry if the interview process seems too much from the outside. It’s not. All you need is a lot of practice with algorithms and some other side knowledge. If you’re confident and fast thinker for the typical interview problems you’re set.

Without delaying it more, I’m going to describe the process in my case.

First, a Google recruiter contacted me and we set up a call to chat. In this call there was a few questions with options for answers, like a test. This is a quick check to assess which areas are best for you in order to send you to the right path on the next interview step. I failed more than 10% of those and still that was very good, so no worry. I guess if you can’t reach a minimum in any category you might not proceed but I don’t know if that could be the case.

After one or two weeks I got my first interview call which used Google Docs for coding, so you can’t depend on autocomplete or syntax highlighting. There are a few guides on internet on how to setup Google Docs so it is easier to code with it. I fully recommend to follow them before taking the interview. If not, Google Docs will get in your way while typing.

For example, this one describes how to configure it:

Most questions have two parts, they first ask a simple problem and after that is solved and discussed, then they ask another question that usually can be built on top of the last one. And the second question is the one that is usually tricky. If there’s time left, it will be used to discuss the performance analysis on the final solution.

In my case I found this first interview “easy”, I could recall the related algorithm to do what I was asked for and I could code it really fast so I ended with spare time.

After that, as the feedback was good, I moved to the next stage, which is the on-site interview. This is arranged 2-3 weeks after, and in this particular role had 5 interviews on it, full day. Drinks and food is provided by Google for free, and don’t be afraid of taking as much as you’d like. Do it and have a nice day at Google’s office!

My on-site interview took from 10am to 3pm with a lunch break. There were 3 coding interviews, one NALSD (more on that later) and one for leadership/behavioural.

For the interview you have access for both, a whiteboard and a laptop. The laptop has a basic editor that does highlighting and tab+bracket helpers, nothing more. No access to internet.

In my case the laptop was not working for two of the three coding interviews so I had to code using the whiteboard only. Not a big deal, just bear in mind that is almost impossible to move code around, so think how the code is going to look like before writing it down.

I found the whiteboard really useful to explain concepts and do abstract drawings that described how it is supposed to work. It is way better than explaining using text only.

On the actual problems presented for the coding interviews, I found them harder than the one from the phone interview. This makes sense to me so it might be common. As before, they are usually planned as a first simple problem that is easy to solve but gets your brain warmed-up to the task at hand. Then they ask a second problem that is harder but it builds on top.

Don’t be afraid to ask for directions. Also, speak up all the time what you’re thinking, they should be following your reasoning as you go. Some problems may have missing data on purpose. Is your job to detect what’s missing and ask the interviewer.

But what is going to be asked you might ask. The problems there resemble a lot to those in The “Interview Preparation Kit” contains a lot of those with varied topics. Highly recommended:

From those, there are around 25% that are highly complex and will never be part of an interview; just because they cannot be finished under 40 minutes unless you know the answer beforehand. Pay attention to the “Success Rate” on each problem. Those lower than 80% tend to be too hard for an interview, so you may want to skip them altogether.

Anyway, if you have extra time, it is good to do the hard problems as well, because what Google tests isn’t if you knew the problem, what it tests is your ability to come to your own new solution, so practicing really hard problems even if they cannot be in an interview will give you the knowledge on how to solve a new problem in less time.

I also studied on creating unbalanced binary search trees, binary heaps, hash tables with linear probing and chaining, linked lists, merge sorts and quick sorts. Most of that wasn’t required for my coding interviews, but that might be different depending on interviewers.

Also, don’t forget about path-searching algorithms, at least the basic Breadth-First and Depth-first. Object counting in a matrix and other cool stuff to do with 2D vectors, like labyrinth solving problems.

It might seem unfair to test around those topics because “no one codes a tree in real life anyway”. But at the scale level that Google operates they actually have to code those from time to time. And also, it’s the best way available to test candidate skills when you try to differentiate between good candidates from the excellent ones. So, don’t expect to be able to crack Google’s interview without studying these. I didn’t mention yet the Big O notation, but of course that is needed; just I think it’s kind of implied here.

With that, I do think we’re set on the coding part of Google’s interview. My next topic is the Non-Abstract Large Scale Design interview (NALSD).

I got really scared when I learned that they were going to ask me how to scale things across datacenters, like how many servers are required to do some task. How the hell am I supposed to answer that? I never had experience at such scales and if I don’t work at a place like Google I would never expect to have it.

But it’s simpler than it sounds. The recruiter shared to me material to learn these. And by googling for a bit I found a really nice course at that has really good material for this:

It has a few free articles that might be enough for the interview. In my case the interview started with a fairly simple problem and it was calculated using the same approach as described in the site and the recruiter materials, so far so good.

As this interview for NALSD progressed it became more and more concise with questions that I had less good answers each time. As from my interviewer words: “This just gets harder as we progress, don’t worry, it’s normal”. So no matter how good you are on this, if you progress fast enough you will be facing at some point incredibly concise questions with apparently no good answer. The further you get, the better. This is like Tetris in endless mode; it ends when your screen is full, or in this case, when time is up. Also be aware that numbers here are not expected to be precise, it is just a ballpark. As long you aren’t too off (by a factor of 2-3) you should be good. I could “amend” the numbers a bit to make math easier to do without a calculator. And most questions don’t have one correct answer, so don’t worry. As long as your design seems to work without any big flaw, you’re good to go.

To understand this topic you should have had to manage servers before. It doesn’t need to be a big cluster, in my case I only managed single computers (but a lot of them), so the concepts are easy to grasp to me.

Last thing I want to cover is the behavioral interview (or leadership interview). They call it Googleyness interview or how to be “Googley”. There’s not much out there about those terms so you might find yourself lost on what you can be asked. From my experience this is exactly the same as Amazon’s Leadership questions but way less intimidating.

So, to get an example just google for “amazon leadership principles questions” and browse around. This one gives a good list of questions:

In this case I found that the interviewer helped a lot directing me onto the right topics when I was answering, and I could talk freely like chatting to a friend. I believe it’s better to memorize topics, not full answers. Once you start talking about a topic, the interviewer will direct you on the right track and you just have to keep talking. In my case at least, as I started on a topic, it is really easy to pull the details from my mind.

One really interesting thing I noticed there is the interviewers take tons of notes. I never saw anyone taking so many notes before. For the amount of typing I would say there’s around one or two pages of feedback per interview. I’m certainly impressed by that, this will for sure make the decision as objective as possible and as fair as it can be.

Interviewing is stressing no matter how is done, but Google really polished it a lot. Really appreciate the amount of thought and effort they put onto this. Also, their process makes also the life of the interviewee easier; by being able to take most of the process by a short call (30min-45min) and the final one by concentrating everything on the same day. This allows us to interview without losing much work time while they are getting tons of data to take the right decision.

As a final note, I was scared a lot by lots of different things. And I learned that there’s no reason to be scared. It is a really nice place with nice people. So if you’re to be interviewed by Google, hope this served to clarify a bit on how it works and what do you need study to do it.

PD: As said, I got hired. Thanks a lot to all my interviewers who did an awesome job, to my girlfriend which gave me a lot of support during all this time studying and to my managers at BAML who understood my decision. It’s hard to see people go and I miss my old coworkers but I am also enjoying a lot my new team.