Lesson 26 — How to Run a Revision Day

~20 minutes · Days 6, 13, 20, 28 · revision protocol

On Days 6, 13, 20, and 28, the goal is not to collect another solution. The goal is to prove that a pattern can come back from memory under interview pressure: blank file, no hints, clear reasoning, and a hard rule for what counts.

The invariant

Re-solve your weakest problems from a blank file with no hints; a problem only counts as revised when it compiles and passes on the first or second run.

That rule keeps revision honest. Reading notes can feel productive, but it does not test whether the pattern is retrievable. A blank file does.

The comfortable way first

The tempting version of revision is to reread notes, rewatch a solution, and nod along. It is low-friction, but the signal is weak: recognition is not the same as recall. Interviews ask for recall.

The better version is stricter. Pick the weak item, say the invariant first, write the brute force and its complexity, then code the best approach without opening a stored solution. Only the first two runs count.

The revision loop is strict on purpose: only a blank-file pass in run one or two leaves the weak list.

Revision day as code

Read this like a checklist, not a LeetCode submission:

def revision_day(weak_list):
    for problem in weak_list[:3]:          # use the current topic block
        open_blank_file(problem)           # no stored code, no hints
        predict_invariant(problem)         # pattern, brute force, complexity
        runs = code_and_submit(problem)    # stop after run one or two
        if runs <= 2 and tests_pass():
            mark_revision_done(problem)    # this one counts
        else:
            log_root_cause(problem)        # keep it in the queue

The mistake log matters. Every failed revision gets one clear line: WA: <root cause>, such as wrong invariant, off-by-one, missed edge case, or misread problem. That line chooses the next revision target more reliably than mood does.

Transfer: same protocol, new day

Day 20 is a stack revision day. Suppose the weak list points at a monotonic stack problem. Before reading on, predict the first two things to say before coding.

What the trade buys you

The second approach is harder, but it gives a usable signal: pass, fail, or specific mistake. That is what lets the queue improve.

Practice — answer before you scroll past

while not tests_pass():
    edit_and_run_again()
mark_revision_done(problem)

Your move (revision days)

Run this checklist on Days 6, 13, 20, and 28. Log every item in your Notion tracker with predict → attempt → compare → encode:

1. Choose up to three weak problems from the current block. Use mistake-log lines first; use hesitation second.
2. Open a blank file. Do not open notes, stored code, editor history, hints, or a video.
3. Before coding, say the pattern invariant, the brute force idea, and the target complexity out loud.
4. Code and run. If it passes on run one or two, tick Revision Done.
5. If it fails after two runs, write WA: <root cause>, leave Revision Done unticked, and keep it in the queue.
6. End with the gate for the day: Day 6 arrays, Day 13 strings/sliding window, Day 20 stack, Day 28 linked list.

The gates are concrete: arrays means one easy hashing and one prefix-sum solve in under 15 minutes each; sliding window means stating every validity rule from memory; stack means explaining amortized push/pop; linked list means reversing on paper with no pointer mistake.