Troubleshooting Methodology
Almost every technical interview question about a support role reduces to one thing: can you take an ambiguous problem and impose structure on it? The commands are secondary. This page is the answer.
The eight steps
Rehearse this until it is automatic. Deliver it in about sixty seconds.
- Identify the problem. Ask what, when, who, and since when. Get the exact error text, not a paraphrase.
- Determine scope. One user, a team, a floor, a site? This single question most often tells you where to look.
- Reproduce it. Try it yourself. If you cannot reproduce it, the problem is environmental or intermittent — both are harder.
- Question the obvious. Recent change? New hardware? New software? A password that expired last night? Most incidents follow a change.
- Form a hypothesis and test the cheapest thing first. Form one theory about one layer, then test it. Changing five things at once teaches you nothing.
- Fix, and verify with the user. Your fix is not validated until the user confirms it works.
- Document. What happened, root cause, what you changed.
- Prevent. Patch it, replace it, document it, or automate the check.
Closing a ticket as "done" before the user confirms is a real-world failure that costs you credibility. Say the phrase out loud in the interview.
The layered approach
When scope does not identify the layer, walk the stack from the bottom.
| Layer | Ask | Tool |
|---|---|---|
| Physical | Is it powered? Link lights? | Look, listen |
| Data link | Is the port up and in the right VLAN? | Switch port status, ARP |
| Network | Do they have an IP, gateway, DNS? | ipconfig /all |
| Transport | Is the port open? | Test-NetConnection |
| Application | Is the service healthy? | curl, service logs |
Because it prevents the two classic L1 failures: jumping straight to DNS when the cable is unplugged, or reinstalling software when a switch port is disabled. Say this and you have demonstrated structured thinking.
L1, L2, L3 — what each means
| Level | Role | Scope |
|---|---|---|
| L1 Service desk | Reset passwords, replace peripherals, known errors, ticket logging | Single user |
| L2 Desktop / Network support | Install software, OS repair, AD, VLAN, switch config | Workgroup or site |
| L3 Infrastructure / engineering | Domain design, backbone, firewall policy, architecture | Enterprise |
Mentioning escalation without being asked is a strong signal. Something like: "Once I've confirmed the fault is above my level — a core switch change or a firewall policy — I'd attach my findings and the steps already taken, so L3 doesn't repeat my work."
Ticket handling
Good practice, and it comes up in behavioural questions:
- Record the exact error, the time, and the machine name.
- Record every change you make, so you can back it out.
- Set expectations: tell the user what you are doing and when you will update.
- Do not reboot a user's machine as your first action.
- Close with the user, not silently.
- Never promise a fix time you do not control.
The questions to ask
| Question | What it tells you |
|---|---|
| "What exactly were you doing?" | Reproducibility |
| "When did it start?" | Correlate with a change |
| "Does anyone else have it?" | Scope — the single most valuable question |
| "Did anything change?" | Recent install, update, move, new cable |
| "What is the exact error?" | Avoids chasing a paraphrase |
| "Has it worked before?" | Confirms it's a change, not a lifetime fault |
| "Can you test on the wired network?" | Rules out the wireless path |
Everything here can be done over remote support. Being able to say "I would try to remote in first, since most of these are diagnosable without touching the machine" shows cost awareness.
Common failure modes to avoid
| Bad habit | Why it costs you |
|---|---|
| Changing several things at once | You cannot attribute the fix |
| Restarting first | Destroys evidence; fixes nothing |
| Guessing the cause | Unverifiable |
| "Try turning it off and on again" | Technically true, structurally empty |
| Escalating without investigation | You have not done your job yet |
| Closing without user confirmation | The fix may not hold |
The answer to "tell me about a difficult problem"
Use STAR, with the verification step explicit:
| Letter | Give |
|---|---|
| Situation | Context and blast radius |
| Task | What you were responsible for |
| Action | What you actually did, in order |
| Result | Outcome, measured, plus the prevention step |
Spending ninety seconds on Situation and ten on Action. Interviewers are grading the Action. Be roughly 20 / 60 / 20.
Your three stories — prepare them now
You already have the material. From your own projects:
- A server that wouldn't stay up — systemd, logs, dependency ordering, resource limits. Use TerraDash.
- A monitoring/telemetry problem — you built SysMon; describe a metric that lied and how you found the real cause.
- A network or DNS fault in your own homelab — a domain that stopped resolving, a container that lost its route.
Do not invent incidents. If you have not run a domain controller, say "I stood one up in a home lab for exactly this reason" — that is a strong, honest answer, and it is true. See Lab 3.
Drill
Next
Common Scenarios — the real tickets.