## Completeness Completeness is the least glamorous dimension and the one candidates most often assume they have. It asks a blunt question: **did you actually finish, and do you know that you finished?** The second half is the hard part. Plenty of candidates produce working code and cannot demonstrate that it works. In a round where a model wrote much of it, "it looks right" is not evidence of anything. Think about the last bug you fixed with AI assistance. - Did you see it fail before you fixed it? - After the fix, did you re-run the thing that failed — or did you run something new that passed? - Who wrote the test that convinced you: you, or the model that also wrote the code? If the answer to the last one is "the model," you have a closed loop. The code and its verification came from the same source, and it can be self-consistently wrong. ## Reproduce before you fix This is the highest-value habit in the entire course, and it takes about ninety seconds. Before changing anything, write the smallest thing that demonstrates the failure. In the session: ```python rl = RateLimiter(capacity=5, refill_rate=1) allowed = sum(1 for _ in range(100) if rl.allow()) print(allowed) # prints 100, should be about 5 ``` Four lines. Look at everything it bought: - **An oracle.** After the fix, this either prints `5` or it does not. No judgment call, no "seems better." - **Prompt content.** "Returns True 100 times when I expected about 5" is the most useful sentence in the prompt that follows. - **A named target.** You are no longer hunting a vague misbehavior; you are explaining a specific number. - **Insurance against a wrong diagnosis.** If your fix is wrong, you find out in four seconds instead of at minute thirty-eight. > "Before I change anything I want to see it fail, so I know when it's fixed." Interviewers consistently flag reproduction as a senior signal, and skipping it as a mid-level one. It is the clearest single discriminator in the first fifteen minutes. ## Run between generations The reported failure is specific: candidates stack three accepted changes without executing anything, hit a break, and cannot tell which change caused it. Then the debugging is worse than the original problem, because you are now bisecting three simultaneous edits under a clock, in code you did not write. The rule is simple and nearly free: **run after every meaningful change.** Accept, run, observe, then continue. In an interview it also produces a steady stream of observable verification, which is exactly what this dimension is scored on. ## The closed-loop test problem Tests written by the same model that wrote the code, passing on the first run, are the weakest possible evidence — and interviewers know it. First-run green should make you suspicious, not satisfied. Two fixes, both cheap: **Write the failing test yourself, first.** Ninety seconds, and it inverts the logic entirely: now the test is your specification and the model's job is to satisfy it. ```python def test_users_have_independent_buckets(): rl = RateLimiter(capacity=2, refill_rate=1) assert rl.allow("alice") is True assert rl.allow("alice") is True assert rl.allow("alice") is False # alice is out assert rl.allow("bob") is True # bob is unaffected ``` Watch it fail. Then let the model fill in around it. Watch it pass for a reason you can articulate. **Tell the tool to leave your tests alone.** One line in the prompt — `do not modify the existing tests` — and it removes the entire category of silent test drift. Sometimes a test genuinely should change. That is fine — but announce it and explain why. Letting tests quietly change until they pass is covered in the Red Flags lesson, because that is what it is. The failure is not the edit; it is the silence, which makes every subsequent claim unverifiable. ## Edge cases are part of finished "Works on the happy path" is not done, and the model will rarely volunteer the unhappy ones. A quick sweep, out loud, is worth a lot: - **Empty and zero** — no users yet, capacity zero, refill rate zero. - **Boundaries** — exactly at the limit, one over, one under. - **Time** — what if elapsed time is zero, or the clock does not advance between calls? - **Repeat and concurrent** — the same user twice in the same millisecond; two threads at once. You do not have to handle all of them. Naming them and choosing scores well: > "Zero capacity would divide oddly here — I'm going to assume capacity is at least one and note it rather than handle it, given the time." That sentence demonstrates you saw the edge, made a call, and know it is a call. That is completeness even though the code does not handle the case. ## Landing the plane The last five minutes are scored, and most candidates waste them. **The failure:** refining quietly until the interviewer says "we're at time." The final observed state is a candidate mid-edit, and the last impression is incompleteness. **The fix:** stop early on purpose. At minute thirty-eight, stop, run everything once more, and narrate: > "I've got two minutes, so I'm going to stop here rather than start something I can't finish. Where this stands: the refill bug is fixed and verified against the reproduction, per-user limits work with a test I wrote first. What's missing is the lock around the token update and real eviction — right now the dict grows forever. Those two are what I'd pick up next, in that order." Three things happen in those fifteen seconds. You demonstrate you know what your code does. You show you can prioritize remaining work. And you take control of the final impression instead of letting the clock take it. These rounds are usually scoped so that finishing everything is not expected — the third phase is often discussed rather than implemented. Knowing precisely what is unfinished is the signal. Pretending it is done is the anti-signal. ## Practice this **Drill 1 — Reproduce first, always.** For one week, never fix a bug you have not first made fail on demand. Notice how often you would have fixed the wrong thing. **Drill 2 — The stacking audit.** Next AI session, count how many accepted changes you make before running anything. If it is more than one, that is the habit to break. **Drill 3 — Test first, then generate.** Write the failing assertion by hand before prompting for the implementation. Three repetitions and it stops feeling slower. **Drill 4 — The two-minute landing.** In timed practice, set an alarm at minute thirty-eight. Stop and deliver the summary out loud. It is a rehearsable speech, and rehearsing it is why it will be there under pressure. ## What's Next Finished is not the same as good. The next dimension asks whether the thing you delivered would survive your own code review.