Forward deployed engineer interview questions and answers

• 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."

• 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.

• 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.

• 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 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."

• 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".

• 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".

• 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.

• 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.

• 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.