The work is the second year, not the first month
A model that performs well on a held-out set is the beginning of the job. What machine learning engineering actually consists of is everything that follows: getting the thing served reliably, noticing when its inputs drift away from what it was trained on, retraining it without breaking the system around it, and being able to explain a bad prediction three months later. Teams that hire against the first month and interview accordingly tend to end up with a strong modeller and an unmaintained system.
Machine Learning Engineer
Owns models in production end to end — features, training, serving, monitoring and retraining.
Has kept something running and improving for years, not launched something once.
ML Platform Engineer
The infrastructure the models run on: feature storage, pipelines, experiment tracking, deployment.
Software and data infrastructure depth. Frequently the hire that unblocks everyone else.
Machine Learning Scientist
Method selection and experimental design where the approach itself is genuinely uncertain.
Research depth. The smallest pool, and the wrong hire for a problem that is really an engineering problem.
Underneath those, machine learning splits by problem domain, and each of these is a separate market with its own conventions and its own scarcity: MLOps Engineer, Recommender Systems Engineer, Computer Vision Engineer, NLP Engineer and Reinforcement Learning Engineer among them. Domain experience transfers less than the shared job title suggests — a strong recommender engineer is not thereby a computer vision hire.
Your data maturity decides which role you can fill
This is the constraint that determines whether an ML hire succeeds, and it has nothing to do with the candidate. An organisation with reliable pipelines, a place features live, and some way of knowing whether a model is behaving can hire a machine learning engineer and see value within a quarter. An organisation without those can hire the same person and watch them spend a year building the missing infrastructure — work they did not apply for, are not specialised in, and will leave over.
It is worth being honest about which of those you are before writing the advert, because the answer changes the role rather than the salary. Your first ML hire might not be an ML engineer sets out the questions that tell you, and what to hire instead if the answer is no.
If nobody in your organisation can currently say with confidence how a number on a dashboard was calculated, an ML engineer is not the hire that fixes it.
What the market is paying
Machine learning engineering is priced against senior backend and data engineering rather than against research, which surprises teams budgeting from the assumption that it is an exotic specialism. The range below is what employers are advertising on this board; read it as the spread across the role, not as a target for an individual.
Based on live Machine Learning Jobs adverts for Machine Learning Engineer roles across the UK. Salaries stated in the advert, not offers accepted.
Whether the platform already exists
Joining a team with working pipelines is materially more attractive than being asked to build them alone, and prices accordingly.
Ownership of production or not
Roles carrying on-call and production responsibility for models are priced above roles that hand a model to another team.
Whether anyone senior is already there
A sole ML hire with nobody to learn from is a career risk, and candidates price that risk into what they will accept.
Interview against the failure, not the algorithm
The standard machine learning interview tests derivations and algorithm recall, which selects for recent study rather than for the ability to keep a system working. The things that actually go wrong in production are mundane and specific, and asking about them separates people who have operated models from people who have built them in notebooks.
-
1
Ask about a model of theirs that got worse
How they noticed, how long it had been happening, what the cause turned out to be, and what they changed so it would be caught sooner. Anyone who has run models in production has this story; anyone who has not, does not.
-
2
Ask what they would monitor, and why that
The answer reveals whether they think about inputs drifting, about the delay before ground truth arrives, and about the difference between a model being wrong and a pipeline being broken.
-
3
Ask how they decided something was good enough to ship
Offline metrics rarely settle it. What you want to hear is how they connected a model metric to a business consequence, and who else they had to convince.
-
4
Give them one of your real problems
Described honestly, including the messy data. How someone interrogates a problem is more informative than how they solve a clean one, and it shows them the actual job.
Before you publish
Check the advert against this
Where to look first
Comparable adverts are the quickest way to calibrate both the range and the seniority language before writing your own.