Letting Claude Interview You

The last lesson had you asking the questions. This one turns that around, and the reason has nothing to do with cleverness. It is that you do not yet know what you want.

Not because you are careless. Because a feature of any size is a pile of decisions, and most of them stay invisible until something forces them into the open. What happens when the list is empty. Whether this is per-user or per-team. Whether the old rows get migrated or left alone. You will answer every one of these eventually. The only question is whether you answer them now, in a conversation, or in three days, after Claude has built something around a guess.

The prompt

You start deliberately small — one line about what you want — and then hand control of the conversation over.

claude

1. >You typed: I want to build saved searches: a user can save a set of filters and come back to them later. Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, concerns and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

2. Claude ran: Read src/search/filters.ts

3. Claude ran: Read src/db/schema.ts

4. WhyIt reads first. The questions are better for it — instead of asking where saved searches should live, it can ask whether they belong next to the existing user preferences table it just found.

5. Claude ran: AskUserQuestion: Where should a saved search be stored?

6. Output: 1. New saved_searches table, one row per search
   2. JSON column on the existing user_preferences row
   3. Client-side only, in local storage

7. WhyThis is what the AskUserQuestion tool does: it puts a multiple-choice question to you rather than burying it in a paragraph. Read the options even when you already know your answer — they are a free summary of the decision you are making.

8. >You typed: 1 — we'll want to share searches between users later.

9. Claude ran: AskUserQuestion: A saved search references a filter that no longer exists — a deleted tag, say. What should happen?

10. Output: 1. Drop the dead filter silently and run the rest
    2. Show the search but flag it as broken and refuse to run it
    3. Delete the saved search when its filter is deleted

11. WhyHere is the whole point of the exercise. You had not thought about deleted tags. Answering it now costs you fifteen seconds; finding it in a bug report costs you an afternoon and a migration.

12. >You typed: 2, but let them edit it — being told why it broke matters more than convenience.

13. Claude ran: AskUserQuestion: Should saved searches appear in the existing search UI or somewhere new?

14. Output: 1. A dropdown next to the search box
    2. A dedicated page under /searches
    3. Both — dropdown for recent, page for all

15. >You typed: I don't know. What does the rest of this app do for lists like this?

16. WhyYou do not have to pick one. Typing your own answer is always allowed, including saying you are unsure and asking it to explain or recommend first. An honest 'I don't know' produces a better spec than a confident guess.

17. Claude replied: Every other collection in this app is a page with a table — tags, exports, API keys — and none of them have a dropdown shortcut. Option 2 is the consistent choice. I'd suggest a page now and a shortcut later if people ask for it.

18. >You typed: Agreed, page only.

19. Claude ran: Write SPEC.md

20. Claude replied: Written. It covers the schema change, the two new routes, the broken-filter behaviour, what is out of scope, and a verification script. Start a fresh session and point it at SPEC.md to build it.

A few things in that prompt are doing real work and are worth keeping.

Naming AskUserQuestion asks for structured multiple-choice questions rather than a wall of prose you have to read and answer point by point. You answer by choosing an option, or by typing something else entirely.

Saying do not ask obvious questions is what stops the interview being a customer-service script. Without it you get asked whether you would like tests.

Saying keep interviewing until we have covered everything stops it after two questions, which is otherwise the default instinct.

And ending with write a complete spec to a file is the part that makes the whole thing worth doing.

The spec is the product

The interview is not the output. The file is.

Time spent making the spec precise pays back more than the same time spent watching the implementation. Read it properly. This is the cheapest moment in the whole task to disagree with something — the file is a hundred lines and nothing has been built on top of it yet.

It also being a file, rather than a conversation, has quiet advantages. It survives your session ending. It can be committed and reviewed by a colleague. It can be handed to a second session, or three sessions working in parallel. And when the implementation drifts, you have something to compare against rather than a memory of what you agreed.

Then start again

When the spec is written, do not carry on. Start a fresh session and tell it to implement the spec.

This feels wasteful and is not. Your interview session is now full of things that did not happen: two storage designs you rejected, a UI you decided against, a tangent about migrations. Every one of those is still in the context window, competing for attention with the plan that survived. A new session begins with an empty context window, reads a hundred-line file that contains all the conclusions and none of the deliberation, and starts work.

You can reference the file directly in the new session with @SPEC.md, which puts its contents into the conversation without waiting for Claude to go looking for it.

Where it goes wrong

Two honest failure modes.

Using it for small things. The interview costs several minutes and a real slice of context. For a change you could describe in one sentence, that is overhead with nothing on the other side of it. This technique earns its keep in proportion to how expensive a wrong assumption would be.

Answering carelessly. The spec is built from your answers, so a shrug becomes a design decision. If you genuinely do not know, say so and ask for a recommendation, as in the transcript above. What you must not do is pick option one to move things along, because you will meet that choice again later wearing a different hat.

One more thing worth knowing: by default these questions sit and wait for you rather than timing out, so you can leave one open while you go and check something. If you would rather an unanswered question eventually close and let Claude proceed on its own judgement, there is a setting for that, and it applies only to these multiple-choice questions — permission prompts never resolve themselves.

What to take away

For anything large, the bottleneck is not Claude's ability to write the code but your ability to say what you want, and you cannot say it because half the decisions have not surfaced yet. Asking Claude to interview you with the AskUserQuestion tool drags them into the open at the point where they are cheap, and reading the options it offers is often as useful as answering them. The output is a spec on disk, and a good one names the files and interfaces involved, states plainly what is out of scope, and ends with a verification step that decides when the work is finished. Then start a fresh session to build it, so implementation gets the conclusions without the debate.

Next: sessions themselves — how to resume one, when to fork instead, and why naming them turns them into something like branches.