How to Practice — Spaced Repetition for Algorithms

Most engineers prepare for technical interviews by grinding LeetCode: working through problems linearly, marking them solved, and moving on. This approach is suboptimal — most of what’s “learned” decays within days because nothing forces re-encounter at spaced intervals. The high-leverage alternative is to apply Sebastian Leitner’s spaced-repetition system (1972) — the box-based ancestor of the algorithms behind Anki, SuperMemo, and Duolingo’s review schedules — to algorithmic practice. Combine it with pattern-based grouping (recognize the pattern, not the problem) and a focused curated list (Blind 75, NeetCode 150), and a 4–8 week ramp-up produces durable interview readiness rather than fragile, problem-specific memory. This note is the practice protocol: the science, the system, the lists, and the 4–8 week schedule template.

1. Why This Matters — The Forgetting Curve and Interview Prep

Hermann Ebbinghaus’s 1885 Über das Gedächtnis established the forgetting curve: without re-encountering material, memory of it decays steeply at first and then levels off. A crucial detail usually mangled in popular retellings is what Ebbinghaus actually measured. He did not measure direct recall (“what fraction can you reproduce?”). He measured savings — the proportion of relearning time saved on a second study trial relative to learning the list fresh. A savings score of 58% means relearning the list took 58% less effort than the first time, implying roughly that fraction of the memory trace was still accessible (Murre & Dros 2015; SuperMemo, History of spaced repetition). Ebbinghaus relearned eight 13-syllable series after intervals of 20 minutes, 1 hour, 9 hours, and 1, 2, 6, and 31 days. His reported savings were about 58% at 20 minutes, 34% at 1 day, and 21% at 31 days — the well-known interior figures (a value near 44% at one hour, ~33% at one day) are widely repeated but the precise per-interval numbers vary across retellings and are not all attributable to Ebbinghaus’s own tables; treat the three endpoint figures as the firm ones. The 2015 PLOS ONE replication by Murre and Dros reproduced the curve closely, with the one wrinkle that it is “not completely smooth” but shows a small upward jump starting around the 24-hour mark — plausibly the consolidating effect of a night’s sleep (Murre & Dros 2015). The shape is the durable takeaway: fast initial decay, then a flattening tail, with each spaced re-study pushing the half-life out further.

The implication for interview prep: a candidate who solves LeetCode #200 (Number of Islands) on day 1 and never sees it again by day 30 of practice has effectively forgotten it. They won’t remember the BFS/DFS scaffolding, the visited-set pattern, or the boundary conditions — unless the problem is re-encountered at the right interval. Linear “I’ve solved 300 problems” practice is a memorization treadmill where late additions push earlier ones out of reach.

The high-quality response: structured spaced repetition. The science is well-established. The Cepeda et al. (2006) meta-analysis synthesized 839 assessments across 317 experiments in 184 articles and found that spaced practice beat massed practice in 259 of 271 cases — an overwhelmingly robust effect (Cepeda et al. 2006; Wikipedia, Spacing effect). Its central, more subtle finding is that there is no single “best” gap: the inter-study interval that maximizes retention grows with the retention interval you are aiming for — the longer you need to remember something, the wider the optimal spacing.

Uncertain

Verify: the often-quoted figure that distributed practice yields “200%+ better long-term retention” than massed practice. Reason: this specific multiplier does not appear in the Cepeda et al. (2006) abstract or in the summaries consulted, and it conflates “absolute recall doubled” with the meta-analysis’s actual result (an effect favoring spacing in ~96% of comparisons, with magnitude depending heavily on the ISI/retention-interval ratio). It reads as folk wisdom. To resolve: read the full Cepeda 2006 PDF results tables for the mean effect size, or cite a specific experiment that reports a 2× recall difference. uncertain

The mechanism, regardless of exact magnitude, is simple: re-encounter material at expanding intervals — 1 day, 3 days, 1 week, 2 weeks, 1 month — and only mark something “learned” once it survives a long-interval review.

For interview prep, this means maintaining a queue of problems by mastery level, not by completion date. The cost is bookkeeping (a spreadsheet or Anki); the benefit is durable knowledge that survives a 6-week interview prep window.

2. The Leitner System — The Foundation

Sebastian Leitner, a German science journalist, published the Leitner system in 1972 (So lernt man lernen — “How to Learn to Learn”). Originally designed for physical flashcards, it is the simplest, most-cited spaced-repetition system. The protocol:

2.1 The Original Boxes

