# Forward deployed engineer interview questions: 25 questions and what a good answer covers

URL: https://aixl.academy/blog/fde-interview-questions/
Published: 2026-11-03
Updated: 2026-11-03
Author: AIXL Academy
Topics: forward deployed engineering, interview questions, ai engineering, evals, agentic ai

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?

**1. A business team asks for "an AI agent for invoice queries". What do you ask in the first meeting?**
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.

**2. How do you pick the first workflow to build?**
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.

**3. When would you say no to a use case?**
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.

**4. The stakeholder's description of the process does not match what you see users doing. What now?**
Covers: trust the observed process, write down the exceptions, and confirm the rules with the owner before encoding them.

**5. How do you know the engagement is finished?**
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?

**6. Walk me through a data access request you would write.**
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.

**7. Security says no. What do you do?**
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.

**8. How do you handle personal data in prompts and logs?**
Covers: minimise what you send, mask or drop identifiers, decide log retention, and check where the model is hosted.

**9. What does an agent need to be allowed to do, and what should always need a human?**
Covers: read actions free, reversible writes with logs, irreversible or external actions behind an approval step.

**10. What would an auditor ask for after your agent has been live for a month?**
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?

**11. How do you build an eval set for a workflow you have never seen?**
Covers: collect real past inputs including messy ones, write the expected output with the business owner, and agree on how each case is graded.

**12. When would you use exact match, a rubric, or an LLM as judge?**
Covers: exact match for structured outputs, rubrics for free text, LLM as judge only when it is checked against human grades on a sample.

**13. Your accuracy number went up after a prompt change. Do you ship?**
Covers: check which cases changed, look for regressions, confirm the eval set still represents real traffic.

**14. What is a baseline and why does it matter?**
Covers: the score on day one is the number you defend; without it, "better" is an opinion.

**15. Three weeks after launch, users complain but your evals still pass. Why?**
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?

**16. Single agent or multi agent for this workflow?**
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.

**17. How do you design a tool for an agent?**
Covers: fewer, sharper tools with typed inputs and outputs, clear error messages, and permission checks inside the tool.

**18. How does the loop end?**
Covers: a done condition, a turn cap, an error policy, and what state is kept between turns.

**19. Where do you put the human in the loop?**
Covers: at actions that are hard to reverse, at low confidence, and at the first runs of any new tool.

**20. How do you estimate the running cost of this agent?**
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?

**21. What goes in a handover pack?**
Covers: a runbook, the eval set and how to extend it, the owner, the escalation path, and known failure modes.

**22. The system is up but giving wrong answers. What does the runbook say?**
Covers: how to spot a bad output, where the eval set lives, how to add a failing case, and who to tell.

**23. How do you monitor an agent in production?**
Covers: task success, human override rate, latency, cost per task, and drift in input types.

**24. Tell me about a time you shipped something on real data. What blocked you?**
Covers: a specific story with the blocker, what you did, and what you would do differently. This is the question where real experience shows.

**25. How would you explain this system to the business owner in five minutes?**
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/