Every SRE interview asks some version of "tell me about a time production went down." Every candidate has a rehearsed answer where they stayed calm, found the root cause, and led the postmortem. The story is polished because they have told it ten times.
It tells you nothing about how they behave when the pager actually goes off in front of you.
Incident response is a behavior, not a fact. The traits that matter (staying methodical while a graph is red, communicating while investigating, resisting the urge to change everything at once) only show up under mild real pressure. So create some.
Give the candidate a running system in a real environment, then break it while they watch, or hand it to them already broken with a realistic alert: "the API is returning 500s for about half of requests, error rate started climbing ten minutes ago, find out what is happening and get it back."
A good incident scenario has a few properties:
Good causes to seed: a bad config rollout that a rollback fixes, a dependency that started timing out, a resource exhaustion that builds under load, a recent change that broke one code path. Each forces the candidate to observe, hypothesize, and act, rather than recite.
The fix is almost secondary. You are watching for the incident-response behaviors that decide whether someone is safe on your rotation:
The anti-signal is someone who goes quiet, starts editing configs at random, and cannot tell you at the end what actually broke or why their change fixed it.
"They seemed calm" is not a score. Break it into observable moments so two interviewers agree (see how to write a technical interview rubric):
A candidate who does not fully resolve the outage but stays methodical, communicates, and correctly identifies the cause is a stronger hire than one who stumbles into a fix and cannot explain it. On a real rotation, the first person is the one you want holding the pager.
You cannot run an incident drill on a whiteboard. The pressure, the messy signals, and the temptation to over-react only exist when there is a real system responding to real commands.
EasyEnv runs the candidate in a live workspace with a seeded fault and records the whole session. The recording is the debrief: you and the panel watch the actual order of investigation, the commands, and the moment they either found the trail or lost it. It turns "I think they handled pressure well" into a shared, reviewable record. That is also what makes the debrief converge instead of drift (more on that in the interview debrief that reaches a decision).
Anyone can tell a good incident story. Far fewer can run an incident in front of you and stay methodical, communicative, and reversible under pressure.
Stop asking about the outage. Run one, and watch.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Hiring managers are now expected to judge how well candidates work with AI, mostly without having done it themselves on real work. Here is the minimum literacy you need to run that round honestly, and the four questions that expose whether you have it.
The first infrastructure hire is not a scaled-down platform engineer. Here is what the role really is at that stage, why tool-list interviews mislead, and four scenarios that show whether someone can work inside a system nobody documented.
Read more
Time to hire is mostly waiting, not interviewing. Here is where the days actually go, which ones you can remove without lowering the bar, and the two changes that cut the most.
Read more
