The “Interview Yourself” Pattern: Clarification Technique with Claude

One of the most valuable skills of a senior engineer isn’t about code — it’s the ability to ask the right questions before a single line is written. It’s the discipline of transforming “build feature X” into a clear, shared understanding of what is actually needed.

The “Interview Yourself” pattern simulates that discovery process with Claude cast as the interviewer. Instead of jumping straight to a spec, you open a dialogue in which Claude asks clarifying questions — and you answer them — until the specification can be written with precision. This article shows how to run that interview yourself clarification spec golang workflow end to end.

07.1 Why Self-Clarification Is Hard

There is a psychological trap in self-clarification: we tend not to know what we don’t know. When we write a spec alone, we quietly fill the gaps with assumptions that feel obvious — yet those assumptions are rarely shared by other developers, QA, or the AI that will implement the code.

The example below shows a single innocent sentence exploding into three incompatible interpretations across three engineers.

 1Developer A writes the spec:
 2"Users can cancel an order that hasn't been processed yet"
 3
 4Unwritten assumption A: "not processed" = status PENDING
 5Unwritten assumption B: cancel is allowed anytime while PENDING
 6Unwritten assumption C: stock returns immediately on cancel
 7
 8Developer B reads the same spec and assumes:
 9"not processed" = PENDING or CONFIRMED (not yet shipped)
10"cancel anytime" = but only within 24h of the order date
11"stock returns" = scheduled, not immediate

The takeaway: one sentence, three engineers, three divergent mental models. The Interview Yourself pattern eliminates this by surfacing hidden assumptions before they harden into bugs.

07.2 Basic Structure of Interview Yourself

Before running a session, it helps to picture the loop you are about to enter. The diagram below traces the back-and-forth between you and Claude, from the initial feature description to the final draft spec.

 1You                    Claude (as Interviewer)
 2  │                              │
 3  ├── "I want feature X" ────────►
 4  │                              │
 5  │◄── Q1: [question 1] ─────────┤
 6  ├── [answer 1] ────────────────►
 7  │                              │
 8  │◄── Q2-Q5: [...] ─────────────┤
 9  ├── [answers 2-5] ─────────────►
10  │                              │
11  │◄── "I have enough info now"  │
12  │◄── [Draft Spec] ─────────────┤

What to take from the flow: the spec is never dictated up front — it emerges as the residue of a structured Q&A. You describe the feature, Claude probes one question at a time, and only after the ambiguity is drained does a draft appear.

07.3 Starter Prompt: Beginning an Interview Session

The quality of the interview depends heavily on how you frame Claude’s role. The prompt below sets the persona, the rules of engagement, and the focus areas so the questions stay concrete instead of vague.

 1You are a very experienced senior product engineer specializing in
 2defining requirements for e-commerce systems.
 3
 4I'll describe a feature I want to implement.
 5Your job is to ask clarifying questions like an interview that will
 6surface all hidden assumptions and ambiguities.
 7
 8Interview rules:
 91. Ask ONE question per turn (not multiple at once)
102. Questions must be specific and concrete — not "what about error handling?"
11   but "if a user tries to cancel an order that's already CONFIRMED, what should happen?"
123. Follow the thread of previous questions before moving to new topics
134. After gathering enough information, say "I have enough information,
14   shall I create the spec draft now?"
155. Focus areas: happy path, error cases, concurrent scenarios,
16   external dependencies, data consistency
17
18OK, I want to implement a cancel order feature in Santekno Shop. Cancellation is done by customers.

Notice how rule 2 forces specificity: a question like “what about error handling?” gets you nowhere, while “what happens if the user cancels a CONFIRMED order?” produces a decision you can encode. That single constraint is what turns a chat into an interview.

07.4 Complete Interview Session Example: Cancel Order

Theory is easier to trust once you see a full run. The transcript below is a realistic Interview Yourself session for the cancel-order feature — read how each answer closes one ambiguity and opens the next question.

[You]: I want to implement a cancel order feature in Santekno Shop. Cancellation is done by customers.

[Claude as Interviewer]: First question: In what order statuses can customers cancel? Only PENDING, or also CONFIRMED?

