How do I know if an FDE job is really a sales role?

Look for "partner with the sales team", demos, RFPs and proof-of-concept management in the responsibilities. If those fill the list and the technical section is vague, it's solutions engineering with an FDE title. Ask what share of the week goes to the sales cycle.

What does "travel up to 50%" mean in an FDE posting?

You'll spend up to half your time at customer sites. That's normal for embedded work if the posting also describes real building. If the travel is heavy and the technical section is thin, expect field consulting.

Should I avoid FDE roles at consulting firms?

No. FDE roles at consulting firms lean toward integration and system design, and model depth is a plus rather than a must. That suits plenty of engineers. Ask how the week splits between building and account work before you decide.

A small team sent to a customer together: often an engineer who builds, a product manager who owns the problem and a platform engineer who keeps integrations stable. It spreads work that one FDE would otherwise carry alone.

How to read a forward deployed engineer job posting

Two jobs can carry the same forward deployed engineer title and have little in common. One writes production code inside a customer's systems. The other runs demos for the sales team. The posting tells you which, if you know where to look.

Below: the signs of real FDE work, the red flags, the board's role families, how the employer changes the job, how FDE teams are organized and what to ask before you sign.

What are the signs of a real forward deployed engineer role?

A real FDE posting describes building and owning software in a customer's environment, in concrete terms. Look for these:

Production code in customer environments. The verbs are "build", "ship" and "deploy", not "support" or "advise".
A named stack. Specific languages, clouds and data tools, not "familiarity with modern technologies".
Ownership after go-live. Incidents, on-call, monitoring and a handoff to the customer's own team.
Outcome measures. Deployments that work and get used, not pipeline or quota.
A route back to product. What you learn in the field goes to the core engineering team.

A posting doesn't need all five. Two or three, stated plainly, is a good sign. None at all means the title is doing the work the description should.

What are the red flags in an FDE job description?

Four signs suggest the FDE title covers a different job:

"Partner with the sales team" in the responsibilities. That usually means demos, RFPs and managing proofs of concept. It's solutions engineering with an FDE title.
Vague technical requirements next to heavy stakeholder language. "Familiarity with ML models" beside five lines about relationships is a rebranded solutions role. Real FDE postings name their tools.
No technical ladder or mentoring. The job stops at senior, and there's nowhere technical to go next.
"Travel up to 50%" without technical depth to match. That's field consulting, not engineering.

None of these rules a job out. Each one tells you what to ask in the interview. For how these roles differ in what they ship and how they're measured, see FDE vs solutions engineer vs ML engineer.

What do the board's role families tell you?

The FDEBench board sorts every listing into a role family by its title, which gives you a first read before you open the posting:

Core FDE: plain forward deployed titles. Start here for build work.
Applied AI / ML: titles with AI, ML or agents in them. Expect more model work.
Data Engineering: data and analytics titles. Pipelines and platforms.
Solutions / Implementation: solution, implementation, customer engineer and field engineer titles. Check for the sales red flags first.
Field Architecture: architect titles. Design across a customer's systems.
Deployment Strategy: strategist and product owner titles. More scoping than code.
Leadership: lead, manager, director and head titles.
Early Career: intern, junior, entry and associate titles.

The family is a sort by title, so it's only a first read. A Solutions / Implementation listing can be real build work, and a Core FDE listing can be pre-sales. The signs and red flags above settle it.

How does the type of employer change an FDE job?

The same title means different work at an AI lab, a software vendor and a consulting firm. Roughly three kinds of employer hire FDEs:

AI labs want model-layer work: integrating LLMs, deploying models, building prompt systems. Expect them to test working fluency with models. Search the board for OpenAI or Anthropic to see what they post now.
Enterprise software vendors want platform integration, data pipelines and fast onboarding. ML depth is preferred, not required. Search the board for Snowflake or Databricks.
Consulting firms and startups want engineers who wire systems together and design how they fit. Model depth helps but isn't required. More of the week goes to account meetings and supporting the sales cycle. Try Deloitte or Accenture.

The biggest hirers on the board are Google, Databricks and Salesforce, out of 799 companies in all. For what each level pays, see forward deployed engineer salary.

How are FDE teams organized?

FDE work doesn't have to fall on one engineer alone. SVPG describes the model as sending "empowered engineers (and other product creators)" directly to the customer.

A useful way to picture it is a pod of three roles, each owning one loop:

The FDE owns the build: working code under the customer's real constraints.
A product manager owns the problem: framing it, translating for stakeholders and defining the outcome.
A platform engineer owns stability: integrations, data pipelines and the environment.

If the posting doesn't say who else is on the team, ask. When you're the only one, you carry all three loops at once, and each crowds out the others.

Ask how decisions get made, too. One write-up of FDE culture says the model relies on Auftragstaktik, the military idea of mission command. Senior leaders set only the high-level objectives, and the forward deployed team makes the other decisions. Find out how much your pod can change on site without sign-off.

Then ask about access, because it decides whether you can do the job. Full Stack Deep Learning's lecture on ML teams describes research-style teams with no control over the data and no data engineers, whose models rarely reach production. An FDE without production access is in the same spot. There's more on pods and handoff in how FDE teams work.

What should you ask in the final round?

Ask questions that turn the posting's promises into specifics:

Once an account is live, walk me through a normal week. How much is building and how much is meetings?
How much of an FDE's time goes to the sales cycle, and how much to building? Ask for the answer in writing with the offer.
How are FDEs judged at review time: by deployments that ship, by customers who renew, or both?
Has anyone on the team moved from FDE into a pure engineering role internally?
Will I have write access to production at the customer, and will I be paged when something I built breaks?
Who else is on the pod, and what's the plan for handing the system to the customer's team?

These questions do double duty. They also show the interviewer you understand the job you're interviewing for.

The earlier rounds come first, so match your practice to the family you're applying for. For Core FDE, try the multi-tenant RAG assistant returning other customers' documents, which has a full rubric. For Data Engineering, a data pipeline from ingestion to a feature store. For Field Architecture, standardizing LLM access across multiple teams. For Solutions / Implementation, the customer who thinks three-zone replication keeps their data safe.

The customer round has its own guide, and the full loop is in the forward deployed engineer interview. For scoping practice, open the Product & scoping questions on the prep page.