A while ago I had an on-site job interview at Google. The position I was interviewing for was a Google SRE. SRE stands for Site Reliability Engineering. Site reliability engineers (SREs) are both software engineers and systems administrators, responsible for Google's production services end-to-end.
I interviewed with eight separate people. The first three were over the phone and the remaining five were on-site. The first interview was with the recruiter and was not very technical but the other seven were technical.
Unfortunately, I just learned that I'm not getting hired. The recruiter said that "the morning interviews were not that great" and "I should get more experience to work in their mission critical team."
Here is how it all happened.
Shortly after I published the Code Reuse in Google Chrome post, I was contacted by a recruiter at Google. The email said:
I recruit top notch Software Engineering talent at Google. I recently came across your name as a possible world class Engineer and am intrigued to know more about you. I promise to exchange some detailed info about us as well. Interested to hear more? Want to be an impact player at Google? Then please respond with a current (English) copy of your resume and I'll be happy to call you and discuss.
At first I thought I would be applying for a software developer position but after we went through my skillset, the recruiter concluded that I would better fit as an SRE. I agreed with him. This seemed like a perfect position for me. I love system administration as much as I love programming.
First Interview (phone)
The first interview was on 10th of September with the recruiter. He explained the Google recruitment process to me and we went through my skill set. I had to rank myself from 0 - 10 in a bunch of areas.
Here is how I ranked myself:
- C programming – 8
- C++ programming – 7
- Python programming – 6
- Networking – 6
- Algorithms and data structures – 6
- Distributed systems – 5
- Linux systems administration – 9
Based on my answers, we concluded that SRE was the best position for me. An SRE has to know everything: algorithms, data structures, programming, networking, distributed systems, scalable architecture, troubleshooting. It's a great hacker position!
The second half of the interview had some basic technical questions to make sure I wasn't bluffing. The questions were about Linux systems administration, algorithms, computer architecture and C programming. You can find all questions from all interviews at the bottom of this post.
I made a couple of mistakes but he was satisfied and we scheduled the next phone interview. He warned me that it will be very technical and I should do a really good preparation. I asked him to give me a plenty of time for the preparation and we scheduled the next interview on 22nd of September.
He also told me that each phone interview is going to be 45 minutes to 1 hour long.
I created a daily schedule and started preparing. I found three presentations on what SRE is all about:
- Engineering Reliability into Web Sites: Google SRE
- Google SRE: That Couldn't Happen to US... Could It?
- Google SRE: Chasing Uptime
Then I read all other blog posts about Google interviews, including typical qustions:
- Corey Trager's Google Interview
- Rod Hilton's Google Interview
- Ben Watson's Google Interview
- Shaun Boyd's Google Interview
- How I Blew My Google Interview by Henry Blodget
- Get That Job at Google by Steve Yegge
- Tales from the Google's interview room
- Google Interview Questions
- Google Interview Questions -- Fun Brain Teasers!
- And some others...
I printed and read four Google research papers:
- The Google File System
- Bigtable: A Distributed Storage System for Structured Data
- MapReduce: Simplified Data Processing on Large Clusters
- and just for fun Failure Trends in a Large Disk Drive Population
I also went through several books:
- the best book on basics of networking "TCP/IP Illustrated"
- the best book on algorithms "MIT's Introduction to Algorithms" + my notes on algorithms
- a book on scalability "Building Scalable Web Sites"
Second Interview (phone)
The second phone interview was with an engineer from Google. He worked on the Ads team which is responsible for running AdSense, AdWords, and other advertisement stuff.
The interview was very technical and started with an algorithmic problem which was too large to fit in computer memory. I had to tell him precisely how I would get around this problem and what data structures and algorithms I would use. He also asked me to think out loudly. The interview continued with questions about data structures, DNS, TCP protocol, a security vulnerability associated with TCP, networking in general, and Google itself.
The questions where:
- You've 100GB file but only 1GB of memory. How would you sort it?
- Tell me about your favorite data structure.
- How does DNS work?
- Can DNS work over TCP?
- How do DNS root servers work?
- How does BGP work?
- How does TCP work and what is 3-way handshake?
- How does TCP session spoofing works and how is it prevented?
- What would you change at Google?
After the interview the engineer had to write feedback to the recruiter. It was positive and I could move on with the interview.
Third Interview (phone)
I gave myself more time to prepare and the third interview was on the 1st of October. It was with an engineer from the Google traffic team.
In this interview, I had a very simple programming question and I had to do coding over phone. I was free to choose the language and I chose Perl as it is my most favorite programming language. It was impossible to dictate Perl syntax over phone "for my dollar sign element open paren at data close paren open curly brace ... close curly brace" so I submitted my Perl program over the email.
The question was: Write a program to find the set difference. Given two sets A and B, find elements in A-B, or in other words, find elements in set A that are not in B.
Then the same problem was taken to the next level, what if the data we are working on is gigabytes in size, terabytes in size. How would my program/solution change?
Finally I had a question about DNS again, then HTTP protocol, routing, and TCP data transfer.
The questions were:
- How does DNS work?
- How does HTTP work?
- What happens when you type www.google.com in the browser?
- If a HTTP request fails, does the operating system retry it, or the browser?
The feedback was again positive and I could prepare for the on-site interviews. In my conversation with my recruiter I got to know that there will be five on-site interviews, each exactly 45 minutes long. One on my previous work experience, one on algorithms and data structures, one on troubleshooting and networking, and two on software development with the focus on C and C++.
My recruiter suggested that I read a few more documents:
- Google C++ Style Guide
- Web Search for a Planet: The Google Cluster Architecture
- Algorithm Tutorials on TopCoder
Fourth Interview (on-site)
The fourth interview was finally at Googleplex in Mountain View. At 10am I met my recruiter and we had a 15 minute discussion about the interviews. He told me I would have two interviews now, then one of Google engineers would take me to lunch in one of Google's restaurants and then I would have three other interviews.
At 10:15am the first on-site interview began. It was about my previous job experience. I have had a lot of job experience in the past and I decided to tell about a physical security notification system that I coded in C on Linux a few years ago. The system received messages through the serial port, send out emails through SMTP, and text messages through a GSM modem.
In the last minutes of the interview he asked me some basic Unix filesystem questions, such as, what is an inode?
In all the on-site interviews I was writing and drawing on two big whiteboards.
Fifth Interview (on-site)
The fifth interview began at 11am. It was a coding session and began with a trick question and not a real coding problem. The trick question was this: "What's the angle between clock hands when it's 3:15?" Then I was asked to implement the solution in C for arbitrary time (hour/minute). The solution was a mathematical expression that was a one-line return statement. Then I was asked to write an implementation of a binary tree on the whiteboard. While coding, I forgot to initialize a data structure that I had mallow()'ed. The program would have segfault'ed in real life and I would have noticed the error. I said there were no errors here but the Google engineer pointed out I hadn't initialized data.
After this interview I was taken to lunch by the engineer who interviewed me on the second phone interview. She told me she was working at Google for two years and was very happy about it. We went to Asian food restaurant in Googleplex. Then she showed me around Googleplex.
Sixth Interview (on-site)
The sixth interview began at 12:45pm. It was a troubleshooting and networking interview. The interviewer drew a network diagram on the whiteboard and had imagined a problem in there. I had to ask a bunch of specific networking questions to locate the problem. He was satisfied and in the last few minutes of the interview he asked me some specific networking device questions, like what's the difference between a router and a switch, and what's OSI model.
Seventh Interview (on-site)
The seventh interview began at 1:30pm. It was a coding session. I was asked to implement a simple string manipulation subroutine that finds common characters in two C strings. I could use either C or C++. I chose C. I made an off-by-one mistake there. The whole interview focused on this one problem.
Eighth Interview (on-site)
The last, eight, interview began at 2:15pm. It was algorithms and data structures interview. The problem presented here was similar to the problem in the 2nd interview. Not only was it a problem too large to fit in computer memory but it also was distributed. How to sort data that doesn't fit in memory and you've got 100 computers to sort it. I had to do all kinds of trickery to solve it. The interview was very free-style and we talked back and forth about the problem. I arrived at the correct solution near the end of the interview and he said that not many candidates got that far. I was also asked if I knew map-reduce and of course I knew map-reduce as I just had read the Google paper. This was a map-reduce problem.
After the interview the engineer escorted me out to the lobby and I went back home.
Overall, the Google interview was super fun. I love trivia questions like this. The questions were technical but not very challenging or difficult.
Here are all the questions that I can remember:
- Tell me about one of the projects on your resume.
- What technologies did you use to get this project going?
- What if your project had 5000 or 50000 or 5000000 users?
- What's an inode?
- What's the angle between clock hands when it's 3:15?
- Write a C function that returns angle between clock hands for any (hour, minute).
- Implement a binary tree (on a whiteboard).
- How would you troubleshoot this problem - network diagram presented.
- What's the difference between a router and switch?
- Implement a routine in C that counts number of characters in a string.
- Given 100GB file and a computer with 1GB of memory, how would you sort it.
- Can you make it parallel and solve it on 100 computers?
- What's a priority queue?
- How does BGP work?
- Can DNS use TCP? In which cases DNS uses TCP?
- Implement set difference in any language you like.
- How does HTTP work?
- How does 3 way handshake work in TCP?
- What's the sticky bit?
- What's the system call for creating files?
- Order by execution time: reading disk, accessing memory, context switch, writing a cpu register.
- How would you count the number of set bits in a very huge number?
See you all next time!