[You]: Only PENDING. After CONFIRMED, the merchant has already started processing.

[Claude]: Is there a time limit for cancellation? For example, PENDING but more than 24 hours ago — can it still be cancelled?

[You]: Yes, we decided there’s a 15-minute window from when the order was created. After that, no cancellation even if still PENDING.

[Claude]: When a cancellation succeeds, what happens to the stock of products in that order?

[You]: Stock must be returned automatically. It must be atomic — all or nothing.

[Claude]: Who gets notified after a successful cancellation? Customer only, or merchant too?

[You]: Customer gets an email. Merchant must also be notified since they’ve reserved stock. Notifications via Kafka event.

[Claude]: If there are two concurrent cancel requests for the same order — say the customer double-clicks — what should happen?

[You]: Only one succeeds, the other gets an error. No duplication.

[Claude]: If Kafka publish fails after the order is successfully cancelled in the database — rollback or stay successful?

[You]: Stay successful. The order is already CANCELLED and stock is restored. Kafka failure should be logged as a warning but no rollback. Notification service has its own retry mechanism.

[Claude]: I have enough information. Shall I create the spec draft now?

[You]: Go ahead.

The lesson from this transcript: every design decision in the eventual spec — the 15-minute window, atomic stock restore, best-effort Kafka publish — was extracted from an answer, not invented by the AI. The interview is what converts tacit knowledge in your head into explicit acceptance criteria on the page.

07.5 Interview Variations: Domain Expert Perspectives

A single persona finds a single class of gaps. To harden a spec, re-run the interview with Claude wearing a different hat each time. The three prompts below swap in a QA, security, and performance lens respectively.

 1Variation 1 — Skeptical QA Engineer
 2Act as a senior QA engineer known for finding production bugs.
 3Ask questions a QA would ask for comprehensive test coverage.
 4Focus on: race conditions, boundary values, invalid input combinations,
 5external system failures, and data integrity issues.
 6
 7Variation 2 — Security Reviewer
 8Act as a security engineer focused on OWASP Top 10.
 9Ask clarifying questions about security aspects:
10authentication, authorization, input validation, rate limiting, data exposure.
11
12Variation 3 — Performance Engineer
13Act as a performance engineer who has debugged production outages
14during flash sales.
15Ask about: expected load, DB query performance, caching strategy,
16concurrent access patterns, scaling concerns.

The value here is coverage by rotation: the QA persona finds edge cases the product persona never imagines, and the security persona surfaces threats neither of the others would ask about. Each hat is a different flashlight into the same dark room.

07.6 Interview for Multi-Service Features

When a feature spans multiple services, the interview becomes harder but far more important, because the riskiest ambiguities live at the boundaries between services. The prompt below aims the questioning at ownership, communication patterns, and failure modes across the boundary.

 1You are a senior architect experienced in distributed systems.
 2
 3I want to implement an "order confirmation email" feature involving
 4Order Service, Notification Service, and Email Provider.
 5
 6Ask clarifying questions about:
 71. Service boundaries (who is responsible for what)
 82. Communication patterns (sync vs async, which uses events)
 93. Error handling at each service
104. Idempotency and eventual consistency
115. What happens when a downstream service is down
12
13Start from the most fundamental question about ownership.

The key move is starting from ownership: once you nail down which service is responsible for what, the questions about sync-versus-async and failure handling fall into place naturally. Distributed features fail at their seams, so the interview should spend its energy there.

07.7 Recording Interview Results: Interview Notes

The interview is worthless if its decisions evaporate the moment the session ends. Capture them in a durable notes document before you write the formal spec — the template below records each decision alongside its reason.

 1# Interview Notes: Cancel Order Feature
 2Date: 2025-07-15
 3
 4## Key Decisions Made
 5
 6### Status eligibility
 7- Decision: Only PENDING can be cancelled
 8- Reason: After CONFIRMED, merchant has started processing
 9
