Get started

Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.

Platform, DevOps and site reliability · Senior level

How to assess a Site Reliability Engineer

The SRE screen does not fail because candidates can fake it — it fails because it never observed the thing in the first place. Reliability work is decision-making under partial and possibly false information, with a clock running and a business consequence attached, and a whiteboard has none of those properties. Ask someone to explain how DNS resolution works and you learn whether they have read about DNS. Put them in front of a service that is returning errors, a dashboard that is missing a metric and a graph that is misleading, and you learn whether they check the recent deploy before the kernel version, whether they mitigate before they understand, and whether they can say "I do not know yet, here is what I am doing next" out loud. Uptime Institute's 2026 outage analysis found 57 percent of surveyed operators saying their most recent major outage cost more than $100,000 and around one in five putting it above $1 million, with failure to follow established procedures still the leading driver of human-error outages — which says the expensive failures in this role are behavioural and procedural, precisely the category the trivia interview does not touch.

An SRE is paid for the twenty minutes a quarter when everything is on fire, and for the year of unglamorous work that makes those twenty minutes shorter. Both halves are assessable, and neither is assessed by the interview most teams run.

The incident half is a reasoning discipline. Something is wrong. The dashboard says latency is up, but the dashboard is fed by an agent that may itself be affected. The error rate looks fine, but only because the failing requests never reached the service that reports it. There was a deploy forty minutes ago and a config change ninety minutes ago and a cloud provider status page that says everything is normal, which it does not always mean. The strong SRE narrows this quickly by asking what changed, in what order, and what the shape of the failure implies about where it sits — errors on every request means one thing, errors on one percent means another, errors that started exactly on the hour means a cron or a certificate. The weak one starts at the layer they know best and works outward regardless of the evidence.

Two behaviours separate the top quartile more reliably than any amount of platform knowledge. The first is mitigating before understanding. A candidate who insists on root cause while customers are affected is describing a debugging temperament in a job that requires an operational one; the correct instinct is roll back, fail over, shed load, then investigate at leisure. The second is stating uncertainty out loud. Incidents are collaborative, and an SRE who says "I think it is the cache, sixty percent, I am checking the deploy log now" makes everyone around them more effective. One who goes quiet for eleven minutes and emerges with a theory does not.

The quiet half of the role — the SLO nobody has argued about, the alert that fires only when a human should act, the runbook written for someone who has just been woken up — is where reliability is actually manufactured. Uptime Institute's 2026 analysis is blunt about this: failure to follow established procedures remains the leading driver of human-error outages. Procedures fail to be followed partly because people are careless and largely because the procedures are bad — written by the person who already knew, at a level of detail that assumes the reader does. Assessing whether a candidate can write an instruction that a tired stranger can execute is therefore not a soft extra; it is a direct measure of the thing that causes outages.

This family also has an unusual structural property worth stating to buyers, because it changes the integrity argument. An assistant can write Terraform, but it cannot tell a candidate what is currently broken in a system it cannot see. Diagnosis in a live, degraded environment is inherently resistant to substitution, which makes an incident simulation one of the more robust assessments available anywhere in software hiring. The 2025 DORA research found 90 percent of nearly 5,000 surveyed technology professionals using AI at work and a negative relationship between AI adoption and delivery stability — more change arriving faster, with the downstream consequences landing on exactly this team. That raises the value of the hire and the cost of the screen being decorative.

The design puts the candidate into a monitored sandbox with a degraded service and telemetry that is partial and slightly misleading, watches what they check first and how they narrow, then asks for the post-incident summary and a live briefing to an AI stakeholder who wants to know when it will be fixed and whether it will happen again. The follow-up conversation about their own session is the sharpest instrument: you looked at the pod logs before the deploy history — why that order? You rolled back at eight minutes; what convinced you? Your summary says the cause was a config change, but the timeline shows the errors started before it — reconcile that for me. What alert would have caught this sooner, and what would it have cost you in false pages? Nobody can answer those about someone else's twenty minutes.

What the job actually needs

How people fail in this seat

What most employers do instead

CV screen against a tool list, a whiteboard question about container networking or DNS, and a general algorithm interview.

