Middle Technical Support Engineer — Technical support engineer interview questions

A specific error has shown up in twelve tickets this month with no common root cause visible yet. How do you investigate?

Pull all twelve tickets and look for what's actually common — browser, plan tier, feature flag, time of day, geography — rather than assuming they're unrelated because the surface symptom varies. Reproduce it with the narrowest shared condition you find, then check recent deploys or config changes around when the pattern started. If you can't reproduce it, that's itself data worth handing to engineering rather than closing the tickets as one-offs.

How do you set an ETA for a customer when you genuinely don't know how long a fix will take?

Give a time for the next update, not a time to resolution, because promising a fix time you can't back is worse than an honest "I don't have an ETA yet, but I'll update you by 3pm." Once engineering gives you a real estimate, pass it along with the same honesty about uncertainty. Customers tolerate not knowing far better than they tolerate being told something that turns out to be wrong.

How do you balance CSAT and resolution time when they pull in opposite directions?

A rushed resolution that doesn't actually fix the problem tanks CSAT on the follow-up contact even if it looks fast in the report, so speed without correctness is a false win. The real lever is usually the first response and update cadence — customers rate the experience of waiting, not just the total minutes, so a slower fix with clear updates often scores better than a fast one that goes silent.

A ticket has been reassigned between support and engineering three times with no resolution. What do you do?

Stop the ping-pong by owning it yourself as a single point of contact — read the full history, write a one-paragraph summary of what's actually known, and set up a short sync instead of another async handoff. Most of these loops happen because each side is answering a slightly different question; getting everyone talking about the same reproduction case usually breaks it.

Your ticket queue is at 200 and growing. What do you actually do differently versus a normal day?

Triage in a batch first — sort by severity and SLA breach risk before answering anything, rather than working top to bottom by arrival time. Send fast holding responses on lower-priority tickets to stop SLA clocks and buy time, then work the true emergencies. And flag the backlog itself to your lead, because a growing queue is usually a staffing or a recurring-bug signal, not something to quietly absorb.