Claude Code Interview Pattern: The Hidden Gem for Enterprise Developers

Ask an AI coding assistant to build a feature, and it starts building right away. It will likely fill every gap in your request with an educated guess. Most of those guesses are reasonable, and that's the problem. In finished code, a guess looks exactly like a decision. Nobody reviews a decision they don't know was made.

On a small change, that's fine. In enterprise software, some of those silent guesses end up in a public API contract, a database schema, or the way a service behaves when a dependency fails. Those decisions are expensive to undo.

The interview pattern flips the order. Before writing any code, the model asks you questions. In my experience, no other pattern has done more for the correctness and quality of the code I ship with AI. Let's look at why it works and how to make it part of your workflow.

A REST client that turned out not to be simple

A while ago, I had to add a REST client to a microservice in a Java Quarkus application. On paper, it was routine work. Call an endpoint, map the response, and hand it to the service layer. You'd expect an AI assistant to finish that in one shot.

Instead of asking for the code, I asked Claude to interview me first. The first questions were easy. Then they went somewhere I hadn't planned to go. How long should a call wait before giving up? Which failures are safe to retry? What happens when the provider starts rejecting requests because we call too often?

That last question stopped me. The endpoint was going to be heavily used. I hadn't thought about rate limiting at all, and I'd only thought about fault tolerance in a vague "we'll add a retry" way. The interview made both explicit, and that changed the implementation. I ended up with timeouts, retries limited to failures that are actually retriable, a client-side rate limit, and a defined fallback for when the dependency is down.

The code was better. But the bigger win was something else. By the end of the interview, the model and I understood the problem the same way, and in more depth than either of us started with. The plan that came next was built on my answers, not on its assumptions.

What the interview pattern is

The idea is simple. Before implementing anything, Claude asks you questions that surface the decisions and edge cases you haven't thought about yet. The Claude Code best-practices guide calls this letting Claude interview . Matt Pocock calls it grill-me. Here is a way to express it in a prompt.

I need to add a REST client for the inventory service. Before writing any code, interview me using the AskUserQuestion tool.

- Ask one question at a time, offer likely answers, and recommend one.
- Cover edge cases, failure modes, and assumptions I haven't stated.
- Flag any decision that would be hard to change later.

When we've covered everything, write the decisions to specs/inventory-client.spec.md.

Three details make this work.

- One question at a time. Each answer gets your full attention, and later questions build on earlier answers.

- A recommended answer. You're reviewing a proposal, not filling in a blank form. If you disagree with the recommendation, that disagreement is usually the most useful part.

- Documenting the decisions at the end. The decisions outlive the chat. A fresh session can plan or implement from a file with a clean context, and your colleagues can read it too.

Where the risk hides: five areas worth figuring out first

Some questions matter more than others. The first two are about inputs. The last three are about the system around the change.

Edge cases. These are single inputs at an extreme: an empty response, a null field, the largest page size, a malformed payload, a duplicate request. They're the cheapest to find and the cheapest to fix, and each one should become a test.

Corner cases. These are two or more conditions happening at once. Each condition is fine alone, but together they break something. In the REST client, retries and rate limiting are the classic pair. A retry policy that looks sensible on its own multiplies traffic at exactly the moment the provider is already throttling you. Three retries on every rejected call can turn a rate limit into an outage. Written requirements almost never mention corner cases, because nobody pictures two failures at once.

Regression risk. In a legacy application, this is often the biggest risk of all. Old code is full of behavior that nobody wrote down but someone depends on: a quirky default, an error code a downstream job parses, an ordering a report assumes. The model can't see those dependencies, so it changes them without noticing. Ask about them before the change, not after the incident:

- Which existing callers, jobs, or reports depend on the behavior we're touching?

- Is that behavior pinned by a test? If not, should we write a characterization test first, to capture what the code does today?

- What's the blast radius if this goes wrong, and how would we roll it back?

Maintainability. Code that works isn't automatically code your team can live with. Left alone, a model will happily introduce a second way of doing something the codebase already does: a new HTTP client next to the existing one, its own retry helper, a fresh naming style. Each one is reasonable on its own. Together, they turn a codebase into a collection of dialects. Ask:

- Should this follow an existing pattern in the codebase, or is there a reason to introduce a new one?

- Does it add a dependency, and who keeps that dependency up to date?

- Who maintains this code after it ships, and what will they need to understand it?

Decisions that are hard to revert. These are the decisions that leak out of your codebase into other people's. Ask about them first, and spend the most time on them.

