Service Desk Analyst interview questions and practice.
Acts as the first point of contact for IT issues, logging incidents, resolving common problems and escalating the rest. An interviewer hiring a Service Desk Analyst is not testing whether you know what the job is. They are trying to establish whether you can fix things without being told how, and whether the person you fixed it for felt looked after rather than patronised.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
What interviewers for Service Desk Analyst actually ask
Three questions from the bank below, each scored against one competency. The follow-up is what separates a prepared answer from a memorised one.
A user says "the internet is down". Walk me through what you actually do.
Tell me about a fault nobody else could fix.
Where does your knowledge run out?
What they are really assessing
That gets scored against 7 competencies: structured troubleshooting, technical breadth across the stack, customer communication & empathy, prioritisation & sla management, documentation & knowledge sharing, security awareness & process discipline and ownership & follow-through. Each one is assessed from the specifics in your answers, which is why "we improved the process" scores lower than a sentence with a number, a date and a decision in it.
At mid level they assume you can do the job and are testing how you handle the parts that go wrong. Expect them to push hardest on a hard technical case, a repeat issue they eliminated, and managing conflicting priorities.
Structured troubleshooting
Diagnoses problems methodically: gathers symptoms, forms hypotheses, tests them in order of likelihood and impact, and confirms the fix rather than guessing.
- Weak
- Troubleshooting is 'restart it' or 'reimage it'; cannot describe isolating a problem step by step or a case where the obvious fix was wrong.
- Adequate
- Follows a logical sequence (scope, recent changes, isolate, test) and uses logs or diagnostic tools, but sometimes closes tickets without confirming the root cause.
- Strong
- Gives a specific hard case: how they scoped it (one user or many, what changed), the hypotheses tested and in what order, the tool or log that confirmed the cause, and how they verified the fix and prevented recurrence.
Technical breadth across the stack
Understands end-user devices, operating systems, identity, networking basics, productivity suites and common business applications well enough to solve most issues without escalation.
- Weak
- Comfortable only with one area (e.g. password resets); cannot explain DNS, DHCP, Active Directory group policy or how email authentication works.
- Adequate
- Handles Windows/macOS, Microsoft 365 or Google Workspace, basic networking and identity issues independently, but escalates anything involving servers or unusual configurations.
- Strong
- Describes resolving issues across devices, identity, network and applications, explains the underlying mechanism (e.g. why a Kerberos ticket or DNS cache caused the symptom), and knows precisely where their knowledge ends.
Customer communication & empathy
Explains issues and fixes in plain language, manages the user's expectations, and stays calm and respectful with frustrated or non-technical users.
- Weak
- Uses jargon; blames the user ('user error'); cannot describe calming an angry user or adapting their explanation for someone non-technical.
- Adequate
- Explains clearly, sets expectations on timing and has handled frustrated users, but does not consistently follow up or confirm satisfaction.
- Strong
- Gives a case of an angry or senior user: how they acknowledged the impact, what they said, how they kept the user updated, and the feedback received afterwards; explains how they adapt explanations to the person.
Prioritisation & SLA management
Triages tickets by impact and urgency, manages a queue under pressure, meets SLAs, and escalates appropriately with complete information.
- Weak
- Works tickets in order received or by who shouts loudest; cannot explain the difference between impact and urgency or describe an escalation they made with full context.
- Adequate
- Triages by impact and urgency and meets SLAs most of the time, but struggles when multiple high-priority issues collide and escalations sometimes lack detail.
- Strong
- Describes a day where several urgent issues collided, how they ranked them (users affected, business impact, workaround available), what they communicated to whom, and an escalation with complete diagnostics that sped up resolution.
Documentation & knowledge sharing
Writes clear ticket notes and knowledge base articles so problems are solved faster next time, and contributes to reducing repeat tickets.
- Weak
- Ticket notes say 'fixed'; has never written a knowledge article; cannot describe a repeat issue they helped eliminate.
- Adequate
- Writes useful ticket notes and has contributed knowledge articles, but does not analyse ticket patterns or drive self-service.
- Strong
- Describes a recurring issue they spotted in ticket data, the article or automated fix they produced, and the measured drop in tickets or handling time.
Security awareness & process discipline
Follows identity verification, access, change and data-protection procedures even under pressure, and recognises phishing, social engineering and policy risks.
- Weak
- Resets passwords or grants access without verification when someone sounds senior; cannot describe a suspected phishing or social engineering attempt they handled.
- Adequate
- Follows verification and access procedures and has reported a phishing attempt, but bends process under pressure from senior staff.
- Strong
- Gives a case of refusing an improper access request from a senior person, how they handled it, and a security issue they spotted and reported; explains why the process exists in terms of risk.
Ownership & follow-through
Owns a user's problem until it is truly resolved, even when it crosses teams, and does not close tickets to hit metrics.
- Weak
- Closes tickets when escalated or when the user stops replying; cannot describe chasing another team on a user's behalf.
- Adequate
- Follows up on escalations and confirms resolution with the user, but loses track of long-running issues.
- Strong
- Describes a problem that crossed several teams which they tracked to resolution, how they kept the user informed, and what they changed in the process afterwards.
10 questions you should expect
What a strong answer contains, not a model answer to memorise. A memorised answer falls apart on the first follow-up, and there is always a follow-up.
A user says "the internet is down". Walk me through what you actually do.
Scored against: Structured troubleshootingA strong answer contains: Scope it before touching anything: one user or many, one site or all, wired or wireless, when did it last work, what changed. Then narrowing layer by layer with a check at each step. The best answers say what they would rule out first and why.
And then they askIt is only that one user. Where do you go next?
Tell me about a fault nobody else could fix.
Scored against: Structured troubleshootingA strong answer contains: The symptom, the assumptions others had made, the thing they checked that nobody had, and what the cause turned out to be. Bonus for it being unglamorous: a duplicate IP, a GPO, a full disk, a bad patch cable.
And then they askWhat had everyone else assumed that turned out to be wrong?
Where does your knowledge run out?
Scored against: Technical breadth across the stackA strong answer contains: An honest map: strong on endpoints and identity, competent on networking to a point, weak on this. Candidates who claim uniform expertise fail the very next question; candidates who draw the line accurately are trusted.
And then they askTake the weakest of those. What would you do if a ticket landed on it right now?
A user cannot sign in and the password reset has not helped. What are the possibilities?
Scored against: Technical breadth across the stackA strong answer contains: Several branches named (account locked or disabled, expired password, MFA device lost, cached credentials, time skew, conditional access policy, licence removed, wrong username) and how they would tell them apart quickly.
And then they askHow would you distinguish an MFA problem from a conditional access block?
How do you explain a technical problem to someone who does not want to know the detail?
Scored against: Customer communication & empathyA strong answer contains: What is broken, what it means for them, what happens next, when they will hear again, in that order and in their language. Best answers include an example of a time they got it wrong and lost the person.
And then they askWhat do you say when the honest answer is that it will take three days?
A user is furious and it is partly your team's fault. What do you say first?
Scored against: Customer communication & empathyA strong answer contains: Acknowledge the impact before explaining anything, do not defend the team in the first breath, say what you are doing now and by when. An apology that is specific rather than formulaic.
And then they askWhat do you do when it is not your team's fault but they think it is?
You have a director with a broken laptop and thirty people who cannot print. How do you decide?
Scored against: Prioritisation & SLA managementA strong answer contains: Impact and urgency, not seniority (thirty people beats one), with the caveat that they would tell the director directly and give an ETA rather than leaving them in the queue silently.
And then they askWhat do you say to the director?
Tell me about a ticket you had to escalate. What did you do after you escalated it?
Scored against: Ownership & follow-throughA strong answer contains: That escalating did not end their involvement: they kept the user informed, chased at intervals, and closed the loop themselves. Escalation as a way of getting rid of a ticket is the failure mode being tested for.
And then they askHow long do you leave it before chasing, and who do you chase?
What have you written that someone else has used?
Scored against: Documentation & knowledge sharingA strong answer contains: A specific KB article, runbook or how-to, why it existed, and evidence it reduced tickets or was reused. Strong answers mention writing it in the user's language rather than the engineer's.
And then they askHow do you know anyone read it?
Someone rings claiming to be a new starter and needs their password reset urgently. What do you do?
Scored against: Security awareness & process disciplineA strong answer contains: Verify through an out-of-band channel, follow the identity process regardless of urgency or claimed seniority, and escalate rather than bending it. Urgency and authority are the two levers of the attack, and both should be named.
And then they askThey say they are the finance director and they are about to go into a board meeting. Now what?
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Service Desk Analyst and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns second-line issues, device and application management, and improvements to knowledge and processes; accountable for resolution quality.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: diagnosing a 'the internet is down' complaint step by step, active Directory or Entra ID: accounts, groups, group policy and login problems and microsoft 365 or Google Workspace: mail flow, shared mailboxes, licensing, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns first-line tickets end to end: diagnosis, resolution or escalation, and communication with the user. | Owns second-line issues, device and application management, and improvements to knowledge and processes; accountable for resolution quality. | Owns a support area or site: escalations, standards, tooling, automation and major incident coordination for end users. |
| Tolerance for ambiguity | Handles common issues independently and escalates unusual ones with good notes. | Investigates unfamiliar problems independently and decides when to involve infrastructure or vendors. | Defines processes where none exist; handles major incidents and ambiguous cross-team problems. |
| People leadership | No formal leadership. | Coaches first-line staff and reviews their tickets. | Leads a small team or shift; mentors, allocates work, may do performance input. |
| Who they deal with | End users, second-line engineers, team lead. | Users including senior staff, infrastructure and security teams, vendors. | Department heads, infrastructure and security leads, vendors, HR for onboarding processes. |
Where candidates lose this interview
Jumping to the fix before scoping the fault
"I'd reboot it" or "I'd reinstall the driver" as a first move tells the interviewer you guess rather than diagnose. Even when the guess is right, the reasoning is what is being scored. Say how you would establish scope (one user or many, when it last worked, what changed) before you touch anything.
Claiming to know everything
Service desk interviewers deliberately push past the edge of your knowledge to see what happens there. Candidates who bluff get caught inside two follow-ups. Candidates who say "I have not done that; here is how I would find out" score higher than those who guess correctly.
Escalation as disposal
The most common weak answer is one where escalating is the end of the story. The user does not care which team owns the ticket. Strong candidates keep the user informed, chase the other team and close the loop themselves.
Bending the identity check for someone senior
The password reset question is a security test wearing a service question's clothes. Any answer that speeds up verification because the caller claims to be a director is a fail, and it is exactly how real help-desk compromises happen.
All technical, no human
Half of a support role is how the person felt afterwards. Answers that never mention what was said to the user, or that describe users as an obstacle, score badly regardless of technical depth.
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Service Desk Analyst would have said them.
A user says "the internet is down". Walk me through what you actually do.
- Scope it before touching anything: one user or many, one site or all, wired or wireless, when did it last work, what changed. Then narrowing layer by layer with a check at each step. The best answers say what they would rule out first and why
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report