Across our crawl of 1.1 million UK careers pages, exactly one employer puts “research engineer” in a job title. That is not a measure of demand — dozens of British teams do the work — but of how little help the market will give you.
The brief goes wrong the same way almost every time: it reads as though the job were having ideas. It is not. The job is taking an idea that already exists and establishing whether it survives real data and a real deadline — a skill rarer than originality, and far easier to test.
The job is to make somebody else’s idea run
Strip the role back and three verbs remain: implement, scale, debug. Implement means turning a method described in prose and mathematics into code that does what the prose meant. Scale means running it on far more data than the original ever did.
Debug is why this is a specialism at all. A wrong implementation of a correct method looks almost exactly like a correct implementation of a bad method: the loss falls, the curves look plausible, the numbers come out worse than hoped. Somebody has to tell those apart within days rather than months, and the rest of the job description is downstream of that.
Judged on the idea, or judged on whether it ran
A research scientist is judged on whether the idea was worth having. A research engineer is judged on whether it ran, how quickly, and whether anybody can rerun it next month and get the same answer. Confuse the two and you get a brilliant person who cannot ship.
So settle two questions before advertising: who chooses the next experiment, and who owns a negative result? If both answers are your new hire, you want a scientist with strong engineering, and the applied AI scientist guide fits better. If the ideas come from elsewhere and nothing gets built correctly, you want this role — say so plainly rather than dressing it up as blue-sky work.
They fail differently, too. A scientist’s failure is a dead end, a normal cost of research. A research engineer’s is a subtle bug that made a good idea look dead, found a year later.
The paper they reproduced, and the parts it left out
If you take one screening task from this guide, take this one: ask for a paper they reproduced, then ask what the paper did not tell them.
The answers separate people immediately: the omissions are always the same kind of thing, and only somebody who did the work knows them. Strong candidates mention the warmup schedule nobody wrote down, preprocessing described in one clause that turned out to matter enormously, a result that held only at the batch size used, or a normalisation detail present in the released code and absent from the method section.
Then two follow-ups. How close did you get, and how did you decide that was close enough? And the sharper one: what did you do when your number came out worse? Good answers narrow the search — overfit a tiny subset to prove the training loop is sound, unit-test a component against a value computed by hand, suspect the data loader first. The answer to dread is that they tuned hyperparameters until it matched. That is not reproduction, and nor is cloning a repository and running the script.
Telling an implementer from a well-read enthusiast
The pool is full of people entirely fluent in the vocabulary of the field. Fluency is cheap now, so the interview has to reach past it.
The tell is the altitude at which somebody describes a mechanism unprompted. People who have only read stay abstract. People who have built it drop at once into what exists in memory, what shape it is, and where the masking goes wrong. They volunteer an off-by-one that cost them a day, and that is very hard to manufacture. The PyTorch engineer guide goes further on framework depth.
One more question: what did you remove from the published method and find made no difference? Only somebody who ran the ablations can answer, and it shows whether they treat papers as instructions or claims.
The day research code becomes the product without a decision
Research code is written to answer a question and then be discarded. Some of it never is, and nobody ever decided which. Two years on, the core of your product is a module descended from a notebook, with hard-coded paths, a training loop nobody dares modify, no tests — and it is load-bearing.
Ask the standards question directly, about their own work: what did you write expecting to throw away, what did you write expecting to keep, and how did you tell on the day? The best answers describe two deliberate tiers — experiment scripts that need a seed and a config and promise nothing else, over a small library with tests and real review. Then ask who decides when something graduates. “It sort of became the service” is the failure mode, stated out loud.
Decide your own position early. Is this person allowed to deploy to production, or do they hand over at a boundary? Either works; leaving it unstated is how LLM engineer roles drift into becoming this one.
Money, and why this is among the hardest hires in Britain
Indicative permanent salaries: roughly £85,000 to £120,000 at mid level, and £120,000 to £170,000 at senior, with equity pushing past that at the few employers doing frontier work. Indicative day rates run about £600 to £950. Treat those as orientation: with one advertised vacancy carrying the title, any figure is inferred from adjacent roles rather than read off a market.
The difficulty is structural. The job needs real comfort with the mathematics of a method and real software discipline, and different institutions produce each: universities reward the first and are largely indifferent to the second, commercial engineering the reverse. Add employers who need this most and can pay what you cannot, plus a title so rare that the people doing the work are not scanning job boards.
The practical response is to widen on the engineering attribute rather than the mathematical one. A strong engineer who has carefully reproduced two papers usually gets further than a theorist who has never had code reviewed: the first can be taught to read, the second learns discipline slowly and unwillingly. Look for the person in a research group everybody else went to when their code would not converge, who is rarely paid as though they are the reason the group ships.