10### Time window
11- Decision: 15 minutes from created_at
12- Reason: UX decision to prevent abuse
13
14### Stock restore
15- Decision: Atomic with status change
16- Implementation note: SELECT FOR UPDATE in transaction
17
18### Kafka failure
19- Decision: Log warning, remain successful
20- Reason: Notification service has retry, cancel is already committed
21
22### Refund
23- Decision: OUT OF SCOPE — separate spec
24
25## Assumptions to Confirm with Stakeholders
26- [ ] Is the 15-minute window based on user timezone or server timezone?
27- [ ] Does the customer get notified if a cancel FAILS (expired window)?
28- [ ] What format does the merchant notification need?

Notice the separate “Assumptions to Confirm” section: it captures the questions you couldn’t answer yourself and flags them for a stakeholder, so an unresolved unknown never masquerades as a settled decision.

07.8 When to Use Interview Yourself vs Writing Spec Directly

The interview is a tool, not a ritual — some tickets deserve it and some don’t. The table below maps common situations to the right choice so you don’t over-invest on trivial work.

The pattern in the table is clear: reach for the interview when uncertainty and blast radius are high (new, cross-team, or money-touching work), and skip it when the feature is a well-worn path. Spending 30 minutes interviewing a simple CRUD endpoint is its own kind of waste.

07.9 Interview for Non-Technical Stakeholder Requirements

Requirements often arrive from a product manager or business analyst in vague, aspirational language. Interview Yourself becomes a translation layer that converts “make it like Tokopedia” into engineering-ready rules — the prompt below drives that translation.

 1Product manager requirement:
 2"We want to add a loyalty points feature. Customers earn points every purchase,
 3redeemable for discounts. Like Tokopedia."
 4
 5Act as a technical product manager bridging business and engineering.
 6Ask questions to:
 71. Clarify business rules (points per IDR, conversion rate)
 82. Define edge cases (points expiry? minimum redeem? maximum discount?)
 93. Identify technical implications (real-time or batch?)
104. Separate MVP scope from future features
11
12Start from the most business-critical question.

The takeaway: framing Claude as a technical product manager gets it to bridge the two worlds — it will ask business-rule questions in language a PM can answer, then quietly surface the technical implications those answers carry.

07.10 Advanced: Multi-Persona Interview

For genuinely complex features, don’t rotate personas ad hoc — sequence them so each round builds on the last. The prompt below chains four persona rounds into a single escalating interview.

1We'll do 4 interview rounds for the checkout feature.
2
3Round 1 — Product Engineer: business rules and happy path
4Round 2 — QA Engineer: edge cases and testing scenarios (reads Round 1 draft)
5Round 3 — Security Engineer: auth, authorization, data protection
6Round 4 — Performance Engineer: load, latency, scaling
7
8After all rounds, produce a final comprehensive spec.
9Start Round 1.

The strength of sequencing is that Round 2 critiques Round 1’s draft rather than starting cold, so each persona layers new rigor onto an increasingly solid foundation. By Round 4 you have a spec stress-tested from four independent angles.

07.11 Interview Completeness Checklist

How do you know the session is thorough enough to stop? Run the checklist below after each interview; any unchecked box is a gap you carry into implementation at your own risk.

 1### Business Rules
 2- [ ] Happy path fully defined
 3- [ ] All predictable error scenarios covered
 4- [ ] Scope boundaries clear (IN and OUT)
 5
 6### Technical Concerns
 7- [ ] Concurrent access scenarios addressed
 8- [ ] External dependency failure scenarios addressed
 9- [ ] Data consistency requirements clear
10- [ ] Transaction boundaries defined
11
12### Non-Functional
13- [ ] Performance expectations clarified
14- [ ] Security requirements addressed
15- [ ] Observability needs mentioned
16
17### Organizational
18- [ ] Ownership clear
19- [ ] Cross-team/service dependencies identified
20- [ ] MVP vs future scope separated

Treat this list as a stopping condition, not paperwork: if every box is checked the feature is genuinely understood, and if several are blank the interview isn’t finished no matter how long it ran.

07.12 Interview Yourself in Sprint Planning Context

The pattern pays off beyond a single spec — it reshapes how a whole sprint is planned. The workflow and benefits below show how a 15-minute pre-planning interview changes the character of the planning meeting itself.

Before sprint planning:

