FDE Interviews & Case Practice

This final lesson is about the interview itself. Picture the hiring manager. They want to see that you can handle a customer project from a vague start to a working result. They test your thinking, not only your facts. This lesson shows the common rounds, how to answer scenario questions and how to show your work.

What the interviewer wants to see

• You find the real problem before you build.
• You choose simple designs and can explain why.
• You test with evidence, and you talk about failure honestly.
• You respect security, privacy and customer systems.
• You communicate clearly with people who are not engineers.
• You take ownership, and you learn from mistakes.

Common interview rounds

• Technical build: a short exercise, such as extract fields from messy text, or answer questions over a set of documents.
• Scenario or case: a customer story with missing information. You talk through what you would do.
• System design with customer limits: for example, data cannot leave their network.
• Behavioral: stories about conflict, failure, ambiguity and delivery.
• Customer role-play: the interviewer plays a difficult customer.

A way to answer any scenario

Use the same steps each time. Say them out loud, so the interviewer can follow your thinking.

1. RESTATE   Say the problem back in one or two sentences. Name what you do not know.
2. ASK       Ask three to five questions: who is affected, what happens today,
             what does success look like, what data exists, what rules apply.
3. SCOPE     Propose a small first version and one success number.
4. DESIGN    Pick the simplest approach that could work. Say why not the fancier one.
5. TEST      Say how you will build a test set and what pass mark you would agree.
6. RISKS     Name two or three: data access, wrong answers, adoption. Give a plan for each.
7. ROLLOUT   Shadow mode, then assist mode. Say how you hand over.
8. LEARN     Say what you would tell your own team afterwards.

Practice scenarios, with strong answers

Scenario one: a customer says, we want an AI that answers all our customer emails. A strong answer does not start building. It restates the goal, asks which emails, how many, what answers look like today and what must never be said. It proposes a first version for one email type with a person approving every reply. It names a number, such as minutes to first reply.

Scenario two: the customer will not share real data. A strong answer asks why. It offers choices: work on site, use hidden copies, use a small approved sample, or build with made-up data and test on real data inside their system. It explains the risk of each. It does not push for access that makes them uncomfortable.

Scenario three: the prototype is right eight times out of ten, and the customer expected ten. A strong answer looks at the errors first. It groups them, fixes the biggest group and adds an unsure path that sends doubtful cases to a person. It resets expectations with real counts. It does not promise perfection.

Scenario four: the sponsor is happy, but daily users do not use the tool. A strong answer asks the users why. It looks at the work steps, the training and whether the tool adds effort. It adjusts the design, not only the training. It measures real weekly use.

Show your work

• Build two or three small customer-style projects. Each needs a one-page spec, a test set, a short demo and a handover note.
• Write a short case study for each: the problem, your choices, what failed and the result in numbers.
• Keep a public repository with clear instructions, and a two-minute video of the demo.
• Be ready to explain every choice. If you used a tool, say what it did and what you checked yourself.

Questions to ask them

• What does a typical first month look like for a new person?
• How do you pick which customers get an FDE?
• How do field lessons flow back into the product?
• How is success measured for this role?