How to Screen IT Help Desk Technicians: 9 Questions and What to Listen For Screening Interview Template

What kind of support do you actually do: a tier 1 phone and chat queue, deskside at one site, remote support across an MSP's client base, or a mixed service desk? Describe your last environment: how many users, how many tickets you personally closed in a day, what you were allowed to fix yourself, and what you had to pass to somebody else.

What this assesses: This is the calibration question and it does more work than the rest of the list, because the title is the same across jobs that share almost nothing. MSP tier 1 is context switching: a different tenant, a different naming convention, and a different standard of documentation every ticket, with time tracked against a client. An internal service desk at two thousand seats is the opposite shape: one standard image, a known app list, defined escalation tiers, and change windows you cannot deploy outside of. Deskside support is physical, so imaging, asset tracking, moving hardware, and being able to get to a floor matter more than queue speed. A one-person IT shop at a small company covers everything including the firewall, the backups, and the vendor calls, usually with no runbook, which builds range and leaves gaps. The ticket number is worth asking for on its own. Forty resets and unlocks a day is a different job from ten well-documented tickets a day in a complex environment, and a candidate who gives you a number has been measured before. The what-you-were-allowed-to-fix answer is where the real scope shows up: unlocking an account is not the same as editing group policy, and reimaging a laptop is not the same as approving a change. Strong answers pick a lane, name the environment and the counts, name the tools, and are honest at the edges, something like ran a tier 1 queue for 400 internal users on Freshservice, did all the account and laptop work, never touched the network gear. Be cautious with a candidate who lists every tier at the same level, who was informally the person people asked about computers, or who cannot tell you roughly how many tickets a day they closed. That experience rarely survives a real queue with an SLA clock running.

A user says Outlook stopped working this morning. Before you touch anything, what do you ask them? Then what do you check and in what order, and at what point do you decide the problem is not just this one person?

What this assesses: The order is the answer, not the fix. Strong candidates scope before they touch: when did it start, is it the desktop app, the browser, or the phone, is it everything or just sending, and what changed, since a password change, a new laptop, travel, or an expired license explains most of these. Then they isolate client from service with one cheap test. A tech who asks early whether Outlook on the web works has split the problem in half with a single question, and that instinct is the thing you are screening for. After that, listen for a sequence that moves from cheap and likely to expensive and rare: network and sign-in first, then cached credentials after a recent password change, then profile and add-ins, then mailbox size, then a rebuild. Credit anyone who checks the queue and the service health dashboard for a pattern before doing a deep dive on one user, because a tenant-wide outage handled one ticket at a time is forty wasted hours and an angry morning. Credit changing one thing at a time and putting it back if it did not help, which is the difference between troubleshooting and guessing. Be cautious with an answer that opens with reboot it or reinstall Office, and be more cautious with reimage, which destroys user data, teaches you nothing about the cause, and guarantees the same ticket next month. Be cautious too with a candidate who never asks the user a single question. Closing tickets without finding root causes looks productive on a dashboard and shows up as repeat callers.

Which ticketing systems have you used, and how do you decide what to work next when fifteen tickets are open and two people are standing at your desk? Then tell me what you actually write in a ticket before you close it.

What this assesses: Naming the tool is table stakes, whether that is ServiceNow, Jira Service Management, Zendesk, Freshservice, ConnectWise, Autotask, Halo, or Zoho Desk. Prioritization is the first real signal. Strong answers weigh impact against urgency: how many users are down, whether there is a workaround, which SLA clock is closest to breaching, and what is blocking revenue or patient care rather than what is loudest. Listen for how they handle the interrupt, because the walk-up is the single most common way help desk work goes untracked. A strong answer logs it as a ticket even when it takes two minutes, since work that is never recorded is invisible when somebody asks whether the team needs another head. The close-out notes are where almost nobody screens and where plants of institutional knowledge quietly die. The answer you want describes the symptom, what they verified, what they changed, and how they confirmed it was fixed, written for the next person rather than for themselves. Fixed, resolved, and user is fine now are all the same note, and they mean the next tech starts from zero. Credit anyone who knows the difference between an incident and a service request, who tells the user what happened at close rather than just closing, and especially anyone who has written or corrected a knowledge base article, because that is the habit that makes a queue get smaller over time. Be cautious with pure first-in-first-out, with working whatever is loudest, with documents when there is time, and with a candidate who has only worked somewhere a lead wrote up the tickets for them.

