The Bullet About an Incident

Most engineers leave incidents off their resume. The ones who include them usually write a hero story: a heroic night, a heroic fix, an unquantified disaster averted. Both are mistakes, and the second is worse, because a reviewer who has run incidents can hear the exaggeration.

An incident is one of the few things you can put on a page that demonstrates reasoning under uncertainty. That is exactly what a technical reviewer struggles to assess and would most like to know.

This is not the reliability-programme framing — reducing pages, tuning alerts, eliminating classes of failure over quarters — which is covered in resumes for infrastructure and platform roles. This is one event, in two lines, and it applies to product engineers as much as to anyone on call.

What makes an incident bullet work

Four elements, and you can fit three of them into two lines if you are disciplined.

The symptom, in system terms. Not “a major outage” — what was actually observed. Requests timing out on one endpoint, a queue growing without bound, duplicate charges, a region serving stale data.

The diagnosis, including the wrong turn. This is the element everyone omits and the one that carries the most information. Real debugging involves a hypothesis that was wrong, and saying which one you eliminated tells a reviewer how you think.

Containment separated from the fix. Senior incident behaviour is stopping the bleeding first and fixing the cause afterwards, and the distinction is invisible in most resumes. A bullet that shows you know the difference between a mitigation and a repair reads as experience.

The follow-through. What made it not happen again, or made it detectable next time. Without this, the bullet is a war story; with it, it is engineering.

Weak: Resolved critical production outage affecting thousands of users, restoring service quickly under pressure.

Stronger, illustrative: Diagnosed a checkout outage that presented as database saturation: the query load was a symptom of a cache client falling back to origin on a TLS renewal failure. Contained it by pinning the previous client version, fixed the renewal path, and added an alert on fallback rate so the next occurrence pages before the database does.

The second one is longer and it earns the space. It contains a misleading symptom, a real cause, a mitigation, a repair, and a detection improvement. It also contains no adjectives about severity, which is why it reads as true.

Honest scope in a multi-person response

Incidents are the single most tempting place to absorb other people’s work, because the write-up you remember is the team’s and the pronoun in a resume is “I”.

Write your part. “Joined the response as the service owner and found the cause” is a strong claim if it is true. “Led the incident response” means you were the incident commander, which is a specific role, and a reviewer who has held it will ask what you did about comms and handover. If you were one of six engineers on a call, the honest and still impressive version names your contribution: the hypothesis you tested, the dashboard you built during the incident, the rollback you executed.

The general rule is in when the numbers belong to another team, and it has an incident-specific corollary: never claim the recovery time as your achievement if the recovery was a group effort with somebody else’s decision at the centre of it.

What to leave out

Impact figures you did not measure. Revenue lost, users affected, orders dropped — these usually come from someone else’s estimate, made under pressure, and they are the first thing an interviewer probes. If you have a real figure from a real dashboard, use it and say where it came from. Otherwise describe the class of impact: “checkout unavailable for a subset of regions”.

Blame. Naming the team or the vendor whose change caused it reads badly no matter how accurate it is, and it tells a reviewer how you will talk about their colleagues. Describe the mechanism, not the author. This holds even when the mechanism was somebody’s obvious mistake.

Anything security-sensitive. An unpatched weakness, an internal hostname, or the specifics of a data exposure do not belong on a document you send to strangers. Describe the class and the control.

Endurance as an accomplishment. Hours awake, weekends worked, and nights on a bridge call are not signals of engineering quality, and to many hiring managers they read as a signal about the organisation you came from rather than about you.

Severity labels without context. “Resolved a Sev1” means whatever a particular company’s matrix decided, and reviewers know the definitions vary. Say what was broken instead.

The incident you caused

Almost everyone has one. It does not belong on the resume as a confession, and it does belong in your interview preparation.

There is a legitimate middle path. If your mistake led to work that genuinely improved the system, the improvement is yours to claim, described as the work it was: “added idempotency keys to the payment retry path and backfilled the duplicate detection” is true, useful, and does not narrate why it was needed. If the interviewer asks what prompted it, answer plainly. That conversation goes far better than most people expect, and the version where you have clearly learned something specific is one of the better answers available to you.

What you must not do is invert the story so the cause becomes someone else’s. It is a small lie that a follow-up question exposes, and it converts a story about growth into a story about honesty.

Where it goes, and how many

One incident. Two if they demonstrate genuinely different things — a diagnosis and a systemic prevention, say.

It sits as a bullet inside the role where it happened, usually not the first bullet: ownership and scope should come before your best debugging story, because scope is what the reader is sorting on. If the incident was the most interesting engineering you have done and the follow-through was substantial, it can carry a selected-work block instead, which has room for the constraints and the trade-off — see a selected-work block for the system you know best.

For junior engineers the calculus shifts. A well-described diagnosis is one of the strongest things a junior resume can contain, because it substitutes for scope you do not have yet. A small system is a perfectly good place to demonstrate reasoning, and reviewers know it.

The check

Read your incident bullet and ask what a reviewer learns about your thinking. If the answer is “that something bad happened and it stopped”, the reasoning is missing — you have written the outcome and left out the part where you were uncertain.

Then ask whether every clause would survive the question “how do you know?”. The clause that would not survive is almost always the impact figure, and cutting it makes the bullet stronger, because what remains is the part only the person who was there could have written.