The 10 questions I asked every helpdesk candidate
After a few hundred tier 1 interviews, my list stopped changing much. Every question below has a job behind it, a real thing that went wrong or right on the desk, and most of them are really testing the same two traits: how you handle not knowing, and how you handle people who are having a bad day.
1. "Walk me through what happens when you type a website into a browser."
The classic, and I asked it because it does double duty: it shows how deeply you understand things you use daily, and it shows whether you can build an answer in order. Good answers start anywhere, DNS or even the keyboard, and proceed logically. Bad answers are memorized word salad. If you can explain DNS, TCP, HTTP, and rendering in five plain sentences, you're ahead of most applicants.
2. "A user says the internet is down. What do you actually do first?"
There is no single right answer, and that's the point. I want a sequence: check the ticket/ask questions ("just you or the whole floor?"), check the obvious (cable, Wi-Fi toggle, is it one site or everything), then escalate outward. The trap answer is a deep technical monologue. Tier 1 is triage, not surgery.
3. "Tell me about a time you had to deal with an angry user."
Every tier 1 job is this question wearing a headset. I'm listening for: did you take it personally (bad), did you stay calm and solve the thing (good), and did you follow up after the fix (rare and excellent). The STAR method is fine as a skeleton, but rehearsed-sounding answers score worse than messy true ones.
4. "You don't know the answer to a ticket. Now what?"
The question under most of the interview. The answer I wanted: search the knowledge base, search the vendor docs, try one or two sensible things, then ask a senior tech with what you've already tried written down. The answer that sank people: guessing at random, or going silent and struggling alone for two days. Nobody expects tier 1 to know everything; everyone expects them to know how to find out.
5. "What's the difference between a ticket that should be escalated now and one you should work first?"
Checks judgment. Good signs: impact vs urgency thinking, whole-department-outages jump the queue, one user's font preference does not. Also whether you close the loop. An escalation isn't throwing it over a wall, it's handing it off with notes.
6. "Tell me about a time you made a mistake that affected someone else."
I care less about the mistake than about ownership. "I disabled the wrong account, realized it, told my lead immediately, and we fixed it in ten minutes" is a hiring answer. "The process was confusing" is not. IT teams run on trust, because everyone has production access to something.
7. "How do you keep track of things when you're handling five problems at once?"
Desk reality is interruptions. Notes, ticket updates in real time, a personal system; anything honest works. "I just remember it all" worries me, because at 40 tickets a day nobody remembers it all, and unlogged work becomes invisible work.
8. "What's something you've fixed or built on your own time?"
Same question as the homelab bullet on the resume, but out loud, with follow-ups. People who genuinely tinker light up and have details. People padding a resume go flat. This is the easiest question in the interview to be genuinely good at.
9. "Why this company / this desk?"
Mostly a filter for attention. If you can't say one true thing about the place: the size of the environment, the industry, that it's an MSP versus internal support, anything, it reads as "any port in a storm," which is fine, but say it honestly. "I want internal enterprise support at scale and you have 1,200 users" is a better answer than flattery.
10. "What questions do you have for me?"
"What does a tech's first month look like here?" and "What separates your good tier 1 techs from the great ones?" — both are questions that made me like the candidate, because they're questions about the actual job. Zero questions was the only wrong answer.
The pattern, if you want one: every answer is better with a specific true story in it, told in under 90 seconds, ending with what you did and what happened. Prepare six stories you can bend to different questions: one angry customer, one mistake, one hard problem solved, one thing you built, one team conflict, one boring win, and you can answer almost anything a tier 1 interview throws at you.