A small set of physical boxes (or, in Leitner’s own description, partitioned compartments within a single learning box), with each card living in exactly one compartment. The core movement rule is the part that is genuinely Leitner’s and is universal across all retellings: a card answered correctly advances to the next box; a card answered incorrectly is sent all the way back to Box 1 (Leitner system, Wikipedia). Cards that survive the final box are “learned” and retired (or moved to a long-term archive box reviewed rarely).

Uncertain

Verify: the specific schedule “Box 1 daily, Box 2 every 2 days, Box 3 every 4, Box 4 every 8, Box 5 every 16 days.” Reason: Leitner’s So lernt man lernen (1972) did not prescribe fixed calendar intervals at all. Per Wikipedia’s account of the original method, “the schedule of repetition was governed by the size of the partitions in the learning box… Only when a partition became full was the learner to review some of the cards it contained” — i.e., review was triggered by how many cards had accumulated, not by a fixed day count. The geometric “1/2/4/8/16-day” schedule is a later popularization of Leitner’s idea, not the original. Different sources give different intervals (one common variant is 1/2/4/7/14 days; another 1/3/5 days for a three-box setup), confirming there is no single canonical day schedule. To resolve: consult Leitner’s 1972 text directly. The five-box, doubling-day schedule shown here is a reasonable modern reconstruction, presented as such. uncertain

For a usable modern reconstruction, treat it as five boxes with review intervals that roughly double — day 1, day 2, day 4, day 8, day 16. The reason to prefer multiplicative growth (each level ~2× the previous) over additive growth is that it matches the spacing literature’s repeated finding that the optimal gap widens with proficiency — formalized in the SuperMemo SM-2 algorithm, whose interval rule is literally $I(n)=I(n-1)\times \text{EF}$ for an easiness factor EF (see §2.4) (SM-2 description). Leitner reached the same qualitative shape — expanding intervals — without the arithmetic, two decades before SuperMemo.

2.2 The Adapted-for-LeetCode Version

The original Leitner schedule is too aggressive for LeetCode-scale problems (which take 30–60 minutes each, not the 20 seconds a flashcard does). The adapted intervals:

• Level 1 — Failed: re-attempt the next day.
• Level 2 — Struggled but solved: re-attempt in 3 days.
• Level 3 — Solved with hesitation: re-attempt in 1 week.
• Level 4 — Solved fluently: re-attempt in 2 weeks.
• Level 5 — Solved fluently twice in a row: re-attempt in 1 month, then archive.

A practical schema: a spreadsheet with columns Problem, Pattern, Last Attempt, Result, Level, Next Review Date. Each day, you sort by Next Review Date and work through what’s due. New problems start at Level 1 by default.

The result: each problem you’ve struggled with comes back to bite you tomorrow; each problem you’ve crushed gets a longer break. Over 4–8 weeks, the queue stabilizes around 5–15 problems per day, with most of your time on freshly-failed problems and Level-2 reviews.

2.3 Why This Beats Linear Grinding

A candidate doing 200 problems linearly forgets much of them within a couple of weeks; a candidate doing fewer problems with Leitner-spaced review retains substantially more at the 6-week mark, for the same total study time.

Uncertain

Verify: the precise figures “forgets 50% in 2 weeks” vs “remembers 90%+ at 6 weeks.” Reason: these are plausible illustrative numbers but I found no controlled study of LeetCode-style algorithm practice that measured them; they are an extrapolation from the verbal-recall literature to code, which is studied far less. To resolve: cite a study of programming/skill retention under spaced vs massed schedules, or relabel as a qualitative illustration. uncertain

The directional claim, however, rests on solid ground. The Karpicke & Roediger (2008, Science) study established that retrieval practice — the Leitner-style “can I produce it from memory?” test — is more effective than re-reading or re-studying. In their experiment, students who, after first learning foreign-language vocabulary, were repeatedly tested recalled about 80% of the items on a one-week delayed test, versus about 36% for students who instead repeatedly studied the already-learned items and dropped them from testing (Karpicke & Roediger 2008). Strikingly, repeated studying of an item already learned once produced essentially no improvement in delayed recall — only repeated retrieval did. The earlier Roediger & Karpicke (2006, Psychological Science) “test-enhanced learning” study found the same pattern: testing beats restudying specifically on delayed tests, even though restudying can look better on an immediate test. The lesson for problem practice is direct: the act of trying to recall the solution strengthens the memory far more than seeing it again, which is exactly why the daily loop below forces a from-scratch re-implementation rather than a re-read.

2.4 SM-2 — How the Software Descendants Schedule Reviews

