SRE (Site Reliability Engineer)

Also known as: Site Reliability Engineer, Reliability Engineer, Production Engineer, Senior SRE, Infrastructure Reliability Engineer.

What does an SRE do?

An SRE (Site Reliability Engineer) is an engineer who owns the reliability of services in production and treats operations as a software engineering problem: they write code that replaces manual work. In the approach formulated at Google, an SRE spends no more than half their time on operational work (tickets, on-call, manual tasks) and the rest on development. Typical tasks:

• define SLIs and SLOs together with product teams and track the error budget;
• build monitoring, alerts and observability so that problems are visible before users notice them;
• go on call, lead incidents and run blameless postmortems;
• find bottlenecks and causes of degradation under load, from memory leaks to database settings;
• automate repetitive operational work so that growing load does not require a growing team.

When does a company need an SRE?

A company needs an SRE when downtime starts costing money or customers, and incidents keep recurring because nobody analyses them systematically. This is usually a company with significant load and several teams that sells to enterprise customers with SLA requirements or is entering new regions. Another trigger is product teams spending more time on firefighting than on new features. If the load is small and an hour of downtime worries no one, a dedicated SRE is overkill: on-call can be shared among Backend Developers, with infrastructure handed to a DevOps Engineer.

SRE vs DevOps Engineer: what's the difference?

An SRE differs from a DevOps Engineer in being responsible for reliability measured in SLOs rather than for infrastructure and code delivery as such. A DevOps Engineer builds pipelines and environments so that teams can ship changes; an SRE decides how much failure a service can afford and stops releases when the error budget runs out. In practice the titles are often mixed, so what matters more is how much of the work is code. What sets an SRE apart from a Platform Engineer is the focus on production rather than on developer experience.

SRE vs related roles: comparison

Why is it hard to hire an SRE?

An SRE is hard to hire because people with very different backgrounds work under the same title, and strong developers are a minority among them.

• At many companies SRE is the title for administrators and on-call engineers who tune alerts but write almost no code.
• The role needs a rare combination: deep knowledge of Linux, networking, Kubernetes and databases plus the level of a developer who can pass live coding and algorithm tasks.
• Experience of incidents under heavy load can only be gained at companies that have such load.
• On-call puts off some strong candidates, and without an honest account of on-call duties offers fall through at the final stage.

What to decide before hiring an SRE?

• What SLOs do the services have today, and who sets them? If there are none, an SRE's first months will go into agreeing them with product, and expectations should reflect that.
• How is on-call organised, and how many incidents happen per month? This determines how much time is left for development and who will accept the role at all.
• Will the SRE have the right to stop a release when the error budget is exhausted? Without that right an SRE becomes a fire brigade rather than a reliability engineer.
• What language will automation be written in, and how strict is that requirement? Strong SREs are often hired for engineering level and learn the language on the job.

Where to find an SRE?

SREs most often come from companies with high load and rigorous engineering hiring: large internet services, cloud providers, fintech and infrastructure products where downtime is measured in money. A strong profile signal is contribution to open source such as Kubernetes, databases or monitoring systems, and a development background rather than operations only. NEWHR finds such candidates by the results of their work, not by applications to a job post.

How to assess an SRE in an interview?

An SRE is assessed with a technical interview that includes live coding and a walkthrough of a real incident: what broke, how the cause was found and what changed afterwards. The head of SRE or infrastructure and an engineer from a product team that will share on-call with the future SRE usually take part.

Strong signals:

• walks through an incident where they made the mistake, and what they automated afterwards;
• names the SLOs and reliability metrics of the services they owned;
• explains which manual work they removed with code and how much time it freed up.

Red flags:

• describes only operations: tickets, alerts, manual deployments, with no code of their own;
• cannot explain what an error budget is for;
• looks for someone to blame in an incident review instead of the cause.

How long does it take to hire an SRE?

We present the first candidates for the SRE role within 5–7 days of the brief. NEWHR built a team of 10 senior SREs for Workato from scratch: all 22 candidates presented to the client were invited to interview.

Related roles

• DevOps Engineer — builds infrastructure and delivery pipelines and usually does not own reliability against SLOs.
• Platform Engineer — builds the internal developer platform rather than looking after production reliability.
• Staff Engineer — the level of an engineer who leads technical decisions across several teams; an experienced SRE can grow into it.
• AI Infrastructure / Inference Engineer — owns the speed and cost of serving AI models, including their reliability.
• DevSecOps Engineer — builds security into infrastructure and pipelines.