Asking Clarifying Questions That Matter

Four questions that change nothing

"What's your tech stack? How many users? What's the budget? What's the timeline?" Questions like these arrive almost by reflex when a brief is vague, and they feel responsible. Yet none of them would change what you build in week one. Any brief prompts them, which is exactly why an interviewer hears them as filler: they could have been asked without reading the brief at all.

So what makes a clarifying question worth its time? A useful test is to finish this sentence in your head before you ask: "If the answer is A, I build X; if it's B, I build Y." If you cannot fill in X and Y, the question can wait, or go. It is cheap, and it filters out the reflexive questions while keeping the ones that matter.

Four kinds of question tend to pass it, whatever the brief. Each points at something the build will have to fit around.

• Who decides: whose decision the software changes, and who signs off on that change.
• What happens today: the current process, step by step, and where the time or money goes.
• What failure costs: what a wrong output does and to whom, compared with a slow one.
• What data already exists: the records, their owner, and how much is missing.

The rest of this lesson watches those four at work on a brief whose obvious reading turns out to be wrong.

The credit union that asked for faster underwriting

A fictional credit union with about 90,000 members sends this brief: "Members complain that personal-loan applications take forever. We want to use AI to speed up underwriting." Every number below is made up for the example.

Ten questions and no direction

The candidate opens with ten questions: tech stack, cloud provider, loans per year, which AI vendor they are considering, budget, timeline, team size, whether a data warehouse exists, compliance requirements, preferred UI. The interviewer answers a few of them vaguely. Twelve minutes pass, there is still no direction, and the brief's own diagnosis, that underwriting is the slow part, has not been examined.

Two things went wrong. The questions are generic, so they surface nothing specific to lending. And the candidate accepted the customer's framing without testing it. "Speed up underwriting" is a solution dressed as a problem, and nobody has yet shown that underwriting is where the time goes.

Following the nine days

A better opening starts with the question that tests the diagnosis: "Walk me through an application from submission to decision. Where does the time go?" Say the loan system records a timestamp when an application enters each stage. The interviewer, playing the lending manager, reveals the split. Median time from application to decision is 9 business days. About 6 of those sit in "awaiting documents" (pay stubs and bank statements the member has not uploaded), 2 in the underwriter queue, and 1 in review and decision.

That one answer moves the design. Underwriting plus review is 3 of the 9 days, so an underwriting step that took zero time would still leave a 6-day median. The bigger lever is the document chase.

Next comes who decides: "Who approves a loan today, and does anything above a limit go to a committee?" Say underwriters approve up to a limit, and above it a credit committee meets weekly. That matters, because a file that just misses Tuesday's committee waits a week whatever software you build. Then failure cost: "What's worse for you, a slow approval or a wrong one?" A wrong approval is a loss, and the regulator examines lending decisions; a slow one loses the member to a competitor. So anything touching the approve or decline call keeps a human sign-off, while document collection can be automated freely. Then data: "When an application stalls in 'awaiting documents', do you record which document is missing?" The stage is recorded and the missing document is not. Staff email members by hand.

Now comes the reflect-back, one sentence that restates the problem in the customer's terms before any design: "So the nine days are mostly members not sending documents, your staff chase them by hand, and larger loans also wait on a weekly committee. I'd start with the document chase and leave underwriting alone for now. Does that match what you see?"

The plan that follows is modest. In week one: a checklist of required documents per loan type, automatic reminders to members on day 1 and day 3 with an upload link, and a daily list for staff of applications stuck more than 3 days. The metric is median days in "awaiting documents", with a baseline of 6 from the stage timestamps. Underwriting help, if it ever comes, keeps the underwriter as the decider.

When the interviewer won't answer

Sometimes the reply to a good question is "what would you assume?" State the assumption, give its fallback, and keep moving: "I'll assume the loan system exports stage timestamps. If it doesn't, my first step is pulling 50 recent files and timing the stages from the email trail." The round keeps its pace, and the interviewer can still correct you if the assumption matters.

Why each good question splits the plan in two

Look back at the credit union and notice that each of the four questions earned its place the same way: two plausible answers would have sent the plan in different directions. The table puts the splits side by side.

