The SRE Interview That Actually Works: Screening for Resilience Thinking

Most SRE interviews test what candidates know. The ones that work test how candidates think when systems fail.

The hire that looked perfect

The following is an illustrative composite, not a specific person or company.

The candidate had everything on paper. Strong résumé, deep Kubernetes knowledge, fluent in three observability stacks, clean answers on every technical screen. The team hired them.

Three months later, during a real incident, the same engineer spent twenty minutes tuning a dashboard while customers could not complete a transaction. They knew the tools. They had never learned to ask the first question of any incident: what can customers not do right now?

The interview had measured tool knowledge. The job required systems thinking under pressure. Those are different skills, and most SRE interviews only test the first. This is a framework for testing the second.

Why the usual SRE interview fails

The typical loop has three parts: a coding screen, a trivia round on your stack ("explain how a Kubernetes pod gets scheduled"), and a system design whiteboard. All three reward preparation. What none of them reveals:

• How the candidate reasons when information is missing
• Whether they look for causes in systems or in people
• Whether they think about safety before they act
• Whether they can explain risk to someone who does not want to hear it

Google's SRE book frames the discipline as applying software engineering to operations, with explicit attention to risk, error budgets and blameless learning. Those are ways of thinking. That is what an interview should probe.

The four-part framework

Run these as conversations, not quizzes. Give each 15–20 minutes and take notes against the rubric below.

1. Incident archaeology

Ask: "Tell me about the worst production incident you were part of. Walk me through it." Then keep digging: What was the first signal? What did you check first, and why? What did you rule out? What would have prevented it?

A candidate with no real incident story is not disqualified, but you lose your best signal. Ask about the nearest thing: a failed deploy, a bad migration, a near miss.

2. The hypothesis test

Ask: "We want to know whether our service survives losing its primary database. How would you design that experiment?"

This is chaos engineering in miniature. The Principles of Chaos Engineering describe the loop: define steady state, form a hypothesis, introduce realistic failure, compare, and minimise blast radius. You don't need the candidate to have done chaos engineering. You need them to reason like an experimenter.

• Steady state first. Do they define what "healthy" means before breaking anything?
• A falsifiable hypothesis. "I expect checkout success rate stays above X while failover completes."
• Blast radius and abort conditions. Do they ask how to stop the experiment before asking how to start it?
• Staging before production, and a reason for the order.

Red flag: jumping straight to tooling. "I'd use tool X to kill the database" skips every question that matters. Green flag: "What's the rollback plan if this goes wrong?" asked within the first two minutes.

3. The stakeholder scenario

Ask: "A VP says: 'I will not let you break production on purpose.' How do you respond?"

Resilience work is as much persuasion as engineering. Listen for whether they treat the objection as legitimate (it is), whether they can offer a low-risk starting point (non-critical service, off-peak window, small blast radius, staging first), and whether they translate into business terms instead of technical purity.

Red flag: "Best practice says we have to test in production." That's an argument from authority, not from the VP's concerns.

4. The trade-off question

Ask: "Your product team wants to ship faster. Your service is at its reliability target. What do you do?"

The SRE book's answer is the error budget: reliability targets below 100% create room for change, and when the budget is spent, risk-taking slows. A strong candidate may not know the term, but should reason toward the same idea: reliability is a trade-off with velocity, not an absolute.

• Green: asks what the target is and how it was chosen; treats the remaining budget as shared between product and reliability; knows why 100% is the wrong target.
• Red: "Reliability always comes first" (no sense of cost), or "Ship it, we'll fix issues later" (no sense of risk).

Scoring: a simple rubric

Score each section 1–4, independently, before the debrief, so the first confident voice doesn't set everyone's view.

Hire on the pattern, not the total. A 4 in incident archaeology with a 1 in stakeholder communication may be teachable. A 1 in incident archaeology usually isn't, because it means they look for people to blame instead of systems to fix.

Red flags and green flags

• Hero narratives. "I stayed up 36 hours and fixed it myself." Sustainable reliability comes from systems and teams.
• Blame as root cause. Blameless postmortems focus on contributing causes without indicting individuals. "Human error" is where analysis starts, not ends.
• Tool obsession. Tools change every few years. Principles don't.
• Certainty. Strong candidates say "I don't know yet, here's how I'd find out."

On the other side: they ask about blast radius before they act, separate detection, mitigation and root cause, talk about what they learned with specifics, and are curious about your incidents.

Where good SREs come from

Three profiles tend to work well, and none needs "chaos engineering" on the résumé:

• The incident veteran. Has worked real incidents, ideally as incident commander. Needs to learn how to cause failure safely.
• The skeptical tester. A senior QA or test engineer with an adversarial "what breaks if I do this?" habit. Needs production operations and stakeholder skills.
• The reliability pessimist. An infra engineer who distrusts "it works in staging" and writes failure modes down. Needs structured experimentation and business framing.

The market for people who've done this exact job is small, and the discipline is young. Chaos Monkey was open-sourced by Netflix in 2011, so "ten years of chaos engineering experience" postings ask for something very few people can have. Hire for judgment and train the tools.

The first 90 days

• Days 1–30, learn the failure history. Read a year of postmortems, shadow on-call, write up the top recurring failure modes.
• Days 31–60, safe experiments. One or two small, well-scoped experiments in staging with a senior partner.
• Days 61–90, own something. One reliability improvement end to end: a runbook, an alert cleanup, a rollout guardrail.

What to do Monday morning

1. Replace one trivia round with the incident archaeology conversation.
2. Add the hypothesis test as a 15-minute exercise.
3. Write the rubric down and score independently before debriefing.
4. Put the red and green flags in your interview guide.
5. Look among responders, testers and security engineers, not only titles that say "SRE".

You're not trying to find someone who knows every tool. You're trying to find someone who, when the pager goes off, asks the right first question.

All examples are illustrative or drawn from public sources. No company-specific projects or proprietary data are referenced. Views are my own.

Sources

• Google, Site Reliability Engineering (the SRE book)
• Google, The Site Reliability Workbook
• Principles of Chaos Engineering
• Netflix Technology Blog (history of Chaos Monkey)