Study plan and flashcards

Two things: a schedule that fits around a full-time job, and a set of retrieval drills. The drills matter more than the schedule — fluency comes from recall, not from reading, and the specific failure mode you are trying to fix (fundamentals eroded by AI-assisted coding) is a retrieval failure, not a knowledge failure. You have not forgotten what a heap is; you have lost the ability to produce one without help.

That distinction drives the whole design below: every session ends with something written from a blank file.

Table of contents

• 1. The principle: retrieval over review
• 2. Pick a track
• 3. The 8-week plan
• 4. The maintenance loop
• 5. Spaced repetition schedule
• 6. Self-assessment tracker
• 7. Flashcards
• 8. Blank-file drills
• 9. Using the Anki deck

1. The principle: retrieval over review

Four findings from the learning-science literature that actually change how you should spend an hour:

The practical rule: 10-minute rule. Stuck for 10 minutes with no new idea? Look at the reference, then close it and rewrite from scratch immediately. Do not read the solution and move on — that produces recognition, not recall, and recognition is worthless in an interview.

2. Pick a track

Everything below assumes the Standard track and 7 hours a week: five weekday sessions of ~45 minutes plus one longer weekend session of ~2.5 hours. Adjust proportionally.

3. The 8-week plan

graph LR
    W1["Week 1<br/>Complexity and<br/>the two runtimes"] --> W2["Week 2<br/>Arrays, hashing,<br/>two pointers, windows"]
    W2 --> W3["Week 3<br/>Stacks and heaps"]
    W3 --> W4["Week 4<br/>Trees and tries"]
    W4 --> W5["Week 5<br/>Graphs"]
    W5 --> W6["Week 6<br/>Dynamic programming"]
    W6 --> W7["Week 7<br/>Language depth<br/>and design"]
    W7 --> W8["Week 8<br/>Integration<br/>and mocks"]

Each week: a rebuild focus (write it from a blank file), a read focus (the chapter that explains it), and a drill focus (problems). The weekend session is a timed mock.

Week 1 — Complexity and the two runtimes

Milestone: you can state the complexity of any built-in in either language without looking, and you can write all three binary-search templates from memory.

Week 2 — Arrays, hashing, two pointers, sliding window

Milestone: given a problem statement, you can say “sliding window” or “two pointers” and justify it in one sentence before writing anything.

Week 3 — Stacks, heaps, and the structures JS lacks

Milestone: you can write a heap and a monotonic-stack loop without thinking, and you know which one a problem wants.

Week 4 — Trees and tries

Milestone: every tree problem starts with “is this top-down or bottom-up, and what does the recursion return?”

Week 5 — Graphs

Milestone: you reach for BFS on unweighted graphs without thinking, and you can say why Dijkstra breaks on negative edges.

Week 6 — Dynamic programming

Milestone: you define the state in words before writing code, and you can state complexity as “states x transitions”.

Week 7 — Language depth and design

If you own Effective Python or Effective TypeScript, this is the week to fold them in. Do not read them cover to cover — use the coverage matrices in chapter 20 §3 and chapter 21 §2 to skip the ~35% of each book already covered here at equal or greater depth, and spend the time on the gap lists instead (20 §5, 21 §4). Those are trap-shaped and therefore interview-shaped.

Milestone: you can answer “why this data structure” and “which patterns does your language make unnecessary” fluently.

Week 8 — Integration and mocks

Milestone: you can be interrupted mid-solution with a changed requirement and adapt out loud.

4. The maintenance loop

The version that stops the rust coming back, at about two hours a week. This is the one to keep doing indefinitely.

Weekly (90 minutes)

1. One blank-file drill (15 min) — rotate through the 20 in Problem sets §6 and the 20 in Testing §8, alternating. One per week means the whole set every nine months, which is enough to keep it warm.
2. Two mixed problems (50 min) — random pattern, no hints, narrate the choice out loud.
3. One flashcard pass (15 min) — whatever the spaced schedule says is due.
4. One trap (10 min) — pick a row from the trap list in Cheat sheets §7 and reproduce the failure in a scratch file.

Monthly (30 minutes extra)

• Re-read one chapter’s interview-questions section and answer out loud before reading the answers.
• Update the tracker in section 6.
• One trap from a gap list (20 §5 or 21 §4) — predict the behaviour, then run it. These are the cheapest single item in the loop and the ones most likely to come up unprompted.

