# Forward Deployed Engineer Interview Questions and Answers
FDE loops test whether you can ship a model into someone else's systems, prove it with their evidence, and leave something that keeps working.
11 min read · Advanced · Lesson 4 of 7 in Interviews and careers · Updated 2026-10-03 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/forward-deployed-engineer-interview-questions/
> **In short.** Forward deployed engineer interviews test three things at once. Can you build production software in
> an environment you do not control, turn a vague customer ask into a provable scope, and leave behind
> something that keeps working and feeds the product? These ten questions probe each, with the
> framework, a strong answer, the follow-up that finds your limit, and the red flag.
**In this lesson** you'll practise:
- the questions that separate an FDE from a strong engineer who has never worked inside a customer;
- a framework and a strong answer for each, with the follow-up that tests it;
- the deliverables and feedback duty that AI labs name in their own postings.
## Sound familiar?
- Your system-design answers assume you control the data, the network and the identity model.
- Your best story is a demo that impressed an executive.
- You have never had to say no to a customer with the contract on the line.
FDE interviews are built around exactly those gaps.
## What does an FDE interview test?
**Engineering inside someone else's constraints, with their evidence, towards an outcome you own.** The
public postings make the scope plain: OpenAI's FDEs own discovery, technical scoping, system design, build
and production rollout, and are measured by production adoption and by eval-driven feedback that changes
product and model roadmaps; Anthropic's build production applications inside customer systems and deliver
artefacts such as MCP servers, sub-agents and agent skills, then codify repeatable patterns. Expect
coding, a system design set in a customer's world, a decomposition or case exercise, and deep
behavioural questions about customers. [What is an FDE?](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/what-is-a-forward-deployed-engineer/)
The ten questions follow the job's three stages, as
[the forward-deployed engineer guide](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/) sets them out: Frame (Q1 to
Q3), Deliver (Q4 to Q8) and Evolve (Q9 and Q10).
## Frame: discover and scope
### Q1 · "Walk me through your first two weeks at a new enterprise customer."
**Tests:** whether you know where engagements actually stall · **Framework:** discover → scope → prove →
hand over, with lead-time items first
What a strong answer covers
- **Day one, the lead-time items**: model access in the right regions, data access, network and identity,
the security review. They set the calendar, not the build.
- **Measure the pain in their data**: cases, minutes, money, and who owns the risk.
- **Pick a provable first slice**, and write the AI-fit verdict with what was rejected.
- **A walking skeleton in their environment** as soon as one access passes: their authentication, their data path, no model.
- **Agree what done means**: the bar per slice, signed by their risk owner, and the evidence that will prove it.
- **The insight:** most engagement risk is access and alignment, not the model. An FDE who starts with the
model is usually waiting for a firewall rule by week three.
**The follow-up:** "The security review takes six weeks." → start it on day one, build against redacted or
synthetic data meanwhile, and design for their constraints: private networking, no data leaving the account.
**Red flag:** "I'd build a quick demo first."
What a strong answer covers
- **Build it**, on representative redacted or synthetic data, and **frame it honestly**: it shows the
workflow, not the accuracy.
- **Use the demo to elicit requirements**: watch what the executive asks about and what they skip.
- **Push the data access in parallel**, and say when real numbers will exist and who will label them.
- **The insight:** the danger of a good demo is that it becomes the success criterion. Name the evidence
that will replace it before anyone leaves the room.
**The follow-up:** "The executive loves it and wants it live next week." → a shadow run beside their staff,
a bar per slice, and the first slice only.
**Red flag:** presenting demo results as accuracy.
What a strong answer covers
- **AI-fit first**: the answer may be a rule or a workflow.
- **Then configuration**: can the product do it as shipped, with settings?
- **Then the pattern test**: is it something you have seen at other customers? A third occurrence is a
product gap, not a customer request.
- **Say no** when the use case cannot meet its bar, the damage is irreversible, or nobody at the customer
will own it after you leave.
- **The insight:** every bespoke build is a liability the customer inherits. An FDE's value includes the
complexity they keep out of the customer's estate.
**The follow-up:** "The customer insists." → a time-boxed pilot with exit criteria and a named owner.
**Red flag:** always building.
What a strong answer covers
- **Real contracts, redacted, labelled by the customer's lawyers**, never by the model.
- **Slices**: clause types, jurisdictions, contract families, plus an abstention slice for genuinely ambiguous
clauses.
- **A checker per kind of step**: exact checks for extracted fields such as dates and amounts; a rubric and a
calibrated judge for summaries.
- **Report per slice with lower bounds**; fifty cases per slice to start finding problems, more where the
score sits near the bar.
- **The insight:** measure how often the lawyers agree with each other first. Their agreement rate is the
ceiling on any bar; an agent cannot be held to 95% on work experts agree on 85% of the time.
**The follow-up:** "The lawyers disagree 15% of the time." → adjudicate a gold label, report agreement with
it, and set the bar with that ceiling in view.
**Red flag:** a public benchmark, or labels generated by a model.
What a strong answer covers
- **What differs**: data (formats, encodings, longer documents that overflow the context), tools
(authentication, rate limits, latency causing timeouts and retries), model access (region, inference
profile, failover to another model), network (proxies), permissions.
- **Log what answered and what happened**: the answering model, tokens per call, tool errors, turns per task.
- **Reproduce with their data** before changing anything.
- **The insight:** a tool that returns an empty result on error reads to the model as "nothing applies".
Tools must fail loudly, with the error as the result, or the agent confidently answers the wrong question.
**The follow-up:** "Answers got worse, and there are no errors." → silent failover or drift: which model
answered, and what changed in the inputs?
**Red flag:** "I'd rewrite the prompt."
What a strong answer covers
- **Map the steps**: read the exception (exact), classify the cause (best-guess), look up records (exact
tools), propose a resolution (best-guess), execute it (consequential).
- **Authority per action**: read tools open; writes gated; payments never autonomous at first, with a named
approver, caps in the tool signatures, and idempotency keys so a retry cannot pay twice.
- **Tools as MCP servers** over the bank's core systems, each with its own least-privilege identity.
- **An audit trail as a product requirement**: who, what, why and on what evidence, redacted, for every action.
- **Prove it**: per-slice bars, then a shadow run against the operations team.
- **The insight:** in a bank, the explanation of a decision is the evidence it was based on (the records
and tool calls), not a paragraph the model writes afterwards.
**The follow-up:** "The regulator requires an explanation of every decision." → store the evidence with
each decision and generate explanations from the trace.
**Red flag:** one agent with broad credentials and a prompt that says "be careful".
What a strong answer covers
- **Code in their repository**, with tests, a context file and decision records.
- **The harness and golden sets**, running in their CI.
- **Runbooks with timed rollbacks**, a drift chart, a cost-per-case report, each with a named owner.
- **The authority budget and the refusal tests** for every cap.
- **Back home**: the patterns, written up (the MCP server, the skill, the sub-agent) for the product team.
- **The insight:** the test of an FDE is what keeps working when they are no longer in the room.
**The follow-up:** "Who owns the cost and incident loops?" → a named person each, agreed before you leave.
**Red flag:** "the code".
What a strong answer covers
- **Find which actions carry the review load.** Often most reviews are on reversible, low-risk actions.
- **Remove review there, or add a veto window**, rather than raising autonomy on irreversible ones.
- **For any action moving up a level**, show the evidence: a lower bound above its bar without the human
hold, and shadow agreement per slice.
- **Keep money actions gated.**
- **The insight:** "more autonomy" is usually a request for less friction, and friction can be cut without
touching the actions that can hurt anyone.
**The follow-up:** "Their competitor's agent does it without approval." → then ask what that competitor's
incident rate is, and show what evidence would justify the change here.
**Red flag:** flipping the switch, or refusing without an alternative.
What a strong answer covers
- **Put them in charge of what "right" means**: their expertise builds the golden set.
- **Show them the disagreements** from the shadow run, and let them adjudicate.
- **Give them a veto on the bar** for their area, and credit their requirements by name.
- **Find the part of their own workload** they would like to hand off.
- **The insight:** sceptics make the best evaluators. Their objections are test cases you were missing.
**The follow-up:** "They still refuse." → escalate the decision, not the person, with the evidence.
**Red flag:** going over their head first.
What a strong answer covers
- **The repeat**: the same connector, evaluation or approval flow built at more than one customer.
- **What you built instead**: a configurable, tested asset (an MCP server, a skill, a harness template).
- **The number**: time saved at the next deployment, or defects avoided.
- **The change**: how it reached the product team and changed a roadmap item. That is the eval-driven feedback
the role exists to produce.
- **The insight:** an FDE's lasting effect is the loop back into the product. Delivery alone does not scale.
**The follow-up:** "What did the product team reject, and why?" → shows you understand product trade-offs.
**Red flag:** only bespoke delivery stories.
Show the answer
**Yes to the backlog, no to unsupervised refunds, and a date for the evidence.** Agree the goal, then
split it: the agent can triage and draft the whole backlog this week, with people approving every refund;
refunds under a cap can move to a veto window once a shadow run shows agreement with their staff on that
slice. Put the cap in the refund tool itself, and name the day the shadow numbers will be ready. You have
kept the momentum and the customer's money safe in the same sentence.