The way first ML hires usually fail
It rarely fails at the interview. A capable machine learning engineer joins, and then discovers that the data they were hired to model is spread across systems that disagree with each other, that nobody can say authoritatively how the key metric is defined, and that the historical record needed to train anything either does not exist or cannot be reconstructed. They spend their first year doing data engineering. Some of them do it well. Almost none of them stay, because it is not the job they took, and the next employer will assume the gap on their record is theirs.
The organisation concludes that machine learning did not work for them. What actually happened is that a modelling hire was asked to solve an infrastructure problem, which is a scoping error made before the advert was ever written.
Five questions that tell you where you are
These are deliberately about the past rather than the future. Machine learning is a claim about predicting what has not happened yet, and an organisation that cannot describe what already happened is not in a position to make that claim.
Answer these honestly before advertising
Two or more uncomfortable answers is not a reason to abandon the plan. It is a reason to change the order of the hires.
What to hire instead
Where the foundations are not there, the effective first hire is the person who builds them: someone whose job is reliable pipelines, a trustworthy definition of the core entities, and the infrastructure a model will eventually be served from. On this board that work is advertised as ML Platform Engineer or ML Infrastructure Engineer, and it is a considerably easier search than the one you were about to run.
It is also better sequencing on its own terms. The infrastructure work has to happen regardless — the only question is whether it is done by someone who chose it or by someone waiting to do something else. Doing it first means the eventual machine learning hire arrives to a working platform, produces something within a quarter, and stays, which makes them cheaper to attract as well as more likely to succeed.
When the foundations are missing
- No reliable pipeline or single source of truth.
- Outcomes are not recorded in a usable historical form.
- Nobody currently owns the data the model would need.
When you are genuinely ready
- Pipelines exist and someone maintains them.
- You have labelled history and can reconstruct a past state.
- A named decision changes if the prediction is good.
If you are ready, scope it narrowly
An organisation that clears those questions should still resist advertising for machine learning in general. A first hire succeeds by delivering one thing that visibly works, which then funds everything after it — and a role scoped around a single named problem attracts better candidates than one scoped around a capability, because it tells them what they would actually be doing.
-
1
Pick the problem before the person
One prediction, one consumer, one decision that changes. If you cannot name all three, the scoping is not finished.
-
2
Agree what success looks like in six months
In terms of the business consequence, not the model metric. This is also the conversation that reveals whether your stakeholders expect something ML cannot deliver.
-
3
Borrow a specialist for one interview stage
If nobody in house can assess the work, one experienced practitioner for a single stage costs little and is far better than proceeding on impressions.
-
4
Consider a contractor for the first phase
Where the problem is genuinely uncertain, a short engagement that establishes whether it is tractable is cheaper than a permanent hire made on a guess.
Once the role is scoped, the rest — the three role shapes, what the market pays and how to interview for production work — is in how to hire machine learning engineers.
See what the market is offering
Both routes are worth comparing against live adverts before you commit to one.