Voice systems fail in a way that text systems do not: the user hears the mistake immediately and cannot scroll back. That single difference drives most of what makes this hire specific, because latency is not a performance metric here — it is the product. A pause of a second and a half in a spoken exchange reads as the system being broken, however good the eventual answer is.

So the discipline is about a pipeline and its budget, not about a model.

The pipeline, and where the time actually goes

A spoken interaction has at least four stages: detecting that the person has stopped talking, transcribing what they said, working out a response, and speaking it. Each has a latency cost, and the total is what the user experiences.

The one candidates most often underestimate is the first. Deciding that a speaker has finished is genuinely hard — wait too long and the system feels sluggish, cut in too early and you interrupt somebody mid-sentence, which is the single most irritating failure a voice product has. Ask how they tuned that. Anybody who has shipped a voice interface will talk about endpointing with some feeling, and will know that the right setting differs between a short command and a discursive answer.

The second thing to ask about is streaming. Waiting for a complete response before speaking anything doubles the perceived delay; starting to speak the first clause while the rest is still generating usually halves it. An engineer who has not built that has not solved the problem this role exists for.

Transcription quality is a data problem, not a model problem

Off-the-shelf recognition is now very good on clear speech in a common accent. It degrades on everything else, and the degradation is where your product lives or dies.

Ask what it struggled with. The honest list is accents outside the training distribution, background noise, two people talking at once, and above all domain vocabulary — product names, drug names, part numbers, postcodes. A candidate who has fixed this will talk about biasing the recogniser toward an expected vocabulary, or post-correcting against a known list, rather than about changing model.

In a British context ask specifically about regional accents, because the published accuracy figures are dominated by American English and the gap is real. A candidate who has measured accuracy across accents rather than in aggregate is telling you they take the product seriously.

Synthesis: the questions that separate a demo from a service

Generated speech has become extremely good, which moves the difficulty elsewhere.

Ask how they handled pronunciation of things the model gets wrong — names, initialisms, currency, dates read aloud. There is always a list, and mature systems have a pronunciation override mechanism rather than a hope. Ask about cost per minute and caching, because synthesis is billed by output and any product with repeated phrases is paying repeatedly for identical audio unless somebody noticed.

And ask about voice cloning consent if that is anywhere near your product. Reproducing somebody’s voice has a legal and reputational dimension that is moving quickly, and an engineer who treats it as a purely technical capability is a risk rather than an asset.

What to measure, which is not what teams usually measure

  • Time to first audio, not total response time. It is what the user perceives as responsiveness.
  • Interruption rate — how often the system speaks over the user or is spoken over. A direct measure of whether the turn-taking works.
  • Containment and escalation. For anything service-related, how often the exchange completed without a human, and whether the handover carried context.
  • Transcription accuracy on your vocabulary, not on a public benchmark. Word error rate on generic speech tells you very little about performance on your part numbers.

Who to hire, and where they come from

The strongest candidates usually come from real-time audio or telephony rather than from machine learning. Somebody who has built a voice or video calling product understands jitter, packet loss, echo cancellation and the discipline of a latency budget, and those instincts are harder to acquire than the model APIs are.

Traditional contact-centre and interactive-voice-response engineers are also worth considering and are frequently dismissed too quickly. They have spent years on turn-taking, barge-in, confirmation strategies and escalation design — the interaction problems that the current generation of tools has not removed.

If the substance of your product is the conversation logic rather than the audio path, the NLP engineer guide describes that hire better, and on a small team one person often covers both with the audio work contracted in.

What it pays, and why the advert numbers understate it

Indicatively £75,000 to £115,000 permanent, with day rates from around £550, and higher where the work is genuinely real-time rather than request-response.

Across the UK careers pages we index, roughly 165 employers name voice AI and a similar number mention text-to-speech, with speech recognition a little behind. Those are modest numbers that understate the activity, because a great deal of this work happens inside products that describe themselves by what they do rather than by the technology underneath.

The scoping question worth settling first

Ask yourself whether the interaction is a command or a conversation, because the engineering differs more than the vocabulary suggests. “Set a timer for ten minutes” is a short, bounded, low-risk exchange where accuracy matters and latency is forgiving. A discursive support call is open-ended, needs memory of what was said two turns ago, and is unforgiving about timing.

Teams that scope the second and budget for the first are the ones that end up rebuilding. Being explicit about which you are building will improve your shortlist more than any interview question on this page.