Almost every IT interview, from a Tier 1 help desk role to a mid-level developer position, eventually lands on some version of this question: “Tell me about a time you fixed a technical problem.” It sounds simple. It isn’t. Most candidates either freeze because they can’t think of an example fast enough, or they ramble through a vague story that never actually answers what the interviewer wanted to know.
This guide breaks down why interviewers ask this question, what a genuinely strong answer sounds like, and how to prepare answers even if you don’t feel like you have “impressive enough” stories to tell.
Why Interviewers Keep Asking This Question
A resume tells an interviewer what you claim to have done. This question tests whether you can actually think through a problem out loud, under mild pressure, the way you would with a real user or a real production issue. It’s less about the specific fix and more about your process: did you gather information before jumping to conclusions, did you stay calm, did you know when to escalate, and did you learn something from it afterward.
Recruiters at IT staffing firms consistently point to this exact question as the moment where a candidate’s real experience level becomes obvious, regardless of what’s written on the resume.
The STAR Method, Applied Properly to Technical Stories
Most interview prep content mentions the STAR method (Situation, Task, Action, Result) without explaining why it works for technical questions specifically. Here’s the version that actually holds up under follow-up questions:
- Situation: One or two sentences of context — what system, what user, what was broken. Don’t over-explain the background; interviewers want to get to the actual problem-solving quickly.
- Task: What you were specifically responsible for, especially if it was a team effort. Be honest about your actual role rather than inflating it.
- Action: This is the part that matters most, and where most candidates rush. Walk through your actual troubleshooting steps in order — what you checked first, what you ruled out, why you tried the next thing. This is what separates a candidate who can genuinely troubleshoot from one who got lucky once.
- Result: What happened, quantified if possible, and — this is the part people skip — what you’d do differently or what you learned. Interviewers notice when a candidate treats a fixed problem as a closed chapter versus a learning moment.
A Worked Example: Help Desk Scenario
Weak answer: “A user’s computer wasn’t connecting to WiFi, so I fixed the network settings and it started working again.”
Strong answer: “A user reported their laptop couldn’t connect to our office WiFi, but their phone connected fine on the same network, which told me it was likely device-specific rather than a network-wide issue. I checked whether other laptops on the same floor had the same problem — they didn’t, ruling out an access point issue. I checked the laptop’s network adapter settings and found the WiFi adapter driver hadn’t updated after a recent Windows update. I rolled back the driver, confirmed the connection stabilized, then flagged the driver version to our team since two other users on the same laptop model reported the same issue within the week — which meant it wasn’t a one-off, it was a batch issue worth documenting.”
Notice what the strong version does: it shows a process of elimination, includes a specific technical detail (driver version, not just “settings”), and ends with proactive thinking rather than stopping the moment the immediate issue was resolved.
What If You Don’t Have “Real” IT Experience Yet?
If you’re prepping for your first IT role and don’t have a work history to draw from, you still have material — it just needs the same STAR structure applied to non-job scenarios:
- Home lab troubleshooting: “I set up a home network lab with an old router and a spare laptop running Linux. When I couldn’t get two VMs to communicate on the same virtual network, I worked through the VirtualBox network adapter settings, checked whether it was set to NAT versus Bridged mode, and eventually traced it to a subnet mismatch I’d misconfigured.”
- Helping non-technical family or friends: A grandparent’s laptop running slow, a friend’s printer not connecting — these are legitimate troubleshooting stories if you walk through your actual diagnostic process rather than just saying “I fixed it.”
- Coursework or certification labs: If your CompTIA A+ or Google IT Support coursework included hands-on labs, pick a specific one where you hit a snag and worked through it, rather than one that went smoothly.
The interviewer isn’t grading you on the complexity of the problem. They’re grading you on whether your explanation shows a genuine troubleshooting process.
Common Mistakes That Undercut a Good Story
Starting with the solution instead of the problem. Interviewers want to hear you reason through the diagnosis, not just announce the fix.
Using vague verbs. “I looked into it” and “I sorted it out” tell the interviewer nothing. Name the specific tool, setting, or command you used.
Taking full credit for team efforts without acknowledging it was a team effort — interviewers often ask a natural follow-up like “what was your specific part in that?”, and getting caught overclaiming hurts more than being upfront would have.
Not having a second example ready. Interviewers frequently ask “tell me about another time” as a follow-up, specifically to see if your first story was a rehearsed one-off or if you genuinely think this way.
How to Actually Prepare, Not Just Read About It
Write down three to five real troubleshooting scenarios — even small ones — in the STAR format, in advance. Practice saying them out loud, not just reading them silently, since the pacing and clarity of a spoken answer is different from a written one. If you’re preparing for a role listed with specific tools (ServiceNow, Active Directory, a particular OS version), try to have at least one story that name-drops that specific tool, since it signals direct relevance beyond generic troubleshooting ability.
Your Next Step
Pick one real troubleshooting moment from the last month — even something small, like fixing your own WiFi or helping someone with a printer — and write it out in full STAR format tonight. Then read it out loud once. If it takes you longer than 90 seconds to tell, trim it; if you find yourself skipping the “how,” that’s the part to build back in before your next interview. Pairing a well-rehearsed answer here with a resume that’s already passed ATS screening is what actually turns an application into an offer.
