Almost every company that advertises for this skill has already installed the tool. That is the peculiarity of the hire: you are rarely buying an implementation, you are buying somebody who can make a team actually use one, and those are different people.

The software is not difficult. Tracking experiments, registering models, promoting them between stages — a competent engineer learns the API in a day. What is difficult is that the whole value depends on discipline maintained by people who are busy and under no obligation to comply, and that is an organisational problem wearing a technical costume.

The unused-installation problem

The pattern is consistent enough to be worth naming. A tracking server goes up. For three weeks runs are logged. Then a deadline arrives, somebody trains a model in a notebook without logging it, that model ships, and within two months the registry describes a world that no longer exists.

At that point you have something worse than nothing: a system of record that people half-trust. Somebody looks up which model is in production, gets an answer, and is wrong.

So the most useful interview question is simply: how did you get people to log their runs? The answers that work are structural rather than exhortative — logging built into a shared training entry point so it happens whether or not anybody remembers, a deployment process that refuses to promote a model with no registered lineage, a dashboard somebody senior actually looks at. Answers about documentation and reminders describe somebody who has not yet watched this fail.

What good looks like in the registry

Ask what they record beyond parameters and metrics, because that boundary is where useful practice starts.

The things that matter later are the ones nobody logs at first: which exact dataset version, which commit of the training code, which environment, and what the model was evaluated against. Six months on, the question you will be asked is “why did this model change its mind about this customer”, and answering it requires all four. A candidate who mentions data versioning unprompted has been asked that question before.

The second question worth asking is what they do about experiments that were not worth keeping. Mature users prune, archive and name things deliberately. A registry with four thousand runs called experiment_1 is a search problem rather than a record.

This is a governance hire more often than teams realise

In regulated work — finance, health, insurance, anything with a model risk function — the reason to invest here is not convenience. It is being able to demonstrate, months later, exactly which model made a decision, what it was trained on, who approved it and what it scored at the time.

If that is your situation, screen for it directly. Ask whether they have supported an audit or a model risk review, what was asked for, and what turned out to be missing. Somebody who has been through it will describe scrambling to reconstruct lineage after the fact, and will have opinions about what should have been captured automatically.

This also changes who the right hire is. In a regulated setting the person needs to be comfortable talking to risk and compliance colleagues, which is a different profile from a platform engineer who prefers to be left alone with a cluster.

The scope question to settle before advertising

Tracking is a component, not a job. Ask yourself what else this person owns, because the honest answer determines whether you are hiring at all.

  • Tracking and registry only, for a team of three or four. Realistically a fraction of somebody’s role rather than a hire.
  • The whole lifecycle — training orchestration, deployment, monitoring, rollback. A real job, and the MLOps engineer guide is the better description of it.
  • Governance and reproducibility for a regulated function. Also a real job, and the one most often under-specified as “set up experiment tracking”.

Advertising the first when you need the second is the most common error here, and it shows up as an engineer who finishes the stated brief in a fortnight and then has no mandate for the work that actually mattered.

Screening for the engineering underneath

Two questions that reliably separate people who have run this from people who have installed it.

“Where did the tracking server live, and what happened when it was slow?” Under real use it becomes a service with a database behind it, and artifact storage that grows without limit. Somebody who has operated one will talk about retention, artifact size and the day a training job blocked because logging was synchronous.

“How did a registered model get into production?” You want a path: a promotion step, an approval, a deployment that reads from the registry rather than from a file somebody copied. If the answer is that models were downloaded and deployed by hand, the registry was a filing cabinet rather than part of the system.

Pay, and the shape of the market

Indicatively £70,000 to £105,000 permanent, day rates from around £500, with the regulated-sector version of the role paying toward the upper end because the compliance dimension narrows the field.

About 250 UK employers name the tool across the pages we index, which understates its presence considerably — it is commonly used without being advertised, because it is a component of a platform rather than a job title. The practical consequence is that you will find more candidates by searching for the lifecycle work than for the tool, and that the strongest applicants often describe themselves as platform or data engineers who happen to have built this.