How to hire site reliability engineers: a practical guide for U.S. engineering and HR leaders.
Written by Damian WassermanSite reliability engineering started at Google as a simple idea: give operations to software engineers and let them automate it. Google still caps the operational work of its SREs (tickets, on-call, manual tasks) at 50% of their time, so the other half goes into engineering that removes that work (Google SRE book). Most companies do not run SRE the Google way, and that is fine. The problem for hiring is that "SRE" now appears on the résumés of release engineers, cloud administrators and genuine reliability engineers alike. This guide is about telling them apart.
What site reliability engineers do
An SRE makes reliability measurable and then keeps it within a target the business agreed to. The work runs in a loop:
- Choose the signals. Service level indicators (SLIs) for what users feel: request latency, error rate, availability of a login or checkout.
- Set the target. A service level objective (SLO), for example 99.9% of checkout requests succeed over 30 days. An SLA is the contractual promise to customers; the SLO sits inside it, stricter, so you find out before the contract does.
- Spend the error budget. The gap between 100% and the SLO is the error budget. At 99.9%, that is about 43 minutes of full downtime per 30 days. While budget remains, the team ships; when it runs out, reliability work comes first.
- Alert on what matters. Page a human when the error budget is burning fast, not when a CPU graph looks high.
- Run incidents and learn from them. Clear roles during an incident, then a blameless postmortem with action items that actually get done.
- Remove toil and plan capacity. Automate repetitive manual work, and size the system for the next peak before it arrives.
If a candidate describes their job only as building pipelines and provisioning infrastructure, they are describing DevOps work. Valuable, but a different hire.
SRE vs. DevOps and platform engineering
The three roles share tools and often share people. They differ in what they are accountable for.
| Role | Primary outcome | Typically owns | Measured by | Hire when |
|---|---|---|---|---|
| Site reliability engineer | Services meet an agreed reliability target | SLOs, alerting, incident response, on-call, capacity | SLO attainment, incident frequency and duration, pages per shift | Outages hurt revenue or trust, or on-call is burning people out |
| DevOps engineer | Code reaches production safely and often | CI/CD, infrastructure as code, environments | Deploy frequency, lead time, change failure rate | Releases are slow, manual or risky. See how to hire DevOps engineers. |
| Platform engineer | Product teams self-serve infrastructure | Internal developer platform, golden paths, templates | Adoption, time to first deploy for a new service | Several teams keep rebuilding the same setup. See platform engineers. |
Inside SRE, profiles also differ. An embedded or product SRE sits with one product team and owns its services' SLOs. An infrastructure SRE owns shared layers such as Kubernetes clusters, networking and databases. An observability-focused SRE builds the metrics, logs and tracing pipeline everyone else relies on. An SRE lead designs the incident process and on-call model itself. Decide which one you need before writing the job description.
Seniority you need
- Mid-level SREs work inside an existing reliability practice: they improve dashboards, fix noisy alerts and take on-call shifts with an experienced engineer to escalate to.
- Senior SREs can start the practice: define the first SLOs with product, redesign alerting around them, and run a major incident without a manager in the room. This is the right level for a first SRE hire.
- Staff or lead SREs set policy across teams: what happens when an error budget is spent, how severities are defined, how on-call is staffed and compensated.
Years in infrastructure are a weak signal on their own. Ask how many incidents they have led and what changed afterwards.
One SRE or a team
One senior SRE can bring SLOs, alerting and a postmortem habit to a product with a handful of services. What one SRE cannot do is carry on-call alone. Google's guidance is that a single-site team needs at least eight engineers to sustain a 24/7 rotation without burning people out (Google SRE book, "Being On-Call"). Most companies meet that by sharing the rotation between SREs and the developers who own the services, with the SRE designing the process and escalation path. Move to a dedicated SRE team when you run many services with separate SLOs, or when your uptime commitments are in customer contracts. If most of the work is the Kubernetes layer itself, consider pairing SREs with Kubernetes engineers.
Job description essentials
Strong SRE candidates filter job posts on a few specifics. Answer them:
- What they will own: which services, and whether SLOs exist today.
- The stack: cloud provider, orchestration (EKS, GKE, AKS, ECS), infrastructure as code tool, monitoring and tracing stack (Prometheus, Grafana, Datadog, OpenTelemetry), incident tooling (PagerDuty, Opsgenie, incident.io).
- On-call: rotation size, expected pages per week, whether after-hours shifts exist and how they are compensated.
- The split: roughly how much time goes to operations versus engineering. If the honest answer is 90% tickets, say so.
- Outcomes at 90 and 180 days: for example, "SLOs defined and alerting on burn rate for the three revenue-critical services."
- Team and hours: who they report to, and the overlap required with U.S. time zones.
Skip the tool laundry list. "AWS, Azure, GCP, Kubernetes, Nomad, OpenShift" tells candidates you have not decided what you run.
Skills, layer by layer
Foundations
- Linux internals and troubleshooting under load: processes, memory, file descriptors, DNS, TLS, TCP.
- One cloud in depth, including its failure modes (zonal outages, throttled APIs, quota limits).
- Kubernetes or your orchestration layer: scheduling, probes, resource limits, what a CrashLoopBackOff is telling you.
Automation
- Infrastructure as code (Terraform, Pulumi, CloudFormation) and reviewed changes, never console edits in production.
- Python or Go for tooling that removes toil.
Observability
- Metrics, logs and traces, and knowing which one answers which question.
- OpenTelemetry instrumentation, and cost control on high-cardinality metrics.
Reliability practice
- Writing SLIs from the user's point of view and setting SLOs with product.
- Multi-window burn-rate alerting instead of static thresholds.
- Incident command, communication, and postmortems with owners and deadlines.
- Capacity planning and load testing. For a practical starting point, see our write-up on performance testing with k6.
AI-assisted work
- Using AI assistants to draft runbooks, queries or Terraform, and reviewing the output for blast radius before it touches production.
How to interview
A loop that separates reliability engineers from infrastructure generalists:
- 1Incident deep-dive (45 min)Ask the candidate to walk through the worst incident they worked on. Timeline, how it was detected, what they tried, who they told, what changed afterwards. Interrupt with "why" often.
- 2Troubleshooting exercise (60 min)A broken service in a sandbox or a realistic scenario on paper: latency up, error rate normal, one zone affected. Watch how they narrow the problem before touching anything.
- 3SLO design (30 min)Give them a service description and ask for SLIs, an SLO, the alerting rules and what happens when the budget runs out.
- 4Team conversationHow they push back on a launch, how they run a postmortem where a senior engineer caused the outage.
BEON.tech's own technical interview covers the infrastructure foundation (cloud, Kubernetes, infrastructure as code, pipelines, monitoring). That leaves your own round free for step 1 or step 3, run in your own environment.
Interview questions
- How would you choose SLIs for a checkout service?Best answerUser-facing signals: success rate and latency of checkout requests measured at the load balancer or client, not CPU or pod count. Mentions excluding bot traffic or health checks.
- Our SLO is 99.9% over 30 days and we spent the budget in week one. What now?Best answerReliability work takes priority until the budget recovers, risky launches wait, and the decision rule was agreed with product in advance. Asks what burned the budget.
- Why alert on burn rate instead of error rate thresholds?Best answerBurn-rate alerts page on user impact relative to the SLO, with fast and slow windows to catch both sharp outages and slow leaks. Fewer false pages.
- Latency doubled in one availability zone. Walk me through your first 15 minutes.Best answerDeclares or joins an incident, checks recent changes, compares zones, considers shifting traffic away before root-causing. Communicates status early.
- What makes a postmortem useful?Best answerBlameless, a clear timeline, contributing factors rather than one root cause, and action items with owners and dates that are tracked.
- What is toil, and how do you decide what to automate first?Best answerManual, repetitive work that scales with traffic and adds no lasting value. Prioritizes by frequency and pages caused, not by what is fun to automate.
- How do you plan capacity for a launch?Best answerLoad tests on realistic traffic shapes, known limits per component, autoscaling tested in advance, and a rollback or feature flag plan.
Red flags
- They have never been on call, or cannot describe a specific incident they handled.
- Every monitoring answer is about installing tools, never about acting on what the alerts said.
- They measure reliability with host metrics only: CPU, memory, disk.
- Postmortems they describe name a person as the root cause.
- They see 100% uptime as the goal. Past a point, extra nines cost more than they return.
- Manual production changes are their normal way of fixing things.
- They trust AI-generated infrastructure changes without reviewing what they touch.
What it costs
The U.S. median base salary for software developers is $135,980 (BLS, May 2025), before payroll taxes, benefits, equipment and recruiting. Senior SREs with on-call responsibility usually sit above that median.
A senior LatAm SRE through BEON.tech costs $6,800 to $8,500 per month, all-inclusive ($81,600 to $102,000 per year), priced on our DevOps and infrastructure rate card. That is 25% to 40% below the U.S. median base salary alone. Use the LatAm developer cost calculator to compare by country and seniority.
Nearshore in LATAM
Reliability work is time-sensitive in a way most engineering work is not. An incident that starts at 11 a.m. Eastern needs someone on the bridge at 11 a.m., and a deploy window needs the SRE awake for it. Latin America works 0 to 4 hours from U.S. Eastern time, so both happen inside the engineer's normal day. Our network includes more than 750 engineers working as site reliability engineers, most of them senior or above. For after-hours coverage, agree rotation terms upfront rather than assuming them. For a broader view of the region, see our guide to hiring Latin American developers.
Hiring model comparison
| Model | Speed | Vetting done for you | Who owns reliability knowledge | Best for |
|---|---|---|---|---|
| In-house U.S. hire | Slowest | No | You | Roles that must be U.S.-based |
| Managed SRE service or consultancy | Fast | Vendor's own | The vendor | Short audits or a defined reliability project |
| Freelance marketplace | Fast | Partial, résumé level | The contractor | Short, well-defined tasks |
| Staff augmentation (BEON.tech) | 24–48h shortlist, 2-week start | Yes, live interview + recording | You, the engineer is on your team | Ongoing SLO, alerting and on-call ownership |
| Contract-to-hire (BEON.tech) | Same as staff augmentation | Yes | You | A first SRE you want to see run a real incident first |
| IT recruitment (BEON.tech) | Shortlist first, then your process | Yes | You | SRE leads who will set policy |
The first 90 days
- Weeks 1 to 2: access to dashboards, runbooks and the incident channel. Read the last five postmortems. Shadow on-call shifts.
- Weeks 3 to 6: first primary on-call week with a named escalation contact. Inventory of alerts: which ones paged, which ones were ignored.
- Month 2: SLIs and draft SLOs for one or two critical services, agreed with product.
- Month 3: alerting on burn rate for those services, one toil item automated, and a written proposal for the incident process or on-call changes.
Hiring with BEON.tech
Tell us your cloud, your orchestration layer, whether SLOs exist today and how your on-call works. Within 24 to 48 hours you get two or three senior site reliability engineers, each with the recording and scorecard of a live interview on that stack. Most engineers start within two weeks, and 88% are still on the team after year one.