Data-Driven Debugging

Tell debugging stories that follow evidence: stop the damage, measure, form a hypothesis, prove the cause, and leave better monitoring behind.

Overview

Debugging questions test whether you find causes with evidence or with guesses. Almost everyone has fixed a hard bug. What the interviewer scores is the path: did you look at data before changing things, did you test an idea before trusting it, and did you prove the cause rather than stop at the first thing that looked plausible?

A useful model is the one Google's SRE book describes for troubleshooting. You observe the system, form a hypothesis about the cause, and test it; if the test fails, you form the next one. The same book puts one step first: stop the bleeding. Users come before root cause.

Good stories also use the right data. Modern systems give you three main signals: metrics (numbers measured over time, such as error rate or latency), logs (a record of one event) and traces (the path of one request through many services). Naming which one told you what is a strong signal of real experience.

The example stories on this page are fiction. They show the shape of a strong answer; use your own incident.

First move — Limits user impact, then measures — Starts changing code at once
Evidence — Names the metric, log or trace that pointed the way — 'I looked at the logs'
Hypotheses — Forms one, tests it, drops it if wrong — Tries fixes until one sticks
Proof — Reproduces the cause or shows the fix moved the metric — 'It went away'
Prevention — New alert, dashboard, test or runbook — Stops at the fix

What you will be able to do

Tell a debugging story in which every step is driven by a piece of data.
Explain what metrics, logs and traces each tell you, and when to use which.
Show how you ruled out the obvious suspect before you found the real cause.
End with proof that the fix worked and a change that catches it earlier next time.

Interview questions

Walk me through how you debugged a difficult production issue.
What observability data do you rely on, and when?
Tell me about a time the root cause was not what everyone expected.
What do you do after the bug is fixed?

Data-Driven Debugging

Overview

What you will be able to do

Interview questions

More Behavioral topics