Appendix K - Mistake Log and Practice Tracker

A useful log changes the calendar

Suppose a system-design mock ends with this note:

Need to get better at queues. Forgot idempotency. Felt rushed.

The note may be sincere, but it cannot choose the next practice block. Should the candidate read about queues, trace a duplicate-delivery failure, rehearse a clearer explanation, or run another timed design? Nothing in the record settles the question.

A mistake log is not a diary of disappointing moments. It is a queue of repair work. Each active entry should preserve what happened, identify the earliest behavior worth changing, and put a retest on the calendar. The matching practice tracker records whether that correction appeared when the prompt and pressure changed.

Preserve evidence before explaining the attempt

After a serious timed drill, mock, project-story rehearsal, take-home review, or real interview memory, save the lightest artifact that can correct recall. This may be code and tests, a diagram, design notes, a scorecard, a transcript, a recording made with consent, or a reviewer’s sparse timestamps. Do not keep proprietary prompts or another person’s voice without permission.

Write the observable failure before naming its cause:

Artifact:
Observable failure:
Consequence for the answer:
Help or interruption used:

Use language another person could verify. “At minute 31 I chose retries but had not said when they stop” is evidence. “Weak production judgment” is an interpretation. “I panicked” describes an inner state; “after the hint I apologized three times, stopped explaining, and abandoned the valid plan” describes behavior that can be rehearsed differently.

The artifact field is allowed to say reviewer note or memory only. Weak evidence does not make the attempt worthless, but it should limit the claim. Mark the entry uncertain when neither the artifact nor a reliable observer can settle what happened.

Find the first repairable cause

Work backward from the visible miss. A coding answer with no boundary tests may have begun with an invalid invariant, a small implementation error, or a decision to polish until no test window remained. Those endings resemble one another, but they require different practice.

Ask a counterfactual question:

If this diagnosis is right, what will the next practice block contain?

If the answer is “study the missing concept and use it closed-book,” the route is knowledge. If it is “notice this cue among neighboring problem shapes,” the route is recognition. If it is “rebuild the assumption, invariant, or trade-off,” the route is reasoning. Choose one primary route: the earliest cause whose repair would most change the next attempt. Keep a secondary note only when it changes the retest.

The nine routes are deliberately practical:

• Knowledge — learn the smallest missing concept, then use it without the source open.
• Recognition — classify adjacent prompts until the relevant cue becomes visible before solution work begins.
• Reasoning — state the governing constraint, derive the choice, and try to break the argument with a counterexample.
• Implementation — isolate the failed mechanic, repair it under time, then return it to a larger task.
• Testing — derive evidence from the contract or invariant and reserve a real verification window.
• Communication — rehearse the point at which sound judgment became hidden, disordered, or needlessly long.
• Time management — introduce checkpoints and an explicit cut line that protects scoreable work near the close.
• Emotional recovery — script a hint, disagreement, silence, or wrong turn and practice the transition back into useful work.
• Seniority signal — follow the relevant local decision into ownership, failure, rollout, observability, cost, risk, product effect, or coordination.

These are routes, not identity labels. “Careless,” “bad at design,” and “not senior” neither explain the artifact nor prescribe an honest repair.

Carry one attempt through the record

Consider the report-export mock from Appendix J. The candidate accepts an export request, creates a job, and sends work to a queue. When the client times out and repeats the request, the design can create a second job. A focusing question from the interviewer prompts the candidate to add an idempotency key.

The compact entry reads:

DATE AND ROUND
Jul 16 — system design mock

ARTIFACT
Diagram, interviewer card, and timestamps 12:10–19:40

OBSERVABLE FAILURE
The create request could produce two durable export jobs when the client
retried. Idempotency appeared only after a focusing question.

CONSEQUENCE
The system could perform duplicate work and present two histories for what
the user intended as one export.

PRIMARY ROUTE AND EVIDENCE
Reasoning. I treated the first accepted response as the boundary of success
instead of reasoning about a request whose result may be lost to the client.

EARLIEST REPAIRABLE CAUSE
Before defining the create contract, I did not ask what may repeat or which
record represents the user's intent.

CORRECTION RULE
Before accepting asynchronous work, name the retry identity, the durable
record that owns status, and the response returned for a duplicate request.

ADJACENT RETEST
Notification-campaign creation, Jul 18, 30 minutes. The interviewer will make
the first accepted response disappear and later redeliver one worker job.

PASS EVIDENCE
The create contract handles the repeated client request before storage or
queue selection; later worker redelivery does not create a second campaign.

STATUS
Open

The primary route is reasoning, not “queues.” The queue behaves normally when it redelivers. The candidate’s missing decision is the identity and authority that make repetition safe. A narrow implementation drill would be premature; the next attempt first needs the contract to become visible.

Notice that the correction rule begins with an action and can be observed. It does not say “remember idempotency” or demand every possible operational concern before the candidate may proceed.

Schedule a practice block, not an intention

Every open correction gets a dated block. The practice shape must reproduce the pressure that exposed the failure without adding unrelated difficulty.

PRACTICE BLOCK

