Why pre-screen IT support technicians before the interview
In an internal support team, the difference between technicians shows in what happens after the ticket. One closes it and waits for the next identical one; the other notices it is the fifth this month and gets the underlying cause fixed. A short screen asks about a problem nobody else could solve, which surfaces both diagnostic ability and persistence.
What actually matters when screening IT Support Technician candidates
- 01
Hands-on competence
Check hands-on command of Windows 10/11 imaging, Active Directory account and group policy tasks, Microsoft 365 admin, printer queues, VPN clients, and hardware swaps on laptops.
- 02
Safety discipline
Probe handling of access requests, password resets and phishing reports: identity verification steps, least privilege, MFA enrolment, and safe disposal or wiping of retired drives.
- 03
Fault finding
Test structured triage on vague tickets like "email is slow" or "cannot print": layer isolation, Event Viewer, ping and tracert, and knowing when to escalate to network or app owners.
- 04
Reliability and conduct
Assess ticket discipline in ServiceNow, Jira Service Management or Freshservice: SLA response times, documented resolution notes, knowledge base articles, and tone with frustrated non-technical staff.
Pre-screening questions to ask IT Support Technician candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Environments supported
3 questions01What kinds of support work have you done previously?
Listen forOrganisation size and user numbers described, with the scope of what they handled alone.
Experience described without scale, or support limited to one narrow system.
02Which systems and software have you supported?
Listen forSpecific platforms and business applications named, with depth in the ones your users depend on.
Long lists with no depth, or unfamiliarity with the systems your organisation runs.
03Do you have experience providing support remotely?
Listen forRemote support delivered effectively, with the limits of it recognised for hardware faults.
Remote work described as identical to being on site, or hardware issues attempted remotely.
Method not guesswork
3 questions04What is your process for troubleshooting a technical problem?
Listen forA repeatable method that narrows the cause, with each assumption checked rather than assumed.
Remembered fixes tried in sequence, or the cause never confirmed after the symptom stopped.
05Can you give an example of a difficult problem you resolved?
Listen forA genuinely awkward fault with the reasoning described and what they ruled out along the way.
Difficulty described as time pressure, or the problem resolved by somebody else entirely.
06Can you describe your experience troubleshooting systems and hardware?
Listen forComponent-level diagnosis where appropriate, with hardware and software causes clearly separated first.
All hardware faults replaced without diagnosis, or symptoms attributed to hardware by default.
Helps users properly
3 questions07Describe explaining a complex technical issue to a non-technical colleague.
Listen forPlain explanation of cause and fix, with understanding checked rather than assumed.
Explanations built on jargon, or users told the detail would not help them.
08How comfortable are you training users on new tools or systems?
Listen forTraining tied to what people actually do, with follow-up after the first week of use.
Training described as sending instructions, or user difficulty treated as reluctance.
09How do you handle stressful situations with frustrated users?
Listen forCalm handling with the impact on their work acknowledged, and honest timescales given.
Users described as unreasonable, or frustration met with defensiveness about the system.
Prioritises sensibly
3 questions10Tell us about prioritising your support work when several things are urgent.
Listen forBusiness impact and number of people affected weighed, with waiting users kept informed.
Priority given to whoever asks most persistently, or people left without updates.
11Have you developed or improved support procedures in a previous role?
Listen forDocumentation or process they created that others use, reducing repeat questions over time.
No improvements suggested, or knowledge kept individually rather than written down.
12Can you describe your experience with security issues in support work?
Listen forSuspicious activity escalated properly, with an understanding of what a support account can reach.
Security treated as another team's concern, or shared administrator accounts used routinely.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Hands-on competence
35%5Names specific builds, imaging tools (Intune, SCCM, Autopilot), and describes resetting permissions or rebuilding a device end to end unaided.
Safety discipline
30%5Refuses unverified access requests, cites MFA and offboarding checklists, and escalates suspected compromise to security rather than resolving quietly.
Fault finding
20%5Walks through a real ticket from symptom to root cause, names the diagnostic tool used, and states what they ruled out first.
Reliability and conduct
15%5Quotes ticket volumes and SLA attainment, writes reusable KB articles, and keeps stressed users informed without jargon or blame.
One technician closes the ticket; another notices it is the fifth this month. A one-way video screen shows which.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Ten to fifteen minutes across eight to ten questions, answered async. Enough to establish the systems they supported, test their method, and hear how they deal with users.
Do certifications matter much for this role?
They show baseline knowledge was tested. What predicts performance better is how somebody works through an unfamiliar fault and whether they follow up on recurring problems.
Evaluating answers
What is the strongest signal when screening this role?
A problem nobody else could solve. Strong technicians describe the reasoning that got them there. Anyone whose examples are routine fixes has not been the person others escalate to.
How do I judge their communication?
Ask how they explain a fault to a non-technical colleague. Real answers keep the cause intact in plain language. Anyone who says users would not understand will frustrate the whole office.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
