What Do IT Support Technician Interviews Actually Test?

Who is actually in the room

For most first-line or second-line support roles, you will not meet a professional interviewer. You will meet the service desk team lead or the IT manager who currently owns the tickets you would be picking up, sometimes with one working technician sitting in to ask the technical questions because they are the one who has to trust your fixes. In smaller companies this might be the sole sysadmin, who is interviewing you partly because they are tired and want someone who can take tickets off their plate without creating new ones.

There is often a short HR or recruiter screen first, mostly to check salary expectations, right to work, and notice period. That conversation is not testing your technical judgement and you should not read too much into how it goes. The interview that decides the outcome is the one with the person who will sit near you.

The practical assessment, and what it is actually checking

A lot of support-technician interviews include something hands-on, because talking about troubleshooting and doing it are different skills. What this looks like varies by employer, but common versions are:

• A laptop or desktop in front of you with a fault seeded into it — no network connection, a corrupted user profile, a printer that won't queue, a machine that won't leave the login screen — and you're asked to find and fix it while talking through your steps.
• A whiteboard or verbal scenario: "a user calls and says their PC can't reach the shared drive, walk me through what you do."
• Occasionally a short written or online test covering things like subnetting, common port numbers, or reading an ipconfig /all output and spotting what's wrong with it.
• Sometimes a mock call or roleplay, where someone plays a frustrated non-technical user and you have to get useful information out of them and explain a fix without jargon.

What they're checking is not whether you land on the right answer immediately. It's whether you have a method. A network fault, for instance, has a fairly standard order of elimination: is the cable in, is the adapter enabled, does ipconfig show a valid IP or an APIPA address (169.254.x.x, which tells you DHCP failed), can you ping the gateway, can you ping by IP but not by name (which points at DNS), can you resolve externally but not internally (which points at a specific DNS server or VPN split-tunnel issue). A candidate who starts there, out loud, is showing something a candidate who says "I'd try restarting it, then reinstall the network driver, then reimage it" is not. The second answer might eventually work. It isn't diagnosis, it's a sequence of guesses, and anyone who has run a service desk can tell the difference in under a minute.

The questions that are actually probing competence

A handful of questions come up again and again, and they are doing more work than they sound like they are.

"Walk me through how you'd troubleshoot [X]." This is the core question. They don't want the destination, they want the order of operations and the reasoning at each branch. A strong answer narrows the problem systematically — hardware versus software, local versus network, one user versus many — and says what each test would tell them before running it. A weak answer jumps straight to the fix that worked last time on something similar.

"Tell me about a time your first fix didn't work." This is checking two things: whether you actually work tickets independently rather than always escalating, and whether you document and re-test rather than trying random things until one sticks. If your answer has no mention of checking the event log, re-testing after each change, or updating the ticket with what you'd ruled out, that's a gap they'll notice.

"How do you prioritise your queue?" Real service desks run on some version of priority and SLA — a VIP user locked out is not the same ticket as a printer jam, and a P1 outage affecting a whole floor outranks both. If you talk about priority levels, impact versus urgency, or how you'd handle a P1 landing while you're mid-fix on something else, you're answering from experience. If you say "I just work through them in order," that tells them you've either not worked in a ticketing system with real SLAs, or you haven't thought about it.

"Explain [some technical fault] to someone who has never used a computer." This is not a soft-skills filler question. Support technicians spend most of their day translating, and someone who can't do it in the interview room, under no real pressure, is not going to do it well on a call with an angry user at 4:45pm. Watch for candidates who reach for an analogy and keep it short, versus ones who simplify the vocabulary but keep the same run-on explanation.

Directory and access questions. Depending on the environment, expect something concrete: how do you unlock an Active Directory account, what's the difference between resetting a password and forcing a change at next logon, how would you add a user to a security group versus a distribution group, what do you check before you grant elevated access to someone who's asked for it. These aren't trick questions. They're checking you've actually used AD Users and Computers, or Intune, or whatever the shop runs, rather than just read about it.

A security question, almost always. Something like "a user emails you saying they've clicked a link and now their machine is acting strangely, what do you do first?" They want isolation before investigation — disconnect from the network, don't restart it yet if there's any chance of forensic follow-up, report it up, don't just run a virus scan and move on. And somewhere they will probe whether you've ever been asked for your admin password by someone claiming to be a manager in a hurry, and what you did.

What a shallow answer sounds like

People doing the hiring can usually tell within a sentence or two when an answer is memorised rather than lived. A few patterns come up often:

• Naming the fix without the diagnosis. "I'd reimage it" as the first line of an answer, with no mention of what would tell you a reimage is actually needed.
• Treating the ticketing system as paperwork rather than a record. If you can't say what you'd write in the ticket notes, or you describe closing tickets without confirming the fix with the user, that's noticed.
• Reciting certification content without a story attached to it. Knowing that DNS runs on port 53 is not the same as having actually chased a DNS problem. If you hold CompTIA A+ or Network+, or an ITIL Foundation certificate, expect it to come up — but the interviewer already knows plenty of people pass those exams without being able to fix anything. They'll ask a follow-up that requires you to have actually done the thing, not just studied it.
• Vague ownership language. "We fixed it" or "the team resolved it" when asked what you personally did.
• No mention of the user at all. A technically correct answer that never mentions checking back with the person who raised the ticket reads as someone who fixes machines, not people's problems.

What to actually prepare

Have two or three real tickets ready to talk through in detail — not the interesting once-a-year outage, but ordinary ones: a printer that wouldn't queue, a VPN drop for one user, an account lockout that turned out to be a cached credential on a phone. Be ready to state, unprompted, what you checked and in what order, and what you'd have done next if the first thing hadn't worked. If your current or most recent job uses a specific stack — ServiceNow, Zendesk, Intune, SCCM, a particular AD structure — know the actual terms you use for things there, because vague description reads the same as inexperience even when it isn't. And if you're asked a scenario you genuinely haven't handled, say so and reason through it out loud anyway; that's closer to what the job actually is than getting every answer right.

If you're sending out applications and not hearing back before you even get to this stage, jobmarket.pro reads the advert in full, matches it against your actual experience, and prepares the application from that rather than a generic CV.