A forward deployed engineer works close to the organisation using the software. The job combines understanding the customer's problem with designing, integrating and delivering a working solution. The exact balance varies by employer, so a job title alone is not enough to understand the role.
The role starts before the code
OpenAI's current role descriptions include customer discovery, scoping, system design, delivery and rollout. Palantir also describes forward deployed engineering in terms of working with customers on their problems. These employer descriptions are better starting points than assuming every FDE spends the day building AI demos.
The important skill is translating an unclear business request into software that works in a real environment. That requires technical judgment and the ability to ask questions, explain tradeoffs and recognise when the requested solution is not the right one.
What a week can involve
Consider a fictional customer asking for an assistant that finds answers across internal documents. Early work is not just choosing a model. The engineer needs to identify users, document permissions, data quality, the questions people ask and what a correct answer would look like.
Next comes a narrow implementation: connect approved sources, enforce access, return evidence and handle missing answers. The engineer may need to work with the customer's identity system, deployment process and operational constraints. A successful notebook is only one small part of that delivery.
The same engineer might then demonstrate the workflow, observe users, investigate failures and turn recurring needs into reusable product improvements. Some employers require travel or intensive customer collaboration; others organise the work differently. Read the actual posting and ask how delivery ownership works after launch.
- Discovery: understand the process, users and constraints before defining a solution.
- Engineering: integrate data and systems, build the workflow and verify boundaries.
- Delivery: deploy, document, train operators and observe real use.
- Feedback: distinguish a one-off customer requirement from a reusable product opportunity.
How it differs from neighbouring roles
A product software engineer often builds capabilities used by many customers through a shared product. An FDE may focus more directly on making that product useful in a particular customer's environment. That is a difference in emphasis, not a rule that one role writes “real code” and the other does not.
A solutions engineer often helps a buyer understand and evaluate a product before or during a sale. An FDE may own deeper implementation and post-sale delivery. Some companies combine those responsibilities, which is why you should ask about production work, sales expectations and on-call ownership rather than rely on the label.
A consultant can also perform similar work. Employment structure does not define the engineering quality. What matters is whether the role owns a working outcome, understands the customer's context and leaves a system that someone can operate and maintain.
Skills that transfer into the role
Strong software fundamentals matter: APIs, data modelling, authentication, debugging, tests and deployment. AI-focused roles add model integration, retrieval, evaluation and safe tool use. You do not need every fashionable framework, but you do need to understand the failure modes of the system you deliver.
Communication is technical work here. You must explain why a requirement is risky, why a small release is useful and which assumptions remain untested. A customer should be able to understand the decision without learning the vocabulary of your model provider.
Practise writing a short scope with measurable acceptance criteria. For the document assistant, “accurate answers” is too vague. “Answers cite accessible source passages, inaccessible documents remain excluded and unsupported questions reach a clear fallback” gives the team something concrete to test.
Build a portfolio artifact that resembles the job
Use a fictional business and synthetic data so the work can be shared safely. Show the initial problem, the users, the constraints and the decision to build a narrow first release. Then demonstrate the happy path and two meaningful failure paths.
Include a simple architecture diagram, a small acceptance-test set and an operating note. Explain how an operator notices a failure and how the system can be recovered or rolled back. State clearly that the example is a self-directed project, not a confidential customer case or a production success metric.
The most useful artifact is a short delivery story: what you learned, what you chose not to build, how you proved the boundary and what would change for production. A polished chat interface alone does not demonstrate discovery, integration or delivery judgment.
Questions to ask before accepting the title
Ask who owns discovery, who writes and reviews production code, who supports the deployment and how success is measured. Ask how much work is customer-specific and how reusable improvements return to the product team. Clarify travel and working-hour expectations using the employer's actual arrangements.
If you are preparing for the role, deepen one complete delivery example rather than collecting many disconnected demos. Learn to debug an integration, explain an access decision and write a scope that another engineer can implement.
The title is gaining attention, but the underlying work is durable: understand a real problem, build an appropriate system and help people use it successfully. That is a useful direction whether your next role is called FDE, software engineer or technical consultant.