The SRE screen does not fail because candidates can fake it — it fails because it never observed the thing in the first place. Reliability work is decision-making under partial and possibly false information, with a clock running and a business consequence attached, and a whiteboard has none of those properties. Ask someone to explain how DNS resolution works and you learn whether they have read about DNS. Put them in front of a service that is returning errors, a dashboard that is missing a metric and a graph that is misleading, and you learn whether they check the recent deploy before the kernel version, whether they mitigate before they understand, and whether they can say "I do not know yet, here is what I am doing next" out loud. Uptime Institute's 2026 outage analysis found 57 percent of surveyed operators saying their most recent major outage cost more than $100,000 and around one in five putting it above $1 million, with failure to follow established procedures still the leading driver of human-error outages — which says the expensive failures in this role are behavioural and procedural, precisely the category the trivia interview does not touch.

The assessment

About 68 minutes end to end.

The systems it runs in

A three-replica service on Kubernetes: kubectl access, real application logs, a Grafana dashboard backed by Prometheus, deploy and config-change history, an alerting configuration for t4, and the incident run in a chat channel with the AI incident commander in it. The per-replica view the candidate needs in t1 is not a panel — it requires decomposing the fleet-wide error rate by pod in PromQL, which nobody has done in advance. The stale panel is stale because the scrape of that replica is failing, so the same signal that explains the flat graph is the one t4's third alert definition watches.

Datadog, New Relic, Splunk or Elastic for organisations on managed observability rather than the Prometheus and Grafana pair, which the Grafana Labs Observability Survey 2025 and successive CNCF annual surveys both report as the open-source default and the most widely invested-in stack. The fixture is rebuilt on the buyer's own dashboards and monitors where they can provide a sandbox, and that is the version worth paying for, because familiarity with their panels is part of what they are hiring. Nothing in the fork depends on query syntax: it depends on whether the candidate decomposes an aggregate by instance, and whether they notice the instrument itself has stopped reporting. Every one of these tools can hide both equally well.

Working speed is not scored. Time to mitigate is genuinely part of this job and is reported — as a raw number beside the score, never inside it, and never alone. It is reported beside a second number, time to first correct causal statement, because the gap between them is the informative artefact. Scored on its own, speed would rank the restart highest: it clears the symptom in under a minute, discards the log buffer that identifies pool exhaustion, and leaves the cause in place to return later in the session.

What the candidate actually does

TaskWhat happens
The degraded checkout path
coding_sandbox · 30 min		A three-replica checkout service in a monitored sandbox is failing a minority of requests while the sandbox generates steady synthetic traffic. The candidate has kubectl and shell access, real application logs, a Grafana dashboard backed by Prometheus, deploy and config-change history, and a provider status page that says everything is normal. An AI incident commander is on the channel throughout and asks, at intervals, what the candidate is about to check and what they expect to find. Three things are planted. A frontend asset deploy forty minutes ago is a coincidence and touched nothing on the failing path. A config change ninety-five minutes ago cut the database connection pool on one replica only, which is the proximate cause and is visible only if the fleet-wide error rate is decomposed by pod, which no panel on the default dashboard does. And the dashboard's own error-rate panel is stale — the Prometheus scrape of that replica has been failing, so its last data point is twenty minutes old and the graph is flat while customers are failing.
The fork. Restarting the affected replica clears the symptom in under a minute, looks exactly like a fix, discards the in-process state and log buffer that identify pool exhaustion, and leaves the config change in place, so the failure returns later in the session. Draining traffic from that replica, or reverting the config change, mitigates just as fast and keeps the evidence intact.
The stakeholder who wants a time
live_call · 6 min		Immediately after the candidate has mitigated, an AI head of e-commerce joins. She is not an engineer, she has a marketing email scheduled in ninety minutes, and she wants to know when it is fixed, whether it can happen again, and whether she should tell customers. She presses for a single number.
The fork. Naming a confident resolution time satisfies her in the moment and is unsupported by anything the candidate knows. Distinguishing mitigated from fixed, giving a bounded answer with its dependency, and committing to a next update at a stated time is harder in the conversation and is the behaviour the job requires.
The post-incident note
written_artifact · 12 min		The candidate writes the note that goes to the engineering channel and to the stakeholder from t2. It is expected to carry a timeline, what was mitigated, what is still unfixed, and what remains unknown.
The fork. The tidy narrative names the nearest change and calls the incident resolved, which reads well and is false on both counts. The honest note says the pool change is the best current explanation, says the restart or drain was mitigation rather than a fix, and names the thing the candidate never established.
The alert that would have caught it
judgment_scenario · 8 min		Three alert definitions are offered. One pages on any error response. One pages when a single replica's error ratio diverges from the fleet for five minutes. One pages when the error metric itself stops reporting, on the scrape rather than on the service. The candidate picks what to ship, says what each would have cost the on-call rota over the last quarter given a supplied history of past firings, and says what it would not have caught.
The fork. The tight symptom alert would have caught this incident and would also have paged the team several times a week for nothing, which is how a channel becomes unread. The stale-metric alert is the one that addresses why nobody noticed, and it is the one candidates most often skip.
Your own twenty minutes
live_call · 12 min		A live conversation about the candidate's own thirty minutes, driven by the recorded timeline. You opened the pod logs before the deploy history — why that order? You drained at minute eight; what convinced you? Your note says the config change caused it, but your first hypothesis was the deploy — what changed your mind, and what would have changed it back? What did you look at that turned out to be irrelevant?