The Leitner box is the analog ancestor; its software descendant is the SuperMemo SM-2 algorithm, which is worth understanding because it explains why the “intervals roughly double” intuition is sound and where it breaks down. Piotr Wozniak first implemented SuperMemo in December 1987 (the SM-2 variant was in use from late 1987 through early 1989), and later published the underlying optimization work in Acta Neurobiologiae Experimentalis (Wozniak 1994) (SM-2 description, SuperMemo). SM-2 keeps, per card, an easiness factor (EF) initialized at 2.5 and floored at 1.3. After each review the learner rates recall quality $q$ on a 0–5 scale, and EF is nudged by ${\text{EF}}^{\prime }=\text{EF}+(0.1-(5-q)\times (0.08+(5-q)\times 0.02))$ — a formula that raises EF for easy recalls and lowers it for hard ones. The interval schedule is: first repetition after 1 day, second after 6 days, and thereafter $I(n)=I(n-1)\times \text{EF}$. Symbol by symbol: $I(n)$ is the gap (in days) before the $n$-th review, $I(n-1)$ the previous gap, and EF the current per-card multiplier — so an “easy” card (EF near 2.5) stretches out fast while a “hard” card (EF near 1.3) grows slowly. Any failed recall resets the card to the start of the schedule, exactly mirroring Leitner’s “back to Box 1.”

Two practical notes for an interview-prep audience. First, this is the idea behind the modern Leitner-for-LeetCode levels — adaptive, multiplicative spacing — but you do not need the arithmetic; a five-level spreadsheet captures 90% of the benefit. Second, a point-in-time accuracy correction worth knowing: SM-2 was the long-time default scheduler in Anki, but as of Anki 23.10 (October 2023) Anki ships the newer FSRS (Free Spaced Repetition Scheduler), a machine-learned model that can schedule roughly 20–30% fewer reviews for the same target retention; FSRS became the default in subsequent releases (Anki FAQ, What spaced repetition algorithm does Anki use?). So the common shorthand “Anki uses SM-2” is now dated — Anki offers SM-2 but defaults to FSRS.

3. Patterns Over Problems — The Conceptual Shift

The single highest-leverage realization in interview prep: interview problems are instances of patterns, and the patterns repeat. A widely-repeated heuristic holds that roughly 15–20 common patterns cover the large majority of LeetCode-style problems; recognize the pattern, and a single problem teaches the whole class.

Uncertain

Verify: the specific figure “15–20 patterns cover 90%+ of LeetCode-style problems.” Reason: this is community folk wisdom (popularized by pattern-list sites and Grokking-the-Coding-Interview-style courses), not a measured statistic over the LeetCode corpus. The qualitative claim — that a modest set of recurring patterns dominates interview problems — is sound and is exactly why curated pattern lists work; the precise “90%” is unsubstantiated. To resolve: tag a representative random sample of LeetCode problems by pattern and measure coverage, or treat 90% as illustrative. uncertain

3.1 The Common Patterns

Pattern	Representative problem	What it tests
Two Pointers	Two Sum II, Container With Most Water	Linear scan with two indices, often on sorted arrays
Sliding Window	Longest Substring Without Repeating Characters, Minimum Window Substring	Maintain a moving window of valid elements
Hash Table usage	Two Sum, Group Anagrams	O(1) lookups for matching, frequency counting
Binary Search	Search in Rotated Sorted Array, Find Peak Element	Logarithmic narrowing on sorted-or-monotonic data
Binary Search on Answer	Capacity to Ship Packages, Split Array Largest Sum	Binary search the answer space, not the input
Tree Traversals (DFS)	Binary Tree Maximum Path Sum, Diameter of Binary Tree	Recursive accumulation through tree
Tree Traversals (BFS)	Binary Tree Level Order Traversal, Word Ladder	Breadth-first level-by-level processing
Breadth-First Search (graph)	Number of Islands (variant), Rotten Oranges	Shortest unweighted path / connectivity
Depth-First Search (graph)	Number of Islands, Course Schedule	Connectivity, cycle detection
Topological Sort	Course Schedule II, Alien Dictionary	DAG ordering by dependency
Backtracking Framework	Permutations, Subsets, N-Queens	Generate-and-prune search
Memoization vs Tabulation (DP)	Climbing Stairs, House Robber, Coin Change	Optimal substructure with overlapping subproblems
DP State Identification	Longest Increasing Subsequence, Edit Distance	Designing the state space
Monotonic Stack	Next Greater Element, Daily Temperatures	Maintain stack of decreasing/increasing elements
Top K Elements	K Closest Points, Top K Frequent	Heap-based selection
Two Heaps Pattern	Find Median from Data Stream	Maintain min-heap + max-heap
Union-Find	Number of Connected Components, Redundant Connection	Disjoint set operations for connectivity
Trie	Implement Trie, Word Search II	Prefix tree for string keys
Prefix Sums	Range Sum Query, Subarray Sum Equals K	O(1) range sums after O(n) preprocessing
Bit Manipulation Tricks	Single Number, Number of 1 Bits	Bit-level optimization

