Forward deployed engineering: the complete guide / Building the function
How to interview a forward deployed engineer
A forward deployed engineering loop has to test three things in roughly equal weight: engineering depth, judgment in front of a customer, and the ability to reason out loud through ambiguity. That makes it different from a standard engineering loop, where the third is barely assessed. The signature round is an ambiguous case: a vague problem from a hypothetical customer, which the candidate has to decompose into a plan. The most common reason strong engineers fail it is jumping to a solution before scoping the problem.
Key takeaways
- Weight the loop roughly equally across engineering depth, customer judgment, and reasoning through ambiguity.
- The signature round is an ambiguous case study. Score the scoping, not the answer.
- The most common failure is proposing a solution before establishing constraints. Make that an explicit scoring line.
- Keep the coding bar at your normal engineering standard. First Round Review is explicit that candidates should clear a rigorous engineering interview.
This page is for the hiring side: how to design the loop and what each stage should tell you. A standard engineering loop will not surface the things that decide success here.
What the loop has to measure
Three dimensions, roughly equally weighted.
Engineering depth. Can they write production code in an unfamiliar system. Non-negotiable, and the one most often traded away.
Customer judgment. Can they be in a room with a frustrated stakeholder and leave it with a clearer problem than they entered with.
Reasoning through ambiguity out loud. Can they take a vague brief and turn it into constraints, questions and a plan, while thinking audibly enough that you can follow the reasoning.
The third is what a normal loop does not test. It is also the one that most predicts whether somebody survives week three of a real engagement.
A five-stage loop
Stage one: screen. Confirm the basics and be honest early about travel and compensation shape. Say your travel number here rather than at offer. Wasting a candidate's fourth interview on a dealbreaker you knew about is avoidable.
Stage two: coding. Your standard engineering exercise, at your standard bar. First Round Review is explicit that this should be rigorous and should not be compromised, because the role writes production code.
Prefer an exercise in an unfamiliar codebase over a whiteboard algorithm. The job is reading somebody else's system and changing it safely, so test that.
Stage three: the ambiguous case. The signature round, covered below.
Stage four: production ownership. Ask them to walk through something they owned end to end. Push for the unglamorous parts: the security review, the release process, the incident, the handover. The framing to listen for is customer problem, then technical choice, then the trade-off, then the measured result.
Stage five: the trenches conversation. Someone senior, unstructured, testing the bar Shilpa Balaji describes in First Round's piece: would you want to be in the trenches with this person. Also the right stage to answer their questions honestly, because good candidates for this role are evaluating you at least as hard.
The ambiguous case round
Give them a vague problem in a plausible customer context. Something like: a mid-sized insurer wants to use AI to speed up claims triage, their data is in three systems, nobody can tell you what accurate means, and the person who asked for it is not the person who will use it.
Then stop talking and watch what they do.
What a strong candidate does. Asks who the user is. Asks what happens today and what it costs. Asks what accurate would have to mean before anybody would trust it. Asks what happens when the system is wrong. Establishes constraints before proposing anything. Then proposes something small that could be running in a fortnight, and says what it would teach them.
What a weak candidate does. Proposes an architecture in the first three minutes.
That is the single most common failure, and it is worth making an explicit line on the scorecard: did they scope before solving. An engineer who jumps to a solution in an interview will jump to a solution in somebody's production environment, which is how you get a system that solves the described problem rather than the real one.
What to score, specifically
- Did they establish who the user is
- Did they ask what correct means, and notice that nobody knows yet
- Did they ask about the failure path
- Did they identify what they would ship first, and why that thing
- Did they say what they do not know
- Did they change their mind when you gave them a new fact
That last one matters more than it looks. Give them a piece of information halfway through that invalidates their approach, and see whether they adjust or defend.
Do not run these
A pure algorithm gauntlet. It tests something the job does not need and screens out people who would be excellent at it.
A take-home that builds a full feature. The candidates you want most are employed and busy. A long take-home selects for availability.
A presentation round with slides. It tests polish. The job is not polish.
A culture-fit round with no scoring rubric. It reliably measures similarity to the interviewer, which is the opposite of what this role needs given the range of environments the person will work in.
Calibrating against the market
Useful context when setting the bar. Across 1,000 postings, 60 percent targeted three to five years of experience and 20 percent six to eight, so this is a mid-level role in most companies. Customer communication was the most-named soft skill at 47 percent.
You are competing for these candidates against companies who will pay well, so a slow loop loses. Decide fast, and tell candidates the timeline you will actually hold to.
One question to add if AI writes your code
Ask how they would know a change was correct if a model wrote it.
The answers separate quickly. Weak answers describe reading the diff carefully. Strong answers talk about deriving checks from the specification before the code exists, and about not letting the thing that wrote the code be the thing that grades it. That is the discipline eval-driven development describes, and in a customer's production environment it is the difference between speed and liability.
Next: where the function should report, which affects who these people work for once hired.
Best for
- Designing a hiring loop for an embedded engineering role
- Writing a scorecard for the ambiguous case round
- Diagnosing why your loop keeps passing people who then struggle
Avoid if
- You are a candidate preparing, since this is written for the hiring side
Verify before you commit
- Confirm the loop weights engineering depth, customer judgment and ambiguity roughly equally
- Add an explicit scorecard line for scoping before solving
- Introduce a fact mid-case that invalidates the approach, and score the adjustment
- Keep the coding round at your normal engineering bar
Common questions
How is a forward deployed engineer interview different from a normal engineering loop?
It weights three things roughly equally: engineering depth, judgment in front of a customer, and the ability to reason through ambiguity out loud. A standard loop tests the first well and barely tests the third, which is the dimension that most predicts whether somebody survives a real engagement.
What is the ambiguous case round?
A vague problem in a plausible customer context, where the candidate has to decompose it into a plan. For example an insurer wanting AI claims triage, with data in three systems, no definition of accurate, and the requester not being the user. You present it and then watch what they do rather than steering.
What is the most common reason candidates fail?
Proposing a solution before scoping the problem. Make it an explicit scorecard line. An engineer who jumps to an architecture in the first three minutes of an interview will do the same in somebody's production environment, which produces a system that solves the described problem rather than the real one.
Should you lower the coding bar to get customer skills?
No. First Round Review is explicit that candidates should clear a rigorous engineering interview, because the role writes production code. Prefer an exercise in an unfamiliar codebase over a whiteboard algorithm, since reading somebody else's system and changing it safely is the actual job.
What interview formats should you avoid?
A pure algorithm gauntlet, which tests something the job does not need. A long take-home, which selects for availability rather than ability. A slide presentation round, which tests polish. And an unscored culture-fit round, which measures similarity to the interviewer, the opposite of useful for a role spanning many environments.
What should you ask if your code is AI-generated?
How they would know a change was correct if a model wrote it. Weak answers describe reading the diff carefully. Strong answers describe deriving checks from the specification before the code exists, and not letting the thing that wrote the code grade it.
How a build like this runs
Related reading
How to interview an engineer in the age of AI
The take-home and the whiteboard both stopped working, and for the same reason. What is left worth testing is judgment: debugging code you did not write, finding what a spec leaves out, and deciding what not to build.
Never let the model grade its own work
When the same run writes the code and the tests, a green build proves the code agrees with itself. That is not verification, and it is the most common way an AI-built codebase becomes confidently wrong.
More in Building the function
How to build a forward deployed engineering team
Before hiring anyone, confirm three prerequisites: your customers are enterprises, your product is still flexible enough to change based on what you learn, and their use cases differ from each other. First Round Review names all three, and missing two means do not start. Then begin with two or three engineers on your highest-value accounts only, report the function into product or engineering rather than sales, and give somebody the job of turning field work into product from the first month. Those last two decisions determine whether the function becomes a moat or a cost centre.
Forward deployed engineer job description
Most forward deployed engineer job descriptions fail in the same two places: they do not say which of the three jobs the role actually is, and they hide the travel. Across 1,000 postings carrying the title, 60 percent were production engineering roles, 30 percent were sales engineering with implementation duties, and 10 percent faced no external customer. 68 percent required travel, with 50 to 75 percent typical where a number was given. State both in the first hundred words and your funnel gets smaller and much better.
How to hire a forward deployed engineer
The candidates come mostly from software engineering: across 1,000 postings, 45 percent of routes into the role came from software engineering, 22 percent from solutions or sales engineering, 15 percent from data, 10 percent from technical consulting and 8 percent from founding or early-employee roles. First Round Review names five qualities that predict success and one counter-intuitive red flag: ten or more years at a large tech company, because the role needs somebody who operates without institutional scaffolding. Do not lower the engineering bar to get customer skills.
Where forward deployed engineering should report
Forward deployed engineering should report into product or engineering, not sales, and not a separate professional services unit. Marty Cagan's warning is direct: if embedded engineers sit in a professional services group, you lose the feedback loop and drift toward a pure services business. The hiring data suggests most of the market has already made the wrong choice, with only 45 percent of 1,000 postings sitting on a dedicated forward deployed team rather than under sales. This is a nearly free decision at the start and expensive to reverse later.
The forward deployed to product engineer ratio
There is no credible published benchmark for the ratio of forward deployed engineers to product engineers, and we are not going to invent one. What exists is arithmetic you can do with your own numbers, and one documented floor: First Round Review reports Looker validating $25,000 or more in annual contract value before committing to the model. Size the function from account count, deployment length and the contract value that has to carry it, then check the result against whether your revenue per embedded engineer is rising.
The productization loop
The productization loop is the mechanism that turns one customer's custom work into a capability every customer gets. It needs three things: a fixed cadence, a named owner, and a stop rule. First Round Review's version of the stop rule is the useful one: expand scope when the work creates repeatable software value, and halt when the iteration only serves a single customer. Without this loop, embedded engineering produces what a16z describes as bespoke deployments impossible to maintain or upgrade, where revenue grows and nothing compounds.