A VP opens the call: "We want AI to stop our fraud losses." That's it. No system diagram, no data dictionary, no list of constraints. You have 45 minutes, and what you do in the first ten decides most of the outcome.
This is the forward deployed engineer case-study round, and across FDE loops it has the lowest pass rate of any stage — somewhere around 40% of candidates who reach it actually pass. If you're prepping for an FDE interview, this is the round to obsess over. (For the full loop structure and what the other rounds test, see the forward deployed engineer interview guide.)
Anatomy of the round
The round has a shape, even though it feels shapeless while you're in it. Every strong pass, regardless of the specific scenario, moves through four phases.
Interviewers are scoring you against this shape whether or not they tell you it exists. A candidate who skips straight from the opening line to a confident architecture diagram has skipped the phase that was actually being tested.
The three failure modes
Almost every failed case-study round fails for one of three reasons, and they're worth naming explicitly because each one feels like the right move in the moment.
The most common failure. The candidate hears "we want AI to stop fraud losses," feels the pull to demonstrate technical range immediately, and starts describing a real-time ML pipeline before asking a single question. It sounds confident. It's actually the opposite of what's being tested — the interviewer now knows you'll build the wrong thing quickly rather than the right thing carefully.
The stakeholder says "our last vendor promised something similar and it failed." A candidate who wasn't ready deflects — "this will be different because we'll really listen to your needs" — instead of engaging with what specifically failed and how the current proposal avoids that failure mode. Vague reassurance reads as exactly what a burned customer is primed to distrust.
Under time pressure, candidates often try to close the sale by promising more than the discovery actually supports — a full rollout timeline, a hard accuracy number, a commitment on scope that wasn't earned by the conversation. This is the failure mode that looks like confidence and gets punished the hardest, because it's the exact behavior that damages trust with a real enterprise customer.
A worked example: the regional bank
Here's how the four phases play out against one of the more common FDE case-study premises — a regional bank whose fraud losses have become a board-level problem.
The opening ask: "We want AI to stop our fraud losses. What would you build?"
Weak move: Jump straight to a proposal — a real-time transaction-scoring model, an anomaly detection pipeline, maybe a mention of a graph database for entity resolution. All technically reasonable. All potentially useless, because nothing has been asked yet about how the bank's systems actually work.
Strong move — discovery: Before proposing anything, ask what's actually driving the losses (card-present, ACH, account takeover — they're different problems with different solutions), what data is available and how fresh it is, and what the current fraud team's process looks like today. That last question is where the constraint usually surfaces: the bank's core transaction system is a legacy mainframe that exports a batch file once a night. There is no real-time feed to score against. A model that assumes streaming data is dead before it starts.
Strong move — proposal: With that constraint in hand, the scoped answer changes completely. Instead of a real-time detection system, propose a shadow-mode pilot: run a scoring model against the nightly batch export, flag the highest-risk transactions retroactively, and have the existing fraud team review the flags against what they caught manually. No changes to production systems, no real-time promise, no rip-and-replace of the mainframe. The proposal explicitly names what it isn't doing yet — no live blocking, no API integration — which signals judgment rather than limitation.
Objection: "We tried a vendor's real-time solution two years ago and it never worked with our systems." The strong response doesn't argue the point or apologize for the last vendor — it agrees with the underlying concern and explains why the shadow-mode approach specifically avoids that failure: it doesn't touch production, doesn't require real-time integration, and produces evidence before asking for any system changes at all.
Next steps: Not "we'll put together a full proposal." Instead: a two-week shadow-mode pilot against last quarter's batch data, a specific metric (flagged transactions compared against known fraud cases from the same period), and a follow-up meeting already proposed with a date.
That's the whole shape of a pass: resist solutioning, let discovery find the real constraint, scope down instead of up, and handle the objection by explaining the mechanism, not by reassuring.
How to practice it
The hard part about this round is that it can't be practiced by reading. Discovery is a live skill — you have to actually ask a question, hear an answer that changes what you thought the problem was, and adjust out loud, under mild social pressure, in real time. Outlining an approach on paper doesn't train any of that.
A useful drill: take a one-line ambiguous business ask (see the FDE interview guide for six real premises to use), set a 10-minute timer, and force yourself to spend the entire timer only asking questions — no proposing allowed until the timer ends. Most candidates find this uncomfortable the first few times, which is exactly the discomfort the real round is testing your tolerance for.
Rubduck's FDE scenario interview puts you in front of an AI stakeholder built on premises like the bank fraud case above — vague opening ask, a hidden constraint that only surfaces through good discovery questions, and real objections when your proposal has gaps. You get scored on discovery, scoping, and objection handling after the session. Start an FDE scenario →
The candidates who pass this round aren't the ones with the cleverest technical solution. They're the ones disciplined enough to not need one until they've actually earned the right to propose it.
— Team Rubduck