1. The engineer runs a 15-minute Interview Yourself for each ticket entering the sprint.
2. The interview result becomes a spec draft brought to planning.
3. Planning focuses on reviewing the draft — not starting from zero.

Benefits:

• Sprint planning becomes focused review rather than open exploration.
• Estimates are more accurate because a spec already exists.
• Fewer implementation surprises because edge cases were identified upfront.

The payoff is that discovery moves out of the crowded planning meeting and into cheap solo prep, so the team spends its shared time confirming a draft instead of improvising one.

07.13 Socratic Questioning: Advanced Variant

The most advanced variant doesn’t just clarify your feature — it interrogates the reasoning behind your answers. The prompt below tells Claude to question your assumptions Socratically, which often reveals that your first decision wasn’t your best one.

 1Use the Socratic method in this interview.
 2
 3Meaning:
 4- Not just asking clarifying questions
 5- Also question the assumptions behind my answers
 6- Help me discover whether the decisions I'm making are truly best
 7  for the user and system
 8
 9Example:
10You: "Why is the time limit 15 minutes?"
11Me: "So users can't abuse it by cancelling after rare stock sells out"
12You: "Is there another way to prevent abuse besides a time window?
13     Like rate limiting cancellations per day per user?"
14Me: [might discover that a time window isn't the best solution]
15
16Feature to spec: [feature name]

The point of Socratic questioning is that it treats your own answers as hypotheses to be tested, not facts to be recorded — and that pressure frequently uncovers a simpler or safer design hiding behind your first instinct.

07.14 Documenting Interview as Project Artifact

Interview notes are worth version-controlling right next to the spec they produced. The directory layout below keeps the final spec and its originating interview together so the “why” is always one click from the “what”.

1specs/
2└── domain/
3    └── order/
4        ├── cancel-order.md              ← final spec
5        └── _interviews/
6            └── cancel-order-2025-07-15.md  ← interview notes

With that layout in place, the notes earn their keep in four recurring situations:

• Onboarding: “Why 15 minutes, not 30?” → answered in the interview notes.
• Debugging: “Why does this behave this way?” → trace it to the original decision.
• Spec revision: When revising, you can see the original rationale first.
• Post-mortem: If a bug appears, you can ask whether a wrong interview decision caused it.

The takeaway: co-locating the interview with the spec turns tribal knowledge into a durable, searchable artifact that outlives the engineer who ran the session.

07.15 Interview for Complex Bug Investigation

Interview Yourself isn’t only for new features — it is a sharp tool for pinning down a slippery bug. The prompt below turns Claude into a senior debugger that narrows the search space one targeted question at a time.

 1Act as a senior debugger. I'll describe a bug.
 2Ask questions to understand:
 31. Reproduction conditions (when it occurs, how often)
 42. Impact scope (which users are affected)
 53. Expected vs actual behavior
 64. Recent changes that might be related
 75. Is this a regression or something that was never correct
 8
 9Bug: "Some customers report they can't cancel their order
10     even though they just placed it 2 minutes ago"
11
12Start from the question that will most quickly narrow down the root cause.

The discipline that matters here is ordering questions by information gain: asking first what most quickly narrows the root cause keeps a debugging session from wandering, exactly the way a good interview keeps a spec session focused.

07.16 Using Interview Results for Estimation

A completed interview is also the best possible input to an estimate, because the ambiguity that usually wrecks estimates has already been drained. The prompt below turns the interview’s spec into a task-level estimate with explicit confidence and risks.

 1Based on the spec we just produced from the interview session,
 2help me create an implementation estimate.
 3
 4Consider:
 5- Task breakdown based on ACs and ECs
 6- Complexity of each task (low/medium/high)
 7- Dependencies between tasks
 8- Testing effort (unit test for each AC)
 9- Review and buffer time
10
11Output format:
12| Task | Complexity | Estimate (hours) | Dependencies |
13|------|-----------|------------------|--------------|
14
15Total estimate: X hours
16Confidence: [high/medium/low]
17Risks: [what could make the estimate miss]

The takeaway: because the estimate is derived from acceptance criteria that already survived interrogation, the numbers rest on decisions rather than guesses — which is why interview-backed estimates tend to hold up far better than gut-feel ones.

07.17 Combining Interview with Different AI Tools

Interview Yourself doesn’t have to run on Claude alone; different tools bring different strengths to the same session. The mapping below shows when to reach for each.

Claude Code: For clarification that needs code context — architecture, existing patterns, actual file references. Perplexity: For researching industry practice — “is a 15-minute cancel window standard in e-commerce?” A different AI model: For a fresh perspective unbiased by the previous context.

The value of combining tools is triangulation: code-aware clarification, external benchmarking, and an independent second opinion together produce a spec that is more robust than any single model could deliver.

07.18 Tips & Gotchas

Even a well-structured interview can go sideways in predictable ways. The tips and gotchas below capture the habits that keep sessions productive and the traps that quietly ruin them.

💡 Tip 1: Don’t rush to answers — think before answering. Take 30 seconds before responding to each question.

💡 Tip 2: Answer “I don’t know” when you genuinely don’t know — it’s far more valuable than inventing an assumption that becomes a wrong spec decision.

💡 Tip 3: Ask Claude for follow-up questions on the same topic before moving on if something isn’t fully clarified.

💡 Tip 4: Save the complete transcript, not just the final result — the Q&A documents the “why” behind decisions.

⚠️ Gotcha 1: An interview can run on forever without focus — cap it at 20–30 minutes or 15–20 questions. If more is needed, the feature is too large; break it down.

⚠️ Gotcha 2: Claude may not know your specific business domain — it doesn’t know a “flash sale” at Santekno means 10x traffic spikes. Provide that context explicitly.

⚠️ Gotcha 3: Claude may drift into overly technical questions — redirect: “Focus on business behavior, not implementation. Let engineers decide tech details.”

⚠️ Gotcha 4: Not every answer belongs in the spec — some belong in an ADR or technical notes. Separate them cleanly.

The through-line across all of these: the interview only works if you protect its focus and honesty — bound its length, admit what you don’t know, and file each answer where it belongs.

07.19 Building a Question Bank for Common Scenarios

Over time, the most valuable questions repeat across features. Capturing them in a reusable question bank means every future interview starts several steps ahead — the bank below seeds the most common categories.

 1# Question Bank: Common Clarifying Questions
 2
 3## Authorization & Ownership
 4- Who can perform this action? (user, admin, system?)
 5- If a user acts on another user's resource — 404 or 403?
 6- Do admins have override capabilities?
 7
 8## Data Lifecycle
 9- What happens to related data when the primary record changes state?
10- Is this a soft delete or a hard delete?
11- What's the retention policy for this data?
12
13## Concurrency
14- What happens if two requests modify the same resource simultaneously?
15- Is idempotency required? How should duplicate requests be handled?
16
17## External Dependencies
18- What happens if [service X] is down?
19- Is this operation synchronous or can it be eventually consistent?
20- Who owns the retry mechanism?
21
22## Notifications
23- Who gets notified? Customer, merchant, both, internal team?
24- Through what channel? Email, push, Kafka event?
25- Is the notification blocking (must succeed) or best-effort?

The takeaway: a question bank turns hard-won interview experience into a checklist you can reuse, so your team’s collective judgment compounds instead of being re-derived from scratch every sprint.

07.20 Summary

The “Interview Yourself” pattern is a clarification technique that simulates the discovery process between an engineer and stakeholders — but performed solo, with Claude as the interviewer.

Three main variations:

1. Product Engineer interview — business rules and the happy path.
2. QA Engineer interview — edge cases and testing scenarios.
3. Multi-persona interview — for very complex features.

When to use it:

• New features with no existing precedent.
• Features involving multiple stakeholders.
• Features touching financial transactions.
• Requirements arriving from non-technical stakeholders.

Key outputs:

• A spec draft ready for formal review.
• Interview notes documenting why decisions were made.
• More accurate input for estimation.

Keys to success: answer honestly (including “I don’t know”), don’t rush, and save the complete transcript.

In the next article we move from clarification to contract: OpenAPI Spec with Claude — how to define an API contract before code is written, and how Claude Code can generate Go code straight from that contract.