The anti-rust habit, applied to daily work. The reason fundamentals erode under AI-assisted coding is that the choosing and the justifying get delegated along with the typing. Two cheap counters:

• When you accept a generated data structure or algorithm, say (or write in the commit message) why it is the right one and what its complexity is. Thirty seconds, and it keeps the muscle attached.
• Once a week, implement something small yourself first, then compare with what the model would have written. The comparison is where the learning is; the order matters.

5. Spaced repetition schedule

For any single item — a flashcard, a drill, a problem — review at expanding intervals, and reset to the start whenever you fail it.

“Failure” for a drill means: you could not produce a working implementation in the target time without looking. “Failure” for a flashcard means: you could not say the answer out loud, completely, within about ten seconds. Silent “yeah I know that” does not count — say it.

A paper log with six columns works fine. If you want it automated, use the Anki deck in section 9; Anki’s scheduler implements exactly this.

6. Self-assessment tracker

Score 1-5 weekly. 1 = could not start. 2 = need the reference. 3 = can do it with hints. 4 = can do it clean, first try. 5 = can do it and teach it, including the trade-offs.

Practise whatever is lowest, not whatever is most fun. The whole point of the table is to stop you re-solving two-pointer problems because they feel good.

7. Flashcards

The deck moved off this page and into an interactive study tool: /flashcards. Same 154 cards, same flashcards.tsv source (parsed at build time, no client-side parsing) — now with tag filtering (complexity, python, javascript, typescript, dsa, patterns, testing, effective-python, effective-ts), shuffle, and one-card-at-a-time study mode instead of a wall of text.

Say the answer out loud before revealing it. If it takes more than ten seconds, it is a failure — reset the interval.

8. Blank-file drills

The core of the whole plan. Close every reference, open an empty file, and produce a working implementation with a small test. Then run it, then diff against the reference in this guide.

The 20 drills are listed with target times in Problem sets §6. The starred ones — dynamic array, linked list operations, heap, BST, trie, DSU, LRU, three sorts, binary search templates, BFS/DFS/topo, Promise-or-decorator — are the ones to rotate through weekly forever.

Rules that make the drill work:

1. No reference open. Not the guide, not documentation, not an assistant. If you look, you restart the interval for that drill.
2. Write a test. Three asserts minimum, including an edge case. A drill you did not run does not count.
3. Time it. Beat the target time, or note the gap. The gap is your progress metric.
4. Say the complexity out loud when you finish, including the space and the amortization story.
5. Diff afterwards. Not to feel bad — to find the specific thing you forgot. “I forgot to update the position map in the heap swap” is actionable; “I sort of got it” is not.

A drill log is worth keeping, because the pattern in the failures tells you what to study:

date        drill                target  actual  outcome  what I forgot
2026-08-20  heap (TS)             25m     31m    pass     O(n) heapify order (last internal node)
2026-08-21  BST delete (Py)       30m     30m    fail     the two-children case: successor, not swap
2026-08-22  binary search x3      20m     14m    pass     -

9. Using the Anki deck

flashcards.tsv (the same file behind /flashcards, section 7) is every card from the old complexity/Python/JS-TS/DSA/patterns sections plus the 32 testing cards from chapter 19 — 154 in total, tab-separated, with a tag column. The effective-python and effective-ts tags (27 cards) come from the book crosswalks in chapter 20 and chapter 21; they are almost all trap-shaped, so they are the highest-yield subset to drill cold.

Import into Anki

1. Tools -> Manage Note Types -> Add -> Basic. (The default “Basic” is fine.)
2. File -> Import -> choose flashcards.tsv.
3. Field separator: Tab. Allow HTML in fields: off.
4. Map field 1 -> Front, field 2 -> Back, field 3 -> Tags.
5. Deck: create one called “Interview refresher”.

Settings that match the schedule in section 5

• New cards/day: 10 during the 8-week plan, 3 in maintenance.
• Maximum reviews/day: 60.
• Learning steps: 10m 1d.
• Graduating interval: 3 days. Easy interval: 7 days.
• Leave FSRS on if your Anki version offers it — it implements expanding intervals better than the legacy SM-2 defaults.

Tags let you drill one area: complexity, python, javascript, typescript, dsa, patterns, testing. Use tag:dsa is:due in the browser to review just one bucket.

Say the answers out loud. Silent recognition (“yeah, I know that one”) is the failure mode that makes flashcards feel productive while teaching nothing. If you cannot say it in a sentence, press Again.

Back to the index.