Blast radius: measuring what you broke while fixing

The cluster came back up. That's the part everyone can see.

What almost nobody checks: the candidate got it back up by deleting the liveness probe, scaling the deployment to zero and back, and leaving a debug pod running with a hostPath mount into /etc. The service is green. The fix is a time bomb.

Blast radius is the term for this, and it deserves a place in hiring. In production it means the scope of damage an action can cause - how many systems, users, or teammates get hit if this change goes wrong. Every experienced operator carries an internal blast-radius meter. It's the thing that makes your best engineer pause before running kubectl delete namespace and makes your newest one not pause. We think it's the single most underrated signal in a technical interview, and it's currently measured almost nowhere.

Blast radius is a production instinct first

You already know this instinct from incidents. It's the difference between:

kubectl rollout restart deployment/api        # scoped, reversible
kubectl delete pods --all -n production       # bold, let's say

Both can "fix" a wedged deployment. One of them takes down everything healthy in the namespace to do it.

The instinct shows up in a hundred small choices under pressure. Do you edit the live object or the manifest? Do you drain the node or reboot it? Do you widen the security group "just to test" and then - this is the important part - narrow it back? An engineer with a calibrated blast-radius meter fixes the fault while touching the smallest possible surface, and cleans up after themselves. An engineer without one fixes the fault the way a burglar fixes a locked door.

The uncomfortable truth: both engineers pass most interviews. Both would ace a whiteboard question about Kubernetes architecture. Both submit identical take-homes - the take-home is dead anyway, but even when it lived, it never captured this. The artifact looks the same. The path there could not be more different.

Why outcome-only grading misses it

Most hands-on assessments grade one bit: did it work at the end? That bit is worth having - Faultybox checks it with deterministic scripts, not vibes. But outcome-only grading actively rewards the wrong behavior. If the fastest route to green is to disable the health check that's failing, an outcome-only test pays the candidate to disable it. You are scoring the fire as extinguished while the arsonist collects the bonus.

Grading blast radius flips the incentive. Now "disable the probe" is a recorded, scored decision, not a free shortcut. The question changes from did the system recover to what did the recovery cost - which is exactly the question your postmortems ask. Grading an incident and grading a candidate turn out to be the same discipline: process over outcome, with the damage column filled in.

Concretely, a blast-radius score looks at things like:

Destructive shortcuts. Deleted resources that weren't part of the fault. Force-deletes where a graceful path existed.
Disabled safety systems. Probes removed, alerts silenced, limits raised to "unlimited" - the classic probe-deletion move that turns a failing check into an unmonitored failure - it's the standard wrong answer to a CrashLoopBackOff caused by a slow start.
Scope creep. Changes to namespaces, nodes, or configs unrelated to the incident.
Cleanup. Did the debug pods, temporary permissions, and test changes get reverted, or are they still there when the interview ends?

None of this requires mind-reading. It requires watching the actual commands and the actual state of the system - from outside the sandbox, so the record is ground truth rather than whatever the candidate's shell history admits to.

The signal is strongest at the senior end

Here's why this matters more, not less, as you hire senior people. Junior mistakes are usually visible: the fix doesn't work. Senior-shaped mistakes are quiet: the fix works, and something else is now fragile. The engineer who "always gets things back up fast" and the engineer whose fixes generate next quarter's incidents are frequently the same person, and outcome metrics cannot tell them apart.

Time-to-recovery without blast radius is half a metric. Any interview format that measures speed alone will select for exactly the confident-and-destructive profile your incident history is quietly warning you about.

Own the meter, not just the term

You don't need Faultybox to use this. Next time you run a hands-on interview, add one column to your scoring sheet: what did they break, risk, or leave behind? Diff the environment at the end. Ask the candidate what they'd revert before handing the system back. The candidates with the instinct will have an immediate answer, because they were keeping the list in their head the whole time. That's the meter. That's the hire.

We built blast radius into Faultybox as a first-class score because we think in five years it will be strange that anyone assessed infrastructure engineers without it. Anyone can tell you whether the cluster came back up. The interesting question was always what it cost.

FAQ

What does blast radius mean in DevOps? The scope of damage an action can cause if it goes wrong - how many systems, users, or teammates are affected. kubectl rollout restart deployment/api has a small blast radius; kubectl delete namespace production has a very large one. The term comes from the same instinct that makes an experienced operator pause before the second command.

How do you measure blast radius in an interview? Diff the environment before and after, and read the command log from outside the candidate's shell. You're looking for four things: resources deleted that weren't part of the fault, safety systems disabled (probes, alerts, limits), changes outside the scope of the incident, and whether temporary things - debug pods, widened permissions - were cleaned up before the candidate handed the system back.

Isn't a fast fix worth some collateral damage during an incident? Sometimes, and a good score reflects that: the point isn't that every destructive action is wrong, it's that it should be a decision rather than an accident. An engineer who says "I'm disabling this probe to get traffic flowing, and here's what I'll re-enable afterwards" scores well. An engineer who disables it, forgets, and calls the incident closed does not.

Can blast radius be graded automatically? The observable parts, yes - deleted resources, disabled probes, uncleaned state, and scope of change are all visible in a filesystem and cluster diff taken from outside the sandbox. The judgment part (was this trade-off reasonable given the pressure?) needs a rubric with written anchors and a human who can override it. Nobody should ship a pass/fail decision from a model's opinion about intent.

Faultybox runs your candidates through a real broken cluster and shows you exactly how they fixed it - replay included. Free pilot in beta → join