Final Audit + Maintenance Plan

Review boundary and corrected contracts

These are practice protocols, not hiring rubrics. Times, score bands and review intervals are adjustable conventions; neither a difficulty label nor a score predicts an interview outcome. Record the input contract, evidence of correctness and what remains uncertain.

Learning objective: Compare a repeatable audit with L59, validate retention on unseen variants, and write a sustainable maintenance plan.

Series: LeetCode — From Basics to Production-Ready · Session 65 / 65 · Phase 4 · Design review simulation

Watch first

Optional pre-reading, outside the timed session. These original links are retained as navigation; they were not watched or externally revalidated in this review. Use them to collect observations, not as governing evidence for company frequency, stress effects or hiring outcomes.

• How I Got Good at Coding Interviews — Compare earlier advice with the evidence in your completed attempts.
• Gayle Laakmann McDowell — Cracking the Coding Interview — Separate preparation, delivery and feedback when drafting your plan.
• Example Coding / Engineering Interview — Observe one explanation and compare its mechanism with your own mock, not its speed as a hiring threshold.

Why this session exists

Finishing a track and retaining its mechanisms are different outcomes. Use retrieval and delayed checks to find what remains available without prompts; do not assume every skill disappears after a fixed number of weeks. The learning review cited below supports practice testing and distributed practice in studied educational settings, not a universal exponential decay law for coding.

This session has two jobs: compare evidence against L59, then design a maintenance loop that fits your actual week. An audit is one measure, not the only honest measure of progress. Keep tested implementations, explanations and unseen variants alongside the classification table. A plan can be too ambitious, but ninety minutes is not a universally sustainable dose either.

Blank-file warm-up

Use fifteen minutes with no notes to write as many pattern skeletons as you can: two pointers, windows, answer search, monotonic stack, BFS/DFS, topological sort, DSU, backtracking, DP families, heap top-k, Dijkstra and trie. Record the denominator of patterns attempted and separate fluent recall from correctness not yet checked.

Mark errors and continue rather than spending the entire inventory on one repair. Validate the marked skeletons afterward with their input contracts and a small test. Compare like-for-like conditions at the next audit; an immediate retrieval count alone is not proof of transferable problem solving.

Pattern anatomy

The maintenance loop allocates regular opportunities to retrieve, apply and repair. Its design constraint is feasibility on a difficult week, with an explicit fallback rather than a claim that all abandoned plans had the same cause.

# PROPOSED MAINTENANCE LOOP — 3 × 30 minutes = 90 minutes/week
# A: 30 min due retrieval items; if none, two blind templates and their checks.
# B: 20 min unseen Medium + 10 min review; record classification AND correctness.
# C: 30 min one weak-family rebuild: derive, apply, update the cue card.
# Bad-week fallback: one bounded A session; record deferred items without debt.
# Quarterly: 75 min classification sweep for 75 rows, PLUS 10 min comparison.
#            Add validation/repair time separately rather than calling recall proof.
# Two weeks before an interview: measure, target gaps, two narrated mocks,
#            one optional contest, light review/rest; budget these separately.

In session A, a due queue larger than thirty minutes needs triage: prioritize repeated failures and oldest due items, record deferrals and resize the queue or cadence. Do not claim every due item fits. Session C is a compressed L60 practice block, not the full multi-pattern intensive or proof of durable repair; schedule a delayed check.

The cue

Reassess the plan when a previously verified template fails unaided, classification time rises under comparable conditions, or timed practice has been absent long enough that its current status is unknown. None of these observations alone proves a particular decay rate.

An interview within two weeks can trigger a temporary targeted block. More than three families below warm can be a personal triage threshold, not a validated cutoff. Check whether the family lacks a concept, needs retrieval practice or merely needs implementation correction before increasing volume.

Guided solve

Part one: re-audit, 75 minutes for 75 rows. Use the same problem IDs as L59 and sixty seconds per row for classification, not full solving. Save the row order, allowed assistance and time limit. The repeated list supports a paired comparison but benefits from familiarity; a separate small unseen set is needed to assess transfer. Do not mix that set into the paired denominator.

Compute three summaries after the sweep:

1. Improved rows: compare ordinal statuses using failed < hint < warm < cold. Count a row once if it improved by at least one level; keep the transition itself, not just the total.
2. Regressed rows: count downward transitions and keep the unchanged count too. An individual regression could reflect marking, fatigue, task interpretation or retention; replicate a failure before diagnosing it.
3. Weak-list overlap: compare the actual family names and underlying failures. The same bottom three can remain bottom while every family improves, so unchanged rank is not proof that the rebuild failed.

