The FDE case round

The case round is what sets FDE interviews apart. You get a vague customer brief and work through it live, out loud, with an interviewer playing the customer or observing. It tests how you think before you code.

What a brief looks like

Something like: "A logistics company wants to use AI to reduce the time its finance team spends on freight invoice disputes." No data, no architecture, no definition of success.

A five-step approach

1. Ask before you design

Who does the work today, how long does it take, and what makes a dispute hard? What systems hold the invoices and contracts? Who is the sponsor, and what would make them call this a success? Interviewers watch for whether you ask these at all.

2. Narrow to one workflow

Pick the highest-value, most contained slice: for example, matching invoice lines to contract rates and flagging mismatches. Say what you are leaving out.

3. Agree a measure of success

Put a number on it: time per dispute, share of disputes resolved without escalation, or accuracy of flags. Say how you would measure it before and after.

4. Sketch the system

Data in, processing, model or rules, human review, data out. Name the risks: bad data, wrong flags that cost money, access to sensitive contracts. Add evals and a human approval step where errors are costly.

5. Plan the pilot and handover

Who uses it first, for how long, and what decides go or no-go. How the customer's team will run it after you leave.

Common mistakes

• Jumping to a model choice in the first minute.
• Designing for every case instead of one valuable slice.
• Never stating how success will be measured.
• Ignoring the people who will use the system.

Practise with the scoping test and the discovery checklist.