What a Nervous Laugh Tells Me About a DevOps Engineer Candidate

THE INCIDENT QUESTION — READ AS AN
INTERVIEWER:

Interviewer: "Tell me about an incident you
owned."

Candidate: [nervous laugh] "Ha, yeah, so,
there was an outage once. The team handled
it. I was... involved."

What I notice:
- The laugh comes before the answer, not
  after. It's a tell, not a reaction.
- "The team handled it" is the phrase that
  tells me they weren't the owner.
- "I was involved" is vague — involved how?
- There's no timeline, no root cause, no
  fix.

What the laugh reveals:
❌ They didn't own the incident
❌ They can't tell a postmortem story
❌ They've never been the on-call engineer
❌ This is an ownership gap, not a nerves
  gap

What I do next:
- I ask: "What's an incident you personally
  fixed?"
- If they can tell a story, they recover.
- If they laugh again, the reliability score
  drops.

Why it matters:
- Incident ownership is the job
- The laugh is the candidate's own
  recognition that the story isn't there
- The interviewer hears the gap before the
  answer

THE MTTR QUESTION — READ AS AN INTERVIEWER:

Interviewer: "What was your MTTR before and
after the change?"

Candidate: [nervous laugh] "Ha, I don't know
the exact numbers. We didn't really track
MTTR."

What I notice:
- The laugh comes before "I don't know."
- "We didn't really track it" means the
  candidate didn't measure reliability.
- The incident story, if any, has no
  numbers.

What the laugh reveals:
❌ They didn't track MTTR
❌ They can't measure reliability
❌ They can't show improvement
❌ This is a measurement gap, not a nerves
  gap

What I do next:
- I ask: "What did you track? How did you
  know if reliability improved?"
- If they name a metric, they recover a
  point.
- If they can't, the reliability score
  drops hard.

The strong answer:
"MTTR was 42 minutes before the change and
11 minutes after. The 42 minutes was mostly
detection — we found out from customer
tickets. The 11 minutes came from adding
Prometheus alerts on error rate and a
PagerDuty escalation policy. Detection
dropped from 30 minutes to 4, and
resolution from 12 to 7."

Why it works:
✅ MTTR: 42 → 11
✅ Decomposition: detection 30 → 4,
  resolution 12 → 7
✅ Cause: alerts + escalation
✅ The numbers prove the improvement

NO ON-CALL — READ AS AN INTERVIEWER:

Candidate: "I've deployed a lot of things,
but honestly, I've never been on-call."

Interviewer: "So you've never been paged
for a production issue?"

Candidate: [nervous laugh] "Ha, no. The
senior team handled that."

What I notice:
- The candidate is honest, which is good.
- But the gap is real: no on-call, no
  incident ownership.
- The laugh is the recognition that this
  is a big gap for a DevOps role.

What it reveals:
❌ They've never owned a production
  system
❌ They've never debugged at 3 AM
❌ They've never written a postmortem
❌ They've never been the last line of
  defense

What I do next:
- I ask: "What's the closest you've come?
  A lab, a staging incident, a debugging
  session?"
- If they can tell a story, they recover
  some points.
- If not, the role may be too senior.

The honest recovery:
"You're right — I haven't been the
primary on-call. But I've been the
secondary, and I've handled 3 incidents
when the primary was unavailable. The
biggest was a 15-minute outage when a
deploy broke the auth service. I rolled
back, alerted the team, and wrote the
postmortem. I'd like to own the primary
rotation, and I'd prepare by shadowing
the current primary for a month."

Why it works:
✅ Honest: not the primary on-call
✅ Real: 3 incidents as secondary
✅ Specific: 15-minute outage, auth
  service
✅ Action: shadow the primary first

BORROWED INCIDENT — READ AS AN INTERVIEWER:

Candidate: "There was an outage once. The
senior engineer handled it, but I was
involved."

Interviewer: "What did you do?"

Candidate: [nervous laugh] "Ha, I mostly
watched. I was in the incident channel."

What I notice:
- The candidate was in the room but not
  the driver.
- "I mostly watched" is the tell: they
  weren't the owner.
- The laugh is the recognition that
  watching isn't owning.

What it reveals:
❌ They were a spectator, not the owner
❌ They can't describe the root cause
  themselves
❌ They can't describe the fix themselves
❌ They've never been the decision-maker
  in an incident

What I do next:
- I ask: "What would you have done
  differently if you were the owner?"
- If they can reason about it, they
  recover.
- If not, the ownership score drops.

The honest recovery:
"I wasn't the owner — the senior engineer
was. But I can tell you what I learned
from watching. The root cause was a config
change that bypassed review. The fix was
a rollback and a config validation step
in CI. If I were the owner, I'd have added
the validation step before shipping — and
I'd have added an alert on config changes
so we'd know within a minute, not 15."

Why it works:
✅ Honest: not the owner
✅ Root cause: config change bypassed
  review
✅ Fix: rollback + validation
✅ Reflection: validation before shipping,
  alert on config changes
✅ The learning is real, even if the
  ownership wasn't

FULL STORY — AN INCIDENT THAT SURVIVES:

Interviewer: "Tell me about an incident you
owned."

