How to Hire an SRE in 2026: Reliability Math, Not Just DevOps With On-Call

Site Reliability Engineering is one of the most misused job titles in the industry. Companies write “SRE” in the job post because the title is prestigious, then hire an experienced ops person, give them a PagerDuty account, and wonder why reliability is not improving.

The defining feature of SRE is not the tooling. It is error budgets and the organizational discipline to act on them. A team that has not thought about what level of unreliability is acceptable — and does not stop new features when that level is exceeded — is not doing SRE. They are doing operations with a better job title.

Here is how to hire for the real thing.

SRE vs. DevOps vs. platform engineering

The terms overlap but they are not the same discipline.

DevOps is a philosophy: break down the wall between development and operations, give teams ownership of what they build, automate deployment, treat infrastructure as code. It is broad and intentionally non-prescriptive about how you implement it.

Platform engineering is a practice within that philosophy: build the internal tooling, pipelines, and abstractions that let application developers deploy, observe, and operate their services without thinking about the underlying infrastructure. A platform engineer’s customer is the engineering team.

SRE is Google’s specific implementation of DevOps, formalized in the Google SRE book. The key additions are: defining reliability targets as SLOs (Service Level Objectives) measured by SLIs (Service Level Indicators), tracking how much unreliability remains in an error budget, and using the error budget as the decision mechanism for when to slow down feature work. An SRE team that has spent its error budget does not deploy new features until the budget recovers.

Most companies need platform engineering. Some companies at significant scale need SRE. Very few companies need the full Google SRE model, because they do not have Google’s reliability requirements or engineering scale.

What SREs actually do

If this sounds abstract, here is the practical breakdown of an SRE’s week at a well-functioning company:

They define and maintain SLIs and SLOs for services. (“Our checkout API’s SLO is 99.9% of requests under 500ms over a 28-day window.”) They build dashboards that track the SLO burn rate in real time. They own the on-call rotation and run postmortems for every significant incident. They measure how much time the team spends on toil — manual, repetitive work that could be automated — and target keeping it below 50% of working time. They run game days and chaos experiments to find reliability gaps before customers do.

The engineering split is roughly 50% operations work, 50% software engineering. The software engineering half is what distinguishes SRE from pure ops: SREs write the tooling, the automation, the alerting logic, and the runbooks as code.

Where SRE candidates come from

Good SRE candidates arrive by two paths.

Backend engineers who got pulled into operations: These developers built services, got paged when they failed, and gradually became the person who knew how the systems actually behaved. They have strong programming skills and understand the application layer, but they may need to build depth on infrastructure (Kubernetes, networking, storage) and observability tooling.

Senior sysadmins or operations engineers who taught themselves to code: These engineers have deep infrastructure knowledge — how DNS actually works, how Linux process scheduling behaves under load, how storage I/O limits manifest — and have added programming as a tool. Their code may be more operational than elegant, but they understand the system they are operating at a level many software engineers do not.

Both profiles can make excellent SREs. The gaps are mirrors: the backend engineer needs infrastructure depth, the ops engineer needs software engineering discipline. Know which path your candidate came from and probe the gap.

The screen

The error budget question: “You have a service with a 99.9% availability SLO for the month. It is day 20, and you have already consumed 80% of your error budget. The product team wants to deploy a significant feature with new infrastructure dependencies. What do you recommend and what is your reasoning?”

A strong answer covers: calculating how much budget remains, considering the risk profile of the deployment, recommending a deployment strategy that limits blast radius (feature flag, canary, staged rollout), and potentially recommending against the deployment until the budget recovers or the SLO is reconsidered. A weak answer jumps to “we should deploy” or “we should not deploy” without engaging with the trade-off.

Incident walkthrough: “Tell me about a significant production incident you were involved in. What was your role in the response? What did the postmortem conclude?” Listen for: clear timelines, honest attribution of causes (not blame), and evidence that the postmortem led to actual remediation. SREs who have been in real incidents have specific, detailed stories. Those who have not tend to describe minor alerts.

Toil identification: “Describe three things your last team’s on-call rotation dealt with regularly that you think could have been automated. Why were they not automated?” This question reveals how they think about toil — whether they identify it as waste or accept it as “just how things work” — and how they reason about prioritization.

Observability design: “You’re deploying a new microservice. Walk me through the instrumentation you’d add before the service goes to production.” A strong answer covers: the four golden signals (latency, traffic, errors, saturation), alert design that avoids alert fatigue, distributed tracing IDs, and log structure that makes debugging tractable. A developer who only mentions “I’d add some logs” has not operated services in production with real traffic.

SLO calibration: “Your on-call rotation has been getting paged at 3 AM twice a week for two months. What do you do?” The right answer is not “fix the alerts.” It is: understand whether the pages represent real reliability failures or overly aggressive thresholds, engage the team on the SLO target itself, and fix the root causes systematically. SREs who immediately reach for alert tuning without examining whether the underlying system needs work are treating symptoms.

Red flags

No postmortem experience: If a candidate has been running production systems for five years and has never written a blameless postmortem, they have either worked at companies that do not learn from failures or have not been involved in meaningful incidents. Either is concerning for an SRE role.

Tooling as identity: An SRE who leads with “I know Prometheus really well” without showing they understand what they are measuring or why is optimizing for tool familiarity, not reliability. The tools are secondary to the thinking.

No programming experience: This is different from DevOps. An SRE who cannot write a Python or Go script to automate a runbook step, build a simple exporter, or modify a Kubernetes controller is not really doing the engineering half of the job.

No curiosity about failure modes: SRE is fundamentally about imagining what can go wrong and building defenses against it. Candidates who struggle to generate failure scenarios for systems they have not personally operated yet are missing the intellectual posture the role requires.

The FTE vs. fractional question

A time-boxed engagement with an experienced SRE consultant — to define your SLOs, set up your error budget tracking, and build the on-call foundation — often delivers more value for a company at the 20-80 engineer scale than a full-time SRE hire. The setup work is a burst, and maintaining the practice afterward can be done by a platform engineer who has been trained in the approach.

The case for a full-time SRE hire is clearest when: the on-call load is high enough that someone needs to own incident response as their primary job, when your SLOs are contractual (as in enterprise SLAs), or when reliability engineering requires dedicated software development work that cannot be absorbed into the existing team.

Our guide to hiring a DevOps engineer covers the adjacent role that many teams actually need before they are ready for dedicated SRE headcount.