The Reality of the Forward Deployed Engineer
A software demo can look great while leaving the hardest questions unanswered. Where will the real data come from? Who can access it? Will the people doing the work actually use what you've built?
Imagine a logistics company buying a platform to help its dispatchers investigate late deliveries. The demo takes seconds. In the working system, shipment records use different IDs, delivery notes arrive as PDFs, and each depot has its own way of recording exceptions. Someone has to work through those details with the customer.
A Forward Deployed Engineer (FDE) is a software engineer who works closely with a customer to turn a platform's capabilities into software that fits their operations.
The role has been around for years. Palantir was describing its Forward Deployed Software Engineers in 2020. Today, companies including OpenAI and Anthropic hire FDEs to help customers put AI systems into production.
What Does an FDE Actually Do?
An FDE's work can start before anyone agrees on what to build. The customer may ask for an AI assistant when the immediate problem is that staff cannot find a reliable shipment record.
In our logistics example, the work might include:
- Watching a dispatcher investigate a late delivery and identifying where time is lost.
- Agreeing on a useful first release, such as showing shipment history and the relevant delivery notes in one place.
- Building the data integration, access controls, and interface using the vendor's platform and whatever custom code is needed.
- Testing against actual records, rolling out to a small group, and fixing problems those users find.
That combination of discovery and delivery appears in OpenAI's FDE role description, which covers scoping, system design, implementation, and production rollout. It also measures success through adoption and changes to the customer's workflow.
Writing code matters, but the balance changes with the project. One week may involve building an integration; another may involve resolving data access with the customer's IT team. Being embedded means working closely with that team. It doesn't necessarily mean being at their office every day.
What comes back to the product team
A lot of an FDE's value comes from noticing what keeps going wrong across deployments. Perhaps three customers need the same connector, or a permission model makes a common workflow unnecessarily difficult.
Anthropic's FDE posting explicitly includes turning deployment experience into repeatable patterns and sharing insights with Product and Engineering.
A quick customization may help today's customer while creating another piece of software to maintain. An FDE needs the judgment to help decide what belongs in the shared product, what should remain specific to the customer, and what the team should decline to build.
FDE, Solutions Architect, and Related Roles
These titles describe overlapping jobs. The table below is a practical guide to their usual emphasis; an individual job description may draw the boundaries differently. Here, SA means Solutions Architect, and SE means Solutions Engineer.
| Role | Main responsibility | Typical output | Typical sales / delivery stage |
|---|---|---|---|
| Forward Deployed Engineer (FDE) | Work through a customer's problem and deliver a usable deployment. | Integrations, applications, deployment code, and feedback for the product team. | Can span pre-sale discovery or pilots through post-sale rollout; some teams focus on post-sale. |
| Solutions Architect (SA) | Help the customer choose an architecture and make sound technical tradeoffs. | Designs, prototypes, implementation guidance, and sometimes production code. | Often pre-sale architecture; may continue through delivery and adoption. |
| Solutions Engineer (SE) | Establish whether the product meets a prospect's or customer's technical needs. | Tailored demos, proofs of concept, and technical evaluations; coding varies by product and team. | Usually pre-sale evaluation; some teams also cover implementation and ongoing support. |
| Technical Account Manager (TAM) | Guide ongoing technical health, adoption, and operational readiness. | Technical reviews, improvement plans, and coordinated incident escalation. | Usually post-sale, with an ongoing account relationship. |
| Implementation / Professional Services Engineer | Deliver an agreed integration, migration, or rollout. | Configured systems, production integrations, migration tooling, and handover documentation. | Usually post-sale delivery within an agreed scope. |
| Core Software Engineer (SWE) | Develop and maintain the shared product or platform. | Features, services, APIs, and infrastructure used across customers. | Product development across customers; generally independent of an individual sale. |
An FDE may stay with the same customer problem across the sale: Taxbit's FDE role, for example, combines pre-sale technical guidance with ownership of post-sale integrations. That continuity is useful to understand, though it also appears under other titles.
SE deserves a closer look. At security infrastructure company Evervault, the SE role extends from technical evaluation into implementation and ongoing customer support. Those responsibilities overlap with FDE work. Even within security and infrastructure, an SE opening can mean quite different things: the Cloudflare example above emphasizes pre-sale work, while Evervault expects involvement after the purchase too.
FDE vs. SA: what you own
An SA and an FDE could both work on the logistics project. The SA might lead decisions about identity, data access, system boundaries, cost, and how the proposed solution fits the customer's architecture. The FDE might take responsibility for getting the dispatcher workflow working with the actual records and users, adjusting the design as problems emerge.
Both need to understand the business problem. Both may write code. Neither can ignore whether the design works in practice.
Some jobs overlap even more than this example suggests. An AWS Solutions Architect posting includes embedding with enterprise customers, co-building production AI systems, and writing production code. Describing all SAs as people who produce diagrams and hand them off would miss a substantial part of that job.
For a particular opening, find out what you would personally be accountable for: an architecture decision, a technical evaluation, a working deployment, or the health of an ongoing account. Also ask who maintains the code after launch. The FDE title alone doesn't tell you who carries the pager.
FDE vs. implementation engineer
Implementation and professional services engineers also build integrations, handle difficult migrations, and work directly with customers. For example, Recidiviz's Implementation Engineer role includes maintaining production data pipelines, scoping work with partners, and contributing insights to product direction.
An FDE role may give the engineer more room to define the problem, while an implementation engagement may begin with a scope agreed in advance. The Recidiviz example shows how much these jobs can overlap. In a conversation with the hiring manager, pin down how much of the scope you could shape and how much would already be promised to the customer.
The distinction from core software engineering is often the scope of attention. A product engineer might improve a connector for everyone; an FDE might combine that connector with several other capabilities to solve one customer's workflow. Palantir's account of its development and deployment teams describes this difference.
The Parts of the Job to Ask About
The appealing part is seeing someone use your work and tell you, directly, whether it helps. The difficult part can be the number of dependencies outside your control: access approvals, changing priorities, incomplete data, or a customer deadline that conflicts with the product roadmap.
Before accepting a role, get a picture of the workload: how many customers you would support at once, how the team limits custom work, and what happens when an engagement ends. "Who maintained the last deployment six months after launch?" is worth putting to a future teammate as well as the manager.
Travel deserves a specific conversation too. In the postings available on September 8, 2026, Anthropic estimates 25% travel, while OpenAI's Seattle role lists up to 50%. A percentage won't tell you whether trips are planned well ahead or arranged at short notice, or how often you'll spend a full week away.
Preparing for an FDE Interview
There is no single FDE interview format. OpenAI's interview guide says assessments vary by team and may include pair coding, take-home projects, or technical tests. It also calls out code quality, performance, and test coverage. Prepare your engineering fundamentals alongside your customer examples.
A useful preparation plan covers four areas:
- Coding and debugging. Practice producing readable, tested code and explaining your decisions. Confirm whether the employer uses algorithm questions, practical exercises, or both.
- System design. Be ready to discuss data flow, permissions, failure handling, deployment, and monitoring.
- Breaking down an unclear request. Practice turning a broad business goal into something small enough to build and evaluate.
- Working with people. Have specific examples of resolving disagreement, changing scope, and explaining a technical limitation to someone who needed a different answer.
A practice case
Try this hypothetical prompt: "Our dispatchers spend too long investigating late deliveries. The information is split between SQL databases and delivery-note PDFs. What would you build first?"
Before sketching an architecture, work through one investigation step by step. Which record does the dispatcher open, what is missing, and who do they call next? Use that to agree on a way to judge the result, such as investigation time and the accuracy of the information shown. You'll also need to establish who can access the records and where the system is allowed to run.
Then propose a small first release. A searchable shipment history may already remove much of the manual work. If you propose a large language model (LLM) to summarize notes, explain how you would check its answers against source records and handle uncertainty. Choose retrieval, embeddings, or agents when they serve the problem you have identified.
Finally, change one constraint yourself: suppose the PDFs cannot be sent to an external service. Explain which parts of your design still work and what needs reconsidering. This is a practice exercise, not a prediction of a particular company's interview round.
Writing an FDE Resume
Show the connection between a problem, your decisions, and the result. Customer contact is useful evidence when you have it; work with internal users and business teams can also demonstrate relevant skills.
For example, this is already a solid technical bullet:
Refactored the data ingestion pipeline in Python and Kafka, reducing latency by 15%.
If you also worked with the operations team to identify the problem, add that context. If you chose the rollout plan or supported the release, describe your part. Keep the original facts intact: maintaining a service doesn't establish that you migrated it, and fixing bugs doesn't establish that you owned the entire feature.
Choose examples you can discuss in detail. Be ready to explain what was uncertain, what you decided, who else contributed, and how you knew the change helped.
Pay and Career Paths
Compare offers at the same level and location, with base salary, any bonus or commission, and equity broken out separately. You need those details to make a useful pay comparison with software engineering, solutions architecture, or consulting. Promotion criteria and travel reimbursement deserve a look too (reimbursed expenses are not extra pay).
For career planning, look at the experience the job will let you build. Shipping maintained software can support a later move into product engineering. Leading delivery across accounts can be relevant to field engineering leadership. Discovering customer needs and choosing what to build can help with a move toward product management or starting a business. Each path still requires evidence of the skills the next role needs.
The hiring manager should be able to give examples of where former team members moved and what helped them make those transitions.
So, Is It for You?
You may enjoy FDE work if you like writing software and staying close enough to users to hear what isn't working. You also need patience for the conversations, access requests, and revisions that make delivery possible.
That restriction on sending PDFs outside the network, for instance, could take more of your week than the model itself. You might spend a morning with the customer's security team reviewing deployment options, then revise the integration. The first release could show a shipment record beside the correct PDF, with summarization postponed until an approved option is available.
