1️⃣ One question at a time
The first rule of the method is almost absurdly simple: one question per turn. The interviewer asks one question, waits for your response, and only then moves on. No dumping five numbered questions at once.
Why does it matter? Five questions at once force you to do mental triage, and one or two are almost always poorly answered or forgotten. One at a time keeps you focused on resolving a decision before opening the next one.
✗ In batches
- ✗"Answer 1, 2, 3, 4, and 5" — you overwhelm them.
- ✗Shallow answers; something gets left behind.
- ✗Impossible to adapt the next question to the previous one.
✓ Serial
- ✓One question, one answer, one checkpoint.
- ✓The next question comes from the previous answer.
- ✓A conversation with rhythm, not a form.
One question at a time.
One decision at a time.
The next one grows out of the previous one.
Conversation, not a form.
✅ Recommended answer
This is the technique that keeps the interview from becoming tiring: for each question, the interviewer already suggests the answer it recommends — the best guess based on context. You just need to confirm, correct, or redirect.
💡 Why it reduces friction
Answering from scratch is exhausting. Reacting to a proposal is easy—"yes," "no, it's like this," or "actually, the point is something else." Even when the guess is wrong, it speeds things up: it gives you something concrete to react to.
🔁 The three reactions
- • Confirm — "that’s right." The decision goes into the file.
- • Fix — "almost, but the right number is X." Fine-tuning.
- • Redirect — "that’s not the right question." It changes the direction.
Comes with a ready-made guess.
React > create from scratch.
Inferred from context.
Confirms/corrects/redirects.
🌳 Decision tree and dependencies
The interview isn’t a flat list of questions—it’s a tree. Some decisions depend on others. The rule: resolve the decision first upstream (the one above, which others depend on) and only then the decisions downstream (the ones that come after it).
Upstream / downstream? Think of a river: what is upstream (upstream) affects everything downstream (downstream). If you decide on a detail before the choice that governs it, you may have to redo it.
Follow the arrows: decide on the root at the left first to unlock the branches. Each leaf on the right ends as “decided” or becomes a flag—it never remains unresolved.
It’s not a flat list.
The root before the branches.
Each branch to the end.
The order prevents rework.
🔎 Explore before asking
A good interview doesn't waste your attention with what’s already written. If the answer is in the code, a file, or a doc you provided, the interviewer reads it and finds out on its own — and only brings up what’s genuinely new.
✓ Explore first
- ✓Reads the codebase to understand what’s already there.
- ✓Reads the doc you attached and absorbs what it can.
- ✓Ask only what isn't written down anywhere.
✗ Asks the obvious
- ✗"What language does the project use?" — it’s in the code.
- ✗Repeats what the doc already answered.
- ✗It spends your time on what it could have read.
🎯 Tip
Did you provide a Google Doc or a README? The interviewer should read it and only ask net-new — what isn’t there. Your answers are reserved for knowledge that exists only in your head.
Code, file, doc.
Only what’s new.
Nothing that’s written down.
Reserved for tacit knowledge.
🚩 Flags With an Owner
You won’t know everything — and that’s okay. When a question touches on something you don’t know well, it doesn’t stall the session: it becomes a flag with the owner right, and the interview continues.
What is a “flag”? An open item recorded in the capture file, with who can answer it. E.g.: tabela de custo por caixa → financeiro. Then you reach out to the person, get their response, and update the brainstorm.
🚩 Why not get stuck
Stopping the entire session because one detail is missing is wasteful. The flag leaves the gap visible and addressed without interrupting the flow. In the reference video, this is what “talk to so-and-so and bring back the information later” looks like.
Open item recorded.
Who can answer.
The session continues.
Gap addressed.
💾 Checkpoint after each answer
This is the technique that makes the interview loss-proof. After each response, before starting with the next question, the interviewer appends a structured entry to the capture file — the markdown in brainstorms/ that stores the session. Never in a batch.
Capture file? It’s the session capture file—the source of truth (covered in Track 1). The checkpoint is the act of writing to it. If a new answer contradicts an old one, the old entry is corrected, not duplicated.
### Q3 — tamanho da caixa - Asked: como você decide o tamanho da caixa? - Captured: "menor caixa que cabe + 2cm de folga" (nas palavras dele) - Flags: tabela de custo por caixa -> financeiro # ...próxima pergunta só DEPOIS de gravar isto.
📌 The rule you never break
Saving in a batch at the end defeats the purpose: if the session crashes halfway through, the batch doesn’t exist yet. One checkpoint per response ensures the file always contains everything that was said up to that point.
Before the next question.
One per answer.
Updates old entries.
Always complete up to now.
🧯 The Completeness Backstop
No matter how complete the tree is, there may always be a branch nobody saw. Near the end, the interviewer throws out a safety net: “is there any important aspect we haven’t touched on?”.
The tree has been traversed
Every anticipated decision has become an answer or a flag. It seems finished.
The net question
"Anything we haven't touched?" makes room for what was off the map.
The last gap appears
Something almost always comes up — and it’s recorded like any other answer.
Capture what the tree didn't see.
Closes the last gaps.
It ends with a decision, not exhaustion.
The finding goes into the file.
🔧 Reconcile contradictions
A long session accumulates answers that may contradict each other. The final step is a reading the entire file: look for contradictions and gaps, reconcile them, and wrap up with a clear recap.
🧭 The final recap
- • What was captured — the consolidated decisions.
- • What was left flagged — open items and their owners.
- • The suggested next step — where this goes (e.g., becomes a skill).
📌 Why reread
Without rereading, the capture becomes a patchwork where answer 3 contradicts answer 12 and nobody notices. Reconciliation turns the raw log into a document coherent and usable.
The entire file at the end.
Resolve contradictions.
Captured / flag / next.
A document, not fragments.
🎤 Module summary
Next track:
Track 3 · The Skill — look under the hood of SKILL.md: frontmatter, Matt Pocock’s original version, the checkpoint rule, and the philosophy behind it.