Example: previous [failed, hint, warm, cold], current [warm, hint, cold, warm] yields two improved, one regressed and one unchanged, out of four. Mark untested/new/missing rows separately rather than converting them to failed. Provisional retrieval statuses need later correctness validation just as in L59.

Part two: write the plan, 20 minutes. Name three feasible weekdays and times, thirty-minute budgets, queue location and a quarterly audit date. Choose an explicit intensification trigger such as an interview in fourteen days. A calendar entry is a learner action, not something this lesson has created for you. If your schedule cannot sustain three blocks, write the smaller plan you can test.

Part three: honest assessment, 15 minutes. Write five evidence-based sentences: retrievable families, unverified/weak families, timings on unseen work, narration under difficulty, and the failure most worth investigating next. Do not infer that finishing 65 sessions rules out a knowledge gap.

On finishing: celebrate the completed work, then choose whether continued algorithm practice serves your goals. Maintenance is an option with a cost and an intended benefit, not a compulsory rent or a guarantee that ninety minutes prevents decay.

Solo timed

The full classification sweep is 75 problems × 60 seconds = 75 minutes, not forty. If only forty minutes are available, use forty saved rows and label the result a partial audit; compare only the same rows under the same conditions, then finish later.

Log the previous and current statuses row by row. Flag two-level regressions for rechecking; they may reflect an overly generous old mark, a real loss, fatigue or a changed interpretation. Keep the observation without selecting a cause prematurely. Separate this quick classification from later full implementations.

Timing rubric — running today's session

Total: 15 + 75 + 10 + 20 + 15 = 135 minutes, excluding optional pre-reading and correctness validation. Split into sittings if needed and record conditions; do not shorten each row midway through a comparison. The original forty-minute sweep could not contain 75 one-minute rows.

Self-scoring — the exit assessment

Keep six 0–3 dimensions, maximum 18, as a personal baseline, not a hiring-readiness scale. Use recent comparable samples and note their count:

• Pattern retrieval: 3 = 20+ verified skeletons without prompts; 2 = 15–19; 1 = 10–14; 0 = under 10. Keep the attempted denominator.
• Classification speed: 3 = justified candidate within 90 seconds; 2 = over 90 seconds–under 3 minutes; 1 = 3–under 6; 0 = 6 or more/no justified candidate. Pattern naming without a valid contract is not success.
• Implementation speed: 3 = independently correct within 20 minutes; 2 = over 20–30; 1 = over 30–45; 0 = over 45/incomplete. Save tests and assistance.
• Hard decomposition: 3 = independently justified components on the sampled problems; 2 = after one hint; 1 = baseline but no composition; 0 = neither. A difficulty label does not make the sample comparable by itself.
• Communication: 3 = useful explanation through difficult decisions; 2 = some missing updates; 1 = explanation only after prompts; 0 = reasoning unavailable. Continuous talking is not required.
• Timed execution: 3 = no observed error increase on comparable samples; 2 = small increase; 1 = repeated increase; 0 = attempt could not be completed. This is descriptive, not a measurement of adrenaline.

14–18, 9–13 and below 9 can label high/mixed/low completion of this rubric. None establishes readiness for senior work, a typical graduate score or what is fixable in two weeks. Use the weakest evidenced dimension to choose a next experiment; preserve all six scores and the date.

The two-week pre-onsite block

This is a menu for a temporary block, not “roughly double” the weekly budget. Reserve time explicitly; omit or shorten items that do not fit, rather than promising complete repair.

• Days 14–12 — target and measure: inspect the actual role and interview format communicated by the employer, then filter the audit for relevant requirements and personal gaps. Do not treat unsourced company problem-frequency lists as measured distributions.
• Days 11–9 — repair: one targeted L60-style rebuild per day if feasible. Derive the mechanism, test it and schedule the delayed mixed check. Record whether this is a compressed or full session.
• Days 8–7 — relevant practice: two timed problems per day if the budget permits. Practise narration and extension questions according to the stated format, not stereotypes about Amazon or Microsoft.
• Day 6 — recorded mock: use L58's 45-minute protocol and budget playback separately. Pick one observable communication change.
• Day 5 — Hard practice: use L61's 45-minute attempt plus review; rehearse the minute-40 summary while still welcoming a full solve.
• Day 4 — second mock: test the selected change. If it did not occur, use a concrete cue and check it on the next attempt rather than assuming intention is enough.
• Day 3 — optional contest: L64 costs at least 140 minutes including setup and review; do not conceal this inside a thirty-minute slot. Substitute a shorter mock if more suitable.
• Day 2 — light review: due retrieval and familiar cues; avoid adding a large unfamiliar project if recovery time is limited.
• Day 1 — rest/light practice: stop early; an optional familiar Easy is enough if it helps. Protect ordinary rest without inventing a numerical sleep-versus-practice benefit.
• Morning of: optionally rehearse one familiar example and the actual delivery constraints, then stop.

