Here is the thing most job specifications for this role get wrong: they describe research and pay for production, or describe production and interview for research. Around 76 British employers are advertising for one as we index them, and a large share of those adverts ask for novel model development, published work, deep theory — and then describe a job that is mostly getting a gradient-boosted model into a service and keeping it there.
Both jobs are real. They want different people, and conflating them produces a shortlist where the strong candidates for each look weak against the other.
Most of this job is data, and the specification should say so
Ask anybody who has done it where their time went and the model will be a minority of the answer. The bulk is assembling training data that is correct and available at the moment prediction happens, understanding why a field is null for eight per cent of rows, discovering that a column changed meaning in March, and building the thing that will do all of that again next month unattended.
So the strongest signal in an interview is fluency about data rather than about architectures. Ask what the messiest dataset they worked with was and what they did about it. Candidates who describe cleaning, reconciling sources, and negotiating with whoever owns the upstream system are describing the job. Candidates who move straight to model selection have usually been handed clean data by somebody else — which is a fine place to have started and a poor place to be hiring from if nobody will be doing that for them here.
The question that reveals whether they have shipped
“Tell me about a model that performed worse in production than in testing, and how you found out.”
Anybody who has put two or three models live has this story, and it is almost impossible to invent convincingly because the details are specific. The good answers name a cause: training-serving skew where a feature was computed differently in the serving path, a population that shifted, a leak that flattered the offline result, a distribution that was fine in aggregate and wrong for the segment that mattered.
The second half of the question matters as much. “A stakeholder told us” is honest and common; “our monitoring caught it” is better and tells you they build for the failure rather than hoping. Somebody whose models have never disappointed has not yet shipped enough of them.
Where the boundary sits with the people either side of them
This role is defined as much by what it is not, and being explicit saves a bad hire.
Upstream, somebody has to produce reliable data. If that person does not exist, your machine learning engineer will become them, whether or not the advert said so — and an engineer hired to build models who spends a year building pipelines will leave. Downstream, somebody has to run the serving infrastructure and the deployment path; where that is a distinct role it is the one our MLOps engineer guide describes, and on a small team the same person does both and should be paid accordingly.
Sideways, if the models in question are large language models the candidate did not train, the work is different enough to warrant its own description and the LLM engineer guide covers it. A great deal of confusion in the current market comes from adverts that use this title for that job.
A practical test that beats a take-home exercise
Take-home tasks select for people with spare weekends, which is a poor filter and an unfair one. A better hour: give them a real problem from your own backlog, described in a paragraph, with a sample of the actual data if you can share it, and talk through how they would approach it.
What you learn is everything the exercise would not show you. Do they ask what decision the prediction supports? Do they ask about the target definition, the class balance, how often the data arrives, what a false positive costs? Do they propose a baseline before a model? Do they say which part they would do first and why?
Candidates who interrogate the problem before proposing a method are the ones who will not waste a quarter. It is also the closest simulation available of what working with them is actually like.
What to pay, and the seniority signal worth trusting
Indicatively £55,000 to £75,000 for one to three years, £75,000 to £105,000 at mid level, and £105,000 to £140,000 for genuine seniority, higher in London and in finance. Day rates from about £500.
The seniority claim worth trusting is ownership over time. Somebody who built a model, deployed it, watched it degrade, diagnosed why and improved it has been through the full cycle, and that is a different person from somebody with the same years spread across projects that ended at the notebook. Ask how long their longest-running model was in production and what happened to it over that period. The answer is more informative than any list of frameworks, and it is the question fewest candidates expect.
One more thing worth deciding before you advertise
Ask whether you need somebody to build the first model or to industrialise the fifth. A company with no models in production needs somebody comfortable with ambiguity, willing to do the unglamorous data work, and able to ship something simple that earns the right to build something better. A company with several needs consolidation, standards and platform thinking.
Those are almost opposite temperaments, and the same advert attracts both. Saying which you are in the first paragraph of the job description will improve your shortlist more than any interview technique on this page.