The Five Principles

🔬 From the Full Prep Guide →. These five principles are the core of the framework. Each one has a goal, a mantra (≤10 words — works under stress), how to do it in your own words, and the anti-patterns that tell you you're failing.

Remember Them as R³·D²

Three R's, then two D's: Recover, Reveal, Review · Debug, Draw. Say "R-three-D-two" like the droid and the five come back in order. Each principle below also carries a hook — a picture to recall when the words won't come.

---

Overload Hierarchy

When your brain is full and you can only do one thing:

Layer	Action	When
1	"Done with X. Next: Y, because Z."	Always possible. Non-negotiable.
2	Name one rejected alternative.	If you have capacity.
3	Self-test: "Most important decision — did I say why?"	If you have more.
4	The full principles below.	Rehearsal only.

If you only do Layer 1 after every unit of work, you are 80% of the way to a strong interview.

---

Principle 1: Make Your Reasoning Recoverable

Goal: Someone who walked out for 5 minutes could reconstruct every consequential decision you made and why — just from what you said.

Mantra: "Done with X. Next: Y, because Z."

Hook (R1): Breadcrumb trail — a colleague who stepped out for five minutes can retrace every fork from your words alone.

In your own words

After finishing anything meaningful — a function, a prompt result, a design choice — say what you picked and what you didn't pick. If there was no alternative, say what you're doing next and why. Use your own vocabulary. "I went with X over Y because…" or "Next I'm adding auth since everything depends on it."

You're failing if

• The interviewer asks "why did you do X?" and you have an answer but didn't volunteer it. You're hoarding reasoning.
• You chain "next I'll do X, next I'll do Y" without ever naming a rejected alternative. That's a todo list, not reasoning.
• You catch yourself thinking "I should have said that." Narrate in real time, not from memory.
• You sound like you're checking boxes. If it feels like a ritual, it sounds like one.

When silence is correct

Typing boilerplate. Fixing a typo. Executing a single obvious path. But if code is appearing and you've been quiet — say what you're doing.

When interrupted

Answer the question first. Only recover context if you genuinely lost it — no formulas.

When asked "why did you do that?"

Answer the question directly. No meta-apology ("I should have narrated that…"). Just answer. Then make the next two decisions more vocal. The content proves you learned; the apology proves you read a prep guide.

---

Principle 2: Say What the Screen Won't Remember

Goal: The code, prompt text, and error traces stay on screen. Your reasoning doesn't. Verbalize the invisible layer: what you considered and rejected, what you're assuming, what you plan to do next.

Mantra: "Screen shows what. I'm saying why."

Hook (R2): Director's commentary — the screen is the film; you're the track that says why the scene exists.

In your own words

Before speaking, ask: "Would someone reading my screen already know this?" If yes, don't say it. If no, say it naturally. No taxonomy needed — just don't read your screen aloud.

You're failing if

• You read your prompt text aloud. The interviewer can read.
• You explain basics to a domain expert who already knows them. Jump to what's controversial or non-obvious.
• You invent rejected alternatives you never considered. Invented alternatives are worse than no alternatives.
• You don't have a rejected alternative. Say: "I only know one way — open to better ones." Honest. Power move.

---

Principle 3: Review What Matters

Goal: Prove critical reading of generated code without a line-by-line audit. Catch anything that would break the prototype. Name one specific thing you verified.

Mantra: "One thing I checked: [specific]."

Hook (R3): Customs officer — don't open every suitcase; open the risky one and say which and why.

In your own words

When code appears, scan for the first decision that matters — a data structure choice, a missing guard, an assumption. Say something about that one thing. Then run it. You don't need to review every line; you need to prove you didn't blindly trust the output.

For different generation sizes

Output size	Strategy
≤50 lines	Per-file verdict. "Model looks right — composite key. Service is light on errors — noted."
>50 lines	Scan the riskiest file only. Say which file and why. "Checking auth — if that's wrong, nothing else matters."
Streaming	Narrate as it arrives. The narration IS the review.

You're failing if

• You say "looks good" without pointing to anything specific. That's approval, not review.
• You say "nothing jumps out" for the 5th time. That's rubber-stamping, not reviewing.
• You miss something the interviewer finds. Own it: "I missed that — let me look." Owning a miss beats pre-licensing it with "I only did a quick scan."
• You review boilerplate (imports, formatting) while skipping the logic. Review the decisions, not the wrapping paper.

---

Principle 4: Debug Like You're Pair-Programming

Goal: The interviewer should feel like they're debugging with you, not watching you debug. Classify severity instantly. Narrate your hypotheses. Ask for guidance when stuck — don't wait for a timer.

Mantra: "Typo." / "I've seen this." / "Let me think." / "External."

Hook (D1): ER triage nurse — classify the patient before treating anyone.

Triage tier (say this, not a timer)

Tier	Say	Action
Typo	"Typo."	Fix instantly. Zero ceremony.
Known	"I've seen this."	"Usually [X]. Checking." ~30 seconds.
Internal	"Let me think."	Logic or config error. Hypothesis → test.
External	"External."	Rate limit, API outage, quota. Check the service BEFORE debugging code.

The External tier is critical: a rate limit or API outage can eat your entire round if you treat it as a logic bug. Ask: "Is the service up? Is my key valid? Am I rate-limited?"

For Internal bugs: count hypotheses, not minutes

After 3 failed hypotheses, ask. "Three things ruled out. My best guess is [X]. Should I continue or move on?"

If they say continue:

• Hypotheses 4–5: Broaden scope — check assumptions, read caller code.
• Hypotheses 6–7: Narrow — binary search, add targeted logging.
• After hypothesis 7: Shift to collaborative. "Here's what I've ruled out. Your guidance?"

You're failing if

• "Typo." takes 15 seconds of narration. It's a typo. Fix it.
• You're watching the clock more than the bug. Performing debugging ≠ debugging.
• "My best guess is X" when you don't have one. Say so: "I don't have a good hypothesis yet — let me check one more thing."
• "Continue or move on?" when you know you're close. "I'm close — one minute." Judgment beats protocol.
• Claiming to have "ruled out" things you barely checked. Say what you tried, not what you concluded.

---

Principle 5: Draw to Think

Goal: A diagram is a thinking tool, not a deliverable. Draw when it helps YOU reason — not when a prep guide says to. The interviewer cares about your reasoning, not your box-drawing skills.

Mantra: "Let me sketch — three moving parts."

Hook (D2): Napkin, not blueprint — a messy sketch that clarifies beats a pretty one that decorates.

In your own words

Draw when you can't hold the system in your head. Use whatever shapes make sense. The type of diagram matters less than whether it clarifies your thinking.

If the tool fights you for more than 60 seconds, describe it verbally. If screen share is blurry, narrate everything — the diagram becomes your private scratchpad. If you're near the end of the interview, summarize verbally instead of starting a new diagram.

Self-test (rehearsal only)

After drawing, point to any connection. Say what travels across it, what triggers it, and what happens when it arrives. Can't do all three? It's decoration, not reasoning.

You're failing if

• You draw something you could've explained in two sentences. Ceremony, not clarity.
• The diagram is prettier than it is useful. Pretty boxes, hollow content.
• You're fighting the tool for 60+ seconds. Stop. Describe it.
• You redraw for cleanliness. Annotate. A messy living diagram beats a clean stale one.
• You spend more time on the diagram than the code. The prototype is the deliverable. The diagram is scaffolding.

---

The compass: The interviewer is answering one question — "Would I want to pair-program with this person?" Every principle serves that answer. If a rule tells you to say something that would make you annoying to pair with — ignore the rule.

← Back to Full Prep Guide · Quick Reference Card →