FDE vs SWE, Solutions Engineer, Solutions Architect and Sales Engineer

Five titles on the same job board

Search a job board for customer-facing engineering roles and five titles come back side by side: software engineer, solutions engineer, sales engineer, solutions architect, forward deployed engineer. All are technical, four face customers, and the postings borrow each other's phrases. Misread them and you prepare for the wrong loop, or take a job whose days look nothing like the one you imagined. So what separates them, if not the words in the posting?

Two questions that sort the roles

Job descriptions sort these titles slowly, because they list activities and the activities overlap. Two questions about accountability work faster. Who are you accountable to? And are you accountable before the contract is signed or after it?

Treat the table as the usual meaning of each title in software companies. It is no standard, and the names are used loosely: some companies call their FDE job "solutions engineer", and some solutions architects build plenty. When you read a posting, look past the title for two phrases. Does the role write production code, and is it on the hook after the sale?

Where the product engineer and the FDE part ways

The software engineer comparison deserves the most attention, because this track assumes you are coming from that job. A product engineer owns a surface, say the billing service, for every customer who touches it. An FDE owns one customer outcome and writes whatever code it takes to get there: an ingestion job today, an auth integration tomorrow, an eval suite on Friday. The product engineer goes deep on one system. The FDE goes wide across many, inside someone else's constraints.

You might object that plenty of product engineers talk to customers. They do, and that experience will matter for your why-FDE answer. The difference is where the accountability lands. When a product engineer's customer has a strange data setup, the usual answer is a ticket, a workaround or a roadmap discussion. When an FDE's customer has one, it is the FDE's problem this week, because the outcome they are measured on does not move until it is fixed.

The problem that arrives after signature

The post-sale window is the part people underestimate. Say a fictional logistics company signed for an AI dashboard that reports on-time delivery. A sales engineer demoed it on a clean sample. Three weeks into the deployment, the operations team says the on-time number is wrong. It turns out their warehouse system logs a returned parcel as a second delivery, so the denominator is inflated.

Nobody on the sales side had to know that, since the quirk only shows up in production data. The FDE does have to know, because data quality, integration failures and whether anyone uses the dashboard are now their problem. The two roles sit on different sides of the signature, and the FDE's side is where the customer's real data finally arrives.

Comp, levels and career ladders also differ by company and change often enough that this track does not quote figures. Public pay data for these roles conflicts between sources. Ask the recruiter which ladder the role sits on and how promotion is assessed.

What the sources show about the boundaries

Within Palantir, where the role began, the split is drawn by how many customers and capabilities you own. A secondary summary of Palantir's blog contrasts product developers ("one capability, many customers") with forward deployed software engineers, or Deltas ("one customer, many capabilities"), and describes a separate Deployment Strategist role, "Echo", that works in Python, R and SQL as an analyst and generalist (Ophy's Palantir guide, secondary). Even inside one company, then, deployed roles differ in how much production engineering they carry.

The coding bar is the clearest sign that an FDE is an engineer first. For Scale AI, Aced reports the FDE loop holds the same bar as the software engineering loop, and that whether a candidate is placed as FDE or SWE is decided late in the process (Aced, medium-high confidence). Salesforce's Agentforce posting describes an engineer embedded with one enterprise customer, writing the code that ships an agent (Built In posting).

The customer-facing half shows up in what the behavioral rounds look for. Databricks' leadership and values round reportedly covers customer obsession and pushing back on a customer (Aced). Anthropic's reported loop has a values round with non-technical evaluators that looks for honest engagement with the mission, and a hiring-manager round asking why an LLM fit a problem and how you validated it (Aced; medium confidence, sources conflict on the loop).

Building a why-FDE answer that survives pushback

Prepare the coding rounds to the software engineering bar. If a company may slot you as SWE or FDE late, as reported for Scale, a weaker coding performance can decide the slot for you.

Then build a "why FDE" answer that would survive a skeptical hiring manager, in three parts. Start with what you have already done that resembles the job: one concrete episode where you worked directly with the person using your software, changed course because of them, and shipped, with the change named. Then say what pulls you toward the role as a specific preference stated plainly, for example that you would rather own one outcome end to end than one component for everyone, that you like working inside messy constraints, or that you want to see who uses what you build. Last, say what you give up and why you accept it: less depth in one system, travel or on-site time if the posting says so, and context switching across integrations. Naming the cost is what shows you know the job.

Here is a weak first draft from a fictional candidate: "I love customers and I'm tired of being a cog on a big product team." The first half is a feeling with nothing to score. The second half disparages the job the interviewer's colleagues do. The rewrite: "On my last team I spent two weeks with our support leads rebuilding the refund tool after watching them work around it; that was the most useful thing I shipped all year, and I want a job where that is the main work instead of the exception."

Also check which deployed role you are actually applying for. At Palantir, per the Ophy summary, the Delta and Echo roles sit side by side, and a candidate who prefers analysis and stakeholder work to production engineering may fit Echo better. Applying to the wrong one means preparing for the wrong loop: the reported Echo decomposition prompt, detecting illegal firearms in postal packages, is as much a strategy and analysis problem as a design one (reported across the Palantir write-ups collected for this track, including Aced and Ophy). Keep one sentence ready on how FDE differs from solutions engineering that does not run either one down. "Solutions engineers win the technical evaluation; I want to own what happens after it" works.

How this shows up in the interview

The comparison is tested head-on in recruiter and hiring-manager screens, as "why FDE and not a regular engineering role?" or "what do you think the difference is between this and solutions engineering?". It is tested sideways in the behavioral round, where a pushback or ownership story reveals whether you saw the post-sale problems as yours.

To probe, the interviewer takes your stated reason and presses on its cost. "A lot of this job is meetings and access requests, not code. How do you feel about that?" Or: "You'd be on one customer for months. What if it's a dull one?" They are checking that you understand the trade. The Databricks and Anthropic rounds above both look for evidence of customer judgement, so a candidate who treats every customer-facing role as the same job gives vague answers here.

What earns credit is an answer that names the trade and accepts it. One sentence that works: "I'd take this over a product role because I want to be accountable for whether a customer's process actually changes, and I'm fine trading some depth in one codebase for that."

Check yourself

• A posting says the role "partners with sales on technical evaluations, builds proof-of-concept demos and hands off to implementation after close". Which role is this, whatever its title? Answer: A pre-sales solutions or sales engineer. The window ends at signature and the work stops at prototypes.
• What does the reported Scale AI late FDE-versus-SWE placement imply for prep? Answer: The coding bar is the software engineering bar. Weak coding can move you to the other track or out of the process.
• A fictional dashboard is wrong because the customer's warehouse logs returns as deliveries. Whose problem is that after signature, and why? Answer: The FDE's. Data quality and integration failures in the customer's environment are part of the outcome the FDE owns.
• What makes "I'm tired of being a cog" a poor reason? Answer: It is a feeling plus a dig at the roles your interviewers' colleagues hold. A concrete episode and a stated trade-off carry the signal instead.