What a forward-deployed engineer actually does
A forward-deployed engineer, often shortened to FDE, sits close to customers and turns messy business needs into working software. The AI-era version combines software engineering, solutions architecture, product discovery, consulting and executive communication. You are the person who flies to a customer site, sits in a room with the people who will actually use the product, and leaves a few weeks later with something running that was not running before.
The role is growing because AI products often fail at the last mile. A model demo is easy. A production workflow inside a bank, hospital, logistics company or enterprise support team is harder. Someone has to understand the customer's process, integrate systems, handle data constraints, build prototypes, ship fixes and feed product lessons back to the core team. The core product team cannot do this for every account, and the customer's own engineers usually do not know your product deeply enough to do it well. The FDE closes that gap.
A useful way to picture the job is a weekly rhythm rather than a job description. A typical fortnight might look like this:
- Two days mapping a customer process by interviewing the people who run it today, often discovering the real workflow differs from the documented one.
- Three days building a narrow prototype against the customer's real data, in their environment, with their access controls.
- One day demoing to a mix of end users and an executive sponsor, then renegotiating scope based on what you saw.
- The rest writing up integration gaps, filing them as product feedback, and patching whatever broke overnight.
The research file flags forward-deployed engineering as a high-interest emerging role. Public examples include Mattermost forward-deployed engineer roles, AssemblyAI forward-deployed roles, Cognizant AI FDE roles, and candidate discussion on ExperiencedDevs.
The role is not just solutions engineering
There is overlap with solutions engineering, sales engineering and consulting, but FDE roles usually carry more build ownership. The clearest signal is who owns the code after the engagement ends. A sales engineer hands the relationship to an account team. An FDE often keeps maintaining what they built, and that maintenance burden shapes how they build.
| Role | Typical focus | Who owns the code after | Revenue link |
|---|---|---|---|
| Sales engineer | Pre-sales demos, technical validation, deal support | Usually nobody, it was a demo | Direct, tied to the deal |
| Solutions engineer | Customer integration and implementation support | Customer team or services | Indirect |
| Consultant | Project delivery and advice, often scoped by contract | Customer, on handover | Billable hours |
| Forward-deployed engineer | Build customer-specific workflows and productise lessons | Often the FDE, until it graduates to product | Indirect but high visibility |
In practice, companies use titles inconsistently. Read the job description carefully. If the role mentions production code, customer deployments, prototypes, travel, executive stakeholders and product feedback, it is closer to FDE. If it is mostly demos, slide decks and responding to RFPs, it may be sales engineering wearing a fashionable title.
A quick filter: if the job description talks more about closing deals than about shipping software, treat it as a sales role with engineering responsibilities, not an engineering role with customer exposure. The day to day is very different.
What interviews test
Expect a mixed loop. The signal the panel wants is rare: someone who can write real code, reason about an integration they have never seen, and stay calm in front of a frustrated customer. Most loops sample all three.
- Coding or practical build, often against an API rather than pure algorithms.
- System design for an integration-heavy workflow, not a hyperscale one.
- Customer scenario or case interview.
- Behavioural questions about ambiguity and conflict.
- Product judgement around MVP versus scalable platform.
- Communication with non-technical stakeholders, sometimes a live role-play.
Common prompts:
- "A customer wants an AI assistant for internal policy documents. How would you scope the first version?"
- "The customer says the model is wrong, but logs show retrieval found the right document. What do you do?"
- "How do you handle a client asking for a one-off feature that will hurt the core product?"
- "Design a workflow that connects our API to a legacy CRM."
The strongest answers balance empathy with boundaries. You need to show you can help the customer without becoming an unstructured feature factory.
What good versus weak looks like
The gap between a strong and a weak candidate is rarely raw technical skill. It is judgement under ambiguity. Here is how the same prompt separates them.
| Dimension | Weak answer | Strong answer |
|---|---|---|
| Scoping | Builds everything the customer asked for | Asks which decision the work supports, then cuts scope to that |
| Debugging | Blames the model and asks the product team to fix it | Isolates retrieval, prompt and generation as separate failure points |
| Saying no | Either always agrees or refuses bluntly | Offers a smaller alternative that protects the core product |
| Stakeholders | Explains in jargon, talks past the room | Reframes the tradeoff in the customer's own terms |
| Feedback loop | Treats the engagement as one-off | Spots a pattern across customers and files it as product input |
A short worked dialogue
Interviewers often run the debugging prompt as a live back and forth. Here is the shape of a strong exchange.
Interviewer: The customer insists the answer is wrong, but our logs show retrieval returned the correct policy document. What do you do?
Candidate: First I would separate three things that all look like "the model is wrong" from the outside: did retrieval find the right chunk, did the prompt actually include it, and did generation use it. The logs cover the first. I would check whether the right chunk was passed into the context window, because truncation or a reranker can drop it after retrieval. Then I would read the generated answer against the source. Often the model is technically right but answering a slightly different question than the user meant, which is a phrasing and grounding problem, not a retrieval one.
Interviewer: Say the chunk was in context and the answer still contradicts it.
Candidate: Then it is a generation or instruction problem, and I would reproduce it with a fixed input so I can iterate without bothering the customer. I would tighten the prompt to force a citation, and I would add a small eval case from this exact example so any future change has to keep getting it right.
That answer signals systematic debugging, not guessing, and it shows the candidate protects customer trust by building a regression check.
Prepare customer-facing technical stories
Your behavioural stories should show:
- Ambiguous requirement discovery.
- Tradeoff explanation to non-engineers.
- Incident or escalation handling.
- Building something under time pressure.
- Saying no or narrowing scope.
- Turning repeated customer needs into product feedback.
Use a consistent structure so the interviewer can follow you. A light version of situation, task, action, result works, but for FDE roles add one extra beat: what you fed back to the product or to the next customer. That last beat is the thing that distinguishes an FDE from a contractor.
Example answer shape:
A customer wanted a dashboard that combined three operational reports. The initial ask was broad, so I asked which decision the dashboard needed to support and found that the real problem was delayed exception handling. I built a smaller view focused on exceptions, added CSV export because their process still depended on spreadsheets, and documented two API gaps for the product team. The first version was narrower than requested but got used daily, and one of those API gaps shipped as a feature the following quarter.
That answer signals discovery, pragmatism and product feedback. Compare it to a weaker version: "They asked for a dashboard so I built a dashboard with all three reports and they were happy." The second one is not wrong, it is just invisible. It shows no judgement, no narrowing, and no loop back to the product.
Common mistakes candidates make
- Leading with the technology you used instead of the decision you helped the customer make.
- Describing scope creep as a success because the customer got everything they wanted.
- Going silent on conflict, when the panel specifically wants to see how you disagree well.
- Forgetting the customer is a person with a boss, a deadline and a reputation on the line.
- Claiming you "just built what was asked" in a role whose entire point is shaping the ask.
Technical depth still matters
Do not assume FDE is a lightweight coding role. Strong FDEs debug auth, APIs, data shape, networking, model quality, latency and permissions in environments they do not fully control. You will often be debugging on a customer laptop, through a VPN, without admin rights, against systems whose owners are on holiday. That constraint, not algorithmic difficulty, is what makes the technical work hard.
AI FDEs should understand:
- RAG and document ingestion.
- Model API integration.
- Authentication and enterprise SSO basics.
- Data privacy and retention.
- Prompt injection risk.
- Observability and logging.
- Integration testing.
- Cloud deployment basics.
For AI workflows, bring eval thinking. The single most useful habit an AI FDE can show is turning a customer complaint into a repeatable test before touching the prompt or the retrieval.
type CustomerWorkflowEval = {
workflowName: string;
inputFixture: string;
expectedDecision: string;
mustCitePolicyUrl: string;
};
export function hasRequiredCitation(answer: string, evalCase: CustomerWorkflowEval) {
return answer.includes(evalCase.mustCitePolicyUrl);
}Small evals can save customer trust. If a workflow makes a recommendation, you need a way to check whether changes improve it. The same idea scales: once you have one eval case, you have a harness, and adding the next ten cases is cheap. When a customer says "it got worse after your last change", an eval suite is the difference between a calm reply and a panicked afternoon of manual checking.
A second worked example: a customer reports that the assistant occasionally answers a policy question without citing a source, which their compliance team cannot accept. Before changing anything, capture the failing input as a fixture, assert the citation must appear, watch it fail, then tighten the prompt and rerun. The before is a vague complaint you cannot reproduce. The after is a green test you can point to in the next review.
How the role differs by seniority and by company
FDE means different things at a five-person startup and a large enterprise vendor, and at different levels within the same company.
| Level | What the work emphasises |
|---|---|
| Junior or mid FDE | Hands-on building, debugging integrations, owning a slice of an account under guidance |
| Senior FDE | Owning whole engagements, making scope calls, being trusted in front of executives |
| Staff or principal FDE | Spotting patterns across accounts, shaping the product roadmap, mentoring, sometimes pre-sales architecture |
Company stage matters just as much:
- At an early-stage startup, the FDE is often the bridge that keeps the first big customers alive while the product catches up. Travel can be heavy, scope is wide, and your feedback genuinely changes the roadmap.
- At a scale-up, the role formalises. There are playbooks, repeatable patterns, and a clearer line between FDE work and core engineering.
- At a large vendor or consultancy, FDE can drift towards delivery and services, with quotas and utilisation targets. This is not bad, but it is closer to consulting than the startup version, so calibrate your expectations.
Tradeoffs before accepting an FDE role
Ask about:
- Travel and on-site expectations, and whether they are weekly, monthly or quarterly.
- How customer work is prioritised when two accounts want you at once.
- Whether FDE code is production-owned or throwaway.
- Career path into product, engineering or leadership.
- On-call and support expectations, especially across time zones.
- Sales quota influence on your work and your compensation.
- How success is measured, in particular whether it is deals closed, customers retained or features shipped.
FDE can be a strong path for engineers who like ambiguity, users and visible impact. It can be draining for engineers who want deep uninterrupted platform work. Neither is morally better. Fit matters. The people who thrive tend to enjoy the variety, the travel and the human side of the job, and they treat the constant context switching as energising rather than exhausting. If a quiet week of focused coding is your idea of a good week, read the travel expectations very carefully before signing.
Compensation can vary because some companies price FDE as engineering, others as solutions or consulting. Use public ranges, recruiter data and databases such as Levels.fyi, but compare against the actual scope. A title that pays like consulting but demands production engineering is worth questioning. Watch for variable pay tied to sales: it can lift total compensation in a good year and make it volatile in a bad one.
FAQ
Is FDE a good role for a junior engineer? It can be, if there is real mentorship and you are not the only technical person on an account. The exposure to customers and systems early in a career is valuable. Avoid roles where a junior is sent solo to firefight, because you will learn bad habits under pressure with nobody to check your judgement.
Will I write less code than in a core engineering role? Usually yes in raw volume, but the code you write is closer to the customer and more varied. You trade depth in one codebase for breadth across many. If your goal is to become a deep specialist in one system, FDE will frustrate you.
Does FDE hurt my path back to core engineering? Not if you keep your fundamentals sharp and document the systems you build. The risk is drifting into pure delivery work and losing touch with engineering rigour. Keep writing tests, keep doing real design, and the transition back stays open.
How is the AI version different from a classic FDE? The classic FDE integrated and configured software. The AI version adds model behaviour, retrieval quality, evaluation and prompt safety to the list, and those are non-deterministic, so debugging looks different. Eval thinking is the skill that did not exist in the older role.
Continue your prep
FDE interviews blend AI, backend and customer judgement: