Courses › Behavioral Interviews › Question Themes

Incidents & Technical Judgment

Production incidents, trade-offs, tech debt and decisions with incomplete information.

A whole group of behavioral questions is really about engineering judgment: production incidents, hard bugs, technical trade-offs, tech debt, and decisions made with incomplete information. These are the questions where engineers can stand out most, because the story *is* the job. They're also where candidates most often drift into a technical monologue and lose the behavioral signal.

What's being assessed

  • Calm, structured response under pressure, especially in incidents
  • Good trade-offs: knowing what you gave up, and why it was worth it
  • Ownership: you followed through on prevention, not just the fix
  • Communication: you kept stakeholders informed and brought others along
  • Balance: you know when to move fast and when to slow down

Production incidents

Structure an incident story the way a good postmortem is structured:

  • Detection: how you found out, and how bad it was (users affected, revenue, duration).
  • Mitigation first: what you did to stop the damage. Rolling back, a feature flag, failing over. Mitigation comes before root cause, and saying so is a strong signal.
  • Coordination: who you pulled in, how you communicated, and who was the incident commander.
  • Root cause: what actually happened, explained simply.
  • Prevention: the follow-ups you drove (tests, alerts, guardrails, process changes) and the evidence they worked.

[!EXAMPLE] Outline A config change raised connection timeouts on our payments API to 30 seconds. During a downstream slowdown, threads piled up and checkout failed for 18 minutes. I was on call: I rolled back the config within 6 minutes of the page, posted updates in the incident channel every 10 minutes, and brought in the database on-call engineer. The root cause was that timeouts weren't reviewed as risky changes. I added config validation with bounds in CI, a canary for config pushes, and a saturation alert on the thread pool. A similar change was caught by the canary two months later.

[!TIP] Blameless, but accountable If the incident was your mistake, say so plainly. Then focus on the system fix that keeps *anyone* from making the same mistake. That combination of personal accountability and systemic thinking is exactly what senior engineers are expected to show.

Technical trade-offs

Interviewers want to see that you framed the options and chose deliberately:

  • What were the options? Name at least two real ones.
  • What criteria mattered: latency, cost, time to ship, operational burden, reversibility?
  • What did you give up, and how did you limit the downside?
  • Looking back, was it right?

Mention reversibility: "This was a two-way door, so we chose the faster option and planned to revisit it in a quarter." That shows you match the amount of deliberation to the stakes.

Tech debt

These questions test whether you can make a business case, not just complain about bad code:

  • Quantify the cost: incidents per quarter, hours per feature, onboarding time, how often the code changes.
  • Propose an incremental plan, not a rewrite: strangler pattern, a bit of cleanup in every sprint, the 20% of the work that removes 80% of the pain.
  • Show how you got buy-in, and what you measured afterward.

Decisions with incomplete information

Show a process: what you knew, what you couldn't know in time, how you reduced the risk (a time-boxed spike, a prototype, a reversible first step), what would have made you change course, and how it turned out.

Speed vs. safety, and pushing back

  • Shipping fast and iterating: show a clear minimum bar you didn't drop below (data integrity, security), and what you deliberately left out.
  • Pushing back on a request: disagree with data, offer an alternative, and escalate respectfully if needed. Don't just say "no".
  • Refusing to compromise on quality: pick a case where the stakes justified it, and show that you still found a way to meet the goal.

[!WARNING] Common mistakes - Ten minutes of technical detail and no mention of what *you* did or how you worked with others - Hero stories: "I stayed up all night and fixed it alone" with no prevention afterward - Blaming another team for the incident - Trade-offs with only one option that was ever considered

[!TIP] Practice A production incident you handled · The hardest bug you've debugged · A difficult technical trade-off · Making the case for tech debt · A decision with incomplete information · Balancing speed against safety · A time you dove deep