Recruitment process for a Google job (SRE, Site Reliability Engineer)

Since I recently have taken part in the recruitment process for a job at Google, I thought I’d share this experience on here.

The beginning

One day I got an email from a Google recruiter in Dublin, saying that they’ve recognized my github projects and LinkedIn profile and that they think I might be suited for a job in the role of a Site Reliability Engineer (SRE), located either in Dublin, London or Zurich. I was all excited about this, so I responded to the mail and thought that I’d have to have a look at the recruitment process .

After I had responded positively, the recruiter asked me to send out a current CV first, so she’d get a more detailed impression of who she was dealing with.

First phone call (~60 minutes)

Having completed and sent the CV, it was suggested to have a first phone call with the recruiter. As preparation for this, I was asked to estimate my own skills in the following topics on a scale from 0 (weakest) to 10 (strongest):

• TCP/IP Networking (OSI stack, DNS etc)
• Unix/Linux internals
• Unix/Linux Systems administration
• Algorithms & Data Structures
• C
• C++
• Python
• Java
• Perl
• Shell Scripting (sh, Bash, ksh, csh)
• SQL and/or Database Admin
• Scripting language of choice not mentioned: _______________
• Management

A day later I had the first phone call. The recruiter described the SRE job in detail and asked me if I was still interested and if we could go on with a few technical questions to have a first little check on my skills. The recruiter herself didn’t have much of a technological background, so she took the question from a catalog that also provided one or several valid answers to each question.

One remarkable thing was that all questions were taken from the topics that I had rated myself best in.

The recruiter also asked me, which “flavor” of interviewing process I would prefer for the upcoming interviews. For SRE jobs there seems to be one flavor that is more focused on programming & software development, and the other one focuses on system & network administrations stuff. I didn’t give a clear answer to that, since I always liked both domains equally well, and also have gained about as much experience in one as the other, so I didn’t really care about which flavor of recruitment process I would go through.

Well, long story short, in the end of the call I was told that my answers would be presented to some more people at Google to gather some more opinions about my performance.

Luckily, about a week later the recruiter called again and told me that I had made it, so we scheduled another phone interview, this time much more technical with an SRE engineer.

Second phone interview (~60 minutes)

The recruiter sent me a lot of preparation material beforehand, so I had a lot of stuff to refresh and read.

For the interview, a Google doc was shared with me. Not only did the interviewer use this to write down tasks for me, but I also wrote down my script- and code snippets that I worked out as answers to the presented tasks of the quiz.

During the interview I was confronted with several topics, mainly:

• shell scripting
• C programming
• networking protocols

These tasks were designed to check rather deep understandings of the covered topics – it wasn’t enough to just have a superficial knowledge. This didn’t mean that you were supposed to know all command line switches of shell commands, or the exact parameter list of all syscalls or library calls you wanted to use, but you were expected to know that the calls themselves existed, what they are used for and why you should prefer one thing over another for example.

Another thing that I noticed was that there were relatively many questions regarding performance issues. That at times came even down to a physical level, where I found myself mentioning speed of light as a limiting factor to how fast a network packet could travel from point A to point B.

It again took around a week to get feedback on how Google liked my performance. I was glad to receive a call from the recruiter and be told that the feedback had indeed been very good.

So, the next phone call was scheduled.

Third phone interview (~45 minutes)

This time the task was C programming again and the programming task was complex enough to spend most of the time with. While in the previous call the C programming part just required me to write a few lines regarding very detailed problems, this time I was asked to develop an entire routine to solve a certain problem.

I started with a simple algorithm that I knew was slow and far from optimal, but very certainly worked. Afterwards I started to optimize the algorithm’s performance. That all went quite ok and I think in the end I had a routine that worked quite efficiently although it still had a bug as I found out when I tested it for real after the call had ended.

Before the end of the call the interviewer asked me some questions about networking, but this time these were relatively brief, since time was running short. I don’t remember the exact topic, but I remember that I could answer the question without much of a hassle.

Around a week later the recruiter called and once again reported “very good” feedback, so I could go on and have an on-site interview in London.

From this point on, when I had successfully passed the phone interviews, a different recruiter took over and called. He told me what the on-site interview would be like. He also checked if I still was interested in getting hired and if I was aware of the consequences regarding moving to a different city and even country etc.

On-site interview

A few days later I got an email suggesting a date for the interview. I had to confirm this date was fine for me and after that I relatively quickly received confirmations for the flights and also the hotel that I was going to stay at the night before. The arrival was scheduled for a Sunday, then on Monday I would have the on-site interview with the flight going back on Monday evening. The hotel was right across the street of the Google building, which I really liked a lot, since it meant I didn’t have to find my way through London in the morning before the interview.

So, with all this settled, I had another final call with the recruiter, just a few days before departure, in which he roughly briefed me for the interview day. There would be 5 interviews on that day, 45 minutes each. Each interview would be done by just one dedicated SRE engineer, the only exception being one, in which a passive person would just sit by and learn how to do interviews.

So when I arrived at 10:00 AM in the morning, I was picked up by a person that I was instructed to ask for. He showed me around the office a bit and we picked up something to drink before we went to the interview room.

Interview 1, 10:15 AM: C Programming

The first interview started at 10:15 AM and covered programming. The recruiter had told me I could choose the programming language in this one – however, in reality it turned out that the interviewer had prepared for tests in C.

As a first task I was handed a little snippet of code that I should analyse and tell what it would do. As it turned out, this code snippet was quite tricky, but luckily I could figure out its function.

