The FDE Interview Question Bank

Fifty-plus reported Forward Deployed Engineer interview questions across all nine round archetypes — each with the model answer shape and a link to practise it.

Decomposition round — reported prompts

Analyse a city’s taxi data to improve the fleet: Open with: who is the user — driver, dispatcher, or city? What decision changes? Then constraints (what data exists, who owns it), then 3 prioritised sub-problems, then depth on one. Practise it
How would you improve 911 response times?: Trap: proposing routing optimisation immediately. Do: define “response time” (call→dispatch, dispatch→arrival?), find where the minutes actually go, then attack the biggest segment. Practise it
Unify fraud signals scattered across five systems: Frame as: entity resolution + latency budget + false-positive cost. Ask what an analyst does today and what a missed case costs versus a false alarm. Practise it
Design a system to help a ride-hailing marketplace: Ask: which side of the marketplace, which metric, what timeframe. Marketplace questions are a test of picking one side and defending it. Practise it
A hospital wants to reduce readmissions with AI: Do: ask who acts on the prediction and when. A model nobody can act on within the discharge window is worthless. Define the intervention before the model.
How would you scope this if you had two weeks, not two quarters?: The real question. Name the one workflow, the one metric, the one user, and the four things you drop. Say what you would learn that changes the plan.

Learning round

Here is an undocumented internal library — use it to do X: Method: skim the structure first, say your mental model aloud, ask one precise question about the genuinely ambiguous part, then use it. Practise it
Reported Palantir variant: a custom package installer with concurrency: Watch for: ordering guarantees and shared state. Say what you have not yet understood — bluffing is the fastest fail in this round.
Explain back what you just read: Answer shape: the purpose, the two or three key abstractions, the one thing that surprised you, and what you would check before relying on it.
How do you get up to speed in an unfamiliar domain?: Concrete method beats enthusiasm: read the artefacts the team already produces, shadow one person for a day, build a glossary, then teach it back to a domain expert and let them correct you. Handbook

Incremental coding — escalating constraints

Build a cache → make it LRU → make it bounded → make it thread-safe: Do: write the simple extensible version first. Say what breaks before you refactor. Practise it
Reported Anthropic family: LRU, call-stack manipulation, deduplication: Each part invalidates the previous shape. A compressed clever solution that cannot absorb the next constraint is the trap. Practise it
Reported Sierra: evaluate a spreadsheet of formulas → now detect cycles: Topological evaluation, then cycle detection. Structure the first version so the graph is explicit and the second stage is a small addition. Related drill
Now make it handle 10× the data: Ask whether it is memory or latency that matters, then change one thing and say why. Streaming, batching or an index — not all three.

Debugging & re-engineering

This aggregation double-counts. Find out why.: Classic planted bug: a dictionary/HashMap keyed on a mutable or non-unique field. Method: reproduce, narrow to the smallest failing input, then read. Practise it
This pagination loop misses records: Off-by-one on the cursor, or re-reading page 1 after a token refresh. Verify by counting distinct ids, not pages. Related drill
This graph traversal reports the wrong spread: Visited-set placed after the recursive call instead of before, or a queue used where a set is needed. Practise it
Three bugs are planted in this codebase. Find them.: Scored on method, not speed: read fully, hypothesise, add the smallest instrument, fix, verify, then check whether the same class appears elsewhere. Narrate every step. Sierra loop
Why is this integration slow only in production?: Ask about data volume, network egress, and whether retries are stacking. Production-only means environment: data shape, latency, or concurrency.

Take-home & defence

Why this structure and not the obvious alternative?: Have three trade-offs written down while building. Naming the rejected alternative is the answer. Playbook
What did you decide not to build, and why?: The single highest-scoring question in the round. An explicit not-building list in the README pre-answers it.
How do you know it is correct?: Tests for hard properties, an eval with a stated metric and target for fuzzy output. “It works” with no evidence is the weakest claim you can make. Evals
What happens if this call times out halfway through?: Answer with idempotency, retry-with-jitter, and what the user sees. Drill
Where did you use AI, and what did you reject?: Transparency scores where AI is permitted. Never explain a decision by attributing it to a tool — the artefact is yours. Distyl rules
What would you do with two more days?: Converts every gap from an oversight into a stated trade-off. Always include it in the write-up.

