Between November 9, 2023, and February 2, 2024, I underwent a series of interviews at Google for the position of Site Reliability Engineer. Coming from a background as a Linux administrator and c/c++ software enginner, the process admittedly made me somewhat anxious. However, the interviews went well. I love to document my prepreation for future reflection.
Due to the nondisclosure agreement, I’m unable to share specific questions from the interviews.
HR sent me an email to discuss potential opportunities to work at Google as a Site Reliability Engineer (SRE). We scheduled a 45-minute Google Meet session to take place during the workday.
From the moment I received the initial call, I felt anxious, remembering how a previous call (6 years ago) from Google HR ended in rejection due to a mismatch in background. I totally agreed with what danrl emphasized in their article: “No interview should be perceived as ‘informal’ […]. Screening begins with the first call.” [1] Consequently, I decided to request a day off to thoroughly prepare for the interview. My preparations included basic questions like “why Google”, “Can you tell me something about yourself.”, along with a number of screening quizzes covering topics like basic Linux knowledge, fundamental big O algorithms, networking fundamentals including common ports, and the OSI model.
The interview went well, and HR told me there are two paths of Google SRE engineer: SRE-system enginner and SRE-software engineer.
The SRE-SE role places a significant emphasis on Linux system administration skills. In contrast, the SRE-SWE position evaluates candidates on their software knowledge and abstract programming abilities. SRE-SWE looks a lot like those exercises in leetcode. However, it is a bit unclear of what is expected during the interview for SRE-SE.
I found myself uncertain about which direction to take. With a background in software engineering, the SRE-SWE path seemed like a fit, offering a more defined roadmap for preparation. However, I found myself drawn to the SRE-SE role, as it aligned more closely with my understanding of what a Site Reliability Engineer should do. Ultimately, I chose to pursue the SRE-SE path.
I requested four weeks to prepare, and HR consented. Google was very accommodating in allowing ample time for interview preparation.
The interview invitation specifies that I am required to: 1. Write actual code based on Google’s documentation. 2. Select my preferred programming language. 3. Complete the task within a 45-minute timeframe.
The HR manager generously provided me with numerous resources on algorithms and data structures, in addition to inquiring about my preferred programming language for the interview. Previously, I worked as a C/C++ engineer, but considering the complexity of C++ in interview settings, I opted for Python due to its simpler syntax. Despite Python not being my strongest language, I chose it for its ease of use, though I’m uncertain if this was the best decision.
Based on the limited information, I have parepaed the following :
Tuesday, December 12th, 2023, I got my first Phone screen with a Google interviewer. It’s worth noting that the coding interface resembled that of a Leetcode online interview, offering pleasant syntax highlighting and appropriate indentation, although it lacked a “Run Code” button. The expectation wasn’t for me to produce entirely accurate code that passes all backend tests during the interview. Nevertheless, it was crucial for me to craft readable code, explain its implementation to the interviewer, and discuss its time complexity.
The interview was a bit easier as I imaged so I passed it for the on-site interview.
The onsite interviews have now been shifted to Google Meets, eliminating the need for me to drive three hours to Sydney for the interviews. However, this change also means missing out on the enjoyable aspect of meeting people in person, which I believe is most effective for mutual understanding.
The onsite interviews will cover the following topics:
Just like before, I requested six weeks to prepare due to the extensive range of topics I need to cover. The HR manager agreed to this request once again.
Among the five topics, I identified Linux/Unix internals as the area where I was least confident. Despite having nearly a decade of experience in Linux, including almost five years as a Linux administrator, I still believe there’s a significant portion of knowledge I’m lacking in this field. Consequently, I dedicated most of my preparation time to this subject. The topics I focused on include virtual memory, the Linux boot process, the virtual file system, networking, and block devices.
I discovered a series of videos [2] that were incredibly beneficial and engaging. To ensure I was well-acquainted with most of the content, I viewed them nearly 20 times. Additionally, I utilized Chat GPT 4 for assistance with my mock interviews, which I found to be exceedingly useful.
Apart from that, I also re-do the previous 100 leetcode challenges and make sure I am very confident to type python without IDE.
For Non-Abstract Large Scale System Design interview, I checked the various resources online [3], [4], [5], [6]. I love the concept of non abstract, and I even started to use this idea in my work which create really different effect. I really appreaciate Google tells me this.
When it comes to troubleshooting, I must confess it’s the aspect of preparation I find most confusing. The online resources for this are quite scarce. However, it seems that it involves a dialogue during the interview where you can pose questions, and the interviewer provides descriptions to assist you in diagnosing the issue.
I found the experience to be highly engaging. The interviewer posed a question I had never faced before and guided me towards the approach they preferred. It was somewhat surprising that they continued to ask me questions, even when I proposed an unconventional solution. I also found how limited my linux internal knowledge is even after I watched so many videos online.
The interview was somewhat more challenging than the phone screen, with a 30% increase in coding requirements compared to last time. I dedicated more time to completing all the questions they asked, leaving me with minimal time to ask questions from the interviewer. Whereas I managed to ask three questions in the previous session, this time I could only pose one question.
I must admit, I wasn’t too fond of their approach. They presented me with a hypothetical scenario that felt quite unrealistic. Additionally, they expected me to provide the ideal response as outlined in a book, but I struggled to grasp it thoroughly.
The overall experience was positive. It lasted 60 minutes, during which I fully utilized the time to implement the system using actual code, even though the interviewer mentioned that this wasn’t necessary.
I really enjoyed this one. Even though my answers didn’t align with the interviewer’s expectations, they were attentive and made an effort to understand my reasoning. Our conversation extended beyond an hour, resulting in a delightful and engaging exchange.
Throughout the interview, I noticed that many interviewers seemed unclear and hesitant to offer definitive opinions. They often expressed themselves with uncertainty, using phrases like “I think it might be” instead of providing clear guidance. This ambiguity reminded me of attitudes prevalent in many universities, where statements like “today is a good day” can be equated with “today is a bad day.” Yet, in certain aspects, they appeared rigid, insisting on specific criteria and showing reluctance to consider alternative viewpoints. It felt like navigating between the academic ambivalence of a university and the decisive expectations of a corporation.
Throughout the weekend, I reflected on how I could improve and what lessons I could draw from the interview. I came to realize that Google provided me with far more than I anticipated. I truly appreciate the considerable effort they put into preparing questions, trying to understand me, and keeping me engaged.
I unfortuntely failed but I hope my blog can help you gain some information in preparation Google SRE-SE interview.
[1]. https://danrl.com/srm/#screen
[2]. https://www.youtube.com/watch?v=5osOHhBWKOQ&list=PLSIUOFhnxEiC3YTdxwqZqgEY5imVL8U8J&index=1&ab_channel=GoogleTechTalks
[3]. https://www.youtube.com/watch?v=q0KGYwNbf-0&ab_channel=Cl%C3%A9mentMihailescu
[4]. https://www.youtube.com/watch?v=Gg318hR5JY0&ab_channel=LifeatGoogle
[5]. https://sre.google/workbook/non-abstract-design/
[6]. https://docs.google.com/presentation/d/1jW2S9yYZf5DYmri0KlOu1DFSZMTeOswl6ce5V9xMIOQ/edit?resourcekey=0-hzg8gPkGgiOc6HbBqalmWg#slide=id.p
[7]. https://interview.leetcode.com/interview/