Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Identify critical user journeys, valid success, latency and freshness expectations, tenant commitments, and what users can retry. Separate request availability from durable business outcome.
Establish scale assumptions
- Measure volume and impact distribution by journey, tenant tier, region, and payload size. Weighting every request equally can let high-volume cheap reads hide failed saves.
Functional and non-functional requirements
- SLIs reflect user outcomes, targets leave room for change, windows detect fast and slow burns, and budget policy names actions and owners. Contractual SLAs remain distinct from internal SLOs.
High-level architecture
- Instrument journey completion with durable correlation IDs, server and synthetic signals, freshness watermarks, and correctness probes. Compute rolling-window burn and segment views without creating dozens of unactionable targets.
Data model and flow
- Emit attempt, accepted, durable, synchronized, and visible milestones for key operations. Join them into a journey outcome and maintain denominator definitions as versioned code.
Consistency and transaction boundaries
- A 200 response is not success if the accepted write later disappears or misses freshness. Delayed eventual consistency consumes budget once it crosses the promised user threshold.
Failure modes and recovery
- Use multi-window burn alerts, protect telemetry during outages, and define behavior when measurement is unknown. Budget exhaustion triggers pre-agreed actions rather than automatic blame.
Security and privacy
- Do not include tenant content or identifiers in broad telemetry; protect high-cardinality exemplars and access. Security controls are constraints, not error-budget trade items.
Observability and SLOs
- Show journey SLO, contributing stages, tenant and regional tails, error causes, and release correlation. Synthetic probes validate that the measurement pipeline itself still sees the product.
Capacity and cost
- Set targets from user need, architecture capability, and marginal cost. Each extra nine requires redundancy and operations; fund it where customer and contract value justify it.
Alternatives and trade-offs
- One global SLO is easy to communicate but hides important cohorts; too many SLOs diffuse ownership. Keep a small journey set and use segmented diagnostics beneath it.
Evolution and migration
- Run proposed SLIs without policy, compare them to incidents and complaints, then agree targets and budget actions with product. Review targets as architecture and customer expectations change.
What Staff and Principal candidates should emphasize
- Senior candidates define success at the user boundary and explain what decisions error budgets change. They avoid copying a generic 99.9% target.
Decision trade-offs
Measurement unit
Option A
All API requests equally
Option B
A small set of end-to-end user journeys
Recommendation:Use journey outcomes as primary SLOs and endpoint metrics as diagnostic contributors.
Target setting
Option A
Highest affordable availability
Option B
User-need target with explicit reliability cost
Recommendation:Set targets from customer harm and contracts, then fund the architecture; extra reliability without value can reduce product learning.
Follow-up interview questions
- 01Should retries count as successful?
- 02How does sync freshness become an SLI?
- 03What action follows budget exhaustion?
- 04How do enterprise tiers affect the SLO without creating a metric per tenant?
Common weak answers and mistakes
- 01Using HTTP status as the sole measure of a durable workflow.
- 02Setting 99.99% because it sounds credible without cost or user analysis.
- 03Averaging all traffic and hiding critical low-volume operations.
- 04Creating dashboards without an agreed policy that changes release or reliability work.
Interviewer evaluation rubric
Chooses generic uptime and latency targets without user journeys, denominator definitions, or policy.
Defines journey SLIs, rolling windows, burn alerts, targets, and pre-agreed error-budget actions.
Includes durable and freshness outcomes, cohort tails, telemetry failure, target economics, and product alignment.
Creates a trusted decision system connecting customer harm, architecture investment, releases, contracts, and organizational incentives.