Site Reliability Engineer (SRE) interview questionsTechnical Interview round

Purpose

Frames the page as an inheritance with users, a tired rotation and a date, so the hour goes on what to measure, page on and prepare for, not on definitions.

Purpose

Separates knowing the vocabulary from designing an SLO. The draft has ordinary faults — one ratio for three journeys, an availability target never met, and a latency line with no scope or window at 300 ms, which is neither met nor a bucket edge — and the 2nd shows what they cost.

Signals to score

• Splits the SLO by journey, showing that 40% of bookings failing moved the overall rate only to 0.45%
• Prices the 2nd: about 2% of a month's budget under one 99.9% SLO, about 40% under a booking SLO of 99.5%
• Sets each target below what the journey achieves — searches run at 99.96%, so about 99.9%; bookings at 99.8%, so 99.5–99.7% — and drops a 99.99% never met
• Gives latency a scope, a window and thresholds the histograms can count, where the draft's 300 ms is neither met nor a bucket edge
• Says the panel's 640 ms, a mean of twelve p99s, is not the p99 of anything, and sums histogram buckets across pods instead
• Works out that about 6% of six-request screens wait on a request slower than the request p99
• Says what a not-5xx count at the load balancer misses, and uses the app's 0.5% without adopting it raw
• Says what a calendar month costs — a bad 31st forgiven on the 1st — and uses a rolling window

Follow-up questions

• On the 2nd, 40% of bookings failed for ninety minutes. What did the overall number do?
• The panel says 640 ms and the load balancer 1,150 ms. Which is the p99?
• A results screen waits for six requests. What does your latency target mean for the screen?
• The app counts 0.5% of searches failing. Which number goes in the SLO?
• Why not keep 99.99% as something to aim for?

Purpose

The arithmetic of the round. Anyone can say "page on symptoms"; the separator is turning an SLO into thresholds and windows, replaying them against three real events, and keeping the few cause-based alerts that still earn a page.

Signals to score

• Turns each SLO into burn-rate alerts pairing a long window with a short one, and says what error ratio each fires at
• Finds a booking alert would have paged about eleven minutes into the 2nd — at 99.5%, paging at 14.4 times over an hour — not at 19:50
• Shows one alert on all requests could not: 0.45% against 99.9% burns at 4.5, under every paging threshold
• Lets a deploy blip stop paging while it still spends budget, and turns the 502s into a ticket to fix pod shutdown
• Deletes `HighCPU` as a page, since a 70% autoscaling target puts single pods past 80% on most busy evenings
• Keeps cause-based pages only where the symptom comes too late, like a certificate days from expiry with renewal failing
• Keeps `DBConnections` as a capacity ticket: the autoscaler pressing on the database's limit
• Notices a ratio-based alert can still page on 40 requests a second, and asks what the nightly rebuild does to searches
• Replays the 28 days and counts two or three pages, one of them the 2nd

Follow-up questions

• What error rate does your fastest booking alert fire at, and how long does 40% take to reach it?
• What would one alert on all requests have done on the 2nd?
• A deploy fails 2% of requests for four minutes. Who gets paged, and should they?
• Which cause-based alert would you still wake someone for?
• At 03:00 there are about 24 bookings a minute. How many failures does it take to page?

Purpose

Gives everyone the same budget, and makes the release something people want for a good reason, so holding it back costs something.

Purpose

Tests whether the candidate uses a budget as a rule agreed in advance rather than as a veto or a scoreboard. The arithmetic is short; the read is what they do with it four days before the busiest twenty minutes of the quarter.

Signals to score

• Turns the budget into bookings: about 22,000 left, fewer than the 2nd alone cost
• Notices the 2nd leaves a 30-day window on Sunday, so Monday's budget will look healthy by the calendar alone
• Asks what has changed since the 2nd — a test that reproduces it, the booking alert, a fast rollback — before deciding
• Separates the fix from the new feature, and would ship one without the other
• Limits the blast radius: a flag per restaurant, a few first, their failure rate watched against everyone else's, and the rate that turns it off agreed beforehand
• Keeps Monday's capacity work out of any freeze, because it is reliability work
• Says who decides — product and reliability, agreed in advance, with a named tie-breaker — so the budget sets a default, not a veto
• Writes the policy down — costly incidents, an exhausted budget, known peaks, exceptions — and has it signed before it is needed

Follow-up questions

• How many failed bookings are left in this window, and how does that compare with the 2nd?
• When does the 2nd leave the window, and what will the budget look like then?
• Restaurants asked for this. Who decides, and what happens if you disagree?
• Do the capacity changes for Monday stop too?
• What would you write down so this is not argued again next quarter?

Purpose

Most candidates multiply Friday by three and a half and add pods. The separator is finding the database's two limits, connections and CPU; the cache rule that empties itself on the busiest restaurants; and the step at 12:00 that no autoscaler meets.

Signals to score

• Forecasts a range from last year's multipliers — about 3,500 searches and 96 bookings a second — and what 900 restaurants could add
• Finds the connection limit: 30 a pod plus 20 reaches 500 at about 16 pods; the autoscaler may go to 24
• Uses 4 busy connections in 30 to show the pools are oversized, and that busy connections rise if queries slow
• Finds that at the same hit rate the opening's cache misses alone need more than the whole primary
• Sees the release job empty the cache for the 900 restaurants at 12:00, and every booking empty it again
• Sizes staleness to the primary — 12,600 restaurant-dates at a 60-second TTL is about 210 refreshes a second — with jittered expiry, coalesced misses and the booking call deciding
• Adds read capacity before Monday — a search replica or a larger primary — and prices a resize's failover
• Pre-scales before 12:00 instead of trusting the autoscaler with a step, and lifts its limits only once the database can take them
• Wants a load test of the opening's mix, passed or failed on the SLOs rather than on a replayed Friday
• Has a waiting room, waves of restaurants or a cached-only switch ready for being wrong, and names who may use it

Follow-up questions

• What do you plan for, and why that number rather than 3.5 times Friday?
• At how many pods does the database run out of connections?
• The cache hits 85% on a Friday. Why might it not at 12:00 on Monday?
• Someone raises the autoscaler's maximum to 48. Does that help?
• At 12:05 search p99 is four seconds and climbing. What do you have ready?