The order follows from that. Scope-setting questions, about the current process and who decides, come before anything about infrastructure, because they decide what you are building at all. Questions that only show curiosity ("which cloud?") can come later, when a design choice depends on them, or never.

How many to ask up front? Cap the opening at three to five, then commit to a direction. Questioning does not stop there; it moves inside the design, where each later question is tied to a step: "Before I pick where this runs, can staff install anything, or is it browser-only?"

When an answer lands, say what it changed. "That moves me off underwriting" is a sentence an interviewer can score, while silent absorption looks like you did not hear it. When no answer comes, state the assumption with its fallback and continue. And reflect back once before you design. It checks your understanding and shows you listened, and if the interviewer corrects you, the mistake cost thirty seconds instead of thirty minutes.

How questioning goes wrong

Generic questions are the first trap. The tell is that the same question would fit a traffic brief, a hospital brief and this one equally well; "What's your tech stack?" is the classic. It costs points on the line decomposition rubrics put up front, clarifying before solving, because a question with no purpose clarifies nothing.

The second trap is ten questions up front followed by no direction. The candidate treats questioning as a phase to finish before thinking starts, and the interviewer sees twelve minutes gone and nothing committed. Ask three to five, reflect back, propose a direction, and keep asking along the way.

Accepting the customer's diagnosis is the third, and the most expensive. The brief said underwriting and the data said documents. The "where does the time go" question catches this, which is why it belongs early. Close behind it is asking without listening: if the interviewer reveals 6 days in "awaiting documents" and your next sentence is still about an underwriting model, the answer was wasted, and the interviewer noticed.

Drill: the missing infusion pumps

Try this fictional brief. A regional hospital system's facilities director says, "Our infusion pumps keep going missing. Nurses waste time hunting for them. We want asset tracking." Take 10 minutes and write five questions in the order you would ask them. Next to each, write two answers that would send your plan in different directions, and the plan each one implies. Then assume the director answers your process question with: "Nurses spend about 20 minutes a shift looking. The pumps pile up in the cleaning room and nobody knows which are clean." Write the one-sentence reflect-back you would say.

A strong answer asks where the pumps actually end up before asking anything about tracking hardware, and includes a question about who owns the cleaning step. Its reflect-back names the cleaning room as the bottleneck, which may mean the first build is a clean/dirty status board, with tracking tags as a later option. Notice the shape is the same as the credit union: the requested technology was aimed at the wrong step. Rehearse it aloud with the FDE AI coach in thita, or run it as an FDE mock round, where the interviewer holds facts back until you ask for them.

How this shows up in the interview

Two round types reward this skill. In decomposition rounds, such as the Palantir round described by Aced and the Databricks round in Aced's Databricks guide, the prompt is vague and the interviewer injects constraints as you go, so the questions you ask decide what you are designing. The second is the customer simulation. One getperspective write-up, a single source, describes an Anthropic round where the interviewer plays a VP of Engineering at a 5,000-person fintech evaluating an internal copilot, with a rubric covering jobs-to-be-done discovery, no demo-first pitching, reflecting back, and handling skepticism. ElevenLabs' case study round reportedly asks for discovery before a solution, per Aced.

Interviewers probe it in three ways. They withhold the decisive fact until a good question reaches it, they answer "what would you assume?" to see whether you stall, and they play a stakeholder who states a solution ("we need AI underwriting") to see whether you test it. Credit goes to the candidate whose early questions reach the decisive fact, who says what each answer changed, and who reflects back before proposing anything. A sentence to have ready: "Before I suggest anything, can you walk me through an application from the moment it's submitted? I want to see where the time actually goes."

Check yourself

• What test tells you whether a clarifying question is worth asking now? Answer: You can name two plausible answers that lead to different builds. If both answers lead to the same plan, park the question.
• In the credit-union example, why does "where does the time go" come before "who decides"? Answer: It tests the customer's diagnosis. Learning that 6 of 9 days sit in "awaiting documents" moves the target off underwriting before any design starts.
• You ask whether stage timestamps exist and the interviewer says "you tell me." What do you say? Answer: State the assumption and its fallback (assume they export; otherwise time 50 files by hand) and keep designing.
• What goes into a good reflect-back? Answer: One sentence restating the problem in the customer's terms, including the fact that changed your direction, ending with a check such as "does that match what you see?"