Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path →

FDE vs other roles/ vs Solutions Engineer

FDE vs Solutions
Engineer & Architect

These three titles sit closest together, get swapped most often in job ads, and lead to the most disappointing career surprises. One question separates them cleanly — and there is a 30-second test that tells you which one a job posting really is.

One question separates all three

After the contract is signed, who is accountable for the thing running in production at that customer?

Solutions / sales engineer: not you — you hand off. Solutions architect: you designed it, someone else runs it. Forward deployed engineer: you, until you have deliberately handed it to the customer’s team.

Everything else — travel, demos, customer meetings, technical depth — is shared. All three are customer-facing. All three do demos. All three need to explain a system to a sceptical stranger. Sorting them by “how technical” is the classic mistake, because a senior solutions architect at a cloud provider can be extremely technical and still never own production.

The 30-second posting test

Roughly 30% of jobs advertised with the FDE title are pre-sales-shaped. That is not a scandal — it is a labelling problem you can screen for.

An analysis of a thousand FDE postings found the title splits about 60% builder, 30% pre-sales-shaped, 10% internal.¹ The relabelling is rational: “forward deployed engineer” attracts engineers in a way “sales engineer” no longer does. So screen the text, not the title.

Search the posting for “quota”, “variable”, “OTE”, “bookings”, “pipeline”

Any hit means the comp is partly tied to sales outcomes. That is a legitimate, well-paid career — it is simply not the builder FDE job, and the interview and the day-to-day both differ.

Find the verb attached to “deploy”

“Deploy the solution into the customer’s environment and own it through go-live” is real. “Deploy compelling demos” is pre-sales prose. If “POC” appears more often than “production”, you have your answer.

Look for the feedback loop

Real FDE roles describe carrying learnings back into the product — roughly a third of the job at a frontier lab.¹⁰ A posting with no product-feedback language is describing either pre-sales or a billable-hours services role.

Ask about on-call in the interview

“Who gets paged when this breaks at 2am six months from now?” The answer separates ownership from advice faster than any question about tech stack. If nobody can answer, nobody owns it.

Pre-sales work at a good AI company can out-earn a builder FDE role in a strong year, and the travel is often lighter. The failure mode is only the mismatch: taking a pre-sales job expecting to build, or vice versa.

A deal, followed end to end

The cleanest way to see the handoffs is to watch one enterprise deal from first call to renewal.

Two consequences of this timeline are worth internalising if you are choosing between the roles. First, the SE’s work is judged in weeks and the FDE’s in quarters — different feedback cadences suit different temperaments. Second, the FDE inherits every promise made earlier in the timeline. The demo that skipped the hard integration, the SOW clause that says “95% accuracy” with no definition of accuracy — those become your problem. Good FDEs get involved before the ink dries.

Moving between them

SE / SA → FDE

• You already have the scarcest half: customer nerve, demo craft, stakeholder reading.
• Gap to close is production engineering: tests, CI, error handling, idempotency, on-call thinking.
• Build one thing that runs unattended for a month and prove it.
• Expect a real coding loop — incremental coding and debugging rounds are standard.²⁵

FDE → SE / SA

• Straightforward, and sometimes a deliberate lifestyle move: less ownership, less 2am.
• Comp can rise in a good year via variable pay, and fall in a bad one.
• What you will miss: seeing the thing actually get used.
• What you will gain: bounded weeks and a much shorter feedback loop.

If you are coming from pre-sales, these are the reps

Demo-grade code and production code diverge at exactly four places: idempotency, retries, verification, and reconciliation. Each is a coding challenge here with hidden tests.

The picture: one deal, four lanes

Worked example: the “95% accuracy” clause, step by step

The page warns about a SOW that says “95% accuracy” with no definition of accuracy. Here is what an FDE does with one. Say the deployment routes incoming invoices to the right approval queue. The golden set and the scores are illustrative; the arithmetic was computed.

Steps 4 and 6 are the trap. Version 1 passes the contract and still fails the customer, because the overall number hides the slice that matters. Nobody in the sale did anything wrong by sales standards: “95% accuracy” is a fine thing to promise in a demo. It only becomes a problem when nobody defines it before signature. Step 8 is why you size the high-value slice up front. With 40 cases, a single error is worth 2.5 points, so the result jumps around with every run. A larger high-value set gives the gate steadier readings. This is the concrete version of “good FDEs get involved before the ink dries”: draft steps 1, 2 and 7 for the SOW, and the go-live conversation becomes a measurement instead of an argument.

Cost and trade-offs: cadence, ownership and pay shape

Here Case is the role or the move, Time is when your work is judged, Space is what you still hold after signature, and Why is the pay shape and its catch.