WHAT YOU SAY:
"Sure. Last year we had a 22-minute outage
on a Tuesday morning. The API was returning
502s and I was the on-call engineer.

Timeline: at 09:14, the node group hit its
pod limit. The cluster autoscaler tried to
add a node, but the node group was at its
max size, so the new pods stayed pending.

Root cause: the static max size on the node
group. The autoscaler was working correctly;
it just couldn't scale past the cap.

Fix: I raised the max size from 6 to 9
nodes, cordoned the overloaded node, and
drained it to spread the pods. The API
recovered at 09:36.

Prevention: we added a Prometheus alert on
pod-scheduling failures with a 2-minute
threshold. And we moved to Karpenter, which
removes the static cap. A similar event in
Q3 was caught in 3 minutes and resolved in 5.

MTTR went from 42 minutes to 11 minutes on
average, and the page volume dropped 60%."

What the interviewer thinks:
- "Timeline: 09:14 to 09:36." ✅
- "Root cause: static max size." ✅
- "Fix: max size, cordon, drain." ✅
- "Prevention: alert + Karpenter." ✅
- "MTTR: 42 → 11, page volume -60%." ✅
- "This is an owner." ✅

Signal: no laugh. Evidence.

Why it works:
✅ Timeline with timestamps
✅ Root cause, not just symptom
✅ Fix with named actions
✅ Prevention with a specific change
✅ Numbers: MTTR, page volume

WHEN YOU WEREN'T OWNER — STILL RECOVER:

Interviewer: "Tell me about an incident you
owned."

WHAT YOU SAY:
"Honestly, I wasn't the primary owner on
the biggest incident I've seen. But I was
the secondary, and I did three things that
mattered.

Timeline: a deploy broke the auth service at
14:20, and the API returned 401s for about
15 minutes.

Root cause: a config change that bypassed
review. The auth service read a new
environment variable that wasn't set in
production.

What I did: I was the one who spotted it in
the logs — the 401 rate spiked right after
the deploy. I rolled back, alerted the
primary, and opened the incident channel.
The primary confirmed the rollback and we
were back up at 14:35.

Prevention: I wrote the postmortem and
proposed the fix — a config validation step
in CI that fails if a required env var is
missing. That shipped two weeks later and
caught a similar issue before it hit
production.

I'd like to own the primary rotation, and
I'd shadow the current primary for a month
first."

What the interviewer thinks:
- "They were honest about the role." ✅
- "They were the one who spotted it." ✅
- "They rolled back and alerted." ✅
- "They wrote the postmortem and the
  prevention." ✅
- "They have a plan to grow into the
  primary." ✅
Signal: recovered. Strong hire.

Why it works:
✅ Honest: not the primary owner
✅ Action: spotted, rolled back, alerted
✅ Prevention: validation step in CI
✅ Growth: shadow the primary
✅ The learning is real, even if the
  ownership wasn't

DevOps Incident Checklist:

FOR EACH INCIDENT:
☐ Timeline: what time did it start, what
  time did it end
☐ Symptom: what did users or monitoring
  see
☐ Root cause: the actual cause, not the
  symptom
☐ Fix: what you did, in sequence
☐ Prevention: what you changed so it
  doesn't recur
☐ Numbers: MTTR, incident rate, page
  volume

BEFORE THE INTERVIEW:
☐ Write 3 incident stories with all 6 parts
☐ Practice each in under 2 minutes
☐ Record and listen for vague language
  ("the team," "we fixed it")
☐ Cut every "the team" and replace with
  "I"

DURING THE INTERVIEW:
☐ Start with the timeline, not the
  background
☐ Name the root cause in one sentence
☐ Name the fix in 2–3 steps
☐ Name the prevention and the number
☐ Pause after the number

RED FLAGS IN YOUR OWN ANSWERS:
❌ "The team handled it" with no "I"
❌ No timestamps
❌ No root cause, just a symptom
❌ No prevention
❌ No MTTR or incident number
❌ The laugh comes before the answer

THE LAUGH TEST:
For each incident, ask yourself:
1. "Can I tell the timeline in 20 seconds?"
2. "Can I name the root cause in one
  sentence?"
3. "Can I name the prevention and the
  number?"

If any answer is no, that's the incident to
prepare before the interview.

30-DAY INCIDENT PLAN:

Week 1 — Write the stories
☐ 3 incidents you owned or co-owned
☐ For each: timeline, symptom, root cause,
  fix, prevention, numbers
☐ Practice each in under 2 minutes

Week 2 — Cut the vague language
☐ Read each story out loud
☐ Highlight every "the team," "we fixed
  it," "we decided"
☐ Replace each with "I" and a specific
  action
☐ Re-record and listen back

Week 3 — The gaps
☐ For incidents you watched but didn't
  own, write:
  • What you did in the incident channel
  • What you learned
  • What you'd do differently as owner
☐ Practice the honest recovery story

Week 4 — Stress test
☐ Have a peer ask "what was the root
  cause?" and "what did you change?"
  after every story
☐ If you pause or laugh, that's the story
  to prepare
☐ Re-run the stress test until no pauses

Signs it's working:
✅ You start with the timeline
✅ Every story has a root cause
✅ Every story has a prevention
✅ Every story has a number
✅ You never say "the team handled it"
✅ You never laugh at the incident
  question