Client roleplay & case

The customer wants a feature you know will not solve their problem: Ask what outcome they are after, name the mismatch plainly, offer a path that gets the outcome. Never just comply, never just refuse. Practise it
Your demo fails live in front of their CTO. Next sixty seconds?: Name it, scope it (“this is the ingest path, not the model”), commit to a time, keep going with the rest. Handled well, it builds more trust than a flawless demo. Practise it
Security is blocking your access to the data. Two weeks gone.: Show you keep momentum while blocked: synthetic data, the parts that do not need access, and a parallel escalation with a named owner and date. Handbook
A middle manager is quietly undermining the rollout: Assume a rational interest, not villainy — usually headcount or credit. Find what they win. Escalating first is the failure. Practise it
The executive wants a number you cannot honestly give yet: Give the number you can stand behind, the date you will have the real one, and what would change it. Never invent precision.
How would you measure whether this deployment succeeded?: Adoption (who uses it weekly), the workflow metric (time or error rate), and eval quality on a held-out set. Have all three ready. Handbook

Values & judgement

A customer wants to use the system for something you think is a bad idea: Specific past example beats principle. Say what it cost you to raise it. Anthropic loop
Tell me about a time you were wrong and it mattered: A real error, the mechanism of the error, what you changed structurally afterwards. “I learned to communicate more” is not an answer.
What would make you refuse to ship something?: Have a threshold and a story where you applied it. Vague ethics with no example is the modal failure of this round.
How do you handle disagreeing with your own company’s position?: Show the escalation path you actually used, and that you eventually committed to a decision either way.
Describe a risk you flagged that was inconvenient: Good judgement stories have a price attached: a delay, a hard conversation, a lost deal.

Customer-flavoured system design

Design ingestion for 200k webhooks a day with a 2-hour outage window: Queue + idempotency keys + dead-letter + replay. Say who operates it after you leave. Design
A bank will not share a database. Design multi-tenant isolation.: Isolation levels and their cost curve: row → schema → database → deployment. Pick one and defend it against the compliance requirement. Design
They need an audit trail a regulator will accept: Append-only, tamper-evident, who-saw-what, retention policy, and export. Design
The model must run on-prem with no internet: Weight delivery, update path, licensing, observability without egress. Design
Design RAG over their confidential document store: Permissions at retrieval time, not just at index time — the most common enterprise RAG failure. Design

Behavioural ownership

Tell me about something you shipped that nobody adopted: The most FDE question there is. Own the diagnosis: wrong problem, wrong user, or wrong moment — and what you would have detected earlier.
When did you tell a customer no?: Include how the relationship ended up stronger. Saying no badly is easy; the round is about doing it well.
Walk me through a deployment end to end: Discovery → scope → build → integrate → deploy → measure → hand off, with one number and one mistake. Rehearse this until it is four minutes.
Describe the hardest stakeholder you have worked with: No villains. Describe their incentive, what you tried, what worked, what you would do differently.
What did you get wrong that you would do differently?: Have one that is genuinely costly. Candidates who offer a safe non-mistake read as untested.
Why FDE and not product engineering?: Because you want the whole arc — problem to production to a person using it — and the customer half energises rather than drains you. Comparison

Questions to ask them

What percentage of my time is expected to be writing code?: Separates a builder FDE role from a pre-sales-shaped one wearing the title.
Show me something an FDE built last quarter that is now in the product: The strongest single anti-services-trap signal. A specific answer is a strong buy.
Is any part of my review tied to utilisation or billable hours?: If yes, the incentive on your time has inverted. Why it matters
What is the travel expectation, in writing?: Uncompensated cost. Get it before signing, not after.
How does an engagement end, and who is on-call after handoff?: Defines both your ownership and your nights.
Who defines success for a deployment, and is it written down first?: An org that cannot answer this will judge you against a moving target.

Go deeper

FDE interview prep: all 9 rounds →Decomposition Round Simulator →Client Roleplay Simulator →The FDE Playbook →