The second task was to develop a routine for a given task, which I had to do on a whiteboard. Again, I managed to create a first simple, but inefficient version of an algorithm, but there was no time left in the end to do performance optimizations. Instead, we just briefly talked about what could be optimized and how.

My feeling was that this first interview had gone quite well.

Interview 2, 11:00 AM: Linux troubleshooting

The second one (11:00 AM) was on troubleshooting; what if this and/or that happens on a Linux server? How do you find out the cause of the problem and how to you solve that issue?

I was presented with many questions, describing certain situations and I should find solution approaches to each of them. I think I could give good or acceptable answers to most of the questions. However, at times it got somewhat hypothetical, because I was just giving a few ideas on what could be a reason for a given behaviour of the system – without knowing for sure if in reality it would turn out to be a possible cause for the situation.

Well, but at least to every question I had several ideas on how to proceed, and I suppose this is an important skill for being able to manage troubleshooting, so I assume that it has been recognized in a positive way .

In the end I had a positive feeling about this interview as well.

Interview 3, 11:45 AM: Networking

Third one (11:45 AM) was on networking. Explaining network protocols, discussing how I would myself implement certain functionalities if I was in charge to do this; where are security and/or performance issues to be expected?

Basically, the interview dealed with just two network protocols, of which one was fairly popular and well known and the other was probably somewhat less known. However, I was lucky and knew details about both of them.

This interview went almost perfect – there was very little that could have gone better I think. The interviewer and I even had a nice chat in the end, discussing some funny experiences we each had had in our careers. Very nice .

Lunch, 12:30 AM – 1:30 PM

Then I had lunch, for which another SRE engineer picked me up. He explicitly told me that this was not a test and he indeed was not one of the guys that would be doing an interview with me on that day. So this was the opportunity for me to ask some questions. We covered a lot of topics… from how emergency shifts in that SRE job are like, over some details about how Google does revision control to some topics that were not directly related to the job, like the housing situation in London.

After lunch we had a coffee before I was brought to another interviewing room for the last two interviews that were to come.

Interview 4, 1:30 PM: Large systems design

So the fourth interview (1:30 PM) on that day was the large systems design interview. Unfortunately, I was a blockhead on this one, then got nervous more and more and thus failed it. In retrospective, the task was not that difficult, I just had the initial problem of that I didn’t exactly know what was expected and on which detail level I should start solving the problem. Of course I tried to ask the right questions, but I also got nervous when I realized that it wasn’t going well, and that of course didn’t help. After all, in the end I had come up with something that you could call a first solution approach, but it was far from perfect.

Too bad!

Interview 5, 2:15 PM: Unix & Linux internals

The last interview went almost perfect again. This was about Unix & Linux internals, so I was confronted with several situations and had to find solutions. This covered “normal” day-to-day system administrator tasks as well as deep OS knowledge topics that you usually don’t have to worry about too much when doing your system administrator’s daily work.

I even came up with an idea that the interviewer called “very nice” and he himself had not thought of before, so in the end I had a very positive feeling regarding this final interview.

After being done with all interviews, tasks and tests, the last guy showed me around the office a bit to show me some more rooms and locations that I had not seen before yet, and then escorted me out of the building and said goodbye.

In summary, I had somewhat mixed feelings about how it went, because of the one interview that I could have done a lot better in if I had maintained a cooler mind. However, during the following days I was still thinking that I could have made it, because I had done well in seven of eight interviews overall (including phone calls), so that rate didn’t seem to be too bad. And additionally, the subject that I had failed was one that they should expect most candidates to have little experience in, and hey… having a subject to learn could also be interpreted as a challenging and thus motivating factor, right? Cause in fact I love learning new stuff and expanding my horizon to prevent getting bored.

A day later I wrote a short summary and sent it to the recruiter. I told him my impressions on how I had performed on each interview.

Well, to cut a long story short, that one failed interview was enough for Google to reject me. The recruiter called a few days later and told me that he was afraid that Google could not make an offer at the time. He explicitly mentioned as a reason that one specific interview. He also told me that indeed I was right in that I had done really well in especially the networking and Linux internals interviews.

However, he said if I should decide to apply again later, I could of course contact him again.

I don’t know yet if I am willing to give it another try some time.

A few summarizing thoughts

There are some things that I found to be remarkable in the process of hiring people at Google.

I found it amazing that for each of the interviews I was given enough information in advance to actually be able to prepare myself. I suppose this allows for tests that are much more detailed than if you don’t give the candidate hints about the subjects that will be covered.

Another thing of course is the great dimension of this interviewing process. This was by far the most extensive interviewing process I have gone through in my career and I don’t think it will ever get more extensive than this.

The fact that virtually every interview was an individual thing shows how much effort Google puts in giving as many employees the chance to get an impression on a candidate. I think that is a good thing.

The personal benefits that I gain from this entire process are that I now know that, with my skills, I can compete on this very top level of computer engineering. Sure, Google in the end has not offered me a job, but it was a close call:

I made it through all the phone interviews and could also manage most of the on-site interviews. I didn’t feel overwhelmed by all the questions they asked me, instead I in fact could answer most of them.

From what I have gone through in the interviews, I am profoundly confident that I could have done this SRE job, that it would have been interesting and fun, and I could most probably have done it well.

One last thing: The organization of the flights & hotel was really nice as well as the fact that I didn’t have to pay for anything. I recently even got the reimbursement for the transit from airport to hotel in London as well as the dinner on the evening of arrival.

Oh… and… the offices are really as awesome as they are being shown on the web .

Looking forward to your remarks, questions etc.