Map the FDE job market: who hires, what they call the role, and what each variant emphasises
Prepare for the interview loop stage by stage, especially the case study round
Build the portfolio evidence that substitutes for field experience you do not have yet
Test your own instincts against six scenarios drawn from the whole track
Eleven lessons of craft. The last question is whether this is your job, and if so, how to get it.
This lesson is in two halves. The first half is the market and the path in. The second is a set of drills: six situations, each testing whether the track's judgment has become your judgment. No new concepts, only the old ones under pressure.
Four clusters hire for this work, and the same title means different things across them.
The AI labs hire FDEs to make frontier models work inside enterprises. The work leans heavily on the LLM half of this track: evals, integration, deployment constraints. OpenAI's team publicly describes the scoping-validation-delivery engagement structure you met in lesson two, and Anthropic hires for the same motion.
Palantir and its descendants run the original playbook: deep embedding, gnarly environments, data integration as the core craft. Palantir hires early-career engineers into it deliberately, which makes it one of the most accessible entry points, and its alumni have seeded the model across defence, fintech, and health startups.
Vertical AI startups, companies applying AI to one industry, hire FDEs as their entire delivery arm. Highest variance and highest ownership: at a fifty-person company, the FDE function is two people and you are half of it.
Your Reflection
Saves automatically
What’s one thing you learned? What’s still confusing?
Infrastructure and platform scaleups hire forward deployed roles under many names: deployed engineer, solutions engineer with production ownership, field engineer. Read the responsibilities, not the title. The test from lesson one still works: do you ship production code in the customer's world, and do you own the outcome?
Something to Think About
There is no right answer here, and nothing is being marked. Pick the one that sounds most like you.
Two offers. Company A: an AI lab, structured FDE team, strong mentorship, well-defined engagements. Company B: a 40-person vertical AI startup where you would be the second FDE, defining the function. Which factor should dominate the decision?
Loops vary by company, but the published guides and the companies' own materials converge on a recognisable shape: an engineering bar plus two rounds most engineers have never practised.
The engineering rounds are real. Coding at product-engineer level, and a system design round flavoured toward deployment reality: data ingestion from messy sources, staged rollouts, integration with legacy systems. Everything from the integration and deployment lessons is directly usable here, and interviewers reward explicit assumptions and named risks over polished diagrams.
The case study round is the one that decides. You get a large, vague enterprise problem, forty-five to sixty minutes, and the interviewer grades your process rather than your conclusion. The winning process is this track's spine run at speed: clarify who the stakeholders are and what number matters, pick the beachhead workflow out loud using value-feasibility-visibility, state what you would ship in week one, name the risks you are accepting, and say what you would measure. Candidates fail this round by designing architecture for the first twenty minutes.
The customer round tests translation under pressure: explain a technical trade-off to a buyer who does not code, handle a hostile question about a slipped date, deliver bad news. Lesson eleven is the syllabus. Interviewers here are often listening for one specific thing: whether you state implications yourself or make the listener dig for them.
The chicken-and-egg problem: the role rewards field experience you do not have yet. The workaround is that most FDE skills leave artifacts you can build without an employer.
Build one end-to-end deployment story: a real problem for a real organisation, however small. A nonprofit's intake process, a local firm's quote workflow. What makes it portfolio-grade is not scale but the arc: the discovery notes, the scoped bet with a number, the eval set, the deployed thing, and what the number did. One completed arc beats five impressive demos, because the arc is the job.
Make your evals public. A repository showing an evaluation harness for an LLM task, with a holdout set and honest failure analysis, signals the single discipline this field most lacks. It is rare enough to be memorable.
And write one integration post-mortem: take a messy public dataset, integrate it, and document the four lies you found and the precedence rules you chose. It demonstrates the ontology habit, and it gives interviewers something concrete to probe, which reliably beats being probed on generalities.
Each scenario below has one answer that reflects this track's judgment. Argue with the explanations where you disagree; the arguing is the exercise.
What Do You Think?
Drill one. Week two of discovery. The sponsor asks you to skip ahead: the executive team has already decided the problem is document search, and they want a build plan by Friday. Your floor observations point somewhere else entirely. What do you do?
What Do You Think?
Drill two. Your prototype scores 91 percent. The sponsor wants it shown to the CEO tomorrow and asks you to demo the five cases it handles most impressively. What is the right demo?
What Do You Think?
Drill three. The security review demands your system run in the customer's VPC with no external API calls, killing the frontier model your prototype used. The local alternative scores six points lower on your eval set. What is the move?
What Do You Think?
Drill four. Pilot week three: an operator you trust tells you privately that people have started keeping a spreadsheet on the side again, because the tool mishandles one weekly case type. Usage metrics still look fine. What now?
What Do You Think?
Drill five. Handover is in three weeks. The customer's team lead quietly suggests the system is too complex for their team and asks whether your company could just operate it permanently, for a fee. Tempting revenue. What does the discipline say?
What Do You Think?
Drill six. Back home, the product team rejects your field pattern report for the second quarter running: no capacity. Meanwhile your next engagement needs the same capability again. What is the FDE-shaped response?
A last honest filter, because the role is demanding in specific ways. The travel is real: expect a substantial share of your time on site. The ambiguity is constant: you will regularly be the only engineer in the building who works for your company. And the identity is unusual: your best work ships under the customer's roof and your name mostly stays off it, except in the product improvements you feed home.
What you get in exchange: end-to-end ownership that most engineers wait a decade for, exposure to how organisations actually work, and a compounding skill set, half technical and half judgment, that this track has tried to give you a year's head start on.
Quick Check1 / 3
In the case study round, what are interviewers primarily grading?
Four hiring clusters, one test: production code in the customer's world, with ownership of the outcome. Read responsibilities, not titles.
The loop is an engineering bar plus a case study and a customer round. The case study grades process, and process is trainable.
Portfolio: one complete arc, public evals, and an integration post-mortem. The arc is the job in miniature.
The drills reduce to one habit: make decisions visible to their owners, with evidence, out loud.
This completes the Forward Deployed Engineering track. The adjacent tracks are the technical depth behind it: RAG and Knowledge Systems for the retrieval stack, AI Agents for the orchestration layer, and ML Engineering for the production craft.