The Forward Deployed Engineer Is Not a Solutions Architect in a Hoodie
Disclaimer: Views expressed here are my own and do not represent the views or positions of my employer. This is written from observation: the questions companies actually ask, and the deployments that succeed or fail for reasons that have nothing to do with the model.
The demo always works. That’s the problem.
A model that summarizes a contract flawlessly in a sandbox will, three weeks later, choke on the customer’s real contracts: the ones stored as scanned PDFs in a SharePoint nobody has audited since 2019, half of them in a template the legal team deprecated but never deleted. The model didn’t get worse. It met reality.
Forward Deployed Engineer, or FDE, is the role the industry invented to handle that collision, and right now it’s one of the fastest-growing jobs in AI. Frontier labs are standing up FDE teams, scaleups are hiring them faster than they can write the job description, and PE firms are funding entire deployment shops around them. Something structural is happening, and most engineers I talk to still think it’s a relabeled sales-engineering job.
It isn’t. I’ve spent a while reverse-engineering the role from the inside, from the questions companies actually ask candidates and from watching deployments land or fall apart for reasons that have nothing to do with the model. Here is what it actually is.
The job is three jobs, and that’s the point
A Forward Deployed Engineer is a software engineer who writes production code on the customer’s infrastructure, a consultant who turns a vague business pain into a scoped technical problem, and a product manager who carries what they learn back to the core team. Not one after another. All of it at once, often in the same week and sometimes in the same meeting.
That is why it pays a premium, and why it doesn’t compress neatly into a job ladder. The market is roughly three buckets:
- AI vendors like Google, Anthropic, and OpenAI. A handful of high-value accounts, pushing model capability to its edge. Most selective, highest comp. Google sits a little apart in this group: it pairs frontier models with enterprise cloud reach, which gives its FDEs a broader surface to work across, and it’s scaling these teams quickly.
- B2B scaleups like Ramp, Replit, and Notion. You own the enterprise integration end to end, and your solution generalizes across the customer base. This is the best place to compound skills.
- PE-backed deployment shops, where client exposure is highest and hiring volume is largest as the traditional systems-integrator model gets disrupted from underneath.
The tradeoffs differ, but the core is the same. You are the last mile between a model and money.
Why the role exists now and not five years ago
For two years the industry sold individual productivity. Claude wrote your email. Copilot finished your function. Real, useful, and not remotely transformational at the level a CFO cares about.
Organizational transformation is a different animal, and it’s where the money is. It means an agent that reads from SAP, writes to Salesforce, respects a permission model nobody fully documented, and survives a compliance review. The bottleneck there was never intelligence; the frontier models have been good enough for this for a while. The bottleneck is the institutional knowledge to wire a capable model into a messy organization without breaking it, and that knowledge doesn’t live in the model card. It lives in the engineer standing in the customer’s data center.
That’s the structural gap, and the FDE is the role we invented to stand in it.
What the interview actually tests
This is where the rebranding theory falls apart fastest. If FDE were sales engineering, the loop would test polish. It doesn’t. After going through several hundred of these questions, the pattern is hard to miss: the loop tests whether you can stay technically rigorous under maximum ambiguity.
A few things come up again and again:
- System design with the customer’s constraints baked in. Not “design Twitter.” Design a retrieval system when the documents are governed by row-level access control and the customer will not let the data leave their VPC. The constraint is the question.
- Debugging data you didn’t create. You’re handed an eval that’s failing and a pipeline you’ve never seen. Why is recall tanking on one document class? The honest answer usually involves the ingestion step, not the model.
- Eval design from scratch. “How do you know it’s working?” is asked more seriously here than anywhere else in tech, because the customer will ask it on day one and there’s no leaderboard to point at.
- Explaining a tradeoff to someone who doesn’t code. You will defend a latency-versus-accuracy decision to a VP. The screen checks whether you can do it without retreating into jargon.
- The unglamorous fundamentals. SQL that actually runs. A coding round closer to “parse this gnarly real-world format” than “invert this binary tree.”
None of it is theater. It’s the job, compressed into an afternoon.
If you want to prep against the real thing rather than the rebrand, FDE Interviews has the most concentrated bank of these questions and concepts I’ve come across, and it’s a good place to pressure-test yourself before the loop.
Why vertical specialists win
A generalist FDE can deploy anywhere and adds value everywhere. A vertical specialist, someone who knows why a financial-services client cares about trade-reconciliation latency or what a healthcare regulator will actually flag, becomes the person the deal can’t close without.
Financial services is the fastest-growing segment, precisely because its complexity is the kind that defeats a generic deployment: compliance, fraud, and coordination across systems that were never meant to talk. Healthcare and defense follow for the same reason, with a clearance premium stacked on top. The lesson for anyone targeting the role is simple. Pick a domain and go deep enough to understand its failure modes, not just the happy path.
What hiring managers actually weight
The signals that predict success here aren’t the ones a FAANG résumé optimizes for.
- Founder or early-stage experience beats pedigree. It predicts comfort with owning an outcome instead of a ticket.
- A teaching or TA background is the best proxy for customer empathy I’ve seen. Explaining hard things to people who don’t share your context is the job.
- Service orientation and raw drive count for more than credentials.
There’s one common red flag, stated plainly by the people who hire for this: pure big-company experience with no early-stage exposure. It isn’t that those engineers aren’t good. It’s that the role punishes a wait-for-the-spec reflex, and big companies train that reflex hard.
The honest tradeoffs
I won’t pretend this is free money for the technically curious.
It’s two demanding jobs in one. You’re embedded with a customer and also expected to contribute to the core product, and those two masters don’t coordinate their deadlines. The travel is real. The ambiguity is constant. You’re often the most senior person in the room on a problem nobody has fully specified, including you, an hour ago.
The payoff is leverage. You sit on top of the single largest gap AI has opened, the distance between a model that can do something in a demo and a system that does it in production every day, for a customer who is paying. That’s why the most common exit from the role is founding a company. You watch the same enterprise failure ten times, and at some point you realize you have the tools to fix it and the relationships to sell the fix.
What it comes down to
The model is the easy part, and it has been for a while. The hard part is the customer’s data, their permissions, their people, and the gap between what they asked for and what they actually need. The Forward Deployed Engineer is the role that absorbs all four. It isn’t a solutions architect in a hoodie. It’s the person who makes the demo true.