Walk me through the identity work you have done yourself in Active Directory or Entra ID: unlocks and resets, group membership, a new hire setup, an offboarding, and an MFA re-enrollment. What is the difference between disabling an account and deleting it, and why does that matter?

What this assesses: Identity work is the majority of real help desk volume and it is where inflated tier claims fall apart fastest. Strong answers have actually been in the console: they can describe finding a user, resetting with a change at next sign-in, and they know unlocking an account and resetting a password are two different operations solving two different problems. They know adding somebody to a security group is not the same as adding them to a distribution list, and that group changes often do not take effect until the user signs out and back in or a sync cycle runs. In a hybrid environment, listen for whether they know changes made in on-premises Active Directory sync up to the cloud and not the other way around, which is the most common hybrid confusion and the cause of a lot of mysteriously reverted edits. On a new hire, strong answers follow a checklist: license and mailbox, group membership, shared drive or SharePoint access, device enrollment. Copying another user's permissions because it is faster is how access creep starts and it should make you pause. On offboarding, the order matters: disable immediately, revoke sessions and tokens so an active browser does not keep working, handle the mailbox, reclaim the license. Disabling preserves the account as a permission container and an audit record, while deleting destroys the mailbox and the trail, which is the kind of thing legal asks about a year later. Treat MFA re-enrollment as the most sensitive thing on this list, since a password plus a re-enrolled authenticator is a full account takeover. Be cautious with a candidate who has only ever submitted a request for this work, or who claims admin rights but cannot tell you what an OU or a security group is.

What are you genuinely solid on versus still learning across Windows, macOS, Microsoft 365, networking, printers, and mobile devices? Pick one thing you just claimed and explain it to me as if I were another tech: either what DNS does and how you would tell a DNS problem from a dead network, or what happens between plugging in a laptop and it having a working internet connection. Any certifications, and when did you earn them?

What this assesses: Calibration beats coverage, and the explain-it-out-loud half is the actual test, because cert names and buzzwords are cheap. Strong answers claim two or three areas with confidence, state where that knowledge stops, and are direct about gaps: solid on Windows and Active Directory, used to Intune but never set up a policy from scratch, can follow a runbook on the firewall but would not design a rule. On the technical explanation, the marker you want is a mental model rather than a recited definition. A tech who says they ping an IP address and then a hostname, and that the difference tells them which half of the stack is broken, has internalized how the thing works. Credit knowing what a self-assigned address means, knowing what to check when a machine has an IP but no internet, whether that is the gateway, DNS, a proxy, a VPN split tunnel, or a captive portal, and knowing that a cached record is why a change looks like it did not apply. Printers deserve their own moment because they are the most common and most hated ticket category in the building: listen for whether they separate the driver from the queue from the spooler from the network path, and whether they have dealt with a print server or only direct IP printing. Treat A+, Network+, and ITIL as a floor rather than a ceiling, and ask when. A certification from eight years ago tells you less than six months of real Intune or Entra experience in a cloud-managed environment. Be cautious with a candidate who lists twelve technologies at the same level, who says they pick things up fast without naming what they would need to pick up, or who holds an A+ and cannot say in plain words what DNS does, which means the exam was memorized rather than learned.

Tell me about the hardest problem you personally solved, including the theories that turned out to be wrong. Then tell me about one you escalated: how did you decide it was time, and what exactly did you hand the next tier?

What this assesses: Both halves earn their place. On the first, strong answers give a specific problem, a wrong theory they chased and abandoned, where they actually looked, whether that was event logs, a vendor knowledge base article, a configuration diff, or a packet capture if they are deeper than tier 1, and the root cause they landed on. Be cautious with a routine password reset dressed up as difficult, and be more cautious with a candidate who cannot recall a hard problem at all, which usually means they escalate at the first sign of friction and have never built any diagnostic muscle. The escalation half is the one that separates techs who waste other people's time from techs who save it, and almost nobody asks about it. A good handoff states what the user reported, what has been ruled out and how it was ruled out, what was changed and whether it was reverted, how many users are affected, and what the user has already been told. A bad handoff is forwarded to you, user still having issues, which forces tier 2 to redo the entire triage and is the number one complaint senior techs have about a service desk. Credit anyone who works to a time box, spending twenty focused minutes before escalating a ticket with a clock running rather than three hours of pride. Credit knowing which things get escalated immediately rather than investigated: a suspected security incident, possible data loss, and anything affecting many users at once. Be cautious with both extremes here, the tech who escalates everything and the one who escalates nothing, since the first adds no capacity and the second breaks things on the way to being right.

