All jobs / IT support / sysadmin
Troubleshooting interview questions
Troubleshooting questions a IT support / sysadmin can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A ticket says “email is broken.” What do you ask first?
The strongest answer: What they were doing, what they expected, what they saw, and on which device or account — not “I will just take a look”
Why it works: Exactly. Repro, expected, actual, where. That is a ticket you can work.
- Get steps, expected, actual, where.
- Restart is a step, not the ticket.
- Never take their password.
- Do not bounce them for being unclear.
When is “have you rebooted?” the right move, and when is it a brush-off?
The strongest answer: Right after I know what is failing and a reboot is a fair test — a brush-off when I have not heard the repro and I am emptying the queue
Why it works: Exactly. A named test, not a reflex. Surprise reboots destroy work.
- Reboot after you know the symptom.
- Name it as a test.
- Do not use it to empty the queue.
- Do not reboot in secret.
You fixed a laptop after 40 minutes. What goes in the ticket?
The strongest answer: What I tried, what worked, and what I told the user — so the next person is not starting from zero
Why it works: Exactly. Notes are the handover. Clean queues with empty notes are a lie.
- Tried / worked / told the user.
- Do not write only “resolved.”
- No jokes about people.
- Memory is not a knowledge base.
How do you tell someone their VPN certificate expired?
The strongest answer: In their words: the secure-office login on this laptop ran out, here is the one screen to refresh, I will stay until it works
Why it works: Exactly. Outcome, one action, you stay. Jargon is how tickets bounce.
- Say the outcome and the next click.
- Stay until it works.
- Keep jargon for other technicians.
- Do not leave a silent expiry.
When do you escalate, and with what?
The strongest answer: When I am past the runbook or the blast radius is growing — I send what I tried, timestamps, and who is blocked, not “please fix”
Why it works: Exactly. Escalate with a package. Ego is not a queue.
- Escalate when stuck or blast grows.
- Send tried / times / who is blocked.
- Do not escalate to save face.
- Do not @ the company.
When is a ticket actually closed?
The strongest answer: When the user can do the job again — or they agree the leftover — not when I think I clicked the right thing
Why it works: Exactly. Confirmation or an agreed leftover. Clocks are not consent.
- User can work, or leftover agreed.
- “Resolved” is not the test.
- Do not assume silence is joy.
- Do not close for the clock.
Twenty people cannot print badges. One person wants a font. What do you pick?
The strongest answer: The badge outage — impact and who is blocked, not who emailed most
Why it works: Exactly. Impact first. Volume of mail is a signal, not the rule.
- Triage by impact.
- Loud ≠ first.
- FIFO alone can fail a shift.
- Access-gating printers are high impact.
When do you walk to the desk instead of remoting?
The strongest answer: When the machine will not take a remote, the user is stuck on a login screen, or I need eyes on cables — not because I prefer a wander
Why it works: Exactly. The constraint picks the channel. Favourites do not.
- Walk when remote cannot see it.
- Remote when it can.
- Do not moralise the channel.
- Do not pick favourites.
Someone grabs you at the coffee machine with a “quick one.” What do you do?
The strongest answer: Listen, then put it on a ticket so it has a place — I do not promise a silent fix that nobody can see
Why it works: Exactly. Help, then write it down. Invisible work cannot be staffed.
- Capture hallway asks as tickets.
- Do not do invisible fixes.
- Listen first.
- No secret manager queue.
There is a runbook for VPN failures. You have a hunch. What first?
The strongest answer: The runbook, and I note where it is wrong — hunches after the known path, not instead of it
Why it works: Exactly. Known path, then curiosity, and fix the page if it lied.
- Runbook first.
- Note and fix gaps.
- Hunches after the known path.
- Do not skip to rebuild by vibe.
A user sends only a dark photo of a screen. What do you still need?
The strongest answer: The words: when, which account, and what they clicked — a photo is evidence, not a repro
Why it works: Exactly. Pictures help. Steps close. Passwords never.
- Ask when, account, clicks.
- Photos support; they do not replace.
- More pixels ≠ a repro.
- Never take a password.
You want to restart a shared server at 10:30 on a Tuesday. What do you check?
The strongest answer: Whether this is in a change window, who is on it, and who must hear — I do not “quickly bounce it” in business hours
Why it works: Exactly. Shared machines have calendars. Quick bounces are outages with a smile.
- Check the window and the audience.
- Say it before you bounce.
- Business hours are not “quick.”
- Do not double-restart for luck.
You cannot finish today. How do you leave the user?
The strongest answer: With what works now, what happens next, and when they will hear — not “I will look later”
Why it works: Exactly. A bridge. Silence and unowned tomorrows are how trust dies.
- Works now / next / when.
- Do not go silent.
- Do not guess a cause.
- Name an owner for later.
Forty new tickets, one on-call. How do you order the morning?
The strongest answer: Safety and identity first, then many-people down, then deadlines you can see, then the rest — I write the order so the queue is not my mood
Why it works: Exactly. A written impact order. Mood and IM are not a service.
- Safety, identity, blast radius, deadlines.
- Write the order.
- Not IM, not mood.
- Do not only close the easy ones.
A low-severity ticket is about to breach SLA. What do you not do?
The strongest answer: I do not bump its severity to save the clock — I either work it, renegotiate, or accept the breach and say why
Why it works: Exactly. Clocks measure; they do not rewrite impact. Green dashboards with lies train leadership to ignore you.
- Do not relabel severity for SLA.
- Work, renegotiate, or accept.
- No close-reopen tricks.
- No “file again” resets.
The same VPN ticket returns weekly. What do you add besides “reset profile”?
The strongest answer: A cause you can name or a leftover you cannot — and a link to a better path — or you are running a ritual
Why it works: Exactly. Rituals without a cause are how queues become weather. Write the leftover.
- Name the cause or the leftover.
- Link a better path.
- Do not ritual-reset forever.
- Do not blame the user in the note.
Email is down for an hour. What do you send the company?
The strongest answer: What is down, who is affected, what to do instead, and when the next update comes — no blame, no novel
Why it works: Exactly. Status, workaround, next clock. Essays and silence both fail.
- Impact, workaround, next update time.
- No early blame essay.
- Do not wait for perfect knowledge.
- Do not joke the outage.
You escalate to a vendor. What is in the pack?
The strongest answer: Product, version, times, what we tried, logs, and a clean statement of broken versus expected — not “it does not work, please advise”
Why it works: Exactly. Vendors are not telepaths. Packages get queues to move.
- Version, times, tried, logs, expected.
- No wallpaper shots.
- No exec-as-severity.
- No public threats.
A laptop is “unusable and slow.” First measurements?
The strongest answer: Disk free, disk health, memory, a stuck update, and startup pile-up — then image if the disk is dying or the profile is toast
Why it works: Exactly. Measure. Images cost a day of a person.
- Measure disk, memory, updates.
- Image when the disk or profile is dead.
- Do not wipe by culture.
- Do not delete OS folders.
You have solved the same “headset in Teams” issue five times. Next artefact?
The strongest answer: A short article the user can follow, linked on the ticket form — five heroics are not a service
Why it works: Exactly. If it repeats, it is a page. Hidden queues are how you pretend demand fell.
- Publish a short user article.
- Link it on the form.
- Heroics do not scale.
- Do not hide the intake.
A director IMs you to skip the queue. What do you do?
The strongest answer: Help if the impact deserves it, then write the ticket so the skip is visible — I do not run a secret side door for titles
Why it works: Exactly. Impact can jump; titles do not get a hidden lane. Write it down.
- Impact can skip; titles cannot hide.
- Write the skip on a ticket.
- Do not ignore to punish.
- No lunch-based priority.
What is a change advisory for, and what is it not?
The strongest answer: To make blast radius, rollback, and who is awake explicit — not to collect signatures as theatre or to block tiny user fixes
Why it works: Exactly. Awake people and a way back. Theatre and blanket-no both fail.
- Blast, rollback, who is awake.
- Not signature theatre.
- Not a blanket no.
- Not only after incidents.
Identity is down for the company. What roles do you name in the first ten minutes?
The strongest answer: A commander, a tech lead, and a comms person — one throat for decisions, one for the work, one for the words
Why it works: Exactly. Three jobs. A scrum of voices is how you lose twenty minutes.
- Commander, tech, comms.
- One decision throat.
- Do not all-talk.
- Do not leave comms empty.
What makes a runbook real?
The strongest answer: An owner, a last-tested date, and a path that an on-call followed recently — a wiki novel from 2021 is décor
Why it works: Exactly. Used and dated. Novels and farewell videos are museums.
- Owner + last-tested date.
- Someone on-call has followed it.
- Pretty ≠ real.
- Do not rely on a leaver’s video.
A SaaS outage is on their status page. What do you still own?
The strongest answer: Our users, our workaround, our comms, and whether our side is actually healthy — I do not only retweet their amber dot
Why it works: Exactly. Their outage, your people. Workarounds and honesty about our side.
- Own users, workaround, comms.
- Check our side too.
- Do not ticket-storm.
- Do not threaten in hour one.
What does an audit-ready ticket look like?
The strongest answer: Who asked, who approved if needed, what changed, when, and the artefact — not a novel and not “fixed it”
Why it works: Exactly. Traceable change. Jokes, ID photos, and oral history fail you.
- Asker, approval, change, when, artefact.
- No joke-only notes.
- No ID scans in tickets.
- Do not rely on interviews alone.
A user clicked. The company is half-down because of the payload. How do you write the update?
The strongest answer: What is down, what to do, what we are doing — names and shame wait for a private, careful review
Why it works: Exactly. Impact now, blame never in the blast. Shame trains silence.
- Impact and action, no names.
- Shame later is still a no in the blast.
- Do not go silent on impact.
- Do not joke the user.
Leadership wants “IT health.” What do you refuse to invent?
The strongest answer: A single happiness percentile — I show time-to-restore on the paths that matter, leftover risk, and volume I can explain
Why it works: Exactly. Operable stories. Invented joy indexes are how you get managed by a cartoon.
- Show restore time on real paths.
- Name leftover risk.
- No invented joy percentile.
- Do not game close-counts.
The team runs on one hero who “just knows.” What do you change?
The strongest answer: Pair, write the path, and rotate the pager — I do not give the hero a louder title so the bus factor looks like leadership
Why it works: Exactly. Spread the work. Titles and videos do not staff a Tuesday.
- Pair, write, rotate.
- Do not promote the bus factor.
- Do not lock boxes to one person.
- Videos are not a bench.
Your change policy is unread. What do you cut it to?
The strongest answer: What needs a window, what is standard, what is emergency, and who can say go — a novel nobody opens is not a policy
Why it works: Exactly. Operable categories. Signatures and RACIs are how you fake control.
- Window / standard / emergency / who.
- Cut the novel.
- Do not add signature theatre.
- Do not run on vibes.