All jobs / Engineering manager / tech lead
Incident Management interview questions
Incident Management questions a Engineering manager / tech lead can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A developer on your team ran a migration that took production down for an hour.
What do you do?
The strongest answer: Fix it with them first, then look at why the process let a risky migration through — and make sure they know the team has their back
Why it works: Exactly. Repair, then fix the system, and protect the person from becoming the story.
- Repair first, then the system.
- Blameless, in public and in private.
- Do not add yourself as a gate.
- Never name the person as the cause.
Why does a team bother with incident severity levels?
The strongest answer: So that in the moment everyone agrees how big the response is: severity decides who gets woken, who is told, how often we update, and whether there is a review afterwards
Why it works: Exactly — severity is a decision rule agreed in advance, not a label added afterwards.
- Severity decides the response.
- Agree the levels beforehand.
- It sets who is told.
- Never tune it for reporting.
How do you set up on-call for a small team?
The strongest answer: Everyone in the rotation including me, time back after a bad night, and every page tracked so we fix what wakes us
Why it works: Exactly. Fair rotation, recovery time, and pages treated as work to eliminate.
- Everyone rotates, lead included.
- Time back after bad nights.
- Track pages, fix causes.
- Do not be the hero.
Production is down and the team is on the call. What is your role as manager?
The strongest answer: Coordinate: make sure someone is commanding, own the communication outwards, make decisions the responders need, and keep noise away from them
Why it works: Exactly. Your job is coordination and shielding, not a fourth pair of hands on the keyboard.
- Coordinate and communicate.
- Shield the responders.
- Make the decisions they need.
- Root cause comes afterwards.
What makes a post-incident review worth doing?
The strongest answer: Blameless, focused on how the system allowed it, with a few action items that have owners and dates and get tracked
Why it works: Exactly. Systems, not people, and actions that actually get done.
- Blameless, always.
- Ask what the system allowed.
- Few actions, owned and dated.
- Track them to done.
What does a good escalation path look like for the engineer on call at three in the morning?
The strongest answer: Written down before the night: who to call second, when to call them — a time limit rather than a feeling — and standing permission to wake anyone, including you, without asking first
Why it works: Exactly — a named next person, a time trigger and explicit permission are what make escalation actually happen at 3 a.m.
- Escalation is a rule, not a feeling.
- Name the next person.
- Set a time trigger.
- Waking someone is always allowed.
On-call is paging most nights. What do you do?
The strongest answer: Treat the pages as work: track them, fix or tune the top causes with real capacity, and give people time back after bad nights
Why it works: Exactly. Alert load is a backlog to burn down, not a weather condition.
- Pages are work.
- Fix the top causes.
- Time back after bad nights.
- Do not mute, do not pay to ignore.
A major outage is in progress and three executives are messaging you for updates.
What do you do?
The strongest answer: Confirm there is an incident commander, set a communication cadence, take the executive updates myself, and keep leadership out of the responders’ channel
Why it works: Exactly. Structure, cadence, and a shield between the fixers and the anxious.
- Confirm the commander.
- Set the cadence.
- Own exec communication.
- Shield the responders.
A post-incident document lands on your desk. Under “root cause” it says: human error — an engineer ran the wrong script.
What do you say?
The strongest answer: Send it back: ask what made that mistake easy and likely — the script’s name, the missing confirmation, no staging run — and have them list contributing factors instead of one cause
Why it works: Exactly — “human error” is where the investigation starts, and the conditions that made it easy are the fixable part.
- Human error is a starting point.
- Ask what made it easy.
- List contributing factors.
- Fix the trap, not the person.
How do you build a healthy incident culture across an organisation?
The strongest answer: Blameless reviews as a norm, learning shared across teams rather than filed, and reliability work funded from the budget rather than from goodwill
Why it works: Exactly. Blameless, shared, and paid for.
- Blameless as a norm.
- Share learning across teams.
- Fund reliability.
- Never punish the reporting.