1 min lesson
The dry-run protocol
Rebuild the sequence in "The dry-run protocol" from memory, ending with the check that proves the outcome.
Step 1 of 2
The dry-run protocolRecord and review
- 1Walk your three pieces, timed, to a camera or a friend. Three to four minutes each. Lead with the interaction or visual decision, not the project's backstory - the reviewer cares why you chose that easing, not the company's roadmap.
- 2Take five pushback questions per piece, without flinching. Have someone ask “why this and not the simpler version,” “what did you cut,” “show me the worst part.” The goal is calm, specific answers, not a defense.
- 3Deliver your why-Cursor and three STAR stories back to back. No pause to reset between them. If your why-Cursor sounds like it could be said about any AI startup, it's not done.
- 4Tighten every spot that drew a follow-up. A follow-up question is a flag that the first answer was vague. Rewrite that one until it lands clean the first time.
Learn more
Advanced table
What each pushback question is really probing
What each pushback question is really probingRead the subtext
- The question
- “Why this design and not the obvious one?”
- What they're testing
- Taste backed by reasoning, not decoration
- A landing answer
- A concrete trade-off: “the obvious modal blocked the diff; an inline panel kept context visible”
- The question
- “What would you cut or redo?”
- What they're testing
- Truth-seeking; honesty about your own work
- A landing answer
- A real weakness named plainly, plus what you'd do instead
- The question
- “Show me the part you're least proud of.”
- What they're testing
- Whether you have a 90→100 standard
- A landing answer
- You point to it yourself and describe the last-mile polish it's missing
- The question
- “How did you know it was good?”
- What they're testing
- Judgment and how you validate craft
- A landing answer
- How you measured it - a reference comparison, a frame-rate check, user reaction
| The question | What they're testing | A landing answer |
|---|---|---|
| “Why this design and not the obvious one?” | Taste backed by reasoning, not decoration | A concrete trade-off: “the obvious modal blocked the diff; an inline panel kept context visible” |
| “What would you cut or redo?” | Truth-seeking; honesty about your own work | A real weakness named plainly, plus what you'd do instead |
| “Show me the part you're least proud of.” | Whether you have a 90→100 standard | You point to it yourself and describe the last-mile polish it's missing |
| “How did you know it was good?” | Judgment and how you validate craft | How you measured it - a reference comparison, a frame-rate check, user reaction |
Defensiveness reads as fragile craft; naming your own weak spots first reads as a high bar.