A practical walkthrough for answering a troubleshooting question without guessing, overclaiming, or reaching for an unsafe fix. "An employee cannot access a shared folder. What do you do?" There is a temptation to answer with a tool: check permissions, reset an account, run a command. But the question has not yet told you whether the folder is missing, the connection fails, or the user receives an access error. A command is not a diagnosis. A confident guess is still a guess. For a first IT support interview, practise explaining what you would check next and what its result would mean. That gives your technical knowledge a structure without pretending you already know the environment. Table of contents First, distinguish recall from investigation Start with an observation, not a change Walk through the new evidence Use a compact decision note Handle an unfamiliar tool honestly Keep real experience separate from hypothetical answers Rehearse with a change of direction Final thought Key takeaways First, distinguish recall from investigation If the interviewer asks for a definition, give one. If you do not know it, say so precisely. A long troubleshooting speech is not a substitute for knowing a basic concept. A scenario question is different. It may require you to establish the missing context before a proposed action makes sense. Microsoft explicitly encourages candidates to clarify and explain their thinking in its interview tips. Do not assume every employer uses the same assessment approach. Practise switching between a short factual answer and a reasoned investigation. Both matter. The goal is not to turn every answer into a five-minute lecture; it is to make each sentence useful to the question you were asked. Start with an observation, not a change For the shared-folder scenario, a useful first response is: I would ask for the exact error and affected folder, whether the task worked before, and whether anyone else is affected. I would clarify the business impact before assigning a priority through the team's process. That opening leaves several possibilities available. It does not prematurely turn the incident into an account problem. Microsoft's support-scoping questions distinguish the reported behaviour from speculation about its cause. The article is product-specific; this interview exercise applies that distinction to a fictional support request. You do not need to ask every conceivable question at once. Start with the questions that separate materially different paths. "What is the exact error?" usually gives the conversation more direction than a recital of everything that could ever fail in a network. Walk through the new evidence Suppose the interviewer says: "The error is Access denied. Only this employee is affected, and they changed teams yesterday." You now have a reasonable avenue to investigate. You still do not have proof that adding permissions is the right action. Observation: the person reports an access error after a team change. Hypothesis: their authorised access or relevant group membership may have changed. Next check: inspect the documented request and access process, using only the tools and information permitted for your role. Boundary: determine the authorised approver before proposing an access change. Do not copy a colleague's rights simply because their folder opens. Outcome check: after any approved resolution, ask the employee to retry the original task and record the actual result. This is a reasoning exercise, not an instruction to inspect a real company's systems without permission. In an interview, state which information you would need and ask whether the scenario allows you to check it. Use a compact decision note A useful rehearsal aid is a small note with five prompts: Observed: What is actually happening? Unknown: What must I clarify before acting? Next check: What would this tell me? Boundary: Who must approve or take over? Follow-through: How will I verify and communicate? This is an original practice aid, not a certification methodology. Do not memorise the labels as a performance. Use them to notice missing reasoning when you review your answer. For example, "I would check the account" is incomplete until you can explain which aspect you mean and how it would affect your next decision. "I would escalate" is incomplete until you explain the information you would pass on and what the affected person should expect next. The note should become shorter as you get better at the conversation. You are building a habit of connecting evidence to action, not an obligation to say five things before the interviewer can speak again. Handle an unfamiliar tool honestly You may understand the issue but have no experience with the employer's ticketing system or administration console. Separate those two facts. Try: "I have not used that console. I understand the purpose of the access check, but I would need the team's runbook and appropriate access before carrying it out." That is more accurate than either claiming proficiency or deciding that all your previous learning is irrelevant. It also gives the interviewer something specific to follow up on. If you cannot remember a value or a command option, do not invent it. Say what you would verify in the documentation for the relevant version. Avoid proposing a search that would expose an internal hostname, customer record, password, or confidential log to a public service. Being willing to check is useful. Knowing what you need to check is better. Keep real experience separate from hypothetical answers "I would" and "I did" are not interchangeable. For a real example, STAR provides a situation, task, action, and result structure. Describe your own contribution; never turn the practice incident in this article into your employment history. A home exercise can be valuable if you label it accurately. Explain what you controlled and what you could not test. A previous non-IT job can also provide a relevant example of communication or prioritisation without being renamed an IT support role. Be especially careful about results. "The next shift had a complete handover" may be the truthful outcome. "I improved operational efficiency by 40%" is not an upgrade unless you actually measured that result and can explain it. Rehearse with a change of direction Ask a practice partner to change one detail after your opening answer. Perhaps the issue affects everyone, not just one person. Perhaps the error is different from what you first understood. Then pause and say what changed in your reasoning. Do you need to revisit the initial hypothesis? Does the wider impact affect who you contact? What investigation is now less useful? Do not treat the first hypothesis like something you must defend. A better answer can begin, "With that additional information, I would change my next check." Afterwards, review three things: whether you used the new detail, whether you proposed a change before checking authority, and whether you explained how the person would receive an update. This is a practice review, not a prediction of an employer's interview score. Final thought Your first support interview does not require you to invent a history of solving enterprise incidents. It does require you to be clear about your actual knowledge and the work still ahead of you. Make the next check understandable. Make the boundary explicit. Make the handover useful. Those are concrete things you can practise before you know the answer to every question. Key takeaways Definitions and troubleshooting scenarios need different kinds of answers. Separate what was observed from what you think might explain it. Describe the purpose of a check before naming a tool. Never imply that you can grant access without the required approval. Let new evidence change your answer. Andreas-Christian Hetzl writes SHIFT 2 IT for people building a realistic path into IT. Find the broader roadmap at SHIFT 2 IT. Technical confidence is worth building one explainable decision at a time.