Every time I've been part of hiring for a support role, I've watched the same mistake repeat itself. We test for product knowledge. We run candidates through scenarios they can Google. We ask what CRMs they've used. Then we wonder why the person who aced the interview struggles with an angry customer on day fifteen.
Support is a judgment and communication job that happens to require some knowledge. You can teach anyone the product. You cannot easily teach someone to stay calm under pressure, write a clear sentence when flustered, or know when to escalate rather than guess. Over the years, I've settled on three questions that reveal far more than any scenario quiz. None require industry experience. All reveal what actually makes someone good at support.
What You Are Really Testing For
A support agent's hardest days are not the busy ones. They are the days when a customer is furious about something that genuinely is not the company's fault, when the agent does not know the answer and the customer is waiting, when a colleague's mistake became their problem to fix. What you need to know is how this person behaves in those moments: do they go defensive, do they go quiet, or do they stay curious and focused? That is what these questions probe.
Question One: Walk Me Through a Time You Explained Something Complicated to Someone Who Was Frustrated
This is not a trick. I want a real story, not a hypothetical. I ask it early, before the candidate knows where I'm going, and I listen for four things.
Do they make the customer the subject of the story, or themselves? A candidate who leads with "I was really stressed because..." is already telling you something. A candidate who leads with "The customer had been waiting two days and was worried they'd lose access to..." is telling you something better. Empathy shows up in whose experience they center when recalling a hard moment.
How do they describe what they said? Ask them to actually show you. "I explained it in simpler terms" is not an answer. What were the simpler terms? I want to hear the candidate reconstruct the explanation. If they can, that is a real skill. If they can only summarize that they did it, that is a flag.
What happened next? The candidate does not need a perfect ending, but they should care about what happened to the customer after the conversation ended. If they wrap the story at the point they delivered the explanation, with no mention of whether it landed, they may be task-oriented in a way that will show up on the desk. And would they do anything differently? Great support people notice the gap between the conversation they had and the one they wish they'd had. "It went perfectly" is a red flag. "I'd check in sooner next time" is encouraging.
The goal is not a polished answer. It is an honest one that shows me the candidate actually thinks about the other person's experience.
Question Two: A Customer Asks You Something You Don't Know. What Do You Do?
This one is almost a trap, and I ask it directly. I'm not looking for "I would look it up." Everyone says that. I'm looking for the sequence of decisions that happen between "I don't know" and "the customer has their answer."
Strong answers cover this sequence: acknowledge to the customer that you don't have the answer right now (without treating "I don't know" as a dead end), set a clear expectation ("let me find out and come back to you within the hour"), know where to look first, and follow through by checking that the answer actually solved the problem.
The red flag I watch for is a candidate who describes guessing. "I'd probably tell them what I think is true and then verify after." Wrong information delivered confidently does more damage to trust than a brief wait for the right answer. A related flag: immediately defaulting to "I'd escalate to my manager" before any attempt to find the answer. Escalation is correct sometimes, but as a first instinct it suggests a ceiling on independence. Support requires agents who can figure things out, not just triage upward.
Question Three: A Written Exercise
This is not a spoken question at all. About two-thirds of the way through the interview, I give the candidate a printed or pasted email. It is a message from a fictional customer who is unhappy, not abusive, just genuinely frustrated and a little confused about what happened with their account or order.
I ask them to write a reply. They have fifteen minutes. I leave the room.
I do this because support is largely a written communication job, and a live interview penalizes people who think carefully rather than quickly. Fifteen minutes is enough time to write a thoughtful two or three paragraph response. It is also long enough that candidates who are going to write something impulsive will reveal that too.
Four things I look for in the reply: Does it open with acknowledgment, not groveling, but a recognition that the customer's frustration makes sense? Is it clear enough to read once and know exactly what is happening and what to do next? Does it actually answer the question the customer asked (warmth without substance is not good support, it is pleasant noise)? And does it sound like a person who read this specific email, not a template with a name swapped in?
After they hand it back, I ask: "Is there anything you'd change with another five minutes?" That follow-up often tells me more than the reply itself. Candidates with a specific thing to refine are already thinking like experienced support people. The ones who say "no, I think it's fine" usually wrote something fine and nothing more.
The Red Flags That Appear Across All Three
A few patterns show up reliably across candidates I've passed on: treating customers as obstacles rather than people (watch the language: "when a customer won't accept the explanation" versus "when the customer is still confused"), no curiosity about outcomes (finishing their story at the point they delivered the action, not at the point the problem was resolved), and a strong "not my fault" reflex. Support people deal with others' mistakes constantly. A candidate who immediately clarifies what they personally were not responsible for in every story they tell may struggle when they're the face of a problem that someone else created.
What These Questions Don't Test
I am deliberately not asking about specific tools, prior experience, or product familiarity. Those are learnable in weeks. What these questions test is not learnable on the job in any reasonable time: the instinct to center the other person, the honesty to say "I don't know" without panic, and the care to write something worth reading.
I've hired people with no formal support background who became strong agents within months, because they had these instincts. I've also worked alongside people with years of helpdesk experience who struggled at exactly the moments these questions reveal. Skills transfer. Instincts are harder. Run these questions before any scenario quiz and you will learn more in sixty minutes than a week of reference checks would tell you.
Have a question about the process or want to discuss how I structure the rest of the hiring flow? Reach out here.