Hiring a technical support engineer
A hundred and ten applicants for a job that demands two skills most people have only one of — and a CV format that lets applicants lead with whichever one they have.
This role sits between two teams and gets described by only one of them. A technical support engineer has to do two genuinely different things well: work out what is actually happening in a system they did not build, and then translate it in both directions — to a customer without lying to them, and to an engineer without guessing. Applicants come from both sides of that line. The ex-developer writes a CV full of technical depth and no evidence they can handle a frustrated customer; the experienced support agent writes a CV full of tickets resolved and satisfaction scores with no evidence they have ever read a stack trace. Both are half right, both are common, and the format lets each hide the missing half rather than declare it.
Which side of the line the gaps are on
Selene establishes what escalation actually looks like here, because that decides how much debugging depth this role genuinely needs.
Escalation path, product depth, and who the customer is
The decisive question is what happens when this person cannot solve something. If engineering is one desk away, the diplomacy half matters more; if this is the last line before an angry enterprise customer, the debugging half does.
One sentence changes the guide
The phrasing matters more than it looks. Most guides for this role collapse the two into a single communication criterion, which lets a candidate who is excellent with customers and vague with engineers score the same as someone competent at both. Splitting them means the guide can no longer average away the missing half.
Exceptional, not just good —
“Someone who can tell the customer what happened without lying to them, and tell the engineer what happened without guessing.”
→ Communication split into two scored criteria so a strong half can no longer mask an absent one.
What the guide ends up measuring
Five criteria, deliberately split down the middle of the job. The structure is the point: two technical, two communicative, and no single criterion broad enough for a half-qualified candidate to hide inside.
No gates, though one shift question is worth asking
Nothing here disqualifies anyone on a yes-or-no basis. If the role carries weekend or out-of-hours cover, that is a fact worth putting on the application page — not because it is a judgment, but because it is the most common reason a good candidate withdraws at offer stage.
Scored on both halves, separately
Selene never receives the candidate’s name or the raw CV. She scores a blind, structured profile, with any stated age, sex, nationality and religion stripped out before scoring runs.
Because the two halves of this job are scored independently, the output shows exactly which one a candidate evidenced, rather than an average that hides the missing one.
How the blind scoring works →What stays with you
Selene's half
- Establishing where escalation really goes, which sets how deep the technical bar must be
- Reading all 110 against the same guide, blind, with the evidence attached
- A ranked shortlist that names which half of the job each candidate evidenced
- An interview brief aimed squarely at the missing half
Yours
- Getting support engineers to apply — Selene doesn’t post to job boards or source candidates
- Any troubleshooting scenario or written exercise, with her brief in hand
- The interview, and the judgment about how they are under a real complaint
- The offer, and every call that matters
Nearby roles
Enormous volume, thin CVs, and eligibility doing a third of the work.
High volume, and a certification filter that quietly excludes the people you want.
A title too new to have settled, doing four different jobs at four different companies.
Say where escalation goes
Whether engineering is one desk away or unreachable changes this hire entirely — describe yours.