The customer round: scoping, demos and handoff

One student shared notes from eight AI interview loops in October 2026. The subject that came up most was not retrieval or agents. It was customers: how you handle people who aren't technical, and whether you've worked with outside customers. The final rounds were pitches.

That is the customer side of the FDE interview. This post takes it one format at a time, with what interviewers reward and what they mark down.

What is the customer round in an FDE interview?

It is any round where the interviewer plays, or stands in for, a customer. It comes in four forms.

• Scoping: you get a vague brief and turn it into a plan.
• Stakeholder role-play: an interviewer plays a skeptical stakeholder, and you explain, take objections and hold the technical line.
• Demo or pitch: you present something you built, often on their product, under questions.
• Handoff: you explain how the customer's team will run the system after you've gone.

Sometimes it is a named round. Sometimes it is folded into a design round or the final pitch. Either way it is scored on one thing: would a customer trust you with their system?

How do you scope a vague customer ask?

Ask before you design, and turn every answer into a number or a name. The brief might be one line: "Our support team wants AI." A strong first five minutes sounds like this.

• Who uses it, and which task or decision does it change?
• What number would tell us it works, and what is that number today?
• Where does the data live, and can we test on real data in week one?
• Who owns this in production, with a budget, once the pilot ends?
• What has to clear first: security review, data residency, legal?

Each question closes a gap that stalls real pilots. A pilot built on a clean one-off export looks fine until it meets the real pipeline. A pilot with no written pass criteria can't be signed off. A pilot nobody owns after the demo goes nowhere.

Then play back what you heard in one sentence, with numbers, and propose a first slice small enough to ship in weeks. Writing pass criteria is a skill of its own, covered in evals and production readiness questions.

Practice on Design a Q&A assistant over internal company documents where accuracy is critical. Where do you begin? The question tells you what it wants. You begin with questions.

Interviewers mark down designing before asking anything, and accepting adjectives like "fast" and "accurate" without a number behind them.

How do you handle a stakeholder role-play?

Find out what decision the stakeholder is making, then correct the picture in plain words without making them wrong. Take this one from the bank:

A stakeholder believes the model ‘connects to the internet’ to answer questions with fresh information. Correct the picture and describe the actual data flow.

The FDEBench rubric for it starts with an ask: what decision depends on the answer? A security reviewer needs a different emphasis from a product lead. Then it rewards the mechanism, said simply. The model only produces text, including a structured request to search. The application runs that request, holds the credentials, applies the policy and passes the results back. Getting that split right is the biggest single criterion, 25 of 100 points. Treating fetched pages as untrusted input, which can carry prompt injection, earns points too.

The red flags are worth learning by heart: describing browsing as a feature of the model, putting an API key in the prompt, and never mentioning prompt injection.

A second good rep is the customer who says their data is safe because the database is replicated across three availability zones. They are right about availability. Replication keeps the service up. It also copies a bad DELETE to every replica almost instantly. A strong answer separates the two and asks how much data loss and downtime they could live with. Then it proposes point-in-time backups in a separate account, and restore tests on a schedule.

Some prompts are incidents in disguise. For the multi-tenant RAG assistant returning documents from other customers' accounts, the rubric's first asks include whether any customer data has already been exposed. If it has, you are running an incident, with a customer to call, before you are designing anything.

How do you present a demo in an FDE interview?

Scope it narrowly, show where every answer came from, and break it on purpose once.

1. Define the corpus in one sentence: the source, the date range, the number of documents. A narrow set the room can check earns more trust than "we can index anything".
2. Put the source on every answer: the document, a date or timestamp, the quoted passage. A confidence score asks for trust. A citation lets them check.
3. Walk the architecture in three layers: what goes in, how it's found, what comes out. Give the consequence of each layer before the mechanism.
4. Run one query you know it can't answer, and say so out loud. A system that says it found no strong match is more convincing than a perfect run.
5. End with a scoped next step: their data, one document type, a date for the rerun.

Then close with the five-line brief from the prep page: what it does, what one run costs, what could go wrong, who signs off, and the one number you'd track.

Interviewers mark down a polished run with no sources, dodging an edge case someone raises, and ending on "let's explore further". For the retrieval follow-ups, see RAG interview questions. Practice the whole shape with pitch an end-to-end RAG service in 15 minutes.

How do you plan the handoff?

Plan it from the first week, and call it done only when the customer's engineer has run the system without you. A runbook proves you could write the steps down. It doesn't prove someone else can follow them when an output looks odd at midnight.

When an interviewer asks how you'd hand over, describe a witnessed run in three parts.

1. Briefing. Their engineer explains the runbook in their own words before touching anything. You listen for skipped steps and terms they don't define.
2. Solo run. They run it against staging or production while you watch and stay quiet. Every pause is a gap.
3. Debrief. You go through each hesitation, and each one becomes a fix to the runbook before you leave.

Book it in the final week, not the final day, so there is time to act on what you find. It surfaces what documents miss: an output that is valid but unexpected, a quirk of this customer's environment, a branch the happy path never covered.

Name the owner too. A system with a named engineering owner, a budget and written pass criteria can survive your exit. How FDE teams work covers exit criteria in more depth.

What do interviewers mark down in the customer round?

They mark down the habits that would worry a real customer.

• Designing before asking a single question.
• Jargon with a non-technical stakeholder, or talking down when you correct them.
• Hiding a failure in the demo instead of naming it.
• Leaving out cost, risk or who signs off.
• A handoff that is a list of documents rather than a person who can run the system.

To practice, filter the bank by Product & scoping. Then record yourself explaining a project you built to someone who isn't an engineer, and watch it back. To see roles that put customer work up front, browse the Solutions / Implementation family on the board.