FDE vs Solutions Engineer vs Sales Engineer

Three titles, one blurry picture. Sales engineers, solutions engineers and forward deployed engineers all sit between your product and your customer. All three are technical. All three talk to customers. Companies use the titles loosely, and candidates do too.

But the jobs are different, and hiring the wrong one is an expensive way to learn that. This guide lays out what each role does, when in the customer lifecycle it shows up, how to tell them apart in a job description or an interview, and how to decide which one you need right now.

The Short Answer

• A sales engineer helps you win the deal. They work before the contract is signed. Demos, technical discovery, objection handling, proofs of concept.
• A solutions engineer designs how your product fits the customer. The title varies most of the three. Often it means the same thing as sales engineer. At other companies it means a more consultative architect who spans the late sale and early implementation.
• A forward deployed engineer makes the product work in production for that customer. They work mostly after the contract is signed. They write real code inside the customer’s environment and stay until it delivers value.

The simplest test comes from Henley Wing Chiu’s analysis of about 1,000 FDE job postings. If the role carries a quota or commission, it is a sales engineering role, whatever it is called. If the person writes production code and stays on site after go-live, it is an FDE role.

The Comparison Table

	Sales Engineer	Solutions Engineer	Forward Deployed Engineer
Main goal	Win the technical decision	Design a solution that fits the customer	Get the product working in production and delivering value
When they show up	Pre-sale, through signature	Late pre-sale into early implementation	Mostly post-sale, for weeks to months
Writes production code?	Rarely. Demos and configuration	Sometimes. Prototypes and reference architectures	Yes, inside the customer’s systems
Works on real customer data?	Usually not	Sometimes, often sample or anonymized data	Yes, that is the job
Carries a quota?	Often	Sometimes	Rarely
Typical output	Demo, POC, technical win	Solution design, architecture, implementation plan	Shipped integrations, workflows, evals, running systems
Measured by	Technical win rate, deal influence	Adoption, value realized, deal size	Customer outcomes, retention, expansion
Feeds the product?	Feature requests from deals	Patterns across accounts	Field learnings and often code back into the product
Time per customer	Hours to weeks, across many deals	Weeks, across several accounts	Weeks to months, on one or a few accounts

A note on the middle column. Sales tooling company Vivun’s glossary of these roles says many organizations use these titles interchangeably, and suggests the differences are mostly emphasis. Sales engineering leans on technical depth and validation. Solution consulting leans on business outcomes and can extend into implementation and adoption. That matches what we see. When you hire a “solutions engineer,” read the job description, not the title.

The Sales Engineer

The sales engineer is the technical half of the sales team. They pair with account executives, run discovery calls, build tailored demos and handle the hard technical questions in a deal. When the buyer wants a proof of concept, the sales engineer usually builds it.

Their world is the pipeline. They work many deals at once, and a deal is done for them when the contract is signed. Vivun lists metrics like technical win rate and demo-to-win ratio as typical measures. That tells you where their attention goes.

Hire one when: your product works well out of the box, deals stall on technical questions, and your account executives cannot answer them alone.

The Solutions Engineer

This is the slippery one. At some companies a solutions engineer is a sales engineer with a nicer title. At others, especially in enterprise software, it is closer to a solutions architect: someone who designs how the product fits into the customer’s stack, writes the implementation plan, and advises the customer’s team as they build.

The clearest description we have read of the difference between this role and an FDE comes from OpenAI, which employs both. As reported by The Pragmatic Engineer, OpenAI’s Solutions Architects are more advisory. They rarely write code on customer infrastructure and usually build proofs of concept on anonymized or offline data. OpenAI’s FDEs, by contrast, write code directly on customer systems and handle much more ambiguity.

Hire one when: your customers have capable engineering teams who will do the build themselves, and what they need from you is a good design and expert advice.

The Forward Deployed Engineer

The FDE was invented at Palantir, where the company’s own Dev versus Delta post describes the job as working with one customer and being measured by the impact on that customer’s goals. FDEs scope the problem, get into the customer’s data and systems, build what is missing, run it, and feed what they learn back into the core product.

a16z partner Joe Schmidt’s essay Trading Margin for Moat explains why AI companies want this role so badly. AI agents only work once they are wired into a company’s real systems and permissions, and most enterprises cannot do that wiring themselves. Someone has to. Schmidt also recommends keeping implementation people closely tied to account executives but without quotas, so their incentive is the customer’s success.

Hire one when: your product needs real engineering work to deliver value in each customer’s environment, your customers cannot or will not do that work themselves, and you want those learnings to shape your product.

For more on the role itself, read What Is a Forward Deployed Engineer?.

Where the Roles Overlap and Collide

The lines blur in practice, and that is fine. Many great FDEs started as sales or solutions engineers. LeadDev’s piece on the rise of the FDE quotes recruiters who see sales engineers with deep industry knowledge as strong candidates for FDE roles.

The collisions are what hurt. Three we see often:

1. FDEs pulled into pre-sale work. It is tempting to put your best technical person on every big demo. But an FDE who spends half the week on POCs is not delivering for the customers you already signed. It is one of the most common mistakes we see. Some pre-sale scoping is healthy. A standing demo duty is not.
2. Sales engineers rebranded as FDEs. The Bloomberry analysis found that roughly 30% of postings titled FDE were really sales or solutions engineering roles, often quota-carrying. If you do this, you will attract the wrong candidates and confuse the right ones.
3. Solutions engineers expected to build. If you hire an advisory architect and then expect them to write and run production code on a customer’s systems, both of you will be unhappy.

A Worked Example: Which One Do You Need?

Here is an illustrative scenario, not a real company.

Imagine you run a 25-person startup selling an AI tool that drafts responses to procurement questionnaires for large manufacturers. You have six customers and a pipeline of twenty more.

Look at where things are breaking.

• Deals are slow because buyers ask detailed security and integration questions your founders answer on every call. That is a sales engineering problem.
• Customers sign, then take three months to go live, because their document stores are a mess of SharePoint sites, scanned PDFs and an old ERP system. Your product works great in the demo and poorly on their data. That is an FDE problem.
• Two of your customers have strong internal IT teams who want to build the integration themselves and just need a reference architecture. That is a solutions engineering need, and your FDE or a founder can likely cover it for now.

In this scenario your first hire should be an FDE. Slow deals hurt, but customers who sign and never get value hurt more. They do not renew, and they do not refer. Your founders can keep carrying the pre-sale technical calls for another quarter. Once go-lives are reliable, a sales engineer becomes the next hire.

Flip the facts and the answer flips. If your product is self-serve, customers go live in a day, and deals die in technical evaluation, hire a sales engineer first.

Questions to Ask Before You Write the Job Description

• Will this person write code that runs in the customer’s production environment?
• Does their work start before or after the contract is signed?
• Will they carry a number?
• How many customers will they own at once?
• Where does their feedback go, and who acts on it?

Your answers will tell you which role you are hiring. Our JD generator can help you turn them into a job description that attracts the right people, and our guide on how to hire your first FDE covers what comes next.

Where We Come In

We only place forward deployed engineers, and we will tell you honestly if what you need is a different role. Every candidate we introduce has passed a technical screen and a live customer role-play, so you know they can both build and handle the room. You run the final interviews, and interviewing our candidates is free. Start here when you are ready.