SRE Interview Questions and Answers

It's a failure that spreads because the response to it consumes the capacity that was holding the rest up. Typically one instance dies or slows, its traffic redistributes to the survivors, they exceed their own capacity, and they fall over in turn — so the system goes from degraded to fully down without any new external cause. What makes them nasty is that the obvious reaction, restarting everything, brings services back into a full-load thundering herd and they die again.

What the interviewer is checking: whether you understand failure as a system property rather than a component one. It is the SRE question that separates people who have run a fleet from people who have run a service.

⚠Common trap: describing it as "lots of things failing at once". The point is causation — each failure creates the next.

Because retries multiply load exactly when the system has least capacity. A struggling dependency now receives two or three times the traffic, which makes it far less likely to recover on its own. Worse, if every layer retries, the amplification compounds — three layers retrying three times each is twenty-seven times the original request. And retries synchronise: everyone who failed at the same moment retries at the same moment, so recovery attempts arrive as a spike rather than a ramp.

What the interviewer is checking: whether you see retries as a load decision rather than a reliability freebie. This is the question behind most real overload incidents.

⚠Common trap: retrying at every layer because each one looks locally sensible. Nobody owns the multiplication.

It breaks synchronisation. Plain exponential backoff still has every client waiting the same interval, so if a thousand clients failed at the same instant they all retry at the same instant, then again together — the spikes get further apart but never smaller. Jitter randomises each client's wait so the retries spread out across the window and arrive as a manageable rate. It matters most in exactly the situation you care about: recovery, when the system is fragile and a synchronised wave puts it straight back down.

What the interviewer is checking: whether you know backoff and jitter solve different problems. Many candidates treat jitter as a rounding detail.

⚠Common trap: assuming jitter only smooths the graph. In AWS's own measurements full jitter roughly halved the total number of calls needed to succeed, because desynchronised retries contend less and therefore fail less — it is not merely cosmetic scheduling.

Non-Abstract Large System Design is the SRE version of the design interview, and the non-abstract part is the whole point: you are expected to put numbers on it — machines, disks, bandwidth, cost — rather than name components. It typically iterates too: design something that works, then ask what happens at ten times the scale, or when a datacentre disappears, and rework it. So it rewards a candidate who states assumptions and computes, and it exposes one who has memorised architecture patterns.

What the interviewer is checking: whether you will actually do arithmetic in front of them. Employers who use this method say explicitly they score the reasoning rather than the answer.

⚠Common trap: treating it as the standard system-design round and staying at the level of boxes and arrows.

You lose a third of your capacity at the moment you need all of it, so the remaining two zones are immediately over capacity and you get an overload — which, without shedding, becomes a cascading failure rather than a partial one. Sizing for peak across all zones means every zone is a single point of failure at peak. To survive it you provision so that N-1 zones carry peak, which costs about fifty per cent more in a three-zone layout, or you accept degradation and make sure shedding decides what survives.

What the interviewer is checking: whether you can price availability. This is the question where redundancy stops being a diagram and becomes a budget line.

⚠Common trap: answering that traffic simply moves to the other zones. It does — that is exactly the problem.

Burn rate is how fast you are consuming the error budget relative to the period — a burn rate of one exactly exhausts it by the end, so anything much above one deserves attention. Alerting on it rather than on a raw threshold means the page reflects how much trouble you are actually in. Two windows solve the two failure modes of a single one: a long window catches slow burns but reacts late, a short window is fast but noisy, so you require both to fire before paging, and you use the short one to stop alerting once the incident is over.

What the interviewer is checking: whether you can explain why a plain error-rate threshold is worse. The two-window construction is the standard answer and it is worth knowing by name.

⚠Common trap: describing burn rate but not saying what it is relative to. It is meaningless without the budget and the window.

Everyone who would be bound by it — the service owners, the SREs, and crucially the product side, plus someone senior enough to hold the line when it is inconvenient. Without that agreement the budget is a chart: the first time it runs out during a launch quarter, whoever wants to ship simply overrides it and it never binds again. The agreement has to be written down before it is needed, and it has to say what specifically happens, not that reliability will be prioritised in some unspecified way.

What the interviewer is checking: whether you understand the social half. Error budgets fail organisationally far more often than technically.

⚠Common trap: describing the mechanism and skipping the agreement. The arithmetic is the easy part.

Toil is operational work that is manual, repetitive, automatable, tactical rather than strategic, and scales linearly with the service — so it grows as you grow and produces no lasting value. Measuring it means tracking where operational time actually goes: ticket and interrupt time, page volume and what each page required, and time on recurring manual procedures. The linear-scaling test is the useful one in an interview, because it separates genuine toil from work that is merely tedious but does not grow.

What the interviewer is checking: whether you can define it precisely rather than as "boring work". The definition is specific and the specificity is the point.

⚠Common trap: calling all operations toil. That framing devalues the on-call and investigation work that genuinely requires judgement.

By where the work comes from and who can refuse it. Signals: nearly all the work arrives as tickets from other teams, the team cannot decline to support a service or set entry criteria for one, developers do not carry pages for their own code, and engineering time keeps being spent on the incident queue rather than removing its causes. The clearest test is what happens when operational load rises — a real SRE function pushes it back or changes the system; an ops team absorbs it and hires.

What the interviewer is checking: whether you can assess the function honestly — and this is one to ask them, because the answer tells you what the job actually is.

⚠Common trap: judging by the org chart or the title. Both can say SRE while the operating model is unchanged.