An MBA student opens Claude Code and types: "Add a customer churn prediction script to our analytics repo." Claude immediately writes ~300 lines of code that uses logistic regression, picks a 90-day churn window, and assumes a particular feature set. The student didn't specify any of those choices. Half the code is wrong for the team's actual definition of churn.
What approach should the student have taken?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
The interview pattern surfaces design considerations the developer hadn't yet articulated — which is most of the considerations, on most non-trivial tasks. Asking Claude to question you before implementing is a small upfront cost that prevents large downstream rework. It's also pedagogically right for students: it externalizes the reasoning that experienced developers do silently, making it visible and learnable. Use it any time the task has meaningful design choices the prompt doesn't pin down.
There is no industry-standard churn definition. Different teams use 30/60/90/180-day windows, different feature sets, different ML algorithms — these are decisions, not defaults. "Use the standard" assumes a standard exists; it usually doesn't.
Pre-specifying every decision in a single prompt assumes the user already knows every decision they need to make. The whole point of the interview pattern is that they don't — and a dialogue surfaces the gaps faster than a monologue.
Asking the same session that just made unstated assumptions to review its own assumptions is asking it to question decisions it just rationalized. Self-review tends to confirm rather than catch.