October 20, 2026·5 min read
Most technical support interviews are two conversations and a scenario. How would you handle an angry customer. Tell me about a time you did not know the answer. Walk me through your troubleshooting process.
Then the job starts, and the first ticket says: it does not work. No version, no error message, no steps. Behind it is a configuration nobody documented, on a product the customer has used in a way nobody anticipated.
Support is a technical job with a communication requirement, and the interview usually tests only the second half. The fix is the same as everywhere else: give the candidate the symptom on a real system and watch.
The setup. A box running the product with a real fault present. The ticket says the export is broken and nothing else.
Ask: here is the ticket and here is an environment with the customer's setup. Tell me what is actually happening.
Strong looks like: they reproduce before theorising. They try the thing the customer says is broken, in the way the customer would, and they narrow it: every export or one type, every user or one, since when. They ask the system before they ask the customer, and when they do write to the customer, the question is specific enough to answer in one line.
Weak looks like: a long list of generic questions sent straight back, which adds a day to the ticket and often arrives after the customer has worked around it or left.
Why it works: turning a vague report into a reproducible case is the whole first half of the role, and it is completely invisible in a conversation about customer empathy.
The setup. A failure caused by the customer's environment: a proxy stripping a header, a certificate that expired, a permission changed last week, a quota reached. The product is behaving correctly and the outcome is still wrong for the user.
Ask: is this a bug? Justify your answer.
Strong looks like: they prove it rather than assert it. They find the specific difference between the working case and the failing one, and they can say what evidence would change their mind. Then they handle both truths at once: the product is working as designed, and the customer still has a problem that needs solving today.
Weak looks like: either reflex. Blaming the customer's setup without evidence, or filing a bug report that an engineer closes in five minutes with a one-line comment, which is a tax everyone pays.
Why it works: the boundary between defect and environment is where support either earns engineering's trust or loses it, permanently.
The setup. A log with a lot of noise. Warnings that are always present, a stack trace that is a red herring, and one line that explains the actual failure, with a timestamp that does not quite line up with when the customer says it happened.
Ask: find the moment this broke.
Strong looks like: they anchor on time first, converting the customer's timezone, and they search rather than scroll. They can tell a recurring warning from a new error because they look at whether it was there yesterday too. When the timestamps disagree with the customer's account, they treat that as information rather than as the customer being wrong.
Weak looks like: reporting the first red thing in the log. It is usually unrelated, and it sends an engineer somewhere expensive.
Why it works: reading a log under time pressure is the most used technical skill in support, and most candidates have never been watched doing it. The platform side of the same skill is covered in the observability skills assessment.
The setup. The investigation is done. The answer is partly bad news: a workaround today, a fix next release, and one thing the customer did that contributed.
Ask: write the message you would send.
Strong looks like: short, specific, honest. It names what happened without jargon, gives the workaround in steps, says what happens next and when, and mentions the customer's contribution without making it the point. The best candidates write it so that a colleague reading the ticket later knows exactly where things stand.
Weak looks like: apology paragraphs with no information, or a technically correct message that reads as blame. Both generate a second ticket.
Why it works: this is the deliverable. Everything upstream of it is invisible to the customer. Grading it alongside the technical work, rather than in a separate soft-skills round, is what makes the assessment honest.
Four rows, the same for every candidate:
Warmth matters and it is not on this list, because warmth without a reproduction is a pleasant conversation that solves nothing.
All four tasks need a running product with a fault in it, logs with real noise, and a customer-like configuration. A hypothetical scenario tests how someone talks about support rather than how they do it.
EasyEnv gives the candidate a box with the product deployed, the proxy already misconfigured, the certificate already expired and the logs already noisy. Every candidate gets the same recipe, so the fault is identical and comparing two people is fair. The box is disposable, so you can hand over real access without thinking about it. The session is recorded, so you can see whether they reproduced the problem or reasoned about it from the ticket.
The limits, plainly. Someone has to build the faulty environment once, and it should look like your product rather than a generic Linux puzzle. Reviewing takes a support lead, not a recruiter. And for a first-line role where every ticket is triaged by somebody else, tasks one and four carry most of the signal on their own.
Stop running the empathy scenario on its own. Put a vague ticket, a system that is working as designed, a noisy log and a reply to write in front of the candidate.
If you only run one, run the vague ticket. Whether someone reproduces a problem before explaining it is the difference between a support engineer and a very polite relay.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Contract hiring skips the loop, which is the point, and then the work arrives and nobody can say whether it will survive the handover. Here is a single session that tests what actually matters for short engagements, and the four things to watch while it runs.
Anyone can draw the migration diagram. Migrations fail at the cutover, at 2am, when half the traffic is on the new platform and the old database is still taking writes. Here are four tasks that test the parts that actually go wrong.
Read more
Hiring someone to build with models is not the same as hiring someone who codes with one. Here are four tasks on a running LLM service, output that fails to parse, a change nobody can prove is an improvement, a context window that grows until it costs real money, and a provider having a bad afternoon.
Read more