The mark scheme

Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.

Orders the work by customer impact rather than by curiosityweight 0.25Separates stopping the bleeding from understanding the cause out loud, mitigates by the least destructive available means, and says explicitly that th…
1 Pursues root cause for the whole window while requests keep failing, or restarts blindly in the first three minutes without having read anything, and cannot say afterwards what state that destroyed.
3 Mitigates within a reasonable window but only after the diagnosis is essentially complete, and treats mitigation and fix as the same act.
5 Separates stopping the bleeding from understanding the cause out loud, mitigates by the least destructive available means, and says explicitly that the investigation continues after the customer impact has stopped.
States the hypothesis before running the command that would disprove itweight 0.2Unprompted, says what they believe, roughly how confident they are, and what result would eliminate the theory, before the command runs; then says out…
1 Runs commands and reads output without saying what is being tested; when the incident commander asks what they expect to see, answers with what they are typing rather than what would change their mind.
3 Narrates the current theory when prompted, but only after the output has already appeared on screen.
5 Unprompted, says what they believe, roughly how confident they are, and what result would eliminate the theory, before the command runs; then says out loud when the result did not match.
Treats the instrumentation as a system that can also be brokenweight 0.2Checks the age of the data point, identifies the panel as stale, cross-checks the metric against a source with a different failure path, and flags the…
1 Concludes from the flat error-rate panel that the problem is intermittent or has passed, and never checks the panel's own freshness or the aggregate against a raw log count.
3 Notices the dashboard disagrees with the logs and follows the logs, without establishing which one is wrong or why.
5 Checks the age of the data point, identifies the panel as stale, cross-checks the metric against a source with a different failure path, and flags the blind spot as an incident finding in its own right.
Preserves the evidence they will need afterwardsweight 0.15Drains or isolates rather than restarts, or captures the process state before restarting, and says why that mattered before being asked.
1 Restarts or redeploys the affected replica as the first action, and in the session review cannot reconstruct what the process was doing at the moment of failure.
3 Mitigates in a way that destroys some state, but has captured logs or a metric snapshot first.
5 Drains or isolates rather than restarts, or captures the process state before restarting, and says why that mattered before being asked.
Gives an account that survives comparison with the timelineweight 0.2Timeline matches the recorded session including the wrong turns, separates mitigated from fixed, names the residual unknown, and the spoken version is…
1 Written note or spoken briefing claims a resolution that did not happen, names a cause the evidence does not support, or omits the period when the candidate was on the wrong track.
3 Accurate but thin — records what was done without distinguishing confirmed from suspected, or without naming what is still unknown.
5 Timeline matches the recorded session including the wrong turns, separates mitigated from fixed, names the residual unknown, and the spoken version is intelligible to someone who is not an engineer without becoming vague.

How it is scored

Weighted mean of the five criteria, each scored 1 to 5 against the anchors above, reported with the timestamped excerpt from the session that earned each score. The first criterion is additionally reported as two raw observations — time from session start to first mitigating action, and time from session start to a correct causal statement — because the gap between those two numbers is the single most informative artefact this design produces, and it should be read by the hiring manager rather than folded into a mean.

Integrity

The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.

What you receive

Who decides

Required, not optional, for this design. A reviewer with production on-call experience reads the timeline before reading the scores, then confirms or overrides each criterion in writing. Two overrides are expected often enough to name — a candidate who restarted first but for a stated and defensible reason, and a candidate who never mitigated because they correctly judged the impact too small to warrant it — and both are cases where the rubric alone is wrong. The ranking orders who to interview; it does not decide.

