The practice prompts
Twelve prompts cover the six FDE-specific round types, two prompts each, with a suggested time box and what a strong answer covers.
Referral routing for a regional clinic network
Suggested time box: 25 minutes
Scenario. A regional outpatient clinic network asks you to 'put AI on referrals.' Specialists wait on incomplete packets. Primary-care staff re-fax the same forms. Leadership wants fewer lost referrals and faster time to scheduled specialty visit.
What a strong answer covers.
- Discovery questions: how a referral moves today, who owns incomplete packets, and where time is lost.
- The metric: share of referrals that reach a complete packet before the specialty visit is booked.
- The first slice: one specialty line and one packet checklist, with explicit cuts for other lines.
- Evals for missing fields and wrong specialty routing, plus a human review path for edge cases.
- What you tell the customer in week one: which clinics are in the pilot, which fields are required, and how staff escalate.
Common misses. Jumping to a multi-clinic platform before the packet process is clear. Naming model architecture before the metric and first slice.
Quote turnaround for a mid-size freight broker
Suggested time box: 25 minutes
Scenario. A mid-size freight brokerage wants 'AI for quoting.' Brokers rebuild lane history by hand. Shippers wait while staff pull rates from three tools. The ops lead says quote speed is the reason they lose weekend bids.
What a strong answer covers.
- Discovery on the last lost bid: which tools, which fields, who had to approve the number.
- The metric: median time from inbound request to sent quote on a defined lane set.
- The first slice: one lane family and one output format that brokers can edit before send.
- Fallbacks when rate data is stale: hold the quote, flag the gap, and require a broker check.
- Access constraints: which rate tables the system can read, and what stays out of any model prompt.
Common misses. Proposing full autonomous quoting on day one. Ignoring approval and audit needs on the final number.
Prepare for these rounds with recorded practice.
Prior-auth webhook failures at a specialty pharmacy
Suggested time box: 35 minutes
Scenario. A specialty pharmacy chain runs a prior-authorization assistant that posts status updates into the pharmacy management system. Overnight, webhooks start returning 401s for some stores and succeed for others. Pharmacists see stuck authorizations while patients wait on fills.
What a strong answer covers.
- A hypothesis: credential rotation, store-scoped secrets, or a path change on the receiving endpoint.
- How you narrow blast radius: freeze new posts for failing stores, keep successful stores live.
- Checks at the edges: auth headers, store identifiers, payload schema, and retry queues.
- What you tell the customer while debugging: which stores are affected, the temporary manual path, and the next check-in time.
- A rollback or feature flag plan that protects fills if the fix is wrong.
Common misses. Rewriting the integration from scratch. Treating the failure as a coding puzzle with no user-facing update.
CRM note sync dropping at a regional credit union
Suggested time box: 35 minutes
Scenario. A regional credit union deployed a call-note assistant that writes summaries into the CRM. Branch managers report missing notes on some member interactions. Staging looks fine. Production logs are incomplete. Compliance wants a clear answer before the next exam window.
What a strong answer covers.
- Hypothesis formation from the failure mode: write path, identity mapping, or silent validation rejects.
- Edge checks between the telephony export, the summarizer, and the CRM create-note API.
- Access and security constraints: what you can inspect in member data and what stays masked.
- An interim process so advisors re-enter critical notes by hand while the sync is fixed.
- The customer update: known scope of missing notes, recovery plan, and how you will prove the gap is closed.
Common misses. Ignoring compliance while chasing the bug. Declaring victory from staging success alone.
Call summarization under PHI rules for a dental group
Suggested time box: 40 minutes
Scenario. A multi-state dental group wants AI call summarization for front-desk phones. Calls include protected health information. The EHR is legacy. Security requires a review before any vendor model touches production audio. Leadership wants a pilot in six weeks across two clinics.
What a strong answer covers.
- Where the model sits, and where raw audio never goes.
- Access control: clinic-scoped identities, retention limits, and who can open a transcript.
- An evaluation suite for required fields, PHI leakage in the summary, and wrong appointment types.
- Human fallback when confidence is low or the call mixes clinical detail with billing.
- A phased pilot rollout that would pass security review, plus what you cut if the timeline shrinks.
Common misses. Designing for abstract call volume. Having no answer for what happens when the model is wrong on a clinical detail.
Shop-floor ticket triage for a mid-market manufacturer
Suggested time box: 40 minutes
Scenario. A mid-market manufacturer wants AI triage for maintenance tickets from the shop floor. Technicians write short notes on rugged tablets. The CMMS is on-prem. IT will not allow outbound data without an approved path. Plant leadership wants fewer tickets stuck in the wrong queue before the next outage window.
What a strong answer covers.
- Constraints first: on-prem data, network path, and who owns ticket routing today.
- A design that keeps the model where the CMMS allows, with clear outs for free-text that needs a human.
- Evals on queue accuracy and severity misfires, plus a fallback that leaves the ticket with the shift lead.
- Rollout: one line, one shift, measured misroutes before plant-wide expansion.
- What you tell plant leadership about access, downtime risk, and how to kill the feature if routing fails.
Common misses. Ignoring the on-prem boundary. Optimizing for fancy ranking instead of wrong-queue rate.
Intake classifier work trial for a home services franchise
Suggested time box: multi-day build, 20-minute presentation
Scenario. A regional home services franchise gives you three days to improve intake classification for booking requests (plumbing, HVAC, electrical). You ship a working slice, write the decisions, and present to a mock ops director and a franchise owner who ask about tradeoffs and next steps.
What a strong answer covers.
- A scoping brief: in-scope request types, out-of-scope emergency paths, and the metric for misroutes.
- A field-report presentation: problem, number, scope, design, what broke in testing, result.
- The cuts you made so the build stayed inside the brief.
- Evals and fallbacks shown live, including how a wrong class reaches a human.
- Hard questions invited early: data quality, franchise variation, and what you would do next week.
Common misses. A demo with no write-up. Overbuilding past the brief. Defending cleverness instead of the booking outcome.
Claims intake assist work trial for a specialty insurer
Suggested time box: multi-day build, 20-minute presentation
Scenario. A specialty insurer asks you to build a claims intake assist that drafts a structured claim file from messy email attachments. Stakeholders include a claims manager and a compliance lead. They want a working prototype, a one-page decision write-up, and a presentation that survives pushback on risk.
What a strong answer covers.
- Scope that names which attachment types are in and which stay manual.
- Design choices tied to the claims metric.
- Access and security constraints explained in the presentation, including what leaves the insurer environment.
- A clear human review step before any draft becomes a filed claim.
- Next-step plan after the trial: what you would measure in a scoped pilot.
Common misses. Skipping compliance in the talk track. Shipping features that were never in the brief.
Discharge instruction assistant that drifted after launch
Suggested time box: 30 minutes
Scenario. Walk through a fictional past deployment: a regional hospital network shipped a discharge instruction assistant. Early reads looked fine. Two weeks later, nurses reported missing wound-care steps on some packets. You found the cause, fixed it, and changed how you monitor the system.
What a strong answer covers.
- One concrete story end to end: customer, number, launch, failure, fix.
- How you learned about the failure from the floor before the dashboard caught it.
- What the patient-facing packet looked like versus what the system logged.
- The eval or monitor you added so the same miss cannot stay silent.
- What you would cut next time in scope or rollout order.
Common misses. Vague summaries with no measured result. No answer for what happened after the demo.
ETA predictor that broke after a vendor API change
Suggested time box: 30 minutes
Scenario. Walk through a fictional past deployment at a mid-size logistics company. An ETA assistant fed dispatch screens. A carrier API changed pagination without notice. ETAs went stale for one region overnight. Tell what broke, how you found it, what you told the customer, and what you changed.
What a strong answer covers.
- The business number that moved before the break, and how the stale ETAs showed up for dispatchers.
- The diagnosis path: region scope, vendor changelog, and the edge between your job and their API.
- The customer update during the incident: affected lanes, temporary process, and fix ETA.
- The permanent change: contract tests, alert on freshness, or a fallback ETA source.
- What you would cut from the original design knowing this failure mode.
Common misses. Resume-speak with no operational detail. Blaming the vendor without owning the customer update.
Security owner blocking a pilot at a community bank
Suggested time box: 20 minutes
Scenario. An interviewer plays the security owner at a community bank. You proposed a document-intake pilot for commercial lending. They say no vendor model can touch customer documents until a review finishes, and they change the constraint mid-call by cutting your proposed data set in half.
What a strong answer covers.
- Listening and restating the constraint in their language before defending the design.
- A smaller next step that still teaches you something: redacted samples, on-prem processing, or a shadow mode with no write path.
- Clear access and security boundaries you will not cross.
- What you need from them to unblock the review, named as a concrete ask.
- Calm handling when they say no to the original scope.
Common misses. Pitching before you understand the block. Arguing for the architecture instead of the risk outcome.
Ops lead cutting scope mid-call at a multi-clinic practice
Suggested time box: 20 minutes
Scenario. An interviewer plays an ops lead at a multi-clinic specialty practice. You are mid-discovery on an intake assistant. Halfway through, they say the front desk will not change tools this quarter and ask you to propose a next step that still moves a number.
What a strong answer covers.
- Restating the new constraint without fighting it.
- A smaller slice that works inside the current tools: assisted drafting, checklist prompts, or offline packet prep.
- The metric that still moves under the constraint.
- What is out of scope until tools can change.
- A clear next meeting and artifact: one-page scope, shadow trial plan, or field notes from two clinics.
Common misses. Freezing when the stakeholder changes the brief. Pushing the original design after the constraint moved.