Measurement at the start directs the available budget toward observed gaps. It does not establish the employer's question distribution or promise an outcome.

Common failure modes

No re-audit: keep at least a bounded comparable measurement rather than relying only on how the track felt.

An oversized plan: estimate actual weekly availability and use the fallback. Ninety minutes may be small for one person and infeasible for another.

No specific slots: choose days and a queue you will see, then observe whether the plan is followed. A vague plan is not guaranteed to collapse within a fortnight.

No periodic coverage check: sample beyond comfortable families. If quarterly checks are impractical, choose another cadence and record it.

Generous or harsh marking: use explicit evidence and uncertainty labels. Deliberately taking the worse score is not automatically more accurate than optimism.

Assuming track completion implies retention: reading an answer is different from producing and testing one. A gap after time away is a reason to measure, not proof that all prior learning vanished.

Practice testing and distributed practice have support in the cited review; it does not establish exponential decay for these templates, a universal advantage of this exact schedule, or a fixed rebuild cost. The mechanism proposed here is repeated unaided attempts, corrective feedback and later checks. The musician/scales analogy illustrates repetition, not a measured rate of forgetting.

Continuous small blocks offer frequent evidence and predictable time cost; bursts avoid ongoing work but leave less recent evidence and may be awkward on short notice. Choose according to your goals and observed retention. Maintaining interview algorithms is not mandatory for every employed engineer or everyone who might interview within a year.

Complexity

Today's full audit: 135 minutes before extra validation. Ordinary week: 3 × 30 = 90 minutes. Assuming 16 waking hours/day, that is 1.5/(7 × 16) ≈ 1.34% of waking time; the denominator is an assumption, not a universal schedule.

Annual base: 52 × 1.5 = 78 hours. Four 75-minute sweeps add 5 hours; four 10-minute comparisons add 40 minutes. Total planned base is 83 hours 40 minutes, excluding validation, repairs, optional materials and interview intensification. This is not an evidence-based estimate of rebuilding cost or the duration of the whole track. Avoid double counting a quarterly block if it replaces rather than supplements a weekly session.

Self-check (answer follows each question).

Q: What summaries does the re-audit comparison produce?

A: Counts of improved and regressed rows (plus unchanged/missing denominators), and overlap of weak families. These are observations; improvement does not prove a unique cause, and unchanged weak-list rank can coexist with improvement.

Q: Why plan around a difficult week rather than an ideal one?

A: To test whether the plan is feasible when availability is limited. Use a small explicit fallback and resume; no fixed ninety-minute dose is guaranteed sustainable for everyone.

Q: How do recognition and unaided retrieval differ, and why does that matter?

A: Reading supplies cues that writing from a blank file does not. Understanding a displayed solution is useful but does not by itself demonstrate independent construction. This distinction does not establish a universal relative decay rate.

Q: What observation can warn that retention needs checking?

A: A previously verified template failing an unaided attempt. Recheck conditions and correctness; one failure could also reflect fatigue, an earlier marking error or a changed contract.

Q: The same three families remain weak after a rebuild. What should you do?

A: Inspect absolute status and concrete errors, not rank alone. Explain the invariant without code, trace a novel example, then implement it: failure at explanation suggests concept repair, failure only at recall suggests retrieval work, and a correct plan with wrong indices suggests implementation tests. These diagnoses can overlap.

Q: Six months of audits show neither regression nor improvement. Is the loop working?

A: Stable verified performance on comparable and some unseen tasks is consistent with the maintenance goal. It does not prove the loop caused preservation without a counterfactual, and familiar tests can mask gaps. For growth, add an appropriate new difficulty or family deliberately; do not confuse a preservation goal with a growth goal.

Recovery scripts — for the plan, not the design review

Missed a week: resume with one bounded A session. Prioritize the queue and log deferrals rather than accumulating a punitive catch-up debt.

