How do you become a Forward Deployed Engineer?
- Authors
- Name
- Amit Shekhar
- Published on
Forward Deployed Engineer is a role we reach by first becoming an engineer who can ship with an AI coding agent, then learning AI engineering, integrations, and deployment inside a customer's environment. We prove it with one project that adds an AI feature to a system we did not write.
In this blog, we will learn about how to become a Forward Deployed Engineer. We will also see what a Forward Deployed Engineer does, what we need before we start, the skills to learn in order, what to build with a coding agent to prove it, how to show the work, and how to apply for the role.
We will cover the following:
- What is a Forward Deployed Engineer?
- Prerequisites
- Skills to learn in order
- What to build to prove it
- How to show the work
- How to apply
I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.
I teach AI and Machine Learning at Outcome School.
Let's get started.
What is a Forward Deployed Engineer?
A Forward Deployed Engineer (FDE) is an engineer who works directly with a customer, scopes the problem, builds the AI software, ships it inside the customer's own environment, and stays until it works.
The word "forward" means being placed at the front, with the customer, instead of sitting back at the company office. Palantir created this role, and now it is common at AI companies.
Let's say an AI company has built an LLM (Large Language Model). A hospital wants to use it to summarize patient records. The hospital has its own database, its own login system, and its own old software that nobody wants to touch. The AI company cannot just hand over an API key. Someone has to go to the hospital, understand the data, connect the model to the hospital's systems, build the summarizer, test it on real records, and make it run inside the hospital's servers, and that too without breaking the hospital's existing software. That person is the Forward Deployed Engineer.
So, the FDE is half engineer, half consultant, and a full owner of the outcome. The FDE is different from a Solutions Engineer. A Solutions Engineer supports the sales team with demos before the deal is signed. The FDE owns the production delivery after the deal is signed.
Now, let's see the prerequisites.
Prerequisites
There are two things we need before we start.
First, we must be a working engineer who can ship with a coding agent.
The FDE describes the task clearly to an AI coding agent such as Claude Code, reviews what the agent produces, tests it, and designs the system around it. We must know how to read a codebase we have never seen, how to run it, how to ask the coding agent to make a change, and how to verify that the change is correct.
If we have shipped a few features to production in any backend language with a coding agent, we have this prerequisite.
Second, we must be comfortable talking to customers.
An FDE spends a big part of the day in conversations. We sit with the customer's team, ask questions, listen to complaints, explain trade-offs, and say "no" when a request is not possible. We do not need to be a salesperson. We need to be a clear and patient communicator.
Now, let's move to the skills.
Skills to learn in order
Each step builds on the previous one.
Step 1: We learn the AI engineering basics.
The FDE builds products on top of existing models. We do not train models from scratch. So, we need the following:
- LLM APIs: how to send a prompt to a model through an API, how to control the output, and how to manage cost and latency.
- RAG: RAG = Retrieval + Augmented + Generation. We fetch the relevant documents from the customer's data first, add them to the prompt, and then ask the model to answer. This is how the model answers questions about data it was never trained on.
- Agents: an AI Agent is a system built around an LLM that can use tools. The LLM recommends a tool and its input, and our code runs the tool and sends the result back. We need to know how to build this loop and how to add guardrails to it.
- Evaluation: how to measure if the output is good. We build a small test set of real inputs and expected outputs, run the system against it, and track the score. Without evaluation, we cannot say "it works" to a customer.
We learn each of these by building a small version with a coding agent, running it, and checking the output ourselves.
A quick note for you
No matter which tech domain you work in, get familiar with these topics:
- LLM
- RAG
- MCP
- Agent
- Fine-tuning
- Quantization
We put it all together in one video:
AI Engineering Explained: LLM, RAG, MCP, Agent, Fine-Tuning, and Quantization
No need to stop reading - bookmark it and watch later when you get time. Future you will thank you.
Now, let's get back to the topic.
Step 2: We learn integrations with messy customer systems.
This is where the FDE differs from a normal AI Engineer. The customer's systems are rarely clean. We must learn to connect our AI feature to:
- Databases: old SQL databases with hundreds of tables, no documentation, and column names like
cust_fl_2. We need to read the schema, ask the coding agent to write the queries, review them, and get the data out safely. - Auth: the customer has their own login and permission system. Our feature must respect it. A user must see only the data that they are allowed to see.
- Legacy APIs: old internal APIs that return XML, go down at night, and have no docs. We must build connectors that handle timeouts, retries, and bad responses.
We direct the coding agent to write the connector, then we review it line by line, because a wrong query against a customer's production database is a serious mistake.
Step 3: We learn deployment inside someone else's environment.
At a product company, we deploy to our own cloud. As an FDE, we deploy to the customer's cloud, the customer's on-premise servers, or sometimes a locked network with no internet.
So, we need to learn:
- Containers, so that our code runs the same way on any machine.
- Environment configuration, so that secrets and URLs are not hard-coded.
- Logging and monitoring, so that when it breaks at night, we can see why.
- Security basics, so that the customer's security team approves our setup.
We practice this by taking a project we built and deploying it on a machine we do not control, with the rules that a customer would give us.
Step 4: We learn scoping and communication.
The customer will say "we want AI". That is not a task. The FDE turns it into a task.
Scoping means:
- Finding the one problem that matters most to the customer right now.
- Defining what "done" looks like in a measurable way, like "the summary is correct in 9 out of 10 records".
- Cutting everything else from the first version.
- Writing it down so that both sides agree.
Communication means giving a short status every day, showing a working demo every week, and saying clearly when something is not going to work.
We practice this by writing a one-page scope for every project we build, before we build it.
Step 5: We learn to own an outcome end to end.
This skill ties all the others together. Owning means that when the feature fails on a real record at the customer site, we do not say "that is the model's problem" or "that is the database team's problem". We find the cause, fix it, and stay until it works.
We learn it by taking one project from the first conversation to the final working version, with no one else to hand it to.
Want to become a Forward Deployed Engineer?
These are the skills this role needs, and we teach them in our AI and Machine Learning Program at Outcome School:
- RAG
- AI Agent
- Model Context Protocol (MCP)
- Evaluation of LLMs and Agents
- Model Deployment and Serving
- AI Security
We take you from the fundamentals to building real AI systems, step by step.
Now that we have the skills, it's time to build something that proves them.
What to build to prove it
The best way to prove these skills is by building one project that integrates an AI feature into an existing system that we did not write.
A normal portfolio project starts from an empty folder. An FDE project starts from someone else's codebase.
First, pick an existing open-source application that has real users and real data. A good choice is an open-source ticketing system, an inventory tool, or a customer support app. It must have a database, a login system, and an API.
Then, pick one AI feature that would help the users of that app. For example, in a ticketing system, add a feature that reads a new support ticket, finds the three most similar past tickets using RAG, and drafts a reply for the support agent.
After that, write a one-page scope. What is the feature, what does "done" mean, and what is out of scope.
Now, open the codebase with a coding agent. Ask the agent to explain the structure, the database schema, and the auth system. Read its explanation and verify it against the code. This is the same thing we will do at a customer site on day one.
Then, direct the coding agent to build the feature step by step. First the connector that reads tickets from the existing database. Then the RAG pipeline over past tickets. Then the drafting call to the LLM. Then the API endpoint that respects the existing login system, so that a support agent sees only the tickets of their own team. After each step, we review the code, run it, and test it with real data from the app.
After that, build the evaluation. Take 50 real past tickets, run the feature on each, and check how many drafts are usable. Write the number down.
Finally, deploy the whole project using containers on a machine that is not our laptop. Add logging. Break it on purpose and check that the logs tell us why.
Stay updated: Subscribe to our newsletter to get our latest AI and Machine Learning blogs straight to your inbox.
How to show the work
A hiring manager must be able to understand the project in five minutes. So, put the project in a public repository with a README that has the following:
- The one-page scope we wrote before building.
- A short description of the existing system we integrated into and why we picked it.
- A diagram of how the AI feature connects to the database, the auth, and the API.
- The evaluation result, with the number, like "41 out of 50 drafts were usable without edits".
- The deployment steps, so that anyone can run it.
- A short section on what went wrong and how we fixed it.
An FDE is hired for handling things that go wrong. So, a README that says "the legacy API returned empty responses at night, so we added a retry with backoff" is more convincing than one that says "everything worked".
Also, record a short video walking through the feature. Show the real app, show the AI feature working inside it, and talk through one decision we made. This is how we will present to customers, so it is also how we show the work.
Then, write a short blog post about the project, with the problem, the approach, and the result, to show that we can explain technical work in plain words.
How to apply
The role has more than one name, so we must know where to look and what to say.
Which roles to look for:
- "Forward Deployed Engineer", "Forward Deployed Software Engineer", and "Forward Deployed AI Engineer" are the direct titles.
- "Deployed Engineer" and "Customer Engineer" often describe the same job.
- "Solutions Engineer" is usually the pre-sales role, so read the description carefully. If it says "own delivery" and "ship to production", it is an FDE role with a different name.
Which teams to look for:
- AI companies that sell models or agents to large customers.
- Startups that sell AI products to enterprises, which often have a small FDE team.
- Consulting firms that build AI systems for clients, where the title is different but the job is the same.
What to say in the application:
The application must be about the project. Say which existing system we integrated into, which AI feature we built, which messy parts we handled, and the evaluation number. One paragraph is enough.
Then, say one line about customer communication. If we have ever supported users, run a demo, or explained a technical decision to a non-technical person, say it here.
Then, say one line about how we build: with a coding agent, reviewing and verifying every change.
In the interview, expect a practical build round where we work with a coding agent on a small codebase and explain and verify the result. Treat the interviewer like a customer. Ask questions, confirm the scope, and show the working result.
Now we must have understood how to become a Forward Deployed Engineer, what to learn in order, what to build to prove it, how to show the work, and how to apply.
Frequently Asked Questions
Do we need to train models from scratch to become a Forward Deployed Engineer?
No. A Forward Deployed Engineer builds products on top of existing models. So, we need to know LLM APIs, RAG, agents, and evaluation. We learn each of these by building a small version with a coding agent, running it, and checking the output ourselves.
Do we need sales experience to become a Forward Deployed Engineer?
No. We do not need to be a salesperson, but we need to be a clear and patient communicator. A Forward Deployed Engineer spends a big part of the day in conversations with the customer's team. We ask questions, listen to complaints, explain trade-offs, and say "no" when a request is not possible.
Why should a Forward Deployed Engineer project start from an existing codebase?
Because that is what the job looks like at a customer site. A normal portfolio project starts from an empty folder, but an FDE project starts from someone else's codebase. Asking the coding agent to explain the structure, the database schema, and the auth system, and then verifying its explanation against the code, is the same thing we will do at a customer site on day one.
What happens in a Forward Deployed Engineer interview?
A Forward Deployed Engineer interview usually has a practical build round. We work with a coding agent on a small codebase and explain and verify the result. We must treat the interviewer like a customer. We ask questions, confirm the scope, and show the working result.
That's it for now.
Thanks
Amit Shekhar
Founder @ Outcome School
You can connect with me on:
Follow Outcome School on: