The Mistake Taxonomy

The wrong diagnosis wastes the next attempt

In the previous chapter, Nia repaired the opening of her system-design answer. On a collaborative-editing prompt, she identifies the document history as an owner of truth before choosing components. The correction has transferred.

Then the interviewer asks what two users may see while concurrent operations are being reconciled. Nia says the system is “eventually consistent,” but cannot say which temporary states are acceptable or which outcome must never occur. After the attempt, she writes knowledge gap: consistency models in her error log and schedules an evening of reading.

That diagnosis feels plausible. It is also premature. In her notes from an earlier design, Nia accurately explained stale reads, monotonic reads, and conflict resolution. The vocabulary is available. What failed was the move from a general label to a reasoned boundary for this system.

Another survey of consistency models would be respectable preparation that does not touch the failure. Nia needs to practice deriving allowed and forbidden outcomes from concrete concurrent actions. The mistake belongs on the reasoning route, not the knowledge route.

Begin with what an interviewer could observe

Memory edits an attempt quickly. It upgrades intentions into things that were said, compresses long stalls, and turns several small decisions into one vague feeling. Use the residue of the attempt instead: code, tests, design notes, a recording made with consent, a transcript, a scorecard, or timestamped reviewer notes.

For Nia, the observable failure is not “weak consistency knowledge.” It is:

When asked what concurrent users may observe, I repeated “eventual
consistency” but did not name an allowed temporary state, a forbidden final
state, or the rule that resolves conflicting operations.

That sentence stays close to the artifact. It contains no claim about why the failure happened. Diagnosis comes next.

Look backward from the visible miss and find the first behavior that made it likely. If a coding answer ends without boundary tests, the first repairable cause may be an invalid algorithm, a broken state update, or a decision to keep polishing until the clock expired. “Missing tests” describes the ending; it does not yet choose the repair.

Use a simple counterfactual: if this diagnosis were true, what would the next practice block contain? Different answers expose different routes. If the candidate needs a concept, study it. If the concept is available but the prompt did not summon it, drill recognition. If the relevant facts appeared and the conclusion was still unsound, rebuild the reasoning.

Nine routes out of a mistake

The taxonomy separates failures only as far as preparation needs. Two labels that lead to the same correction do not need a debate. Two labels that lead to different work do.

Knowledge: the needed idea is unavailable

A knowledge error survives a direct, unpressured check. The candidate cannot explain the concept, use it in a small example, or identify its relevant limits. A missing graph algorithm, an unfamiliar isolation guarantee, or an unknown deployment technique may fit here.

Repair the smallest missing foundation, then require it to do work. Closed-book recall alone is not enough; follow it with a small problem or explanation that uses the concept. Do not turn every miss into a new reading list. If the idea was already available, another survey postpones the real diagnosis.

Recognition: the idea is available but the cue was missed

Recognition fails when the candidate can explain the right tool after the attempt but did not notice when the prompt called for it. A request for minimum total cost does not trigger weighted shortest-path reasoning. A dual-write migration does not trigger the question of which store is authoritative during the transition. A story about disagreement does not trigger a clear account of influence and escalation.

The repair is cue discrimination across adjacent prompts. Present examples that look similar but require different responses, and ask what feature changes the choice before solving them. Repeating the original prompt mostly tests memory of the correction.

Reasoning: the facts are present but the conclusion does not follow

Reasoning errors live in assumptions, invariants, causal claims, and trade-offs. The candidate knows the components or techniques and recognizes the problem family, yet chooses an invalid relation among them. Nia’s “eventual consistency” answer sits here: the label does not establish what users may observe or why the conflict rule preserves the product’s promise.

Repair the argument in visible steps. State the governing constraint, derive the choice, and look for a counterexample. For Nia, the correction rule is:

Before naming a consistency model, describe two concurrent user actions,
one temporary state the product may expose, one final state it must forbid,
and the owner that resolves the conflict.

Implementation: the plan is sound but the artifact is wrong

Implementation begins after a valid approach. The merge invariant is correct, but the equality boundary is coded incorrectly. The migration plan is sound, but the backfill cursor can skip a row. The API contract is clear, but the error path loses the caller’s idempotency key.

Practice the mechanical failure in a narrow slice. Preserve the valid plan so the drill does not become a new reasoning exercise. Then place the mechanic back inside a larger task, where attention must be shared.

Testing: the answer has no credible proof

Testing is its own route when the work may be correct but the candidate does not establish that it is. They choose no representative cases, fail to derive tests from the invariant, or leave no time to execute them. In design and production rounds, the analogous miss is an architecture declared complete without exercising failure, recovery, or rollout behavior.

Repair the proof ritual. Before implementation, name the important input or state classes. Before the close, run or trace representative boundaries, negative cases, and a failure path. If testing exposes that the original plan was invalid, move the primary diagnosis upstream to reasoning.

Communication: sound judgment is not made legible

Communication fails when the decisions an interviewer needs are hidden by ordering, omission, or excess. A candidate narrates four minutes of chronology before naming the project decision. They silently abandon one approach for another. They list trade-offs but never say which one governs the choice.

Repair the point where the listener loses the thread. Useful rules might be “decision, reason, risk, next step at every phase change” or “stake and personal decision before chronology.” This route is not a demand for constant speech. Silence while thinking can be clearer than narration that conceals the plan.

