If you’re hoping to become a Google Site Reliability Engineer, you’ll need to ace the interview. This blog post will give you an overview of some of the most common questions you can expect to be asked during your interview, so you can go in feeling prepared.
- What’s the difference between DevOps and SRE? …
- Why do you wish to become a Google Site Reliability Engineer? …
- What are the biggest issues in your current deployment pipeline? …
- What tools, programming languages, and architecture are you familiar with?
Meet Site Reliability Engineers at Google
Interviews for Top Jobs at Google
Site Reliability Engineer Interview
ApplicationI applied through an employee referral. The process took 5 weeks. InterviewThe interview consists of two phases: a phone interview and an in-person interview. I interviewed at Google (Warsaw, Masovia) in September 2021. Three algorithmic interviews, one googliness interview, and one system design interview made up the onsite interview. The whole interview process was online. Interview QuestionsThey asked me to not reveal their questions.
Site Reliability Engineer Interview
I applied and was interviewed by Google. I skipped the phone interview because I had a referral. Final round was 5 rounds of 45 minute interviews. 4 rounds technical, 1 behavioral/googliness interview. Spread across 2 consecutive days remotely over Google Meet. Design a data structure to read a stream of temperatures and determine the maximum over the previous 24 hours.
The goal of this repository is to compile helpful materials for Site Reliability Engineer (SRE) interview preparation.
I had to do some very basic programming over the phone for this interview’s question. Given the option, I chose Perl because it is my all-time favorite programming language. The Perl syntax “for my dollar sign element open paren at data close paren open curly brace” could not be spoken over the phone. I sent my Perl program over email using the phrase “close curly brace.”
The fifth interview began at 11am. It was a coding session that started with a prank question rather than a genuine coding issue. What is the angle between the clock hands at 3:15? was the trick question, and I was then instructed to implement the answer in C for any time (hour/minute). The answer was a single-line return statement in the form of a mathematical expression. Then I was instructed to draw a binary tree implementation on the whiteboard. I had mallow()ed a data structure while coding, but I forgot to initialize it. In the real world, the program would have crashed, and I would have seen the mistake. Although I insisted that there were no errors, the Google engineer pointed out that I hadn’t initialized the data.
The interview began with an algorithmic problem that was too large to fit in computer memory and was very technical. He needed to know exactly how I would solve this problem, what data structures and algorithms I would employ. He also asked me to think out loudly. Questions about data structures, DNS, the TCP protocol, a security flaw in the TCP protocol, networking in general, and Google itself were asked as the interview progressed.
Again, the feedback was favorable, and I was able to get ready for the in-person interviews. I learned from my recruiter that there will be five on-site interviews, each lasting exactly 45 minutes. One will be about my previous employment, one will be about algorithms and data structures, one will be about networking and troubleshooting, and two will be about software development with a focus on C and C++.
The seventh interview began at 1:30pm. It was a coding session. A straightforward string manipulation subroutine that searches for shared characters in two C strings was given to me to implement. 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.
How is this reflected in the day-to-day work and responsibilities of an SRE team?
An SRE team is typically in charge of emergency response, capacity planning, change management, monitoring, performance, and efficiency.
Similar roles are played by many operations teams today, sometimes without some of the components I’ve mentioned. But the way that SRE does it is quite different. Thats due to a couple of reasons.
Number one is hiring. We hire engineers with software development ability and proclivity.
Software engineers, according to SRE, are individuals with sufficient knowledge of programming languages, data structures, algorithms, and performance to be able to create software that is efficient. Importantly, while the software may complete a task upon launch, it must also be effective in completing that task as it expands.
“Normally, we hire a roughly 50/50 mix of individuals with a stronger background in software and individuals with a stronger background in systems.” It seems to be a really good mix. “.
We look for candidates who are on the cusp of passing the Google SWE bar and who also have a complementary set of skills that are helpful to us during the hiring process. We typically look at network engineering and Unix system administration, but there are other areas as well. We employ those individuals for SRE who have strong software aptitudes but perhaps lack professional development experience and are also experts in network engineering or system administration. Our typical hiring ratio is roughly 50/50 between those with a stronger background in software and those with a stronger background in systems engineering. It seems to be a really good mix.
Even when it was very difficult to find candidates, we have maintained that hiring bar over the years. However, there has been significant pressure to lower that bar in order to increase hiring volume. Weve never changed our standards in this respect. That has, I think, been incredibly important for the group. Because of this, you end up with a group of individuals who fundamentally reject doing things by hand repeatedly and who also share the majority of the development organization’s academic and intellectual background. This guarantees that SRE and SWE have common language and respect for one another.
One of the differences between engineering and operations roles is that there is typically a chasm in terms of background knowledge, vocabulary, and eventually respect. This, to me, is a pathology.
FAQ
What are the interview questions for site reliability engineer?
To assist you in preparing for a site reliability engineer interview, the following sample interview questions and responses are provided:How can an organization increase its observability? Can you explain what SLO means and why it’s important? . What is cloud computing? . How can the partnership between the IT and operations teams be strengthened?
What is SRE role in Google?
Site Reliability Engineering (SRE) is the method used by Google to continuously define reliability goals, measure those goals, and work to improve our services as necessary.
Is site reliability engineer a hard job?
But it is not an easy job. As was previously stated, an SRE requires development and operations skills, or a skill set with a pi shape. An SRE must be skilled in both trades to possess this skill set, not just one, which is known as a T-shaped skill set. This makes SRE a very demanding and practical career.
How many site reliability engineers does Google have?
In Munich, he oversees three horizontal SRE teams and is in charge of maintaining Google’s SRE Engagement Model, a set of guidelines for SRE and developer cooperation. With between 50 and 300 SREs in each of its product areas, Google has more than 3,000 engineers.
