Turn Incidents Into Your Best Interview Stories
Every major incident you've handled is a gold mine — and most SRE candidates leave it buried. Incident stories show ownership, calm under pressure, systems thinking, and cross-team leadership all in one narrative. The difference between candidates who get Staff SRE offers and those who don't is usually how they tell these stories.
Lead with the blast radius and your ownership, not the technical root cause. Interviewers want to know what you saw, what you did, and what broke less after.
Of Askia DevOps/SRE clients land offers within 60 days
Askia client dataMedian base for Senior SRE in major tech markets
Industry dataResponse rate with infrastructure-outcome positioning
Askia A/B testingIs this guide for you?
Use this Good fit if you…
- ✓You're targeting Senior SRE, Staff SRE, or Platform Engineering roles
- ✓You've led or co-led incident response before
- ✓Behavioral rounds are where you stall out
Skip Not the right fit if…
- ✗You're early-career without production ownership
- ✗You're targeting pure infrastructure-as-code roles
- ✗Your interviews are technical-only with no behavioral component
The playbook
Five things to do, in order.
Open with the blast radius, not the root cause
"We had a 47-minute partial outage affecting 12% of paid users in the EU region." That's a story. "Our Postgres replication lag spiked" is a postmortem bullet. Start with business impact.
Own your specific role in the incident
Don't say "we fixed it." Say "I took incident commander, assigned DRI to each component, and ran 10-minute status syncs." Specificity signals seniority.
Name the decision, not just the action
"I decided to roll back the deploy rather than hotfix forward because the error rate wasn't converging." This is Staff-level thinking — you made a call under uncertainty.
Quantify the before/after
MTTD before: 8 minutes. After your runbooks and alerting improvements: 90 seconds. Cost of the incident: ~$120K in SLA credits. These numbers make your story memorable.
End with systemic change, not just the fix
The most impressive part of an incident story is what you changed so it doesn't happen again. Detection improvement, runbook created, chaos experiment added — this is where Senior becomes Staff.
See the transformation
"We had an outage. I helped debug it and we fixed the database issue."
"Led incident response for a 47-minute EU payment outage affecting 12% of paid users (~$85K SLA exposure). Identified Postgres replication lag as the root cause, made the call to roll back the deploy over hotfix, and coordinated 4 engineering teams to restore within SLA. Post-incident: added replication lag as a P1 alert trigger — MTTD for that failure class dropped from 8 minutes to 90 seconds."
Questions people ask
What if the incident was mostly someone else's fault?
Focus on your role in detection, coordination, or recovery — not blame. "I identified the root cause and coordinated the fix" is enough. Never position yourself as the hero who saved everyone from someone else's mistake.
Can I use incidents from years ago?
Yes, if they're the best examples. Recency matters less than depth. A 3-year-old incident where you led a systemic improvement beats a last-month incident where you ran one kubectl command.
What if I work at a company with no formal incident process?
That's actually a great story hook. "We didn't have a formal process, so I built one — here's what I put in place and how it changed our MTTD."
Ready to put this into practice?
Get personalized coaching for your DevOps & SRE job search — resume, interviews, and offer strategy tailored to you.