Missed a month: use a fifteen-minute template inventory plus five minutes to mark likely gaps, then validate those gaps in later blocks. This is a compressed check, not the full 75-row quarterly sweep.

Loop feels comfortable: first check whether delayed and unseen work remains correct. Comfort can be successful maintenance; increase difficulty only when you want growth or find untested gaps.

Interview in four days: choose one measured priority: day 4 a filtered sweep/rebuild, day 3 relevant timed work, day 2 a recorded mock, day 1 light review/rest. Delivery can be practised, not guaranteed fully recovered in four days.

An interview goes badly: if continued practice fits your goals, record classification, template, implementation, time and composure observations while fresh. Incomplete feedback is useful but not necessarily the highest-quality diagnosis.

You get the job: reassess whether to keep A only, all three sessions, or pause. The decision depends on current goals and workload; employment does not create an obligation to keep interview practice forever.

Checkpoint

Finish with these checkable artifacts, not a claim that every reader now has them:

• A fifteen-minute retrieval inventory with correctness checks or explicit pending flags; 15+ skeletons is an optional target.
• A paired L59 table with improved/regressed/unchanged counts and consistent row conditions.
• A diagnosis separating concept, retrieval and implementation gaps where evidence allows it.
• Named days/times, queue location and an actual chosen audit date.
• Six exit dimensions with sample evidence and a selected repair priority.
• A feasible two-week plan that measures before selecting work.
• A missed-week/month restart policy without an unbounded backlog.
• The weekly and annual time cost, plus the limits of any retention prediction.

Spaced queue

Refresh statuses from this audit while preserving previous dates, attempts, hints and verification evidence. Do not erase history when rebuilding the current view.

Proposed intervals: cold 60d, warm 21d, hint 7d, failed 2d then 7d. A weekly session A cannot guarantee exact two-day or seven-day follow-ups; schedule short extra attempts when needed or record the actual later date. Extra attempts consume extra budget.

Three operational rules:

1. Review the queue in A, prioritize within thirty minutes and log unfinished items.
2. On a reproduced retention failure, shorten that item's interval; 60 to 30 days is one possible adjustment, not a universal halving law. Keep concept/implementation errors distinct from recall misses.
3. Use a periodic sweep to refresh the view and compare with history. Validate uncertainty separately rather than treating classification as correctness.

Keep near-term repair attempts distinct from delayed independent tests. The goal is a usable record, not perfect adherence to invented intervals.

The one-page carry-forward

Weekly · proposed 90 minutes

• A: thirty minutes of due retrieval and checks, with recorded deferrals.
• B: twenty-minute unseen attempt plus ten-minute review; log approach, correctness and assistance.
• C: thirty-minute weak-family derivation/application/cue-card block; schedule a delayed check.
• Difficult-week fallback: a bounded A session; resize if this repeatedly fails.

Quarterly · 85 minutes plus validation — 75-row/75-minute sweep and ten-minute comparison. Preserve history, compare the same IDs and add separate unseen checks.

Intervals — cold 60d, warm 21d, hint 7d, failed 2d then 7d as starting suggestions. Record real due/attempt dates; a weekly slot alone cannot satisfy every interval.

Delivery — explain the contract, baseline when useful, invariant, data-structure choice and edge tests; at minute 40 of a 45-minute mock, state what is verified and what remains conjectural.

When stuck — repeated work? effect of sorting? future-relevant state? composable mechanisms? what bounds permit? Name one question and test it on a small input.

Two weeks out — measure requirements and gaps, select repair work, budget two mocks and optional contest honestly, then allow light review/rest.

Time cost — 78 weekly hours + 5 sweep hours + 40 comparison minutes = 83 hours 40 minutes/year under the stated additive schedule, excluding extra work.

This page is the reusable artifact: a proposed plan with observable outputs. The track's completion, the table's trend and your own goals all inform whether to continue it; none alone guarantees retention or professional readiness.

Corrective source notes

• Dunlosky and colleagues: Improving Students’ Learning With Effective Learning Techniques — publisher-hosted 2013 review summary, saved 2026-10-07 and re-read 2026-10-09. Supports the limited rationale for practice testing and distributed practice; not exact intervals, decay rates, coding-specific causal effects or hiring scores.

Algorithmic arguments and arithmetic above are derived for the stated contracts. Finite executable checks, saved source passages and their limits are recorded in the review artifacts; they do not certify unexecuted service behavior or interview outcomes.