The first difficulty with this hire is that the name covers around twenty separate products. Notebooks, training jobs, hyperparameter tuning, a feature store, pipelines, a model registry, real-time endpoints, serverless inference, batch transform, a low-code studio, monitoring, and a clutch of things added last year. Two engineers can both have four years of genuine experience and have used almost none of the same parts.

So the useful first step is not writing an advert. It is writing down which three or four of those components your work actually touches.

This is an AWS hire before it is an ML hire

Everything here runs on the same substrate as the rest of the account: IAM roles, VPCs, security groups, S3 permissions, KMS keys, CloudWatch. A very large proportion of the difficulty in real projects is not modelling at all — it is a training job that cannot reach a bucket, an endpoint that cannot resolve a private subnet, or a role that lacks one permission nobody can locate.

Ask a candidate to talk through what happens when a training job fails to start. The answer you want moves through the execution role and its trust relationship, the subnet and whether it has a route to the services involved, the bucket policy, and the logs. An engineer who has only ever worked in a permissive sandbox will describe checking the code.

The practical consequence for sourcing is that a strong AWS engineer who has done some machine learning is usually a better hire than a strong data scientist who has clicked through the studio, and the first group is considerably larger.

The cost trap is specific and worth screening for

Real-time endpoints bill for as long as they exist, whether or not anybody calls them. That single fact accounts for a remarkable share of unexpected invoices: a model deployed for a demonstration in March and still running in September, an instance type chosen generously because nobody wanted the demo to be slow, a development endpoint per engineer.

Ask what they have done about it. Good answers cover serverless or asynchronous inference where the traffic is intermittent, autoscaling with a sensible floor, batch transform for anything that does not need to be live, shutting down notebook instances automatically, and knowing which invoice line corresponds to which workload. Somebody who has been asked to explain a bill will answer with feeling.

The related question is whether they can tell you what an endpoint costs per thousand requests. It is a straightforward calculation and very few people have done it, which is precisely why it is a good question.

Where the platform earns its keep, and where it gets in the way

Worth asking directly, because the answer reveals whether somebody has judgement or allegiance.

The platform is genuinely strong when you need managed training on hardware you do not want to own, when the account structure and audit trail matter to a regulator, or when the team is already deep in the wider ecosystem and the integration is free. It gets in the way when a container and a scheduled job would have done, when the abstractions hide something you need to control, and when local development diverges enough from the managed environment that debugging becomes guesswork.

A candidate who says they have deployed a model as a plain container on a cluster instead, and can explain why, is demonstrating the thing you want. Enthusiasm for every component is usually a sign of having been trained by the vendor rather than by production.

Screening the pipeline and lifecycle half

  • “How did a model get from a training job into production?” You want a path with a gate in it: a registry entry, an approval, a deployment that reads from the registry. If models were downloaded and uploaded by hand, the platform was a compute provider rather than a lifecycle.
  • “What did you do about local development?” The gap between a laptop and the managed environment is where a great deal of time disappears. Experienced engineers have a local container story and test as much as possible before paying for a training job.
  • “What broke when you scaled the endpoint?” Cold starts, model loading time, memory limits on the chosen instance, and concurrency behaviour. Anybody who has served real traffic has met at least two.

What it pays, and the certification question

Indicatively £75,000 to £115,000 permanent, with day rates from about £550. Roughly 230 UK employers name it in the pages we index, which understates it — a great deal of use is internal and never appears in an advert.

On certification: treat it as evidence that somebody learned the surface area, which is genuinely useful for a platform this broad, and not as evidence they have run anything. The differentiating questions are the cost and networking material above, because those are the parts a certification syllabus covers thinly and production covers relentlessly.

The cheaper hire that is often correct

If your actual need is to get models trained and served reliably rather than to use this particular platform, the platform is an implementation detail. A strong MLOps engineer will learn the relevant components in a few weeks and bring lifecycle judgement that does not depend on any vendor — and the pool is larger.

Hire specifically for the platform when the estate is already large enough that navigating it is the job: many accounts, strict networking, a compliance regime, and enough spend that cost engineering pays for itself. That is a real and well-paid role, and it is not the same as the one most adverts describe. If the work is principally about the lifecycle rather than the account, say so and widen your field considerably.