Computer science exams have a specific cruelty: they ask you to simulate, repair, or analyze code — the exact skills your IDE does for you. The debugger traces; the compiler catches bugs; the Big-O is a fact in the slides. On the exam, all that scaffolding is gone, and the student who "understood the demo" discovers they were watching, not learning.

A CS exam asks you to be the interpreter. Close the IDE. Hand-trace today's function with a tiny input, state the bug if one line changes, and justify the complexity after that change. That's the skill set — and it's not the same as knowing what the code does when you can see it run.

The gap is between recognition and simulation. Watching the instructor trace binary search feels like understanding; your eyes follow the highlight, the logic seems obvious, the output confirms it. But the exam doesn't let you watch — it gives you a function and a changed line and asks what happens now. That requires producing the state sequence, not recognizing it.

Why watching demos fails the exam

The recorded coding demo is the CS equivalent of highlighting — fluent, passive, and useless for the actual task. You watch the instructor type, the code appears, the logic seems inevitable. What's trained is recognition of the instructor's clicks: "yes, that's how it goes." What's tested is production without the clicks: "here's the code, here's the mutant, what breaks?"

Tracing is retrieval of state, not recognition of syntax highlighting. When you hand-trace, you produce the value of i on iteration 3, the contents of the call stack, the point where the invariant breaks — all from memory, all without the IDE doing the work. Changing one line is a desirable difficulty that blocks memorizing a single walk-through: if you can only trace the exact code you saw, you memorized a movie; if you can trace the mutant, you understand the mechanism.

The trace-debug-justify workflow

Scope to one lecture. Today's recursion or data-structures code, not the whole algorithms unit. The functions your professor wrote are what the exam draws from — practicing on a random LeetCode problem is preparing for a different test.

Force the three stems. For each function, write: trace this with a small input (produce the state sequence), what breaks if this line changes (debug the mutant), and what's the complexity after that change (justify with the new behavior). Every stem requires producing, not recognizing.

Produce the state sequence, not a description. "It finds 4" is a description; "mid=2, go left; mid=0, go right; mid=1, hit" is a trace. The exam wants the states — the values at each step — because that's what demonstrates you can run the code in your head.

Name the fake-progress version. For each item, say what watching the demo would have missed: "the demo showed the working version; the mutant breaks because the off-by-one skips the left half." The contrast makes the skill visible — and shows why recognition isn't enough.

Retest with a new mutant. Same function, different change — delete a base case, swap a comparator, change the input size. The 1/3/7-day spacing holds; the new mutant prevents memorizing the walk-through instead of learning the mechanism.

A 40-minute session on the clock

The weak answer is the summary — "it finds 4, the change might matter" — which is what you'd say if you watched the demo. The strong answer produces the states: mid=2, then 0, then 1, with the values at each step. And it names the failure mode: the off-by-one midpoint can skip a half or loop forever. That's the trace-plus-mutant pair the exam grades.

Why the mutant matters

Tracing the code as-written tells you it works; tracing the mutant tells you why it works. The base case exists because without it the recursion doesn't terminate; the comparator direction matters because swapping it searches the wrong half. You don't see the constraint until you see what breaks without it.

This is why the mutant is the test of understanding. A student who memorized the walk-through can reproduce the trace; a student who understands the mechanism can predict the break. The exam asks for the prediction — "what happens if..." — because that's what distinguishes comprehension from playback.