FDE vs sales engineer: the difference is who takes the 2am call

Three months after deployment, the system goes down at 2am. Who has to get up and fix it? Scaler’s comparison of FDEs and solutions engineers answers without hesitation: recovery is owned by the FDE, not the SE.

That answer captures almost the entire difference between two jobs that are often lumped together. Both roles work with customers, both need a solid technical grasp, and both have to talk to people who do not write code.

If you want to move into an FDE role, or you already hold one and are unsure where your job ends, the question to ask is not “do I meet customers?” The right question is: when the live system breaks, who gets woken up?

The line is the signature

Both roles face the customer, but the core of each job falls on a different side of the signature. A solutions engineer works within the sales cycle, while the FDE’s main work only begins after the contract is signed, as Scaler describes it.

FDE Academy draws a similar line: FDEs operate mainly once the product has been sold, SEs in pre-sales or early implementation.

Christian & Timbers put it more bluntly: a sales engineer’s core task, proving that the product solves the customer’s problem, is largely complete when the customer signs. An FDE’s responsibility extends all the way to results in production.

What changes hands at signing, then, is not the customer but responsibility for the live system. Christian & Timbers put exactly that in the headline of their analysis: the difference is production ownership.

Why the demo works and production breaks

The Pragmatic Engineer stresses that FDEs are far more hands-on than sales roles: they write code directly on the customer’s infrastructure and use the customer’s tools. That is where the gap between demo and production shows.

Picture an agent that reads internal documents to answer employees’ questions. In the demo, it reads a folder of sample documents, answers smoothly, and the customer nods. In production, the agent has to respect permissions, so that staff in department A cannot read department B’s contracts.

In that scenario, the documents also sit in a document management system that has been running for years, with an API nobody remembers how to use. The customer’s security team wants to know where the data goes and where the logs are stored. Then one day someone uploads a scanned file with no text layer, and the agent’s answer is completely wrong.

Paraform describes the FDE as the person who puts production code into the customer’s environment and is accountable for the results there. A demo only has to work once in front of the customer. Code an FDE puts their name to has to work even on the days nobody is paying attention to it.

Who keeps the promise after the sale?

If the sales engineer sells a promise, someone has to turn that promise into a system, and someone has to keep it running over the long term. Paraform, advising startups on which role to hire, sums up the chain in three beats: the SE sells the vision, the FDE builds it, the CE (customer engineer) maintains it.

That position in the middle of the chain explains why an FDE is not simply a sales engineer who codes more. According to The Pragmatic Engineer, the distinctive mark of the FDE is working with customers while also contributing back to the product itself, something sales-side roles do not do.

At the company that pioneered the model, deployment is no niche. Valletta Software counted Palantir’s open job listings on 8 September 2026 and found that 77 of 310 positions were forward deployed, roughly a quarter.

Five questions show where the two roles part ways:

Question	Sales / Solutions Engineer	FDE
When does the main work happen?	In the sales cycle, before signing or early in implementation	After signing, through to results in production
What is the technical work for?	Proving the product solves the customer’s problem	Writing production code on the customer’s infrastructure and tools
Where does responsibility end?	Largely done when the customer signs	Extends to live results
What if the system fails after deployment?	The core work was finished at signing	Owns the recovery
Place in the sell, build, maintain chain	Sells the vision	Builds it, then the CE maintains it

The title is no longer enough to go on

The most practical consequence of this line shows up in job ads. Bloomberry, after analysing 1,000 listings, recorded a 1,165% year-on-year rise in FDE postings, mostly at small companies. Getperspective found the hiring wave has spread from frontier labs to vertical AI startups and hyperscalers such as Google.

When a title gets hot, it gets attached to many different jobs. Getperspective notes that employers are quietly renaming solutions architect roles as FDE to compete for the same pool of candidates, and concludes that the wording describing the scope of work matters more than the title.

Christian & Timbers look at it from the company side: bad hires usually start with the role description, before they surface in the candidate list. When a job ad describes a sales engineer’s work under an FDE label, applicants are misled too.

So look for words like go-live, production, integration, on-call or “own end-to-end”. If the ad talks mostly about demos, POCs, supporting the sales team and deal close rates, it is most likely a sales engineering role, whatever it is called. That role is not a bad one, but it trains a different set of skills.

Rewrite one line of your CV

On your CV, do not write “worked directly with customers”, because a sales engineer could write that too. Take the hypothetical document-lookup agent above as an example. The line everyone writes is:

Before: “Worked directly with customers to deploy AI solutions.”

After: “Took an internal document-lookup agent to production, integrating with a legacy document management system and department-level permissions; was on call after go-live and personally resolved an incident where scanned files without a text layer produced wrong answers.”

If you have ever contributed back to the core product from a problem on the customer’s side, add one more clause, because that is exactly the point The Pragmatic Engineer uses to separate FDEs from sales roles.

The question to take into the interview

In the final round, ask the interviewer one question: three months after go-live, if the customer’s system goes down at 2am, who takes the call, and does that person have the access to fix code on the customer’s infrastructure?

If the answer is that the incident gets handed to another team, you will not own production, whatever the title says. If the answer is “you”, along with the access to fix it yourself, that is an FDE’s seat.