Scoping Ambiguous Problems

TL;DR: Faced with an open-ended prompt, run a fixed sequence before you design anything: clarify inputs, constraints, and where the data lives; state your assumptions aloud; define the smallest MVP that delivers value; name the accuracy-cost-latency trade-offs you are making on purpose; and plan the failure modes. Reaching for a model or a box-and-arrow diagram in the first two minutes is the single most common cut in the simulation round.

The prompt is a test of your process, not your ideas

When an interviewer says "a city wants to reduce 911 response times, how would you approach it," they are not waiting for you to name a model. They are watching whether you can take a problem with no edges and give it edges. The candidates who fail almost always fail the same way: they hear "911" and "AI" and start sketching a dispatch-prediction architecture in the first minute. They have now committed to a solution before knowing whether the bottleneck is call triage, ambulance routing, or hospital handoff. The structure below is what an experienced FDE does instead, and it is largely the same every time, which is the point.

1. Clarify inputs and constraints. What signals exist: call logs, GPS feeds from units, traffic data, historical incident outcomes? Where does the data live, and can the city legally move it? For a 911 system, data residency and PII handling are not footnotes; emergency call data may be barred from leaving city infrastructure, which can rule out a cloud API and force on-prem or a self-hosted model. Latency is a hard constraint here in a way it is not for a support bot: a recommendation that arrives ten seconds late during a call is worthless.

2. State assumptions out loud. You will not get every answer, so make your assumptions explicit and let the interviewer correct them. "I am going to assume we have two years of historical calls with outcomes, that dispatch staff will see suggestions on their existing console, and that we are optimizing time-to-dispatch, not time-to-scene. Tell me if any of those are wrong." This does two things: it unblocks you, and it shows the interviewer exactly what your design depends on.

3. Define the MVP. Resist solving the whole city. The smallest useful thing might be: for incoming calls, predict the incident category and suggested unit type, surfaced to the human dispatcher who still decides. That ships in weeks, keeps a human in the loop on a life-safety system, and produces data to improve on. Routing optimization and multi-agency coordination are phase two. Naming the phase line is itself a signal of seniority.

4. Name the trade-offs you are choosing. Every real design spends one axis to buy another. Say it plainly: a larger model raises category accuracy but adds latency you cannot afford mid-call, so you pick a smaller fast model and accept a slightly lower top-1 accuracy, backed by showing the dispatcher the top three categories rather than one. That is a deliberate accuracy-for-latency trade, framed as a decision with a consequence, not a default.

5. Plan the failure modes. What happens when the model is unsure, the data feed drops, or the prediction is wrong on a critical call? On a life-safety system the answer is conservative: low-confidence cases fall back to the standard human flow, the suggestion is never auto-dispatched, and every override is logged so you can measure where the model misleads. An interviewer who hears you volunteer failure handling before being asked has heard a senior answer.

The last box in the diagram is the point. Architecture is step seven, and the six above it are what earn the right to draw it.

A scoping pass, compressed

Interviewer: A hospital wants to use AI to reduce patient readmissions. Go.

Candidate: Before I design anything, a few clarifiers. Who acts on the output: discharge nurses, care coordinators, or physicians? What data do we have on prior admissions, and is it inside the EHR or exportable? And is the goal to flag high-risk patients at discharge, or to intervene during the stay?

Interviewer: Care coordinators. Data is in the EHR, hard to export. Flag at discharge.

Candidate: Then I will assume PHI cannot leave the EHR environment, which pushes us toward a model running inside it. MVP: at discharge, score each patient for thirty-day readmission risk and show coordinators a ranked worklist with the top contributing factors, so they prioritize follow-up calls. I am trading some predictive power for interpretability, because a black-box score they cannot explain to a physician will not get used. Failure mode: a low-risk patient who gets readmitted is the costly miss, so I would tune the threshold toward recall and accept more false positives, since the cost of an extra phone call is low.

That answer never named a specific algorithm and it is far stronger for it.

Why interviewers probe this

The answer that gets cut sounds competent: "I'd train a dispatch-time prediction model on historical calls and serve it to the console." It names a model in the first minute and has not yet learned whether the bottleneck is call triage, ambulance routing or hospital handoff. The simulation round is built to be underspecified on purpose, and the rubric explicitly rewards structured scoping over technical flash. The interviewer is screening for whether you can be trusted alone in a customer room where nobody hands you a spec. The reserve follow-up is to inject a constraint mid-stream ("actually, the data cannot leave their VPC") and watch whether your structure absorbs it or your half-built architecture collapses. Candidates who scoped first adapt in one sentence; candidates who designed first have to start over, and the interviewer sees it.

The five steps, what each sounds like, and what skipping it costs you in the room:

Common misconceptions

• "Showing deep technical knowledge fast is impressive." It reads as a junior reflex when it precedes scoping. Senior engineers earn the right to talk architecture by first proving they understand the problem.
• "Stating assumptions makes me look like I am guessing." Stated assumptions are a strength; silent ones are the bug. The failure is assuming and not saying so.
• "The MVP should show off the full system." The MVP exists to ship value early and de-risk the rest. A deliberately small, human-in-the-loop first version signals judgment, not timidity.
• "Trade-offs are something you mention if asked." Volunteering the axis you are spending and why is a core senior signal. Waiting to be asked means you did not notice you were making a choice.

Key takeaways

• Run a fixed sequence on any vague prompt: clarify, assume out loud, define MVP, name trade-offs, plan failure modes. Then, and only then, sketch architecture.
• Data residency and latency are first-class constraints, not details. On regulated or life-safety systems they can rule out entire designs.
• The MVP is the smallest thing that delivers value and keeps a human in the loop; phasing the rest is itself a seniority signal.
• Diving into a model or diagram first is the most common cut. The interviewer is grading process, then injecting a constraint to test it.
• Make the sequence a reflex before the loop: say the five steps out loud on three unfamiliar prompts this week, without naming a technology in any of them.