What variable pay does to a year: on-target earnings (OTE) is base plus variable at 100% of quota. Take an illustrative $200K OTE at a 70/30 split: $140K base and $60K variable. Paid linearly, with no accelerators or caps, 50% attainment pays $170K and 150% pays $230K. Real plans add accelerators, caps and clawbacks, so read the plan document itself. A builder FDE’s base does not move with bookings. Their variance sits in the equity instead. So the SE’s pay is uncertain year to year but readable on the plan document. The FDE’s is steady in cash and uncertain in the part you cannot read off any document. Which kind of uncertainty you can live with is a fair way to choose between the two.

Common mistakes

• Reading the title, not the comp lineAbout 30% of FDE-titled jobs are pre-sales-shaped. “Quota”, “OTE” or “bookings” in the posting settles it faster than anything else in the ad. That is not a verdict on the job, only on which job it is. Pre-sales can be a strong career; the mistake is taking it while expecting to build.
• Sorting the roles by how technical they areA senior architect can out-design most engineers and never own production. Ask who is accountable after signature instead. Depth is shared across all three roles. Ownership is not.
• Shipping demo-grade code as productionDemo code and production code part ways at idempotency, retries, verification and reconciliation. A demo that runs once on sample data has tested none of them. Coming from pre-sales, these four are the reps to do first: each is a challenge on this site with hidden tests.
• An FDE who never reads the SOWThe acceptance criteria live there. An undefined “95% accuracy” becomes your problem at go-live, as the worked example shows. Ask to review the criteria before signature. If you arrive after it, propose the definition in week one, in writing, and get the customer to agree to the golden set before you build against it.
• Demoing past the hard integrationA bake-off built on sample data can skip the system the customer actually runs. If it did, say so in the handoff, so the deployment plan starts from the real integration, not the demo.

Which would you pick?

Three situations. Pick the side you'd actually build — the explanation follows.

The contract is signed. Who is accountable for the thing running in production at that customer?

That single question is how the page separates all three roles: the sales/solutions engineer hands off, the solutions architect designed it but someone else runs it, and the FDE owns it until a deliberate handover. Everything else — travel, demos, customer meetings, depth — is shared between them.

You designed the architecture, the customer's team implements and operates it. Which role is that?

Design ownership without production ownership is the architect position on the page's axis. An FDE would still be accountable for it running, and a solutions engineer would have handed off before implementation began.

How should you read a job ad that mixes all three vocabularies?

Because the shared surface is so large, titles are weak signal and the page reduces the ad to one question. Matching on title tells you about the company's naming habits rather than about what you would be accountable for on the Monday after launch.

Quick answers

What is the difference between a forward deployed engineer and a solutions engineer?

A solutions or sales engineer supports the sale — demos, proofs of concept, technical answers — and hands delivery to someone else, usually with a variable compensation component tied to bookings. A forward deployed engineer takes over after the contract and owns the software running in the customer’s production environment, including adoption and the evidence used at renewal.

Is a forward deployed engineer a sales role?

Builder FDE roles are not sales roles — they own production code and are measured on adoption rather than pipeline. However, an analysis of 1,000 postings found roughly 30% of jobs advertised as FDE are pre-sales-shaped. The fastest screen is compensation structure: any quota, OTE or variable-on-bookings language means the role is pre-sales-shaped whatever the title says.

What is the difference between a solutions architect and a forward deployed engineer?

A solutions architect designs the system and advises the people who will run it; a forward deployed engineer builds and operates it inside the customer’s environment. Architects are often deeply technical, so “how technical is the role” is the wrong discriminator — production accountability is the right one.

Can a solutions engineer become a forward deployed engineer?

Yes, and they start with the scarcer half of the skill set. The gap is production engineering discipline: tests, CI, error handling, idempotent integrations, and thinking in terms of on-call. The most convincing proof is one system you built that ran unattended for a month, plus readiness for a real coding loop — incremental coding and debugging rounds are standard in FDE interviews.

Sources

Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.

Cited on this page

• Bloomberry — “I analyzed 1,000 forward deployed engineer jobs” (Nov 2025) — posting growth, builder/pre-sales/internal split. bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/
• Anthropic — Forward Deployed Engineer, Applied AI (JD) — 40/30/30 split; MCP servers, sub-agents and agent skills as deliverables. jobs.menlovc.com/companies/anthropic/jobs/69674588-forward-deployed-engineer-applied-ai
• Exponent — Sierra Agent Engineer interview guide — www.tryexponent.com/guides/sierra-agent-engineer-interview

NextFDE vs Consultant →Next on the “FDE against every adjacent role” ladder · rung 5 of 7

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

More Handbooks

• The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
• The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
• 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
• 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
• 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
• The Agent Evaluations HandbookA self-contained handbook on evaluating AI agents — theory, interactive widgets, and practical guidance. Trajectory evals, tool-use scoring, LLM-as-judge, observability, and reliability for PMs, engineers, and founders.Read →