The Sean Prashad LeetCode Patterns repository (https://github.com/SeanPrashad/leetcode-patterns) is the canonical free reference for this categorization.

3.2 The Practice Implication

When you solve a problem, explicitly tag it with its pattern. When you fail a problem, ask: “Did I fail because I didn’t recognize the pattern, or because I recognized it but couldn’t execute?” The two failure modes have different remedies:

• Pattern-recognition failure: study the pattern systematically. Solve 5 more problems with the same pattern, focusing on what cues point to it.
• Execution failure: practice the implementation specifics. What part of the standard scaffolding tripped you up? Drill that.

Tagging by pattern also informs Leitner-style reviews: when a Level-1 problem comes back, you’re not just re-solving the problem; you’re re-encountering the pattern. Multiple problems sharing a pattern reinforce each other.

4. The Curated Lists — Where to Start

Don’t grind LeetCode in numerical order. Use a curated list optimized for pattern coverage with minimal redundancy.

4.1 Blind 75

75 problems selected to cover all major patterns with the smallest problem set possible. The list was compiled by Yangshun Tay, a Meta (then Facebook) engineer who also authors the Tech Interview Handbook; he posted it to the Blind anonymous-professional forum, which is where the “Blind 75” name comes from (it is the platform’s name, not an anonymous author’s handle — a common misattribution) (Educative, Where did Blind 75 come from?). It quickly became the canonical “minimum viable interview prep” list.

The same author later built Grind 75 (https://www.techinterviewhandbook.org/grind75), a modernized, configurable version: you set your available hours and target difficulty and it generates an ordered list (commonly 75 up to ~169 problems), which makes it the more practical modern default.

Uncertain

Verify: “~150 hours of work for an unfamiliar candidate.” Reason: total-time estimates for a problem set are highly individual and I found no authoritative figure for Blind 75 specifically; Grind 75’s own tool is built around the premise that completion time is user-dependent (you input your hours). To resolve: treat the hours as a rough planning heuristic, not a measured constant. uncertain

Pros: minimal, well-curated, every problem teaches a distinct pattern. Cons: thin on advanced DP and some graph patterns; not enough to fully prep a senior candidate.

Best for: candidates with limited time (2–4 weeks), or candidates already comfortable with the basics who want a refresher.

4.2 NeetCode 150 (and NeetCode 250)

NeetCode (founded by Navdeep Singh, also known as “Navi Singh”, a former Google/Amazon engineer; https://neetcode.io/practice) extended Blind 75 to 150 problems with cleaner pattern coverage. NeetCode also publishes excellent video walkthroughs (free on YouTube) for every problem in the list, which makes it the best self-study resource if you’re learning patterns from scratch.

Pros: deeper pattern coverage; video walkthroughs are the best free SWE-prep content available. Cons: 150 problems is a 4-6 week commitment.

Best for: candidates with 4–8 weeks; new-grad to mid-level prep; anyone who learns better from video.

4.3 LeetCode Top 100 / Top Interview Questions

LeetCode’s own curated list (https://leetcode.com/problem-list/top-interview-questions/) — historically the first such list. Still good but less pattern-coherent than NeetCode 150.

4.4 Cracking the Coding Interview

McDowell’s Cracking the Coding Interview (6th ed., 2015) contains ~200 problems organized by topic (chapters: Arrays/Strings, Linked Lists, Stacks/Queues, Trees/Graphs, Bit Manipulation, Recursion/DP, etc.). Not LeetCode-listed, but the problems are similar quality. Best for candidates who learn from a textbook structure with explanations interleaved with problems.

4.5 Choose ONE List, Don’t Mix

A common mistake: starting Blind 75, switching to NeetCode 150, switching to a YouTuber’s curated list, and ending with a fragmented half-finished mix. Pick one list and finish it. The Leitner-style review schedule depends on the list staying stable so reviews land on the right problems.

Uncertain

Verify: the exact composition and naming of the curated lists. Reason: these lists are volatile — Blind 75 has been remixed and rehosted; NeetCode extended its set to NeetCode 250; Grind 75 is itself an evolving, configurable list. Any specific problem count or membership claim here is point-in-time (as of mid-2026) and will drift. To resolve: check the current canonical version on each source’s own website (neetcode.io, techinterviewhandbook.org) at prep time rather than trusting a frozen list. uncertain

5. The 4-to-8 Week Schedule Template

A concrete template for a candidate ramping up over 6 weeks for a senior FAANG-tier role. Adjust by tightening (4 weeks if you’re already strong) or extending (8 weeks if learning from scratch).

5.1 Week 0 (Pre-Ramp) — Calibration and Setup

• Pick the curated list (Blind 75 / NeetCode 150 / Cracking the Coding Interview).
• Set up the Leitner spreadsheet (or Anki, or NeetCode’s built-in spaced-repetition feature if it exists).
• Take 2–3 sample LeetCode-Medium problems untimed and reflect: what did I solve fluently? What was hard? This gives you a baseline.
• Read Big-O Notation and Memoization vs Tabulation cold — make sure these foundations are in place before practicing problems.

5.2 Weeks 1–2 — Fundamentals and Pattern Recognition

• Daily target: 3 new problems + Leitner reviews. ~2–3 hours/day.
• Focus areas: arrays, strings, hash tables, two pointers, sliding window, Binary Search, Tree Traversals, Breadth-First Search / Depth-First Search basics. The “easy” patterns.
• Don’t skip Easy problems early; they reinforce the muscle memory.
• After each problem: write a 1-2 sentence note in the spreadsheet about what made this problem its pattern. The act of articulating the pattern strengthens the recognition.

5.3 Weeks 3–4 — Core Patterns

• Daily target: 3 new problems + Leitner reviews. ~3 hours/day.
• Focus areas: Backtracking Framework, DP foundations, Topological Sort, Monotonic Stack, Trie, Prefix Sums, Heap patterns.
• Start mock interviews — at least 1 per week. Use Pramp / interviewing.io / a peer. Mock interviews catch the communication gaps that solo solving doesn’t.

5.4 Weeks 5–6 — Advanced Patterns and Mock-Heavy

• Daily target: 2 new problems + heavy Leitner reviews + 2 mocks/week. ~3–4 hours/day.
• Focus areas: advanced DP (LIS, Edit Distance, partition DP), Union-Find, graph algorithms (Dijkstra’s Algorithm, Topological Sort applications), Sliding Window variants, Two Heaps Pattern, harder Backtracking Framework (N-Queens, Sudoku Solver).
• System design study (if interviewing for senior roles): see System Design Interview Framework.
• Behavioral story rehearsal: see Picking Stories — Coverage Matrix.

5.5 Week 7 (Optional Extension) — Polish and Edge Cases

• Daily target: light. 1 new problem + Leitner reviews + 3 mocks. ~2 hours/day.
• Focus on the patterns where Leitner has surfaced repeated failures.
• Re-read Off-By-One Errors — Survival Guide, Edge Cases Checklist, Time Management in Interviews.
• Sleep, exercise, and pacing become more important than additional problem-solving.

5.6 Week 8 / Pre-Interview — Lightning-Round Reviews

• Daily target: Leitner reviews only. ~1 hour/day.
• No new problems. The goal is to consolidate, not to expand.
• Re-do 5–10 problems untimed under interview conditions (talk through, write clean code, no hints) for psychological calibration.
• Light cardio, sleep, and avoid burnout.

6. The Daily Practice Loop

Within a single practice session, the structure that produces the best retention:

6.1 Step 1 — Leitner Review First (45–60 min)

Open the spreadsheet, sort by Next Review Date. Work through the due problems first. Why first?

• These are the highest-priority items (you’ve already invested in them; reviewing now saves the investment).
• Each successful review extends the next-review interval; you free up your queue.
• Failed reviews go back to Level 1 and need fresh mental energy, which you have at the start of a session.

6.2 Step 2 — One New Problem (45–60 min)

Pick the next problem from the curated list. Constraints:

• Time-box at 25 minutes for the first attempt without hints. If you don’t have a viable approach in 25 min, move to step 3 (review the solution).
• Talk out loud, even alone — practices the Talking Through Code interview habit.
• Trace edge cases (Edge Cases Checklist) before claiming correctness.

6.3 Step 3 — Solution Study (15–25 min, if needed)

If you didn’t solve fluently in 25 min: read the editorial / NeetCode video / a clear LeetCode discussion solution. Don’t copy-paste the solution. Instead:

• Understand it line by line.
• Close the editorial.
• Re-implement from scratch.
• Tag the problem in your spreadsheet at Level 1 (definitely needs re-attempt tomorrow).

6.4 Step 4 — Pattern Reflection (5 min)

Write in the spreadsheet:

• What pattern was this?
• What cue from the problem statement should have signaled the pattern?
• What part of the implementation was non-obvious?

This is the pattern-extraction step that makes solving 100 problems teach you the underlying 20 patterns rather than 100 unrelated facts.

7. Mock Interviews — Why They’re Non-Negotiable

Solo problem-solving is necessary but insufficient. The behaviors that distinguish a strong from weak interview performance — clear communication, calibrated handling of feedback, recovery from mistakes — only develop under realistic mock conditions. McDowell (Cracking the Coding Interview, Ch. 4) and Aline Lerner (interviewing.io’s hiring data) both report that mock interviews are the single highest-leverage intervention for under-performing candidates.

7.1 Where to Get Mocks

• interviewing.io (paid; free for students): you get a senior engineer interviewer; anonymous; recorded. Highest signal-to-noise.
• Pramp (free): peer-to-peer; you take turns interviewer and candidate. Lower signal but free.
• Hello Interview (paid): system-design specialist mocks.
• Peers / friends / colleagues: free; lower production value but real.
• CoderPad with a recruiter (some recruiters offer practice screens): rare but valuable.

7.2 Minimum Cadence

For a 6-week prep:

• Week 3: 1 mock.
• Week 4: 2 mocks.
• Week 5: 2 mocks.
• Week 6: 2–3 mocks.

For a 2-week sprint: 1 mock every 2–3 days.

7.3 What to Practice in Mocks

Mocks should target the gaps that solo practice doesn’t fill:

• Talking under pressure: see Talking Through Code.
• Handling hints: how do you absorb feedback without losing the thread?
• Recovering from a stuck state: see Debugging Under Pressure.
• Clarifying questions: see Problem Decomposition in Interviews.
• Behavioral storytelling: at least 1 of every 4 mocks should be entirely behavioral. See STAR Framework / CAR Framework.

8. Tools and Templates

8.1 The Leitner Spreadsheet

Minimal columns for a useful Leitner-style tracker:

Problem	Source / #	Pattern	Difficulty	Last Attempt	Result	Level	Next Review	Notes
Two Sum	LC 1	Hash Table	Easy	2026-05-01	Solved fluently	4	2026-05-15	Pattern: complement lookup
Trapping Rain Water	LC 42	Two Pointers	Hard	2026-05-04	Failed	1	2026-05-05	Re-derive the two-pointer move logic
Number of Islands	LC 200	DFS	Medium	2026-05-02	Solved	3	2026-05-09	Pattern: connected components on grid

Decision rule for Level:

• Failed (couldn’t solve in 25 min, needed editorial): Level 1.
• Solved with significant struggle (multiple bugs, hint required): Level 2.
• Solved with hesitation but no help: Level 3.
• Solved fluently in <25 min: Level 4.
• Solved fluently twice in a row at Level 4 review: Level 5 → archive.

The Next Review = Last Attempt + (1, 3, 7, 14, 30) days based on Level.

8.2 Anki for Pattern Cards

Some practitioners use Anki cards in addition to / instead of a problem spreadsheet:

• Front: a problem statement (or a pattern cue: “When you see ‘find a substring of length K satisfying property P,’ which pattern?”).
• Back: the algorithm template / pseudocode / key insight.

This works for the pattern recognition layer (the 15–20 templates) but is too coarse for the implementation layer. Best used as a complement to problem-level Leitner, not a replacement.

8.3 NeetCode Practice Tracker

NeetCode.io has its own progress-tracking and pseudo-spaced-repetition built in. It’s lighter-weight than a custom spreadsheet but works.

9. Worked Example — A 6-Week Schedule for a Mid-Level Engineer

Candidate background: 5 years at a tier-2 company; comfortable with arrays, strings, basic DFS/BFS; weak on DP, never used Union-Find, fuzzy on system design. Goal: senior offer at a FAANG-tier company.

Week 1:

• Days 1–7: 3 new problems/day from NeetCode 150 (arrays, strings, hash tables, two pointers, sliding window).
• 21 problems total, all at Levels 1–3 by end of week.
• Leitner reviews start kicking in by day 4.

Week 2:

• Days 8–14: 3 new problems/day (binary search, trees, BFS/DFS).
• ~21 new + ~10–15 reviews/day.
• Re-encounter weak Week 1 problems at Level 1; succeed on most this time.

Week 3:

• Days 15–21: 3 new + 1 mock interview at end of week.
• Topics: Backtracking, DP foundations, Topological Sort.
• Mock at end of week reveals communication gaps in DP problems — log this for focus.

Week 4:

• Days 22–28: 3 new + 2 mocks.
• Topics: harder DP (LIS, Edit Distance), Union-Find, graph algorithms.
• Begin system design study in parallel — 1 hour/day on system design + back-of-envelope.

Week 5:

• Days 29–35: 2 new + heavier reviews + 2 mocks (1 coding, 1 system design).
• Reviews are now mostly Level 3+ problems — high signal that retention is sticking.

Week 6:

• Days 36–42: light new problems (1/day) + heavy reviews + 3 mocks (mix of coding, system design, behavioral).
• Final review: read through all Level 4 problems quickly to refresh.

Total problem count by end of week 6: ~80 distinct NeetCode problems with strong retention; ~10 mocks; ~30 hours of system design prep; ~15 hours of behavioral story rehearsal.

Outcome: by week 6, the candidate has fluent recall of the 15–20 core patterns and can recognize them rapidly in unseen problems. This is the readiness state for a FAANG senior loop.

10. Common Failure Modes

10.1 Linear Grinding Without Reviews

Symptom: “I solved 300 problems but I still bombed an Easy in the interview.” Cause: No Leitner-style spaced reviews; problems decayed before the interview. Fix: switch to spaced-repetition tracker; cap new problems and force review time.

10.2 Pattern-Blind Solving

Symptom: candidate solves a problem but doesn’t recognize it as an instance of a pattern; encounters a sibling problem and fails. Cause: Solving without explicit pattern-tagging. Fix: After every problem, write down the pattern. Periodically review the pattern-frequency in the spreadsheet (which patterns have you seen many of, which only one or two?).

10.3 Mocking Too Late

Symptom: candidate’s first mock is the day before the interview; communication is rough; the candidate is rattled. Cause: solo practice felt productive; mocks felt scary and were postponed. Fix: mocks start at Week 3, not Week 5. Treat them as exposure therapy, not as final exams.

10.4 Skipping Easy Problems

Symptom: candidate jumps to Mediums and Hards immediately; solves them but with bugs. Cause: ego (“Easies are below me”). Fix: Easies build the muscle memory. Even senior candidates should warm up with Easies for the first week.

10.5 Over-Reliance on Editorial Solutions

Symptom: candidate reads the editorial after 5 minutes of struggle, thinks “ah of course,” moves on. Then can’t reproduce the solution from scratch. Cause: Reading is not the same as recall (Karpicke & Roediger 2008). Fix: After reading the editorial, close it and re-implement from scratch. Mark Level 1 in tracker. Re-attempt tomorrow.

10.6 Treating Problems as Memorizable

Symptom: “I memorized 300 LeetCode solutions; let me pattern-match the interview problem to one I’ve seen.” Cause: Cargo-culting Cracking the Coding Interview’s “you must solve everything.” Fix: The goal is pattern-recognition + fluent execution, not memorization. If you’ve successfully solved a problem 3 times at Level 5, you’ve internalized the pattern; you don’t need to “memorize” the specific solution.

10.7 Ignoring System Design and Behavioral

Symptom: senior candidate aces coding rounds but fails system design or behavioral. Cause: All time on LeetCode; ignored the other interview dimensions. Fix: Time-budget system design (1 hr/day starting week 3) and behavioral (1 hr/day starting week 4). See System Design Interview Framework and STAR Framework.

10.8 Burnout

Symptom: candidate is on hour 6/day at week 4; problem-solving rate plummets; sleep degrades. Cause: Cargo-culting “grind for 8 hours/day.” Fix: 3–4 hours/day is the sustainable peak for most candidates. More than that, returns plummet. Take rest days. Sleep 8 hours.

11. Sample Phrases for Practice Reflection

These go in the “Notes” column of the Leitner spreadsheet:

• Pattern recognition: “Cue: ‘find a contiguous subarray with property P’ → Sliding Window.”
• Pitfall recall: “Mistake: forgot to mark visited before recursive call → infinite recursion. Always mark on entry.”
• Implementation gotcha: “Standard binary search: lo + (hi - lo) // 2 to avoid integer overflow.”
• Pattern variation: “This is the ‘two heaps’ median problem; remember to balance heap sizes after every insert.”
• Why I failed: “Couldn’t articulate the recurrence. Need more practice with DP State Identification.”

12. Diagram — The Leitner Loop

flowchart TD
    A[Pick problem from list] --> B[Attempt 25 min]
    B --> C{Solved?}
    C -- yes, fluent --> D[Level 4: review in 14 days]
    C -- yes, with struggle --> E[Level 2-3: review in 3-7 days]
    C -- no --> F[Read editorial]
    F --> G[Re-implement from scratch]
    G --> H[Level 1: review tomorrow]
    D --> I{Level 4 review:<br/>still fluent?}
    I -- yes --> J[Level 5: review in 30 days]
    I -- no --> H
    J --> K{Level 5 review:<br/>still fluent?}
    K -- yes --> L[Archive: learned]
    K -- no --> H
    H --> A
    E --> A

What this diagram shows. A problem moves through Levels 1–5 based on review outcomes. A successful review moves the problem up a level (and out longer); a failed review drops it to Level 1 and back into the active queue. The archive is reached only after two successful Level 5 reviews — i.e., the problem has survived progressively longer intervals (1 day → 3 → 7 → 14 → 30 days) without being missed. The crucial structural point: the queue stabilizes as problems graduate to higher levels, freeing daily capacity for new problems. A linear grinder’s “queue” is just an ever-growing pile of forgotten problems; the Leitner queue self-prunes as material is mastered.

13. Variants — Different Practice Goals

Goal	List	Schedule	Mock cadence
New grad, 4-week sprint	Blind 75	4 problems/day, no system design	1 mock/week starting week 2
Mid-level, 6-week prep	NeetCode 150	3/day; +1 hr/day system design from week 3	2 mocks/week from week 3
Senior, 6-8 week prep	NeetCode 150 + Hard practice	2/day; 2 hr/day system design + behavioral	3 mocks/week from week 3
Staff+, 8 week prep	Full DP/graph deep dive + 3-4 system design problems/day + behavioral coverage matrix	Lighter on coding; heavier on design + leadership	4 mocks/week, including senior-leadership rounds
Re-prep after a failed loop	Whatever the gap was	Targeted at the gap (e.g., system design only); 4-6 weeks	5+ mocks specific to the gap

14. Pitfalls Recap

Pitfall	Fix
No spaced reviews	Leitner spreadsheet; review before new problems
Pattern-blind solving	Tag every problem with its pattern
Mocks postponed	Start at week 3; cadence increases through prep
Editorial-then-mark-solved	Close editorial; re-implement; mark Level 1
Skip Easies	Easies build muscle memory; do them early
Ignore system design / behavioral	Time-budget both starting week 3-4
8 hrs/day grinding	3-4 hrs/day max; rest days; sleep
Solving by memorization	Recognize patterns; the goal is generalization
Mixing curated lists	Pick one and finish
Never reflecting on failures	Notes column: “what cue did I miss?”

15. Open Questions

• How does AI-assisted practice (e.g., asking Claude or ChatGPT to drill you on a pattern) compare to traditional LeetCode practice? Anecdotally, AI-driven Socratic practice (where the AI asks probing questions) is high-quality, but AI-generated problems may not match the distribution of real interview problems. Verify with current benchmark data.
• Are there individual differences in optimal Leitner intervals? Wozniak’s SuperMemo SM-2 algorithm uses per-card difficulty estimates; whether engineering-problem retention follows the same shape as factual-recall (which the algorithm was designed for) is unclear. Empirically, the 1/3/7/14/30 intervals work well enough for most candidates.
• How effective is “active” recall vs “passive” review for code patterns? Karpicke & Roediger 2008 strongly support active recall for verbal material. Whether code-implementation recall has the same property is plausible but understudied.

16. See Also

• FAANG Interview Loops — what you’re practicing for
• Levels and Calibration — the level you’re targeting determines practice intensity
• Negotiating Offers — what comes after the loop
• Resume for SWE Roles — getting into the loop in the first place
• STAR Framework — for behavioral story rehearsal
• CAR Framework — alternative behavioral structure
• Picking Stories — Coverage Matrix — preparing the inventory
• Problem Decomposition in Interviews
• Talking Through Code
• Time Management in Interviews
• System Design Interview Framework
• Back-of-Envelope Estimation
• Scaling Patterns
• Edge Cases Checklist
• Debugging Under Pressure
• Off-By-One Errors — Survival Guide
• Big-O Notation — foundation
• Memoization vs Tabulation — DP foundation
• DP State Identification — DP pattern
• Two Pointers — pattern
• Sliding Window — pattern
• Binary Search — pattern
• Backtracking Framework — pattern
• Topological Sort — pattern
• Monotonic Stack — pattern
• Trie — pattern
• Union-Find — pattern
• SWE Interview Preparation MOC