Your First IT Support Interview: How to Answer When You Don't Know
A practical way to handle unfamiliar questions, explain your reasoning, and show where your responsibility ends.
You have prepared your CV. You can talk about a small project. Then the interviewer asks what you would do when an employee cannot open a shared folder, and your mind jumps straight to the permissions screen.
Do you reset something? Add the user to a group? Ask somebody else?
The uncomfortable part is that you do not yet have enough information to choose. Recognising that gap is useful. Pretending it is not there is the problem.
This guide is for people preparing for a first helpdesk or IT support interview. It is not a list of secret questions or a promise that the right sentence will get you hired. It is a way to make your existing knowledge easier to examine, including its limits.
Table of contents
The problem: treating every question like a memory test
Some interview questions really do test recall. If you are asked what DNS does, answer that question directly. A troubleshooting scenario is different: you are being given a situation with missing details, not necessarily an invitation to name a command immediately.
Microsoft's own interview guidance encourages candidates to clarify questions and explain their reasoning. That describes Microsoft's approach, not a universal hiring rule.
The distinction matters when you prepare. Memorising definitions will not, on its own, help you decide whether a reported problem affects one employee or an entire team. Equally, a calm process cannot replace the technical fundamentals the role requires. Prepare both: what you know, and how you work when the answer is incomplete.
Start by recognising the kind of question
Listen for what the interviewer is actually asking before choosing an answer structure.
A knowledge question: explain a concept accurately and briefly. Add an example if it helps.
A scenario question: clarify the situation, describe a safe investigation, and explain what would change your next step.
An experience question: describe something that really happened and identify your own contribution.
For experience questions, the STAR method organises an answer around situation, task, action, and result. Keep imagined scenarios separate from your work history.
You can also ask which kind of answer is wanted: "Would you like me to explain the concept first, or walk through how I would investigate this situation?" That is a useful clarification when a question could mean either. It is not a reason to avoid answering a straightforward technical question.
A practical structure for an unfamiliar scenario
The following is a rehearsal structure, not an official troubleshooting standard or an employer's scoring system.
1. State the gap precisely. "I have not administered that product" is more informative than "I am bad at networking." Say whether you lack product experience, a particular fact, or enough information about this incident.
2. Clarify the symptom and impact. Ask what the person expected, what happened instead, who is affected, and which work is blocked. Pick the questions that matter; do not recite an interrogation script.
3. Propose the next permitted check. Describe one observation that would narrow the possibilities. Explain what you expect to learn before you talk about changing anything.
4. Name the boundary. Say when you would use the team's procedure, seek approval, or hand over to the responsible team. Mention relevant security concerns without inventing a policy you have not seen.
5. Close the loop. Explain how you would check the outcome, record the work, and keep the affected person informed. Escalation is a handover of useful information, not the disappearance of the problem.
If the interviewer interrupts with new information, use it. A prepared structure should help you listen, not make you resistant to a changing scenario.
Worked example: a shared folder will not open
This is a fictional practice scenario, not a reported incident or a universal fix.
Question: "A colleague says they cannot open a shared folder. What would you do?"
A weak starting point is "I would give them access." It assumes the cause, the entitlement, and your authority to change it.
A more useful opening might be:
I would clarify the exact error, which folder they mean, whether it worked before, and whether other people are affected. I would also ask what work is blocked so I can follow the team's priority rules. I would not change access rights until I had checked the approved process and who is authorised to approve access.
Now imagine the interviewer adds: "It says Access denied. The employee moved to a different team yesterday."
That gives you a hypothesis, not a confirmed cause. You could continue:
The team change makes an access or group-membership issue worth checking, but I would not assume the employee should have the same access as before. Using the tools available to my role, I would check the request history and the documented access process. If approval or investigation belongs to another team, I would send them the error, affected resource, timing, and business impact.
Do not invent a successful outcome. If you are asked how you would finish after an approved change, say you would have the employee retry the original task and record whether it now works. If it still fails, the ticket is not resolved just because a setting changed.
Microsoft's support-scoping guidance similarly separates observed symptoms from proposed causes. Its product context is Power Platform and Dynamics 365; the shared-folder exercise above is an original application of that distinction.
What to say when you genuinely do not know
You do not need a clever euphemism. You need an honest statement followed by a credible next step.
When the product is unfamiliar: "I have not used that administration console. I would check the team's runbook and the vendor documentation for the version in use before proposing a change."
When you forget a fact: "I cannot recall that exact value confidently. I would verify it rather than guess. I can explain the underlying concept if that would be useful."
When you are outside your authority: "I can gather the symptoms and relevant ticket details, but I would need the designated approver before changing access."
Avoid turning every difficult question into "I would Google it." Say what you need to verify, where you would look, and how you would check that the advice fits the actual environment. Never suggest entering passwords, customer records, or confidential logs into a public search or AI tool.
Bring one real example from your previous work
A career change does not erase your earlier responsibilities. It does mean you should explain them without relabelling them as technical experience.
Choose a real situation in which you clarified a confusing request, handled a dissatisfied person, corrected an error, or handed work over responsibly. Explain what you personally did. If a colleague made the final decision, say so.
A useful result can be modest. Perhaps the next shift received the correct information. Perhaps an unresolved issue reached the person who could act on it. Do not add a percentage improvement because an interview template seems to demand a number.
Then make a limited connection to support work: "That example shows how I communicate a handover. My technical practice is separate, and I can walk you through it." The distinction lets both parts of your background remain credible.
A rehearsal you can complete this week
Try this sequence over three short sessions. The timing is a suggested exercise, not a preparation deadline.
Session one: sort the questions. Take one real vacancy and write a knowledge question, a scenario question, and an experience question related to its duties. Mark which technical gaps actually need study.
Session two: practise a changing scenario. Ask a friend to add a detail halfway through your answer. If practising alone, prepare two possible updates on separate cards. Notice whether you reconsider your initial idea or keep defending it.
Session three: review one recording. Record only your own practice answer. Listen for an unsupported assumption, an unexplained acronym, and a point where you stopped listening to the question. Rewrite those parts, then answer again without reading a script.
The National Careers Service's interview advice also recommends preparation around the vacancy and practice before the interview. The three-session exercise here is an editorial suggestion.
Questions worth asking the team
Use the interview to understand the role as well as to present yourself.
What kinds of tickets do new starters handle first?
How are access requests approved and escalations assigned?
Who reviews a junior colleague's work while they are learning?
What would useful progress look like during the first few months?
Listen for specifics. A reassuring answer is more useful when it explains who helps, what the process looks like, and where your responsibility begins. Different teams will organise this differently; the point is to understand the actual arrangement.
Final thought
You are not trying to sound like somebody who has already done every part of the job. You are trying to give an accurate picture of the colleague you could become, starting from the skills you have now.
You can leave a question without knowing the answer and still make your reasoning clear. Learn the missing fact afterwards. In the moment, be honest, ask the next useful question, and know which decisions are not yours to make alone.
Key takeaways
Match your answer to the question: knowledge, scenario, or real experience.
Treat a plausible cause as a hypothesis until the evidence supports it.
Explain a safe next check and the limits of your authority.
Use true examples, with modest results when that is what happened.
Practise responding to new information, not reciting a perfect paragraph.
Andreas-Christian Hetzl writes SHIFT 2 IT, a practical guide for people moving into IT. For a broader career-change roadmap, explore SHIFT 2 IT. Bring your real starting point; build from there.
