Why pre-screen site reliability engineers before the technical loop
The SRE title has drifted far enough that it now covers three different jobs: infrastructure automation, platform engineering, and genuine production ownership with an on-call rotation. All three write the same resume, list the same tools, and describe the same cloud platforms. The difference shows up the first time you ask what happened at three in the morning. A short screen surfaces that, along with the scale they have actually operated at, which is the other thing a resume reliably hides.
What actually matters when screening Site Reliability Engineer candidates
- 01
Technical proficiency
Check depth in Linux internals, Kubernetes, Terraform, and observability stacks: ask how they set SLOs, wired Prometheus alerts, or cut noisy pages using error budgets.
- 02
Systems and trade-offs
Probe design trade-offs on multi-region failover, autoscaling limits, and cost: ask where they accepted lower availability deliberately and what capacity headroom they ran.
- 03
Evidence and rigour
Test how they measure reliability: p99 latency, MTTR, change failure rate, postmortem actions closed. Ask for a specific incident timeline and the root cause they proved.
- 04
Collaboration and communication
Assess on-call life: how they ran handovers, wrote runbooks, pushed toil back to product teams, and coordinated an incident as commander across dev and support.
Pre-screening questions to ask Site Reliability Engineer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Systems and automation
4 questions01Can you describe your experience configuring and managing Linux systems?
Listen forReal depth below the tooling: process and memory behaviour, filesystem and network configuration, and a problem they solved by reading system state directly.
Linux experience that stops at running commands from a runbook, with no ability to explain what those commands do.
02Do you have experience with container technology such as Docker or Kubernetes?
Listen forOperating a cluster rather than deploying to one: resource limits, eviction, networking, and a failure mode they debugged inside the orchestrator itself.
Has only pushed manifests to a cluster someone else runs, or cannot describe what happens when a node goes unhealthy.
03How have you contributed to infrastructure as code, and what did you own?
Listen forNamed tooling with the messy parts included: state management, drift between code and reality, and how they handled a change that could not be rolled back.
Describes infrastructure as code as writing templates, with no account of drift or of a change that went wrong.
04Do you have experience automating routine tasks? Can you give a specific example?
Listen forToil they measured before removing, with the time saved named, and awareness that the automation itself became something to maintain.
Automation described with no before figure, or scripts that ended up needing more attention than the manual task.
Incidents and evidence
3 questions05Can you describe the most challenging system issue you have encountered and how you resolved it?
Listen forA narrated diagnosis: what they observed, what they ruled out, the point their first theory collapsed, and how they confirmed the real cause.
Jumps straight to the fix, or cannot say how they knew the cause rather than a change that happened to coincide.
06How proficient are you at system troubleshooting under production pressure?
Listen forA method that survives stress: stabilise first, gather evidence, communicate status, and a clear view on when to roll back rather than keep debugging.
Debugs in production until it works, or has no separation between restoring service and finding root cause.
07Can you describe how you have integrated monitoring, alerting and logging systems?
Listen forAlerts tied to user impact rather than resource thresholds, plus a case where they deleted alerts because the rotation was being woken for nothing.
Alerts on CPU and disk with no symptom-based signals, or a rotation drowning in pages nobody acts on.
Reliability trade-offs
3 questions08How do you ensure the reliability and availability of a service?
Listen forError budgets or an equivalent, with a real decision they made to slow a release or accept risk, and who they had to convince.
Treats more nines as always better, with no sense of what the next nine costs or who pays for it.
09Do you have experience with service level objectives or agreements?
Listen forSLOs they helped set, measured from the user's side, plus what happened the quarter the budget was spent before the end of the month.
Describes targets handed down by management, or SLOs measured from inside the system rather than at the user.
10What is the largest system you have had a key role in running and maintaining?
Listen forScale in traffic, data or nodes, with the specific constraint that bit first and what they changed when the old approach stopped working.
Calls a system large with no figures, or scale that turns out to be a staging environment or a personal project.
Working with product teams
2 questions11Can you share a task where you took a proactive approach to prevent system faults?
Listen forPrevention with evidence it worked: a capacity limit found before it bit, a dependency removed, or a game day that changed an actual design.
Prevention described as good practice in general, with no example and no measure of whether it avoided anything.
12Do you have experience with continuous integration and deployment pipelines?
Listen forPipelines they built for other teams to use, including how they handled a team that wanted to bypass the checks and what they agreed instead.
Pipelines built as a gate rather than a service, or no experience of the teams whose releases they were slowing.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names specific tooling and versions, explains SLI selection and burn-rate alerting, and shows real command of container and network internals.
Systems and trade-offs
25%5Reasons about blast radius, quorum, and cost per nine; defends choices with concrete load numbers rather than best-practice slogans.
Evidence and rigour
25%5Cites before-and-after metrics, describes blameless postmortems with tracked action items, and distinguishes correlation from verified root cause.
Collaboration and communication
15%5Describes clear incident-command roles, runbooks others actually used, and negotiated reliability work into product roadmaps without friction.
Three different jobs now share this title and the resumes are indistinguishable. A one-way video screen lets you hear whether a candidate has actually carried a pager before you commit a technical loop.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for an SRE take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish which of the three SRE variants you have, confirm real on-call experience, and hear one incident described end to end before the technical loop.
Should the screen include a coding or systems exercise?
Not yet. Ask them to walk through an incident and an automation they built. A systems exercise is expensive to run and to mark, and it is wasted on a candidate whose production experience turns out to be a staging environment.
Evaluating answers
What is the strongest signal when screening an SRE?
How they narrate an incident. Strong candidates describe what they observed, what they ruled out and the point where their first theory collapsed. Weaker ones jump to the fix and cannot say how they knew it was the cause rather than a coincidence.
How do I compare a DevOps background with a production SRE background?
Weight the questions rather than scoring both on everything. For the DevOps candidate, push on on-call, SLOs and incident command. For the production candidate, push on infrastructure as code and automation. The gap tells you where onboarding goes.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
