A forward deployed engineer, usually shortened to FDE, is a software engineer who works at the customer's side instead of at a desk next to the product team. The title is everywhere in job postings now, and it means slightly different things at different companies. This guide explains the common core, keeps what companies say about themselves apart from our own reading, and ends with a short self-check. Last reviewed in October 2026.
The job in one paragraph
An FDE takes a customer's real problem, which usually arrives vague, and turns it into software that runs in production on the customer's data and inside the customer's rules. They write code, but a good part of the job is not code: working out what the problem is, who has it, what is allowed, and how anyone will know it worked. Then they hand the result to the customer's team and carry what they learned back to the people who build the product.
The loop of the work
- Discover. Sit with the people who feel the problem. Ask what happens today, step by step, and what it costs when it goes wrong. Scoping a Vague Customer Problem walks through this part.
- Build. Make the thinnest version that works on the customer's real data. A slice that handles one case end to end teaches more than a broad prototype.
- Deploy. Put it where the customer runs things, which means their access rules, their review process and their way of changing production. Deploying an LLM Feature at a Customer covers the checks.
- Hand off. Leave the customer able to run it without you: documentation, a named owner, a way to turn it off.
- Feed back. What you learn is evidence for the product team. Sometimes it is also code that becomes a feature for every customer.
How it differs from the roles next to it
The simplest test is what you leave behind. A software engineer leaves a feature in a product that many customers use. A solutions engineer leaves a demo that helps win a sale. A consultant leaves a recommendation. An FDE leaves something running in production that the customer depends on, and the code lives in the customer's environment.
That has consequences. An FDE cannot assume a clean database, a fast network or a free hand: access is limited, data is messy and every change has to be approved by someone. The upside is a short distance between a problem and its fix. You see the person who uses what you built.
What employers publish about it
These come from the companies' own pages, as of this review. Postings change often and differ by team and country, so open the page before you rely on it.
| Company | What its own pages describe | Read it yourself |
|---|---|---|
| Databricks | Its Forward Deployed Engineer posting calls the role hands-on and customer-facing: working with customers to build and productionize solutions, owning the architecture, and embedding with customer teams from technical contributors to executives. The posting we link is a country-specific one and also lists Apache Spark and cloud experience. | The Databricks posting |
| OpenAI | Its postings for Forward Deployed Engineers describe leading deployments of its models for customers, from discovery and scoping through system design, build and rollout to production. Experience requirements and travel differ by posting. | An OpenAI posting |
| Palantir | Its engineering blog compares its two engineering roles in a post titled "Dev versus Delta" (a Delta is a forward deployed engineer, a Dev builds the product), and a second post describes a day in the life of a forward deployed software engineer. | Dev versus Delta and a day in the life |
What the three share is the shape of the job: customer-facing, hands-on and end to end. What differs is the platform. At a platform company you configure and extend that platform for a customer. At a model provider you deploy models, with evaluation and safety questions close to the center.
What a week can look like
This is an illustration to make the loop concrete, not any company's schedule. The same week often holds all five steps.
| Day | A plausible focus | Part of the loop |
|---|---|---|
| Monday | Sit with the support team and watch how a ticket is routed today | Discover |
| Tuesday | Pull a week of real tickets, check what is missing, write a one-page problem statement | Discover |
| Wednesday | Build the thinnest routing suggestion on the real data | Build |
| Thursday | Get access approved, deploy to a test inbox, fix what breaks in their environment | Deploy |
| Friday | Show the team, write the runbook, send the product team three things you learned | Hand off, feed back |
Skills that matter most
- Solid general engineering. Python or a similar language, SQL, reading unfamiliar code, and debugging systems you did not design.
- Data comfort. Customer data is rarely clean. The Messy Data Day shows a typical afternoon.
- Clear writing and speaking. Status updates, problem statements and honest bad news are part of the work.
- Judgment about scope. Knowing what not to build this week is a skill, and the customer will keep adding to the list.
- Enough AI fluency to deploy it safely, if the role involves models: evaluation, cost, access rules and what to do when the model is wrong.
Is it for you?
The role asks you to be good at all five steps of the loop, including the ones you like less. The self-check below shows which step pulls you and which one will cost you energy. It is a thinking aid, not a test.
A self-check. Rate how much each part of the loop appeals to you. There are no right answers.
Where to practice on ScaleDojo
- Code fluency: the Forge Algorithm Lab and the Forge Learn course.
- Designing systems you will have to deploy: the HLD Learn course.
- Working with models in production: the GenAI Learn course, starting with why AI needs evals.
- Contracts and integrations: the API Design Learn course, including idempotency keys and webhooks.
- Remembering all of it: Revision.
What we know and what we do not
We know what the three companies above publish on their own pages, as of October 2026, and each row links to it. We do not know how any company interviews for the role or how it weighs the parts of the job, and titles mean different things from one company to the next. The comparison with neighboring roles and the weekly illustration are our own reading, not a company's definition. If a posting or a recruiter tells you something different, believe them. Last reviewed in October 2026.
