I was contacted via LinkedIn by a Google recruiter. I'm not providing specifics on the questions due to a Google request, but you can find nearly all of them in other posts here or on other sites.
Initial interview with recruiter: I rated myself 1-10 in various areas, followed by technical questions that mostly had one-word, right-or-wrong answers so a non-technical recruiter could administer them.
Phone screen: The troubleshooting scenarios were typical things I'd seen in my 10 years administering a large network of Linux machines. For the coding exercise, I chose Perl because that's my best language, and as a result, I had to explain some of the code to the interviewer (I think Google uses mostly Python).
I was called the next night by the recruiter to inform me that they'd like to schedule the on-site interview in Mountain View. I was passed to another recruiter who specializes in SREs. This recruiter coordinated the scheduling and also the selection of the five interview topics. The recruiter followed up with Google research papers and several textbooks that I was supposed to read.
On-site interview #1: System administration. We spent most of the time working on the design of a hypothetical web service. I ultimately came up with a solution that I am pretty sure my interviewer hadn't anticipated, but he could find nothing wrong with it and seemed to accept my solution.
On-site interview #2: Troubleshooting. We made it through two problems, one dealing with networking and the other to figure out why a service was failing. I solved these problems quickly and beyond any doubt, and the interviewer seemed satisfied enough not to go on to another problem, so we spent about 15 minutes just talking about Google in general.
On-site interview #3: Large system design. The problem dealt with analyzing large volumes of data. I had read the Google research paper on MapReduce on the plane ride over, since it was one of the things the recruiter had said to read. I suggested that MapReduce might be a good solution, and I was then grilled for 30 minutes about the internals of how Google's current MapReduce works (even though I pointed out that my experience was limited to just having read the paper, and I'm sure that Google's MapReduce in 2013 works much differently than it did when they published the paper in the mid-2000s!). While I thought I did an admirable job on the basics given my lack of experience with that topic, this interviewer seemed to have a particular solution in mind that I obviously didn't get, nor did he really work with me to try to get there. So this one was probably a fail.
On-site interview #4: Perl coding. This consisted of a regular expression question and then a data analysis question with several iterations that made it progressively harder. I flew through these, and it was clear the interviewer was trying to come up with additional iterations of his question on the spot to fill the time. I was surprised that the question was as easy as it was, given Google's legendary interview coding questions.
On-site interview #5: Networking. I have never been, nor claimed to be, a network administrator, and this awkward 45 minutes simply evidenced that fact. The interviewer wasn't particularly helpful, and this was a definite fail.
After the last interview, I was left in a different place from where I was dropped off. I was unable to walk through the courtyard due to an employee-only party, nor did the recruiter come get me to take me to the Google store as he had promised. Therefore, I had to walk around the edge of the campus and the backs of the buildings to get back to my car. This left a sour taste.
The next week, I received a call from the SRE recruiter informing me that I'd done really well on three interviews and that they really didn't care about the networking interview because I wasn't interviewing to be a network engineer. They wanted me to repeat the large system design interview via phone. I had seen enough of Silicon Valley to know I didn't want to move there, and I didn't want to muddle through another MapReduce problem, so I told the recruiter I wasn't interested in continuing.
A week later, I received a call from the original recruiter asking me to reconsider and describing other, more family-friendly offices (e.g., Seattle). Over the next week, I talked to an employee who worked in Seattle and confirmed that this may be a better cultural fit, so I agreed to do the follow-up interview. This occurred two weeks later via phone and was much more of the format of starting with a small setup and determining bottlenecks along the way. I did well on this interview.
I was contacted by both recruiters the next day to let me know I had done well, and I was requested to provide contact information for references. About a week later, I received my verbal offer and subsequently declined.
I'm honoring Google's request not to share specific interview questions.
The following metrics were computed from 71 interview experiences for the Google Site Reliability Engineer role in United States.
Google's interview process for their Site Reliability Engineer roles in the United States is extremely selective, failing the vast majority of engineers.
Candidates reported having very good feelings for Google's Site Reliability Engineer interview process in United States.