FDE Scenario Interview Questions: Four Customer Cases

What you'll learn: how to answer four customer-facing scenario questions (an ambiguous request, a demo that fails live, a customer who pushes back on scope, and a request for an unsafe action) with a repeatable structure, trade-offs you can defend, and a rubric to score yourself.

Scenario questions test judgment under pressure, not recall. The interviewer plays a customer, gives you an incomplete picture and watches what you ask, what you protect and what you commit to. Every number below is illustrative, and every spoken answer is an example of reasoning, not a script to memorise. The lesson The interview loop and an answer framework explains how the loop runs; this page gives four worked cases.

Figure 1. The answer framework used on every question

How to read this: spend the first minute on the left two boxes, because most weak answers jump straight to a solution and never find out what the customer needs.

How to use this page

Cover the answer, say yours out loud for three minutes, then compare. Score yourself on the rubric under each question, and note which criterion you missed most often.

For the technical depth behind these cases, read the AI Architect mindset lesson for requirements and decision records, and agents, tools and MCP for how tool access is limited.

Questions

Q1. A customer says, "Make the assistant answer everything about our products." What do you do first?

What it assesses. Whether you turn a vague ask into something testable before you build. The interviewer is looking for questions about users, decisions and failure cost, and for a smallest useful slice, not for a technical design.

Answer framework.

1. Ask who uses it and what decision it supports ("a sales engineer checking whether part A fits system B").
2. Ask for evidence: a sample of real questions, not a description of them.
3. Group the sample, count it, and rank groups by volume and by cost of a wrong answer.
4. Propose a first slice that covers most of the volume with the lowest risk.
5. Write the out-of-scope list and the success measure, and get the customer to agree to both.

Strong answer example. The answer below shows reasoning, a count and a boundary.

"Everything" is not testable, so I would ask for 40 real questions from the sales engineers' inbox and sort them. Suppose 22 are catalogue lookups, 10 are compatibility checks, 5 are pricing and 3 are something else. That is 55%, 25%, 12.5% and 7.5%. Lookups and compatibility together cover 32 of 40, or 80%, and a wrong answer there costs a re-check, not a lost deal.

I would propose those two first, with a rule that the assistant says "I cannot find this" instead of guessing. Pricing I would leave out of the pilot, because a wrong price in writing is expensive and the data is probably owned by another team. I would write the 40 questions down as the first test set, agree a pass bar with the customer, and show the list of what is out of scope so nobody is surprised in week four. If they insist on pricing, I would ask who owns the price data and what error rate they would tolerate.

Illustrative numbers: the sample and its split are invented for this example.

Common mistakes.

• Starting to build before seeing a single real question.
• Saying "yes" to everything to keep the customer happy, so the pilot has no edges.
• Asking ten questions at once instead of the two that change the design.
• Giving a model or tool name when the customer asked about outcomes.
• Forgetting a success measure, so "done" is a matter of opinion.

Follow-up questions.

• The customer cannot share real questions yet. What do you do?
• Pricing is the customer's top priority. How do you respond?
• How do you decide what "I cannot find this" should look like to a user?
• Two stakeholders give you contradictory definitions of success. Who decides?

Scoring rubric.

Q2. Your live demo returns a wrong answer in front of the customer's director. What do you do, in the room and afterwards?

What it assesses. Composure, honesty and the ability to find the cause of an AI failure instead of defending the system. A strong candidate treats the failure as information the customer can see being handled well.

Answer framework.

1. In the room: acknowledge the error plainly, do not blame the model or the data, and do not improvise a fix.
2. Show the evidence: open the source the assistant used and say what you see.
3. Offer a bounded commitment: a cause and a re-run by a named time.
4. Afterwards: classify the cause (retrieval, generation, data, or configuration) and reproduce it.
5. Fix it, re-run the full test set to check for regressions, and report back with numbers.

Strong answer example. The example below separates what happens in the room from what happens next.

In the room I would say, "That answer is wrong. Let me show you where it came from." I would open the cited document. Suppose it is the older datasheet, which was superseded last quarter. I would not argue or restart; I would say I will confirm the cause and send the result by tomorrow noon, and I would move on to a question I know the system handles.

Afterwards I would trace the request: which passages were retrieved, which were cited, and what the model saw. If retrieval returned the superseded file, the model is not the problem; the index is. The fix is a metadata filter that excludes superseded documents, plus a freshness check on the sync. Then I would re-run the whole test set. Suppose 27 of 30 passed before (90%) and 29 of 30 pass after (96.7%), with no previously passing question now failing. I would send that table to the customer, with the cause in two sentences and the new check that prevents it.

Illustrative numbers: the test-set size and pass counts are invented for this example.

Common mistakes.

• Saying "it is a one-off" before checking whether it is.
• Blaming the customer's data in front of their director.
• Changing the prompt on the spot and re-running the demo live.
• Fixing the one failing question and not re-running the others.
• Going quiet afterwards instead of reporting the cause.