Time management: the answer spends minutes in the wrong place

Time management is not merely an incomplete answer at the bell. It is a sequence of allocation decisions that leaves important scoring evidence unreached: polishing code instead of testing, exploring every architecture branch instead of choosing one, or giving so much background that follow-up questions never reach personal judgment.

Repair with visible checkpoints and cut lines. A checkpoint says what must be true by a certain phase; a cut line says what will be simplified when it is not. If the candidate knew what to do but the mechanics consumed the time, implementation may be the earlier route. If verbose narration consumed it, communication may be earlier.

Emotional recovery: pressure changes the next behavior

Recovery is observable, not a diagnosis of personality. After a hint, bug, challenge, or silence, the candidate may apologize repeatedly, defend an old assumption, stop narrating, rush the rest of the answer, or abandon a workable plan. The technical gap that caused the intervention and the response to it are separate evidence.

Rehearse the transition: acknowledge the new information, restate what it changes, revise the plan, and continue. A realistic retest must contain an interruption or wrong turn. Calm solo repetition cannot show that recovery has changed.

Seniority signal: a local answer omits ownership consequences

A technically correct answer can still leave the interviewer unable to see senior scope. The design selects reasonable components but says nothing about rollout or failure ownership. The project story reports a team outcome without the candidate’s consequential decisions. The code works, but the close ignores operability, user harm, or a risky assumption.

Repair the missing consequence that the target round can legitimately expose: reliability, observability, migration, cost, product effect, coordination, or learning. Do not bolt every senior concern onto every answer. The route is successful when the candidate follows the relevant decision far enough to show ownership beyond the local mechanism.

One failure can offer several true labels

Nia’s design answer also contains a communication miss: she uses a broad term where the interviewer needs an explicit product boundary. It may even expose a seniority-signal gap because she has not connected inconsistency to user harm. All three observations can be true. Making all three primary would produce three correction rules and no clear next attempt.

Choose the earliest cause whose repair would most change the next performance. Nia selects reasoning. If she can derive the allowed and forbidden states, she will have something precise to communicate, and the product consequence will become visible. Communication and seniority signal remain secondary notes.

This rule also prevents category inflation in coding. Suppose an invalid invariant produces a boundary bug, no useful tests, and an unfinished answer. Reasoning, implementation, testing, and time all appear in the wreckage. If a valid invariant would have changed everything downstream, repair reasoning first. Later attempts may reveal a separate testing habit, but the current artifact cannot prove it.

Keep uncertainty visible. “Provisionally reasoning; compare with an unpressured explanation” is more useful than a confident label unsupported by evidence. Ask a reviewer a narrow question when needed: “Does the category match the artifact, and what evidence would change it?”

A repair is only a hypothesis until it transfers

Nia first repeats the collaborative-editing example to make sure she can use the new rule. That checks the correction’s mechanics, not its reach. The prompt now supplies too much of the answer.

Two days later she tries an inventory-reservation design. The domain is different, but the disputed boundary is similar: two buyers act against scarce stock while payment and reservation events arrive at different times. Before naming a consistency mechanism, she describes the temporary state a buyer may see, rules out two confirmed purchases for the last item, and identifies the reservation record as the authority for expiry and release. The reasoning route has produced changed behavior on an adjacent task.

The retest should match the route:

• Knowledge needs closed-book use of the concept in a small new problem.
• Recognition needs the same cue hidden inside different wording.
• Reasoning needs an adjacent assumption, invariant, or trade-off.
• Implementation needs the failed mechanic under time, then reintegration.
• Testing needs a new task whose boundaries or failure cases can disprove it.
• Communication needs a recording or listener who can follow the decisions.
• Time management needs a realistic clock and enforced checkpoints.
• Emotional recovery needs a scripted hint, disagreement, silence, or wrong turn.
• Seniority signal needs a prompt where ownership consequences genuinely affect the answer.

A repaired category can reveal another weakness. Nia’s stronger reasoning may still take twelve minutes to explain, exposing communication or time management. That does not invalidate the first repair. Better practice often replaces one broad failure with a smaller, truer one.

Keep only the record that can change the plan

One compact entry is enough for a serious attempt:

Artifact:
Observable failure:
Primary route and evidence:
Earlier repairable cause:
Correction rule:
Adjacent retest and date:
Result:

Review the log weekly, not as a score of personal deficiency but as a queue of repair work. Frequency is evidence of a habit; severity is evidence of what could damage the target loop. A rare omission of migration and rollback may deserve attention before a frequent low-cost coding slip. A category that persists across round families deserves scrutiny. A category that has transferred can leave the active queue.

Shrink the system when the log starts consuming the practice block. Avoid identity labels such as “careless” or “not senior,” numerical precision the artifacts cannot support, and entries with no correction or retest. Do not use the taxonomy to convert every uncomfortable attempt into more study. Its value is the work it rules out as much as the work it schedules.

Nia’s reasoning repair is now ready for interference. The next chapter builds mocks that can challenge the repaired behavior with time, follow-up questions, and another person in the room. A drill shows that a correction is available. A well-designed mock shows whether it survives the rest of the interview.

Related links

• Deliberate Practice
• The Mock Interview Engine
• Coding Readiness Gates
• System-Design Readiness Gates
• Recovering When Stuck