Prod Is Down
"You get a call: the citizen-facing portal is throwing 500s. Walk me through what you do." This is the most common ops scenario question, and it isn't testing whether you know the answer — there is no answer yet. It's testing whether you have a triage order and whether you can communicate while you work. The candidate who starts with "I'd check the code" has already lost; the candidate who starts with "first I'd confirm the blast radius" is halfway to a yes.
The strong-candidate structure
Clarify first. "Is it all users or a subset? All pages or one endpoint? When did it start?" Interviewers want you to ask — it shows you don't debug a rumor. Then reason aloud through four steps, in this order:
- Impact — who is affected, how badly, and is data at risk? This decides urgency and whether you page anyone else.
- Recent changes — deployments, config changes, certificate expiries, upstream releases. "What changed?" solves most incidents by itself; check the release pipeline and change log before touching a debugger.
- Logs and health — structured logs, health-check endpoints, APM traces, dependency status (database up? auth provider up? disk full?). You're forming a hypothesis, not reading everything.
- Rollback vs fix-forward — if a recent deployment correlates, rollback is usually the fastest path to restoring service; fix-forward only when rollback is unsafe (a migration already ran) or the cause clearly predates the release. Say the trade-off out loud: restore service first, root-cause second.
Communicating while debugging
Public-sector interviewers care about this heavily: who do you tell, and when? A strong answer includes a status cadence — "I'd post in the incident channel that we're investigating, give an update every 15–30 minutes even if it's 'no change,' and never go silent." Mention writing a blameless post-incident review afterward: timeline, root cause, and the guardrail that prevents recurrence. That last sentence signals seniority more than any debugging technique.
Red flags
- Guessing before looking — "it's probably the database" with zero evidence.
- Restarting things repeatedly as a strategy rather than a stopgap you note and move past.
- Debugging in silence for an hour while stakeholders refresh a dead page.
- No mention of verifying the fix actually restored service (watch error rates drop, don't assume).
Practice prompts
- "The site is up but logins fail intermittently — maybe 1 in 10 attempts. Where do you start?"
- "You rolled back and the errors stopped. Your manager asks if we can redeploy tomorrow. What do you need to know first?"
- "You find the bug was introduced by your own commit last week. What do you say in the incident review?"