FDE vs solutions engineer vs ML engineer: what's the difference?

Forward deployed engineer, solutions engineer and ML engineer postings often list the same stack. Some sit in the same team. They are still different jobs, and it pays to know which one you're applying for.

The quickest way to tell them apart is to ask when each role shows up in a customer deal, and what it leaves behind.

How do FDE, solutions engineer and ML engineer roles compare?

The three roles split by timing. The solutions engineer works before the sale, the FDE mostly after it, and the ML engineer away from any one deal. Everything else follows from that.

The FDE interview column comes from the eight loops summed up on the prep page. The table is the clean version. Real postings mix columns, and the sections below show where.

What does an FDE do that a solutions engineer doesn't?

An FDE writes production code in the customer's systems and owns the result. A solutions engineer stops earlier. In the words of the Illinois Tech guide to the FDE role, the solutions engineer "often builds proofs-of-concept with sample data and rarely writes production code on the customer's systems."

The handoff is where the difference shows. A demo runs on clean sample data in a sandbox. Production runs on the customer's data, behind their security team, next to systems older than the product. Closing that gap is the FDE's job.

The line blurs at some companies. When a proof of concept runs deep into the sales cycle, the FDE ends up doing pre-sales work too. That isn't wrong. You just want to know the split before you sign, and how to read an FDE job posting covers how to ask for it.

How is an FDE different from an ML engineer?

An ML engineer goes deep on models in an environment the company controls. An FDE goes broad across systems in an environment the customer controls.

The ML engineer's core skills are model architecture, training pipelines and evaluation. The work is internal, the iteration cycles are long, and success is accuracy on a benchmark. The FDE's core skills are systems integration, deploying APIs, data pipelines and the customer's platforms. The stack changes with every customer, the timeline is short, and success is how fast the customer gets value.

Andrew Ng's AI Engineering Skills Map, published by DeepLearning.AI in August 2026, names four skills: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build.

The map is a useful lens for reading both kinds of posting. An FDE posting puts its weight on building and deploying applications, in someone else's systems. An ML engineer posting adds depth on the model itself.

Each path carries a risk. Deep specialization can narrow an ML engineer's options over time. A customer-facing schedule can pull an FDE away from core engineering. Neither is a reason to avoid the role, but both are worth asking about.

How can you tell from a job posting which role it really is?

Read the responsibilities, not the title. The verbs tell you which job it is:

• "Partner with the sales team", "demos", "RFPs", "proof of concept": solutions engineering, whatever the title says.
• "Time-to-value", "customer onboarding", "account health": closer to technical consulting than engineering.
• "Train", "fine-tune", "benchmark", "research": ML engineering.
• "Write production code in customer environments", a named stack, "own the deployment", on-call: forward deployed engineering.

The FDEBench board gives you a first read from the title. Every listing sits in a role family. Solutions / Implementation collects titles with solution, implementation, customer engineer or field engineer in them. Applied AI / ML collects AI and ML titles. Core FDE holds the plain forward deployed titles.

A family based on the title is only a first read. A "Technical Solutions Engineer (FDE)" can be a real build role, and some FDE titles are pre-sales jobs. The posting text settles it.

Which role should you go for?

Choose by what you want to own. If it's a model's quality, aim for ML engineering. If it's the sale, solutions engineering. If it's a running system at a customer, FDE.

Each starting point has its own gap. If you come from solutions engineering, you already know the customer room. The gap is production code and system design. If you come from ML engineering, the gap is breadth: integrations, cloud platforms and explaining a system to people who don't care how it works.

The FDE loop tests both halves, so practice the half you've done least. For the customer side, start with the rubric question on a stakeholder who thinks the model ‘connects to the internet’. Then try a customer whose deployment ‘can reason about the problem but never actually does anything’.

For the design side, try Netflix search for ‘that show with the guy from Breaking Bad’, which has a full rubric. If you come from pre-sales, arguing both sides of adding a tool-integration protocol on top of REST tests the skill the pitch round needs: making a case and defending it. If you come from ML, a question like why LLM training parallelizes and where it breaks will feel familiar. The FDE loop spends more time on breadth, so practice the customer and design questions first.

The round-by-round guide is in the forward deployed engineer interview, and the customer round has its own guide. For scoping questions, use the Product & scoping filter on the prep page. If you want the role itself defined first, read what a forward deployed engineer is.