- Data model and schema: nullability, keys, stored enum values, and migrations on live data.

- Contracts and events: public API shapes, and the message schemas other teams consume.

- Failure semantics: whether an operation is idempotent, and what a caller sees when a dependency is down (an error, a stale value, or a degraded response).

Here's a useful rule of thumb. The further a decision travels beyond your service, and the older the code it touches, the more it deserves a question. You can rewrite a private helper function tomorrow. You can't do that with an event schema that has three consumers, or with a ten-year-old behavior that a nightly batch job quietly depends on.

When to interview, and when to skip it

Interview when:

- The requirement is vague, or the domain is new to you.

- You need to uncover edge and corner cases.

- Implicit assumptions need to become explicit.

- A wrong guess would be expensive to undo.

Skip it when:

- Tests, examples, or a precise spec already settle the requirement.

- The change is small and well understood, and every question would have an obvious answer.

Match the depth to the risk. A one-line config change needs no interview. A new integration with a heavily used external API deserves ten questions.

Make it repeatable with a skill

A good prompt that you remember to use is a personal habit. A skill makes it a team default. Packaged as a Claude Code skill, the interview runs the same way every time, for everyone on the team. Here is one for inspiration. Feel free to adjust it for your own software development workflows. You can also find the SKILL on GitHub in my Claude Engineering Toolkit.

---
name: interviewing-human
description: Interview the human one question at a time about the work under discussion in the current conversation, to surface edge cases, corner cases, regression risks, maintainability concerns, and decisions that are hard to revert. Use when a requirement is vague or underspecified, the domain is unfamiliar, the change touches legacy code that other systems depend on, or it affects API contracts, event schemas, data models, failure handling, or shared infrastructure, and generally whenever a wrong guess would be expensive to undo. Works on its own or as a step in a planning workflow, after the task has been described and the relevant code explored. Skip it when tests, examples, or a precise spec already settle the requirement, or when the change is small and every question would have an obvious answer.
allowed-tools: Read, AskUserQuestion
---

# Interviewing the human

Interview the human about the task already under discussion in this
conversation. Use what has been said so far, and what exploring the code has
found, to decide what to ask. If the task isn't clear from the conversation,
ask what it is as your first question.

Do not write or change any files. Your job is to turn open questions into
decisions the human has made.

## Interview

Use the AskUserQuestion tool. Ask one question at a time.

- Offer 2–4 likely answers, mark one as (Recommended), and give a one-line reason.
- Always let the human answer in their own words. AskUserQuestion adds an
  "Other" option for free text automatically, so don't add a separate one.
- Ground each question in the conversation and the code where you can.
- Skip questions the conversation or the code already answers. State the
  answer you found instead.

Cover these areas, most expensive to reverse first:

1. Hard-to-revert decisions: anything other code, teams, or stored data will depend on.
2. Failure behavior: what should happen when something the change relies on goes wrong.
3. Edge cases: inputs at the limits of what the change expects.
4. Corner cases: conditions that are harmless alone but break things together.
5. Regression risk: existing behavior that must keep working.
6. Maintainability: how the change fits the codebase and who will own it.
7. Unstated assumptions: anything the request takes for granted.

If the answer is "not sure" or "need to check," treat it as an open question
with a likely owner. Do not guess on the human's behalf.

Stop when the remaining questions would have obvious answers.

## Wrap up

Summarize the outcome in the conversation:

- The decisions made
- The edge and corner cases, each phrased as a testable case.
- The open questions, and who should answer them.

Example output:

```text
Decisions
- Callers get an error when the provider is down, never a guessed value: stale data would mislead downstream reports.
- Retry only on connection errors and 503s, up to 3 times with backoff.
- Follow the existing client pattern in the orders module rather than introducing a new HTTP library.

Cases to test
- Provider returns an empty list → return an empty result, not an error.
- Provider returns 429 while a retry is pending → stop retrying and honor Retry-After.
- Existing nightly export still receives the same field order.

Assumptions confirmed
- Peak load is about 50 requests per second.

Open questions
- Does the provider enforce a rate limit per client or per account? → owning team
```

Do not record the decisions anywhere or start implementing. The human decides
what happens next.

The interview pattern gives you better code, but its biggest payoff is the deep, shared understanding you and the model build before a line is written, and the conversations with architects and colleagues it starts while changing course is still cheap. Questions are cheaper than rollbacks, so the next time you start work you can't easily undo, don't ask for the code: ask to be interviewed.