How to practise the DevOps troubleshooting round

If your DevOps or SRE interview includes troubleshooting, practise it alongside the required cloud, coding and systems topics. Reading commands helps, but it does not show whether you can choose the next observation when several causes fit the symptom.

A useful exercise starts with a deployment you did not write and asks you to explain each diagnostic step.

What the round actually is

You get a symptom and not much else. A pod is restarting. A service returns 503 while every pod looks healthy. Latency at p99 is three seconds while the average is two hundred milliseconds. The interviewer knows the answer, has deliberately given you less information than you need, and is going to make you ask for the rest.

The important part is what they are watching. They are not checking whether you land the cause, and a good interviewer will often stop you before you get there. They are checking the shape of your reasoning:

• Do you form a hypothesis before you start typing commands?
• Do you know which observation would rule that hypothesis out?
• Do you reduce user impact before you satisfy your curiosity?
• Do you change direction when the evidence disagrees with you?

A candidate who lists fifteen commands with no hypothesis behind them scores worse than one who names two possible causes, says which one they would test first and why, and asks for one specific piece of output.

Why memorisation does not work here

Tool questions have a fixed answer surface. There are only so many things to ask about Terraform state, and a week of revision closes most of that gap.

Troubleshooting has no such surface, because the scenario is chosen to be one you have not seen. Preparation that consists of memorising twenty scenarios fails on the twenty-first, and interviewers pick scenarios specifically to get past rehearsed answers. What transfers is method, and method is only built by doing it.

There is a second reason. The round is a proxy for on-call. Whoever is interviewing you will, if you are hired, be woken up by the same pager you are. They are answering a very specific question: when this person is alone at 3am with a system they do not understand, what happens? Everything in the scoring flows from that.

The method that scores

Four steps, and the order matters more than the content.

State the symptom precisely. Not "the service is broken" but "40 percent of requests to checkout return 503, starting at 19:40". Precision here bounds the search immediately: something that started at a moment has a trigger, and partial impact suggests checking cohorts, zones and request paths; a global configuration change can still affect only some requests.

Say what you would look at first, and why. The why is the score. "I would check changes around 19:40, including configuration, traffic and dependencies. A matching deployment is a lead to test, and the absence of one does not rule out a delayed effect of an earlier change."

Mitigate before you diagnose. If a rollback restores service, do it, and say so out loud. You can find the cause with the pressure off. Candidates who explain the failure elegantly while the imagined service stays down have answered a different question than the one asked.

Update visibly when you are wrong. "Latency did not recover after rollback. I would confirm that the rollback completed and check for persistent effects before ruling out the release" is one of the strongest sentences available in this round. It shows you treat a hypothesis as disposable, which is the entire skill.

How to practise it in a week

Use a disposable lab cluster with no production data or shared dependencies. Break things on purpose and diagnose them out loud.

Set a memory limit low enough that the container is killed during warm-up, then work from the exit code back rather than from the manifest forward. Point a Service selector at a label no pod carries, then diagnose the 503 without looking at the manifest you just edited. Add a liveness probe with an initial delay shorter than the application's startup time and watch the restart loop that produces. Delete a PVC while a pod still holds it and work out why it hangs in Terminating.

Each of these takes ten minutes to set up and teaches you a failure signature you will recognise instantly under pressure. Four of them is a better week of preparation than forty flashcards.

The out-loud part is not optional. The round scores narration, and thinking silently for thirty seconds reads as being stuck even when it is not. Practise saying the boring sentence: "I am checking recent changes, then testing whether the timing and affected requests support a connection."

What this means for the rest of your preparation

None of this argues that tool knowledge is worthless. It is the floor, and you will be filtered on it in the screen. The argument is about allocation. We do not have representative evidence for a fixed weighting of interview rounds or for how candidates divide their study time.

If you want a concrete plan: spend half your time on diagnostic practice, a quarter on design with the arithmetic done out loud, and the last quarter on writing behavioral stories with numbers in them. Treat this as a starting allocation for a troubleshooting-heavy loop, then adjust it to your recruiter's outline and your weakest areas.

You can start with the scenario and troubleshooting bank, which is ordered easy to hard and weighted toward the failure signatures that actually appear in loops.