Google Site Reliability Engineer interview questions

Contacted via LinkedIn by a Google recruiter. I'm not providing specifics on the questions due to Google request, but you can find nearly all of them in other posts here or at other sites. - Initial interview with recruiter: rate yourself 1-10 in various areas, then 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 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 map reduce on the plane ride over, since it was one of the things the recruiter had said to read. I suggested that map reduce may be a good solution, and I was then grilled for 30 minutes about the internals of how Google's current map reduce works. (Even though I pointed out that my experience was limited to just having read the paper, and I'm sure that Google's map reduce in 2013 works much differently than it did when they published the paper in the mid-2000's!). 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. 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 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 map reduce 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 received my verbal offer and subsequently declined.