Conducting a Production Readiness Review

WHAT THIS TESTS: Your ability to think like an operator, not just a builder. A PRR is a structured gate ensuring a service can be run reliably in production, and the interviewer wants a repeatable checklist mindset rather than ad hoc instinct.

A GOOD ANSWER COVERS: First, observability: does the service emit metrics, structured logs, and traces, and are alerts tied to meaningful symptoms or SLO violations rather than noisy causes? Second, capacity and performance: has it been load tested to expected and peak traffic, with known resource limits and a scaling story? Third, dependency and failure analysis: what are its upstream and downstream dependencies, what happens when each fails, and does it degrade gracefully with timeouts, retries with backoff, and circuit breakers? Fourth, operational readiness: is there an on-call rotation, are runbooks written for the top alerts, and is escalation defined? Fifth, release safety: can it be deployed incrementally via canary or rolling updates, gated behind feature flags, and rolled back quickly.

COMMON WRONG ANSWERS: Treating the PRR as a functional QA pass, or naming only monitoring while ignoring capacity, dependencies, and rollback.

LIKELY FOLLOW-UPS: How do you handle a service that passes functionally but has no load testing? What do you do if the team resists writing runbooks? How does a PRR differ for a stateful versus stateless service?

ONE CONCRETE EXAMPLE: A new checkout service passes functional tests but the PRR reveals it calls a fraud-check API with no timeout. Under that single finding you block launch until a timeout plus circuit breaker and a degraded fallback path are added, because an unbounded dependency could cascade into a full checkout outage.