Skip to content
Shakeride

Draft, not published · Updated

How to prepare for an SRE interview with hands-on incident practice

Most SRE loops include at least one round where something is broken and you are asked what you would do. Reading about incidents does not prepare you for that round; working through them does.

What the troubleshooting round is looking for

Interviewers rarely expect you to know the answer. They watch the order in which you look at things, whether you state a hypothesis before you change anything, and whether you notice when the evidence contradicts you.

Saying what you are checking and why is half of the round. A silent fix that happens to work tells the interviewer less than a narrated dead end.

Practise on something that is really broken

Flashcards and architecture diagrams teach vocabulary. A broken environment teaches the habits the round measures: reading the symptom before touching anything, narrowing the blast radius, checking one assumption at a time.

Time-box each session. An interview gives you thirty to forty-five minutes, and part of the skill is deciding what to skip.

A routine for the weeks before

One focused session every few days beats a weekend of cramming.

  • Start with a short, single-service failure and narrate out loud as if someone were listening.
  • Write down the first three things you checked and whether each one moved you forward.
  • Move to longer, multi-service failures once the first checks become automatic.
  • After each session, write a five-line timeline: symptom, first hypothesis, evidence, fix, how you confirmed it.

What to say when you do not know

Name what you would look at next and what result would change your mind. That is a complete answer in a troubleshooting round, and it is the one most candidates skip.

All guides

Practise on a real failure

A live AWS account, already broken, and a clock. Fix it with the console and command line, then read a report of how you worked.