On this page
Key takeaways
- FDE interviews test how you handle a messy business problem more than raw coding.
- The 25 questions fall into five areas: discovery, data access and security, evals, agent design, and production handover.
- Strong answers name the owner, the data, the test and the exit plan before they name a framework.
- Bloomberry found that about 60% of the 1,000 FDE job postings it analysed describe a builder role.
Forward deployed engineer (FDE) interviews do not look like a normal software interview. You will still write code, but most of the signal comes from how you handle a messy business problem: who you talk to first, what you refuse to build, how you prove it works, and how you leave.
Bloomberry analysed 1,000 FDE job postings and found that about 60% describe a builder role: embedded with the customer, writing production code and owning the result. The rest are mostly sales engineer style roles plus a smaller group of internal tools roles. This question bank is for the builder role.
We have grouped the questions by what they test. For each one we list what a good answer covers. There are no model answers to memorise. Interviewers are listening for how you think, and a memorised answer is easy to spot.
1. Discovery: can you find the real problem?
Try it first: turn on practice mode to hide the answers, think through each question, then reveal.
A business team asks for "an AI agent for invoice queries". What do you ask in the first meeting?
What a good answer covers
who handles these queries today and how many, what a correct answer looks like, which systems hold the data, what the agent is allowed to change, and who signs off. Strong candidates ask to sit with the person doing the work.
How do you pick the first workflow to build?
What a good answer covers
a narrow workflow with real volume, data you can actually get, a clear owner, and a way to measure success. Weak answers pick the most impressive workflow.
When would you say no to a use case?
What a good answer covers
no owner, no way to test correctness, data you can not access, or a cost of error the business can not accept. A good answer also proposes what to do instead.
The stakeholder's description of the process does not match what you see users doing. What now?
What a good answer covers
trust the observed process, write down the exceptions, and confirm the rules with the owner before encoding them.
How do you know the engagement is finished?
What a good answer covers
agreed exit criteria written at the start, a production workflow, and a named owner who can run it without you. Andreessen Horowitz argues that forward deployment should be treated as scaffolding, not the house; the interviewer wants to hear that you plan the exit.
2. Data access and security: can you get to real data safely?
Walk me through a data access request you would write.
What a good answer covers
the workflow in one sentence, fields needed and fields not needed, read or write, the service account owner, where the model runs and what data stays there.
Security says no. What do you do?
What a good answer covers
ask what the specific concern is, reduce scope (fewer fields, read only, masked data), and come back with a smaller request. Not escalation as the first move.
How do you handle personal data in prompts and logs?
What a good answer covers
minimise what you send, mask or drop identifiers, decide log retention, and check where the model is hosted.
What does an agent need to be allowed to do, and what should always need a human?
What a good answer covers
read actions free, reversible writes with logs, irreversible or external actions behind an approval step.
What would an auditor ask for after your agent has been live for a month?
What a good answer covers
a log of every action with inputs, outputs and who approved, the eval results over time, and the change history of prompts and models.
3. Evals: can you prove it works?
How do you build an eval set for a workflow you have never seen?
What a good answer covers
collect real past inputs including messy ones, write the expected output with the business owner, and agree on how each case is graded.
When would you use exact match, a rubric, or an LLM as judge?
What a good answer covers
exact match for structured outputs, rubrics for free text, LLM as judge only when it is checked against human grades on a sample.
Your accuracy number went up after a prompt change. Do you ship?
What a good answer covers
check which cases changed, look for regressions, confirm the eval set still represents real traffic.
What is a baseline and why does it matter?
What a good answer covers
the score on day one is the number you defend; without it, "better" is an opinion.
Three weeks after launch, users complain but your evals still pass. Why?
What a good answer covers
the eval set was frozen while inputs changed, upstream data changed, or a tool started failing silently. The fix is to turn complaints into eval cases every week.
4. Agent design: can you build something that holds up?
Single agent or multi agent for this workflow?
What a good answer covers
start with one agent and clear tools; add more only when one agent can not hold the context or the roles have different permissions.
How do you design a tool for an agent?
What a good answer covers
fewer, sharper tools with typed inputs and outputs, clear error messages, and permission checks inside the tool.
How does the loop end?
What a good answer covers
a done condition, a turn cap, an error policy, and what state is kept between turns.
Where do you put the human in the loop?
What a good answer covers
at actions that are hard to reverse, at low confidence, and at the first runs of any new tool.
How do you estimate the running cost of this agent?
What a good answer covers
cost per completed task, not per token: tokens per call, calls per task including retries, and the share of tasks that need a human fix.
5. Production and handover: can you leave?
What goes in a handover pack?
What a good answer covers
a runbook, the eval set and how to extend it, the owner, the escalation path, and known failure modes.
The system is up but giving wrong answers. What does the runbook say?
What a good answer covers
how to spot a bad output, where the eval set lives, how to add a failing case, and who to tell.
How do you monitor an agent in production?
What a good answer covers
task success, human override rate, latency, cost per task, and drift in input types.
Tell me about a time you shipped something on real data. What blocked you?
What a good answer covers
a specific story with the blocker, what you did, and what you would do differently. This is the question where real experience shows.
How would you explain this system to the business owner in five minutes?
What a good answer covers
what it does, what it does not do, how you know it works, and what they do when it is wrong.
How to practise
Pick five questions, one from each section. Answer them out loud against a real workflow you know, then ask a friend to push back. The goal is not a perfect answer. It is to show that you think about owners, data, tests and exits before you think about frameworks.
If you want to practise this on a real build, with your work assessed rather than your attendance, the AIXL Academy Forward-Deployed AI Engineering cohort is built around exactly these areas.
Sources
- Bloomberry, "I analyzed 1,000 forward deployed engineer jobs": https://bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/
- Andreessen Horowitz, "The Palantirization of everything": https://a16z.com/the-palantirization-of-everything/
Written by
AIXL Academy
AIXL Academy trains engineers to build and ship AI systems for real customers. Subscribe by RSS or follow the AIXL Academy page on LinkedIn for new question banks.
Keep reading
Interview questions
LLM evals cheat sheet: what to check, how, and when
A one page guide to evaluating LLM and agent systems: code checks, rubrics, model judges, eval sets and when to run them.
Interview questions
AI engineering system design interview questions, with what good answers cover
Common system design questions for AI engineer and forward deployed engineer interviews, and what a strong answer covers for each.