What this does not measure

This design observes one incident, in a sandbox, for thirty minutes, with no real money and no real customers on the other side. It does not measure on-call temperament sustained over months, which is the attribute that actually determines whether someone survives in this role — whether they are still careful at the fourth page of a night, whether they burn out, whether they ask for help at 3am. It does not measure behaviour during a genuine multi-hour outage with a board watching, where the dominant variables are fatigue, organisational pressure and the cost of being wrong in public. No session-based assessment observes those, and a deployer should not let a strong score here substitute for reference conversations about them. Three narrower cautions. The live components must be scored on the content of what is said and never on accent, fluency or speech rate; reviewers are given the transcript alongside the recording for this reason. The sandbox should present a stack the candidate has declared familiarity with, because scoring diagnostic order while the candidate is also learning an unfamiliar toolchain measures the wrong thing and disadvantages engineers whose experience is in another ecosystem. And a fixed thirty minutes is itself a filter — extended time should be available on request as an adjustment, applied before the session and not surfaced to the reviewer, since the scored variable is the order of the work rather than its speed. Monitor score distributions by candidate background and by requested adjustment, and treat any consistent gap as a defect in the scenario rather than a finding about candidates.

The argument for this design is narrower than it looks, and it is worth stating precisely because it is the reason this is the strongest assessment in the engineering hub. Reliability work is the observation of a system you cannot see from outside. An assistant, however capable, can tell a candidate everything about connection pools in general and nothing about the fact that this replica, in this sandbox, right now, has a pool of eight where its siblings have thirty-two. The knowledge that closes an incident is not retrievable; it has to be gathered, in an order, by someone deciding what to look at next. That makes the sequence of actions the primary artefact, and the sequence is not reconstructible after the fact by anyone who did not produce it.

Everything in the task set is arranged so that sequence carries information. The planted deploy is there because it is the nearest change and the most natural first suspicion; a candidate who checks it, rules it out on the grounds that it touched no code on the failing path, and says so, has demonstrated something a candidate who never considered it has not. The stale error-rate panel is there because the most expensive property of any monitoring system is that it fails silently, and the habit of asking how old this number is separates people who have been lied to by a dashboard from people who have only read about them. The per-replica view being off the default dashboard is there because the shape of the failure — a fraction of requests, not all of them — is itself the clue, and noticing that a third of traffic failing implies one of three replicas is the inference that turns a twenty-minute incident into a five-minute one.

The restart fork is the centre of the design. It is a genuine dilemma rather than a trap: restarting is a legitimate mitigation, it is fast, and on many real incidents it is the right call. What separates the strong candidate is that they know what it costs, say so before doing it, and choose the cheaper-in-evidence alternative when one is available. A candidate who drains traffic instead, and explains that they wanted the process left alive to look at, has told you more in one sentence than a résumé does in a page.

The two live components exist because the family's most under-assessed competence is explaining an outage to someone who is not an engineer while it is still happening. The stakeholder in t2 is deliberately reasonable and deliberately insistent; she is not hostile, she has a real deadline, and the pressure to give her a number is genuine. Over-committing to her is the single most common failure among otherwise strong operators, and it is invisible in every other format.

What this refuses to measure is as important as what it does. It does not test whether the candidate can recite the difference between an SLI and an SLO, and the rubric gives no credit for vocabulary. It does not test breadth across clouds or container runtimes. It does not attempt to score how calm someone sounds, because calm-sounding is not the same as effective and is entangled with things that must not be screened on. And it makes no claim about the twenty minutes a quarter that this role is actually paid for — a sandbox with synthetic traffic and no revenue attached is a rehearsal, and the honest way to sell it is as the best available rehearsal rather than as the thing itself.

Sources

Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.

  1. US Bureau of Labor Statistics, Occupational Outlook Handbook, Network and Computer Systems Administrators, 2025, https://www.bls.gov/ooh/computer-and-information-technology/network-and-computer-systems-administrators.htm
  2. Uptime Institute, Annual Outage Analysis 2026, press release, survey of data centre and IT operators, https://uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2026
  3. Stack Overflow, 2025 Developer Survey, Developers section, roughly 49,000 respondents worldwide, developer-type question answered by 43,560, https://survey.stackoverflow.co/2025/developers
  4. Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development, 24 September 2025, vendor-run survey of nearly 5,000 technology professionals worldwide, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.

Read a sample reportOr talk to us about this role