Date and duration:
Correction under test:
Prompt or task:
Pressure preserved:
Artifact to keep:
Observable pass condition:
Decision if it transfers:
Decision if it does not:

For the export correction, the filled block is:

Date and duration: Jul 18, 30 minutes
Correction under test: identity and authority before async mechanism
Prompt or task: create and deliver a notification campaign
Pressure preserved: lost client response; duplicated worker delivery
Artifact to keep: diagram and sparse interviewer timestamps
Observable pass condition: client retry returns the original campaign;
worker redelivery cannot create a second delivery history
Decision if it transfers: place the correction inside the next full mock
Decision if it does not: compare the create and delivery identities, then run
one shorter state-trace drill before spending another full mock

A route should change the shape of this block. Communication needs a listener or recording. Recovery needs an interruption. Time management needs a realistic clock and enforced checkpoints. Testing needs a different task whose boundary or failure cases can disprove the answer. Seniority signal needs a prompt where consequences genuinely affect the decision, not a ritual demand to mention cost, rollout, and observability everywhere.

Update status only when the evidence changes

Keep the vocabulary small:

• Open means the correction has not been retested.
• Retested means it appeared once after an intentional attempt.
• Stable means it survived an adjacent prompt, a later day, or realistic mock interference.
• Retired means the issue has stayed absent across several relevant attempts and no longer deserves weekly attention.
• Uncertain means the evidence cannot support a diagnosis yet.

An immediate repeat of the same prompt can teach the correction, but it cannot show transfer. The prompt now contains reminders. Move an entry to stable only after the domain, wording, time, or social pressure changes enough that the candidate must find the behavior again.

Suppose the Jul 18 retest begins this way:

04:20 names client request key and campaign record before choosing storage
07:10 says a repeated create returns the existing campaign status
18:40 worker redelivery introduced
20:15 preserves one delivery record per campaign, recipient, and channel
27:30 close omits retry exhaustion and the user-visible failed state

The original correction transfers, so its status can become stable. The close also exposes a narrower production-judgment question. Do not quietly enlarge the old entry until it again means “get better at distributed systems.” Open a new entry for retry exhaustion only if its severity justifies active practice.

Let the weekly review make three decisions

Review once a week or after about three serious mocks. Do not sum scores or reward practice volume. Read the active artifacts and decide:

1. Which open failure could do the most damage in the next target loop?
2. Which repeated route suggests a habit rather than a one-off miss?
3. Which correction has transferred far enough to release attention?

Then choose no more than three active correction rules. Put one drill, one adjacent retest, and—when isolated repairs are holding—one integration mock on the calendar. Frequency matters, but severity may override it: a rare missing authorization check can deserve attention before a frequent low-cost syntax slip.

Use this weekly page:

WEEK OF:
NEXT TARGET LOOP:

MOST SEVERE OPEN ENTRY
Entry and artifact:
Why it threatens the target loop:
Next block and date:

REPEATED ROUTE
Route and supporting entries:
Habit worth testing:
Next block and date:

TRANSFERRED CORRECTION
Correction and transfer evidence:
Status change:

ACTIVE RULES — THREE MAXIMUM
1.
2.
3.

CALENDAR
Drill:
Adjacent retest:
Integration mock:

EVIDENCE TO COLLECT NEXT WEEK

Three active rules are a ceiling, not a target. A candidate five days from a coding loop may carry one testing rule and one recovery rule. Adding a third because the page has space makes both harder to retrieve under pressure.

Delete work the tracker invents

The log has become counterproductive when it consumes practice time, turns every warm-up into a record, or accumulates rows with no artifact and no scheduled retest. Remove or archive entries that cannot affect the calendar.

Watch for these distortions:

• Mood becomes diagnosis. Preserve the feeling privately if useful, but route practice from observable behavior.
• Every miss becomes study. Check whether the concept was truly absent before opening another reading branch.
• Labels multiply. Choose the earliest primary route rather than attaching four true categories and four corrections to one attempt.
• Scores acquire false precision. Keep a score only when its behavioral anchor and cited evidence change the next decision.
• The same prompt proves itself. Use immediate repetition to learn, then an adjacent prompt to test transfer.
• Practice volume impersonates readiness. Attempts count only insofar as their artifacts show a repaired behavior holding under relevant pressure.

The tracker serves the campaign. The campaign does not exist to fill the tracker.

Print the two working cards

Mistake entry:

DATE AND ROUND

ARTIFACT

OBSERVABLE FAILURE

CONSEQUENCE

PRIMARY ROUTE AND EVIDENCE

EARLIEST REPAIRABLE CAUSE

CORRECTION RULE

ADJACENT RETEST AND DATE

PASS EVIDENCE

STATUS — open / retested / stable / retired / uncertain

Practice block:

DATE AND DURATION

CORRECTION UNDER TEST

PROMPT OR TASK

PRESSURE PRESERVED

ARTIFACT TO KEEP

OBSERVABLE PASS CONDITION

DECISION IF IT TRANSFERS

DECISION IF IT DOES NOT

Related links

• Deliberate Practice
• The Mistake Taxonomy
• The Mock Interview Engine
• Interview Scorecards
• Mock Interviewer Scripts