SRE
What the work looks like, the stacks behind the title, what each level means and the training that helps, then how interviews run and how to prepare for each step.
What a site reliability engineer actually does
An engineer who keeps production systems reliable, fast and available, with measured goals, strong incident practices and a lot of automation.
A site reliability engineer, or SRE, owns the reliability of production systems. They define service level objectives with product teams, measure them with observability tools such as Prometheus, Grafana and OpenTelemetry, and use error budgets to balance speed and stability.
SREs lead incidents, run blameless postmortems and plan capacity. They write code in Go or Python to automate repetitive operations work, often called toil, and they know Linux, networking and load balancing in depth.
The practice was made popular by Google, which published books on site reliability engineering. More and more teams also work with AI coding tools such as Claude Code, Cursor or GitHub Copilot, and expect engineers to use them with judgment.
- An on-call shift or an incident review
- Writing a postmortem and its follow-up actions
- Defining or reviewing SLOs with a product team
- Automating a manual operations task
- Capacity planning or a load test
The same title, very different stacks
Most SRE searches are defined first by the part of reliability the team focuses on, then by the ground every SRE shares.
What each level means in practice
Titles vary from one company to the next. What changes from one level to the next is the scope you own and the decisions you take.
- Takes part in on-call with a senior SRE
- Learns the systems, the tools and the runbooks
- Automates small tasks with code review
- Handles incidents and on-call on their own
- Builds monitoring and automation for a service
- Works directly with product and development teams
- Leads incidents and sets SLOs for a domain
- Takes choices on reliability and capacity
- Mentors other engineers and leads postmortems
- Sets reliability practices across teams
- Leads choices on observability and architecture
- Writes the design documents others build on
The paths into the role, and what really counts
Companies look first at systems you have kept reliable and incidents you have led. Education and certifications help most early in a career, or to change field.
- Engineering school or master's in computer scienceThe most common path in France, and often expected by large companies.
- University degree in computer scienceThe most common path in the US, at bachelor's or master's level.
- DevOps or system administration firstMany SREs start in DevOps or system roles before owning reliability.
- Backend engineering firstBackend engineers who like production systems also move into the role.
Our view: for this role, an incident you led or a reliability gain you measured often says more than any certificate.
A conversation with a senior tech recruiter
Your first interview is with one of our senior tech recruiters, who knows the role, the stacks and the levels in this guide. The conversation covers your own work through real examples, and the technical exercises come later, with the company. Before the call, we send you the six themes we will cover so you can prepare your examples.
- What you owned yourselfThe services, platforms or on-call scopes you were responsible for, and your own part in the team's work.
- Your environment and its constraintsTraffic, uptime goals, team size, legacy systems or budget: what shaped your technical choices.
- The decisions you madeWhich SLOs, which alerts and which automation, the options you compared and the reasons for your choice.
- The impact of your workWhat changed thanks to your work, with numbers when you have them: uptime, incidents, time to recover or toil removed.
- How you work with other teamsYour work with product teams, developers and support, and how you settle a disagreement.
- What you want nextThe kind of systems, scale and scope you are looking for in your next role.
- Reliability gains you measured
- How you lead incidents
- Automation of toil
- Depth on Linux and networking
The same ground for every candidate. For a given role, every candidate answers the same final questions, built with the hiring manager around what the role really needs.
Ready for the next steps. After our call, we tell you how the company runs its interviews, who you will meet at each step and what each step is meant to assess.
What the company will assess, step by step
Each company runs its own process, and we walk you through its steps before you start. SRE processes often combine the steps below, and the depth expected at each step grows with your level.
- A coding exerciseLive coding in Go or Python, often on automation, parsing logs or a small service.
- A systems deep diveQuestions on Linux, networking, DNS, load balancing and how a request travels through a system.
- An incident scenarioA live outage to investigate, and how you lead the response, find the cause and communicate.
- A reliability designA service to make reliable, with SLOs, monitoring, alerts and capacity.
- ConfirmedYou solve the exercise cleanly, know the basics of Linux and networking and explain each step in simple words.
- SeniorYou lead the incident and the design, weigh speed and stability, and point out risks before you are asked.
- Staff and PrincipalYou run most of the interview as a peer, think about reliability across teams and connect it to the goals of the company.
How to prepare as an SRE
Practical advice for each step of an SRE process, from the way you introduce yourself to the questions you ask at the end of each interview.
Start with the systems and on-call scopes you worked on, their scale and your part in them. Mention your stack in one sentence, then close with what you want next.
For each one, prepare the context, the constraints, your decision, the options you set aside, the result and what you would change today. Say "we" for the team and "I" for your own part.
Interviewers often go deep on how systems work. Review processes, memory, DNS, TCP and load balancing.
In an incident scenario, say what you check first, how you limit the impact and how you keep people informed.
Prepare the SLOs you set or followed, the error budgets and one decision they changed.
Rules on AI coding assistants differ from one company to the next, and sometimes from one step to the next. Ask before each step, and when they are allowed, explain what you ask the tool and how you check its output.
- Walk us through an incident you led, from the alert to the postmortem.
- What happens when you type a URL in your browser?
- How would you set SLOs for a new service?
- How do you decide which alerts should wake someone up?
- Which services does the SRE team own?
- How is on-call organised, and how often?
- How does the team use SLOs and error budgets?
- How are postmortems run and followed up?
- How much time goes to projects and how much to operations?
- How does the team use AI coding tools day to day?
Where SREs come from, and where they go
The roles people most often hold before this one, and the ones they most often move to.
Many SREs also start as system administrators, and some become heads of reliability.