DevOps interview: passing the incident and scenario exercise
· 8 min read
In a DevOps role, the incident scenario is the most revealing exercise — and the worst prepared. They announce an outage and watch you think. The order in which you do things says more than the solution you land on.
What is the right order of reflexes?
Restore first, understand second. Many candidates dive at root cause while the service is still down. An experienced operator starts by measuring impact, communicating, then finding the fastest way back — a previous deployment, a failover, a feature toggle. Analysis comes afterwards, calmly.
- Observe: what does the user see, since when, and across what scope.
- Notify: who needs to know, before the cause is even known.
- Stabilise: return to a known state, even at the cost of the latest release.
- Understand: once the service is back, and not before.
- Fix durably: the correction, then whatever prevents a repeat.
What does your way of finding the cause reveal?
Your method. "I look at the logs" is a weak answer. "I look at what changed in the last few hours — deployment, configuration, expired certificate, load spike — because 80% of outages follow a change" shows you have lived it. Naming where you look, in what order, and why, beats listing tools.
The follow-up almost nobody anticipates
"And if the rollback does not work?" That is where the interview is really decided. They test your ability not to be locked into a single plan: do you have a plan B, can you degrade the service rather than let it fall over entirely, do you know when to escalate rather than push on alone? Prepare that answer too.
Should you mention post-mortems?
Yes, without making it a buzzword. What counts is the culture you describe: a blameless post-mortem, looking for what the system allowed rather than who erred. If you add what actually changed afterwards — an alert added, a regression test, a simplified procedure — you show you close the loop.
How do you answer if you have never handled a major incident?
Say so, then tell the closest one you have lived, however modest: a broken test environment, a failed deployment, an expired certificate. Reasoning demonstrates at small scale. Claiming on-call experience you do not have is the surest way to be dismantled by two follow-up questions.
In an incident, they do not expect you to know. They expect you to know what to do when you do not.
The classic technical questions still need preparing separately: we cover them in DevOps interview, and the architecture angle in the cloud engineer interview.