Loading…
Troubleshooting interview questions: an intermittent login failure, a latency regression, a stalled job. Practise narrowing the blast radius and ruling causes out in order.
Troubleshooting questions give you a symptom instead of a requirement. A customer says the login page fails sometimes; p99 latency tripled while p50 did not move; a nightly job reports success and produces nothing. The interviewer usually has one specific cause in mind and will not volunteer it, so the round is not a knowledge test — it is a test of method. What is being assessed is whether you establish the blast radius before forming a theory, whether each thing you look at rules something out, and whether you can separate stopping the damage from finding the cause. Every question here is worked the way the round is actually scored: the clarifying questions to ask first and what each answer eliminates, a top-down narrowing ladder, and the causes the symptom is genuinely consistent with, with the fingerprint that tells them apart.
The failure mode interviewers see most often is a candidate who starts naming tools. "I would check the logs" is not an investigative step, because it does not say what the logs would rule out, and a candidate who reaches for a dashboard before asking how many customers are affected has skipped the only question that changes what they do next. The strongest answers treat scope as the first measurement — all users or some, one region or everywhere, since when, and correlated with what change — because each answer halves the search space. They also separate mitigation from diagnosis: a rollback, a drained node or a disabled feature flag stops the bleeding while the cause is still unknown, and an interviewer who has carried a pager notices immediately when a candidate leaves customers failing in order to finish being right. Expect to be asked what you would have needed in place beforehand to answer the question in one minute instead of thirty.
6 troubleshooting · 1/3/2 easy/medium/hard
A design round starts from requirements and asks you to build something that survives its own numbers. A troubleshooting round starts from a symptom in a system that already exists and asks how you would find out what is wrong with it. The reasoning runs in the opposite direction: instead of expanding a design to cover more cases, you are eliminating possibilities until one is left. Design rounds reward completeness, troubleshooting rounds reward ordering.
They are standard in SRE, DevOps, platform, cloud and infrastructure loops, where they frequently replace a second design round, and they appear in senior software engineering loops as the operational half of the interview. They are also the most common format for a debugging round in a support or solutions engineering loop. If you are interviewing for a role that carries a pager, expect at least one.
No, and the questions are written on that assumption. The interviewer controls the facts and reveals them only in response to questions, so the candidate who asks "is it all users or a subset?" learns something the candidate who starts listing causes never will. A wrong final hypothesis reached by sound elimination usually scores better than a lucky guess, because the interviewer is hiring the method, not the answer.