Insights_

Eleven interviews in, and the Founder still could not tell us which of the Candidates was any good. He has hired Backend, Frontend and Platform Engineers for a decade. Put a Machine Learning Engineer in front of him and his usual instincts stopped working.

If you are making your first ML hire without an ML person in the building, you are in the same position, and you can still run a credible interview loop. You just have to test different things.

Your Engineers have started apologising for the deploy process. Someone built the CI pipeline in a fortnight eighteen months ago and nobody has touched it since, staging broke again on Tuesday, and the only person who really understands the Terraform is also your strongest Product Engineer.

That is usually the moment a Founder starts typing “Platform Engineer” into a job board. It is the right instinct, and it is still too early to write the advert, because this hire only works if you have decided what the person is actually there to do.

Two job descriptions land on your desk and they read almost identically.

Both talk about customer-facing work, both mention writing code, both promise to shorten time to value. One is titled Solutions Engineer. The other is titled Forward Deployed Engineer.

Hiring the wrong one is expensive, and most teams only work out which mistake they made about six months in, when the person they hired is quietly doing a job nobody asked for.

Three years ago, hiring an ML Engineer meant finding someone who could train a model.

Today, most ML Engineers being hired into SaaS teams will never train anything from scratch. They will pick a foundation model, wrap it in retrieval, build an evaluation harness, and then spend eighteen months making the whole thing reliable enough to put in front of a paying customer.

The title has not changed. The job underneath it has, and most hiring processes have not caught up.

The strongest Engineer you hire this year is not reading your job advert.

They are not unhappy enough to look, and they will not become unhappy on your schedule.

If your hiring plan depends on good engineers applying, you are fishing in the small part of the market that happens to be available and hoping the best of them turns up.

The round has landed.

The plan says you’ll double the engineering team in a year, and everyone is looking at you to make it happen.

So where do you actually start?

And how do you grow fast without breaking the team you already have?

You’ve raised, and now you can finally hire the engineers you’ve been promising yourself.

But a blank headcount plan is deceptively hard.

Who comes first?

And who can wait a couple of quarters without slowing everything down?

You ran a tight process, everyone loved the candidate, you sent the offer – and they went somewhere else.

It’s one of the most expensive moments in hiring, and it’s more avoidable than most teams think.

So why do strong Engineers say no, and how do you tip more of them to yes?

You’ve closed the round.

The board deck has a hiring plan with a number on it, and that number is bigger than your team has ever been.

Now you have to turn funding into shipped product – fast – without the six months of firefighting that usually comes with scaling an engineering team.

Hiring a machine learning engineer is one of the harder roles to get right.

The title covers a wide range of people – from researchers who live in papers and prototypes to engineers who ship models into production at scale – and the cost of a mis-hire is high.

Get it wrong and you end up with impressive demos that never make it past a notebook, or solid software engineers who can’t reason about why a model is quietly degrading in production.

Most machine learning hires that disappoint were not doomed by the calibre of the engineer. They were doomed by the state of the data infrastructure the engineer inherited on day one.

A brilliant ML engineer dropped into a company with no reliable pipelines, no feature store, no clean training data and no way to monitor a model in production will spend months doing plumbing before they build anything, and will often leave before they get the chance.

The best software engineers rarely fail your technical interview – they quietly decline to finish it. They have options, they are usually employed, and they judge a company by how it treats them during the hiring process.

A loop that is disrespectful of their time, riddled with irrelevant puzzles, or designed to catch them out tells them exactly what working for you would be like. The result is that many teams unknowingly filter out the very people they most want to hire, while congratulating themselves on a rigorous process.

The first Forward Deployed Engineer a SaaS company hires is rarely the reason the function succeeds or fails – the decisions made before that person arrives are.

By the time a founder is reviewing CVs, most of the outcome has already been determined by how the role was scoped, calibrated and sold.

Forward Deployed Engineers sit at an awkward intersection of engineering depth and customer instinct, and that combination is easy to get wrong when you are hiring under pressure to close enterprise deals.

If you’ve been paying attention to hiring trends in SaaS and enterprise tech lately, one thing is clear: Everyone is looking for Forward Deployed Engineers (FDEs).

From early-stage startups to global software giants, the role has exploded in popularity – and for good reason.

But what’s behind the surge? Why are FDEs suddenly one of the most sought-after hires in SaaS?

If you’ve spent any time around enterprise SaaS companies – especially those selling complex or data-driven products – you’ve probably come across the term Forward Deployed Engineer (FDE).

It’s a title that sounds part engineer, part consultant, part problem-solver. But what do Forward Deployed Engineers actually do?

Let’s unpack it – and explore why this role has become so important in modern SaaS go-to-market teams.

Forward Deployed Engineers (FDEs) have fast become one of the most in-demand hires in SaaS – especially for companies building data, AI, cybersecurity, and infrastructure products.

But here’s the challenge: FDEs are rare, hybrid operators, combining engineering, customer-facing skills, problem-solving, and product insight.

If you’re wondering, “How do I recruit for a Forward Deployed Engineer?” – this blog will walk you through exactly what to look for and how to hire one successfully.