interviewing

When to Use

• Requirements or goals are ambiguous
• User isn't clear about what they want
• Hidden complexity might derail implementation
• Another skill encounters fundamental ambiguity

Skip when requirements are already clear or user wants to proceed without clarification.

Core Methodology

Ask Non-Obvious Questions

Probe deeper than surface-level:

• Why: What problem does this solve? Why now?
• Constraints: What would make this unacceptable? What can't change?
• Failure modes: What's the worst case? What happens when X fails?
• Success: How will you know this worked? What does "done" look like?
• Tradeoffs: What are you willing to give up? Minimum viable version?
• Assumptions: You mentioned X, but what about Y? Is that always true?

Avoid

• Restatements of what's already said
• Yes/no confirmations
• Generic questions that apply to anything
• Leading questions

Follow the Thread

Dig deeper when answers reveal complexity. Don't jump topics when current one has unexplored depth.

Batch Questions

Use AskUserQuestion with questions array for 2-4 related questions exploring different angles of the same area.

Saturation

Stop when:

• Answers stop revealing new information
• You could explain requirements to someone else
• User expresses readiness to proceed

Output

Summarize what you've learned:

**Clarified Requirements:**
- **Goal**: [specific goal]
- **Constraints**: [hard limits]
- **Success criteria**: [how we'll know it worked]
- **Key tradeoffs**: [prioritizing vs deprioritizing]
- **Open questions**: [if any]

Integration

| Skill | When to use interviewing first | |-------|-------------------------------| | Brainstorming | User unclear about what they want (not just how) | | Technical Planning | Requirements too vague to plan | | Debugging | Problem description unclear | | Blog Writing | Topic or purpose unclear |

For writing, also ask: What's the core message? Who's the audience? What triggered this?

Examples

See reference/examples.md for project and writing interview flows.