Define an SLO for a checkout service. What would you pick and why?
What they are really testing: Whether you can pick a measurable indicator tied to user experience and set a target from business consequence rather than from a habit of writing nines.
A real interview question
Define an SLO for a checkout service. What would you pick and why?
What most people say
drag me
“Five nines availability, since checkout is the most critical service.”
Five nines is about 26 seconds of downtime a month, which is extraordinarily expensive and almost certainly beyond what the business needs or the architecture supports. Picking a number by importance rather than by cost and consequence is the tell.
The follow-ups they ask next
Why 28 days rather than a calendar month?
It contains exactly 4 of each weekday, so weekly traffic patterns are weighted evenly, and it avoids the budget resetting on the 1st, which otherwise encourages risky behaviour at month end.
The service is at 99.99% and the target is 99.9%. Is that good?
Not necessarily. Consistently overshooting suggests you are spending too much on reliability and could take more risk, ship faster, or reduce cost. An unused error budget is unrealised velocity.
What the interviewer is listening for
- Includes latency in the success definition
- Derives the target from business consequence
- Measures at the client or edge, not only server side
What sinks the answer
- Picks nines by perceived importance
- Availability only, ignoring latency
- No consequence attached to breach
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“The indicator is [proportion of checkout requests succeeding within 2 seconds over 28 days], since [a slow success is still a failure]. The target comes from [what failure costs versus what each nine costs], usually landing near [99.9%, about 43 minutes a month]. Frame it as [an error budget with an agreed consequence], and measure [at the edge, since server metrics miss requests that never arrived].”
Keep going with observability
Foundation
A web service is running in production. What would you monitor, and why those things?
Mid
Your team gets 40 alerts a night and mostly ignores them. How do you fix that?
Senior
Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
Senior
Design an observability stack for a system where nobody can currently answer why a request was slow.
Senior
Leadership asks you to prove the platform investment is working. What do you measure?
Senior
You inherit 200 Jenkins jobs with no documentation and are asked to migrate to a modern CI system. How do you approach it?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free