Tell me about a time you had to walk somebody through a fix over the phone or chat when you could not see their screen and they were already frustrated. What did you say first, and how did you know they actually understood rather than just gave up?

What this assesses: Communication drives satisfaction scores in support more than technical skill does, and this is where the tech with a good close rate whose users dread calling them gets caught. Remote hands is a specific skill: naming what is on the screen in the words the user sees instead of jargon, giving one step at a time and waiting for confirmation, asking them to read back what they are looking at, and confirming before anything destructive gets clicked. Strong answers include the acknowledgment before the fix, something to the effect of you have lost an hour to this and we will get you working, because a frustrated user who feels heard stops fighting the troubleshooting. Then they explain the cause in plain language and check comprehension in a way that is not does that make sense, which everybody answers yes to. Asking the user to do the step once themselves is the strong version of that check. Credit setting expectations when the real fix is going to take a while or needs a rebuild, and credit following up later unprompted, which is rare and is remembered. Be cautious with a hypothetical answer that has no actual user in it, with any version of I dumb it down, since condescension travels over the phone better than anything else, and with an answer that blames the user for the problem. Be cautious too with a technically perfect answer that has no human in it at all. That tech generates escalations you have to handle yourself.

Someone calls saying they are an executive, locked out, sitting in an airport, about to miss a board meeting, and they need their password reset and their MFA re-enrolled right now. Your normal verification process is slow. What do you do? Separately: a user forwards you an email they think is phishing. What are your next steps?

What this assesses: The help desk is the most reliably attacked door in any company, and the attack is exactly this call: authority, urgency, and a plausible reason the normal process cannot be followed this one time. Strong answers do not move on the urgency. They verify through the established procedure regardless of claimed seniority, and they can name methods they have actually used: a callback to the number already on record rather than the one the caller offers, confirmation from the person's manager, a one-time code to a device already enrolled, a short video call, or a ticket arriving through a channel that is already authenticated. The best answers also say the quiet part, which is that an executive who is genuinely locked out will accept ten minutes of verification, and that escalating socially instead of waiting is itself the signal. Treat the MFA re-enrollment half as the more serious request, because a reset password plus a re-enrolled authenticator is complete account takeover and no amount of later follow-up undoes it. Credit anyone who says they would log the attempt and notify security whether or not the caller turned out to be legitimate. On the phishing question, strong answers do not click and do not forward the payload onward, report it through whatever defined channel exists, whether that is an abuse mailbox, a report button, or the security team, and check whether the same message landed for other people. If credentials were already entered, the answer should turn into incident response rather than cleanup: reset, revoke active sessions and tokens, check the mailbox for new forwarding rules, and look at sign-in logs. Be cautious with anything resembling I would reset it and follow up afterward, with any deference to seniority under pressure, and with treating a phishing report as the user's own problem. A candidate who fails this question is a breach vector no matter how strong the rest of the screen looks.

This role is [shift] with [after-hours or weekend on-call] and [on-site days per week]. What can you actually commit to, how would you get here for that start time, and what are your pay expectations? Have you worked a rotation or carried an after-hours phone before?

What this assesses: Coverage and pay mismatches break more help desk hires than skill gaps do, and both are cheap to catch here instead of after three rounds. Strong answers are concrete: which shifts they will take, whether they will carry an after-hours rotation and what that looked like the last time they did, whether they can be on-site when a ticket needs hands on hardware, and a pay range that is in the neighborhood of the market for that tier. Credit a candidate who asks what the on-call volume actually is, how often the phone rings at two in the morning and whether there is comp time or extra pay attached, because that is the question somebody who has genuinely carried a phone asks and somebody who has not does not think to. Be realistic about what you are competing against. Remote tier 1 work is now a national market, so a candidate accepting a local on-site rate when they could earn more from their kitchen table will leave once they notice, and that is a six-month problem rather than an interview problem. Be cautious with total flexibility promised in a screen, since it collapses at the first Saturday, and with remote-only expectations for a seat that requires desk-side visits. Be cautious with a pay number far above your band and resolve it now rather than hoping it moves. It is also worth asking what else they have in flight, because good help desk candidates usually have several processes running at once and they come off the market fast.