Follow-up questions.

• How would you prepare a demo so this is less likely?
• What would you show if the trace reveals the model ignored the right passage?
• When is a live demo the wrong format?
• How do you tell a retrieval failure from a generation failure?

Scoring rubric.

Q3. The customer asks you to add three more data sources in week three of a six-week pilot. How do you respond?

What it assesses. Whether you can protect delivery without damaging the relationship. The interviewer wants to see you price the request in days, offer choices and make a decision visible, rather than accept silently or refuse flatly.

Answer framework.

1. Acknowledge the need and ask why now: what changed for them?
2. Price the change in days and compare it with the slack that remains.
3. Offer two or three options: swap, extend, or phase.
4. Recommend one with a reason, and say what you would not do.
5. Record the decision and who made it, so scope changes are visible later.

Strong answer example. The numbers below make the trade-off concrete.

I would first ask why these three sources matter now, because the answer tells me whether they are core or nice to have. Then I would price it. A six-week pilot is 30 working days. Suppose 26 are committed and 4 are slack. Each source takes about 4 days to connect, clean and test, so three sources cost 12 days, which leaves us 8 days short.

I would offer three options. Swap: drop the lowest-value committed item worth 8 days. Extend: add 8 working days, a little under two weeks, with the demo date moving. Phase: keep the pilot as planned and schedule the three sources as phase two. My default is to phase, because it keeps the pilot's test set stable and the result comparable. I would not absorb the work silently: that burns the slack that protects the demo date, and it hides the real cost. I would put the options in one page and ask the customer's sponsor to choose.

Illustrative numbers: the pilot length, commitments and per-source effort are invented for this example.

Common mistakes.

• Absorbing the extra work and missing the date.
• Refusing without offering an option, which sounds like an obstacle.
• Estimating in vague terms ("it will be tight") instead of days.
• Letting the person asking decide, when the sponsor owns the budget.
• Changing scope without changing the test set or acceptance criteria.

Follow-up questions.

• The sponsor says "just make it work" and will not choose. What next?
• One of the three sources has unclear access rights. How does that change your answer?
• How do you estimate a source you have never seen?
• When would you recommend extending instead of phasing?

Scoring rubric.

Q4. A customer's operations lead wants the agent to issue refunds automatically, using one shared admin account "to move faster". What do you say?

What it assesses. Whether you hold a safety line while still helping. It checks that you understand blast radius, human approval and least privilege, and that you offer a path to the customer's actual goal, which is speed.

Answer framework.

1. Restate the goal (faster refunds) before objecting to the method.
2. Size the exposure: volume, value and an error rate, then the worst case.
3. Propose controls that keep most of the speed: approval thresholds, limits, an identity of its own, an audit log.
4. Explain why a shared admin account fails: no attribution, no least privilege.
5. Offer a staged rollout with a measure for loosening the limits.

Strong answer example. The example sizes the risk and proposes a threshold.

I would say the goal is right and the shortcut is the problem. Suppose 500 refund requests arrive per day. Of those, 350 are at or below $50 and average $25, which is $8,750. The other 150 average $210, which is $31,500. Total value is $40,250 a day. If the agent is wrong 2% of the time and each wrong approval costs the full refund, automatic approval of everything exposes about $805 a day.

If the agent approves only the small refunds on its own, the exposure is 2% of $8,750, which is $175 a day, a reduction of about 78%, and the 150 larger refunds go to a person with the agent's recommendation attached. I would also use a service identity limited to the refund operation, a daily cap, and a log of every call. A shared admin account removes all of that: nobody can say who did what, and a bad tool call can reach everything the account can. After two weeks I would review the error log and, if it holds, propose raising the threshold.

Illustrative numbers: volumes, values and the error rate are invented for this example.

Common mistakes.

• A flat "no" with no path to the customer's goal.
• Saying "yes" because the customer is senior.
• Relying on the prompt ("tell it to be careful") as the control.
• Putting the limit in the model's instructions instead of in the tool.
• Forgetting that the 2% error rate must be measured, not assumed.

Follow-up questions.

• The lead insists, and a director backs them. What do you do?
• How would you measure the real error rate before raising the threshold?
• What if the refund tool must run under the customer's own identity?
• Where does a cap belong: in the prompt, the tool or the downstream system?

Scoring rubric.

The cost model for steps like these is in cost and economics, and the controls are in governance and responsible AI.

Last verified: 2026-11-02

How to practise

• Answer each question aloud in three minutes, recorded, then listen for the first sentence that contains a question to the customer.
• Redo the arithmetic with your own numbers; an answer with a count beats an answer with an adjective.
• Rewrite one strong answer in your own words without copying a phrase.
• Ask a friend to play the customer and add one new constraint halfway through.
• Score yourself with each rubric and repeat the criterion you scored lowest.

Next

Continue to Interview questions: solution design scenarios, which covers sizing, total cost of ownership, build vs buy, stakeholder conflict and proposal risk.