Troubleshooting interview: how to debug a system out loud

A structured debugging method

1. Scope the impact: who is affected, since when, how badly, everywhere or one region?
2. Ask what changed: deploys, config, traffic, dependencies, certificates, infrastructure.
3. Observe: dashboards, error rates, latency percentiles, saturation, logs, traces.
4. Form a hypothesis that explains all the symptoms.
5. Test it cheaply, and narrow down layer by layer.
6. Mitigate first (roll back, fail over, scale out), then find the root cause.
7. Communicate status throughout, and propose a post-incident review.

Frameworks worth naming

Two simple checklists help you sound systematic. The USE method checks every resource — CPU, memory, disk, network — for Utilisation, Saturation and Errors. The RED method checks every service for Rate (requests per second), Errors and Duration (latency). Mentioning one of them and then applying it shows structure without reciting theory.

Commands and signals to mention

Worked example: “the site is slow”

Scope: is it slow for everyone or one region, all pages or one endpoint, since when? Suppose the checkout page's p99 latency jumped from 400 ms to 4 s at 14:05 for all regions. What changed: a deploy at 14:00 touched checkout. Observe: CPU is normal, but database connection pool wait time is high and the slow query log shows a new query doing a full table scan. Hypothesis: the deploy added a query without an index. Test: run EXPLAIN on the query. Mitigate: roll back the deploy; latency recovers. Fix: add the index, add a query-plan check to code review, redeploy. Communicate: status updates at each step, and a short post-incident review.

Communicating like an incident lead

Senior SRE and DevOps interviews often add a communication layer: the interviewer plays a manager or a stakeholder asking for updates mid-incident. Give short, regular status updates in a fixed shape — what is affected, what you know, what you are doing next, and when the next update will come. Avoid speculation presented as fact. Say clearly when you have mitigated versus resolved. If the incident is large, mention roles: someone investigating, someone communicating, someone deciding. Candidates who handle the technical side well but go silent with stakeholders lose points in loops that test operational maturity.

Mistakes interviewers see

• Jumping to a fix before scoping — restarting servers destroys evidence.
• Ignoring what changed; most incidents follow a change.
• Looking at averages, which hide tail latency; ask for p95 and p99.
• Debugging silently; the interviewer can only score what you say.
• Forgetting mitigation; users care about recovery before root cause.

Classic troubleshooting prompts

• A server is out of disk space, but deleting files didn't free any (deleted files still held open by a process).
• DNS works on your laptop but not on a server.
• A service is healthy but returns 502s behind the load balancer.
• Latency spikes every hour on the hour (a cron job, cache expiry or log rotation).
• Memory grows steadily until the process restarts (a leak, or an unbounded cache).

Our site reliability engineer questions and Linux interview questions cover the underlying knowledge.

Practising

Have a friend describe symptoms and answer only what you'd actually see if you ran the command you name — a game sometimes called “debugging theatre”. Do five scenarios a week. A free AI interview assistant such as CoPilot Interview can run the same exercise as a mock interview, revealing evidence step by step and scoring your method.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.

Frequently asked questions

What is a troubleshooting interview?

A round, common for SRE, DevOps, support and infrastructure roles, where you are given a broken or degraded system and assessed on how you investigate, mitigate and communicate.

How do I answer “the website is slow” in an interview?

Scope the impact, ask what changed, check latency percentiles, saturation and errors across layers, form and test a hypothesis, mitigate first — often a rollback — then fix the root cause and communicate throughout.

What are the USE and RED methods?

USE checks each resource for utilisation, saturation and errors. RED checks each service for request rate, errors and duration. Both give a systematic starting point for debugging.

Should I mitigate or find the root cause first?

Mitigate first when users are affected — roll back, fail over or scale out — while preserving enough evidence to find the root cause afterwards.