Hiring for this role?
Start free with this planFree for your first open role.
Why Hirezen?
- Every interviewer runs the same script and marks the same signals.
- AI drafts the write-ups, and the debrief puts every read side by side.
- No ATS to set up first, and no bot in the call.
Site Reliability Engineer (SRE) interview questionsSystem design — the dependency that fails slowly round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: System design for a slow dependency: timeouts, retries and isolation so that a payment provider slowing down costs checkout and nothing else, idempotency against double charges, capacity for a sale at three times peak, and running the degraded mode yourself when the provider slows on the night.
Opening
Who is interviewing, how the round will run, and a question to settle the candidate in. The standard openingA provider that answers late
What this part is for
Purpose
Runs over a one-page sketch sent 24 hours ahead. Write it to a known composition. `storefront-api` runs 12 instances, four in each of three zones, and each instance has one pool of 200 worker threads shared by `POST /checkout` and `GET /basket`. At today's evening peak it serves 150 checkouts and 900 basket reads a second; a checkout takes about a second at the median, a basket read about 20 ms. A checkout calls four things in sequence: stock reservation, internal, p99 120 ms; fraud scoring, internal, p99 250 ms; a tax quote from a third party, p99 300 ms; and payment authorization from a third-party provider, p50 700 ms, p99 1.9 s, with a contract promising 99.9% availability a month. A basket read calls only the internal basket store. Every outbound call uses the HTTP client's default timeout of 30 seconds. Retries: the mobile app retries a failed checkout three times; the API gateway times a request out after 10 seconds and retries twice on a timeout or a 5xx; `storefront-api` retries payment authorization three times. The team's proposed SLO is 99.95% of checkouts succeeding over 30 days. Last quarter the provider slowed for 40 minutes on a weekday evening, to a median of 8 seconds and a mean of 12, with about a third of authorizations taking longer than 10 seconds; `storefront-api` failed every request, basket reads included, and 83 customers were charged twice. There is no second payment provider. The plants: a slow dependency holding threads for up to 30 seconds in a pool the basket shares; retries at three layers, which multiply to as many as 48 authorization attempts for one tap; payment retries with nothing to make them idempotent, which is where the double charges came from; and an objective stricter than the one hard dependency it cannot work without. Stock reservation is deliberately right — a hold that expires by itself after ten minutes if checkout does not finish — and should survive the redesign; the one thing a payment-pending mode must add is what happens to the hold once an order is accepted before its payment clears. Fraud scoring is the slowest internal call and the red herring: 250 ms is not what took the site down. A sale in five weeks is forecast at three times today's peak; keep that for the second section. Book 70 minutes; the close is outside the 60.
I'm [YOUR_NAME], and I work on reliability for the shop at [COMPANY_NAME]. You have the sketch. Last quarter a payment provider got slow for forty minutes and took the whole shop down with it, and it charged some people twice. I want to redesign this so that doesn't happen again, and then I want to see how it holds up on a much busier night.
What this line is for
Purpose
Names the incident that motivates the design, so the candidate designs against a failure rather than drawing a generic architecture.
Draw if it helps. I care much more about the numbers you put on things than about the boxes.
What this line is for
Purpose
Moves the weight from diagrams to timeouts, limits and counts, which is where this design is decided.
Redesign the checkout path so that the next forty minutes of a slow payment provider costs checkout and nothing else. Give me timeouts with numbers, where retries live and how many, what is isolated from what, and what a customer sees while it is happening.
What this question is for, and what to listen for
Purpose
Capacity and dependencies are read here. The load-bearing design question. Nearly everyone says "circuit breaker"; the separator is whether the candidate can explain why the whole shop failed — threads held by slow calls in a shared pool, multiplied by retries — and whether their timeouts, retry counts and isolation carry numbers derived from the sketch.
Signals to score
- Explains last quarter's outage as threads held by slow calls in a pool the basket shares, and shows it with the sketch's numbers rather than asserting it
- Counts the retry multiplication — four attempts from the app, three from the gateway, four from the service — and keeps retries in one layer
- Traces the double charges to retried authorizations with no idempotency key, and carries one key from the customer's tap to the provider, and treats an authorization that timed out as unknown until the provider answers for that key
- Sets timeouts from a budget that fits inside the gateway's 10 seconds, with the payment timeout set just above its normal p99 rather than at 30 seconds
- Separates checkout from basket reads — separate pools or separate deployments — so a slow payment cannot take the basket down
- Caps how many payment calls can be in flight per instance, so excess checkouts fail fast instead of waiting for a thread
- Stops calling the provider when it is failing, with a breaker whose opening condition and recovery probe are stated
- Designs what the customer sees: an order accepted with payment pending, or a clear message that payment is slow and what happens next, rather than an error page after 30 seconds
- Notices that 99.95% sits on a provider contracted at 99.9%, and either changes what the objective counts or changes the design so it can be met
- Keeps the stock reservation hold, says what happens to it when an order is accepted with payment pending, and does not spend long on fraud scoring
Follow-up questions
- A slow payment call holds a thread for how long, today? Walk me from that to basket reads failing.
- One customer taps "pay" once. How many authorization attempts can reach the provider?
- Eighty-three people were charged twice. Which part of your design makes that impossible?
- What is the payment timeout, and why that number?
- The objective is 99.95%. The provider promises 99.9%. How does your design meet it?
Five weeks to three times the traffic
What this part is for
Purpose
Capacity, on the design the candidate has just drawn. Give the forecast now: 450 checkouts and 2,700 basket reads a second at the sale's peak, most of it arriving in the first minutes after a campaign goes out. If they ask what one instance can carry, say nobody has measured it; if they ask about the provider, say the contract says nothing about request rates.
The sale is five weeks away at three times today's peak. How many instances do you want running that evening, and what would you have to find out before you trusted your own number?
What this question is for, and what to listen for
Purpose
Capacity and dependencies are read here. Tests capacity planning as arithmetic plus a list of unknowns that could each invalidate it. The separator is whether the candidate plans for losing a zone during the peak, and whether they look past their own service to the dependencies that have to carry three times the traffic too.
Signals to score
- Works out the work in flight at the forecast from the sketch's durations — about 450 checkouts and 54 basket reads in flight at the medians — and says whether threads are the limit
- Says that nobody knows what one instance can carry, and that a load test at target latency comes before any instance count
- Sizes so the sale survives losing a zone at its peak, and shows what that does to the count
- Asks what the dependencies can carry at three times — the provider's rate limits, stock reservation, fraud scoring, the basket store, the gateway — and starts with the provider because it is outside the company
- Scales up before the campaign rather than trusting autoscaling to react to traffic that arrives in minutes
- Checks that the caps and breakers from the first section are sized for the sale, not for today
- Proposes rehearsing the evening — a load test against a production-like environment, or production at a quiet hour — and says what would count as a failed rehearsal
- Commits to a number with its assumptions written beside it, rather than refusing to give one
Follow-up questions
- Is the thread pool the limit at three times, or something else?
- One zone fails at 20:05 on the night. What does your count have to be for that to be a non-event?
- Most of the traffic arrives in the first few minutes after the campaign. What does that do to autoscaling?
- The provider's contract says nothing about request rates. What do you do this week?
- Give me a number. What would change it?
20:10 on the night
What this part is for
Purpose
The design, run live. You play the system and answer only what the candidate asks for. Have these ready: the breaker on the payment provider has opened and closed twice in four minutes; the provider's status page has said "investigating elevated latency" since 20:07; basket reads are normal; there are no double charges; the payment-pending mode exists but is off, and finance agreed in writing that the on-call engineer may turn it on for up to 60 minutes as long as the finance lead is told at once; and marketing has a push notification to two million app users scheduled for 20:15. Reveal the push notification only if the candidate asks what else is about to happen, or asks about traffic. If the candidate did not design a payment-pending mode, the only degraded state is the page that says payment is slow; do not add one for them.
Now it is the night of the sale, and you are on call for the system you just designed.
What this line is for
Purpose
Makes the candidate the owner of the design they argued for, so the live decisions are about their own switches.
It is 20:10. Payment authorization's median is 6 seconds and climbing, 9% of checkouts are failing, and basket reads are fine. Take me through the next fifteen minutes in order, and ask me for anything you want to see.
What this question is for, and what to listen for
Purpose
Incident response is read here, on a live problem, with the pressure of a sale and a pre-agreed trade-off waiting to be used. The separator is whether the candidate stops the damage from growing — including the traffic about to arrive — before trying to understand the provider.
Signals to score
- Declares an incident within the first minutes and says who commands, who works the problem and who talks to the business
- Converts 9% into time: against 99.95% it is a burn rate of about 180, about four hours to spend a month's budget at the month's average traffic, and much less at three times peak, because the budget is a count of failed checkouts
- Asks what else is about to hit the system, and delays the 20:15 push notification
- Asks whether the payment-pending mode may be used, finds out it was agreed in advance, switches it on, and tells the finance lead
- Tells support and marketing what customers will see before customers start asking
- Escalates to the provider through its support route rather than waiting on its status page
- Avoids changes made in the heat — no restarts, no timeout tuning — unless they can say why each one is safe
- Checks for the second failure a slow payment causes — duplicate orders or charges — and confirms the idempotency keys are holding
- Sets a time to review the decision and says what would make them switch the mode back off
- Writes the timeline as they go
Follow-up questions
- Nine percent of checkouts are failing. How long before this month's budget is gone?
- Is anything about to make the traffic worse in the next ten minutes?
- Accepting orders before the payment is authorized is a financial risk. Whose call is that, tonight?
- The status page says "investigating". What do you do with that?
- It is 20:30 and the median is back under a second. What do you switch back, and in what order?
Closing
That is the design and the night. What would you like to ask me about how we run the shop — what our dependencies have cost us, which trade-offs have been agreed in advance, and what the last sale was like?
What this line is for
Purpose
A candidate who has carried production through a peak asks about pre-agreed trade-offs and dependencies; one who has not asks about the cloud provider. Naming the topics makes the choice the signal.
One true thing to finish: [name one specific, unflattering fact about your own dependencies or peaks — a third party with no escalation contact, a timeout nobody has set on purpose, a decision that would have to be made at 20:10 because nobody made it in advance]. You would be walking into that. I would rather you heard it here.
What this line is for
Purpose
Ends on a true, specific weakness in how the team handles its dependencies or its busiest nights — the honest pitch to the candidate this round is for, and a fair warning to anyone who wants the hard decisions already made. Check it is still true before you say it.
Site Reliability Engineer (SRE) interviews — common questions
- Who is this Site Reliability Engineer (SRE) interview plan for?
- It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the System design — the dependency that fails slowly round for a Site Reliability Engineer (SRE) role. It gives you a 60 min script to follow in the conversation — 3 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
- What does the System design — the dependency that fails slowly round assess?
- This round is focused on: System design for a slow dependency: timeouts, retries and isolation so that a payment provider slowing down costs checkout and nothing else, idempotency against double charges, capacity for a sale at three times peak, and running the degraded mode yourself when the provider slows on the night. It works through A provider that answers late, Five weeks to three times the traffic and 20:10 on the night, scoring against 28 observable signals, with follow-up prompts on all 3 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- 60 min on 3 questions. The questions take in A provider that answers late (25 min), Five weeks to three times the traffic (15 min) and 20:10 on the night (20 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
- What other rounds should I run for a Site Reliability Engineer (SRE)?
A single round does not cover a whole role. The other rounds in this library for a Site Reliability Engineer (SRE):
Hiring for this role?
Open this plan in Hirezen and make it a position in one click.
- Every interviewer runs the same script and marks the same signals.
- AI drafts the write-ups, and the debrief puts every read side by side.
- No ATS to set up first, and no bot in the call.
Free for your first open role.