// pattern debugger≡ menu

stack>reference / study_plan

// Study Plan

Five tracks, run in order or dipped into: the core patterns, the rest of the pattern catalogue, how the machine runs code, how the network moves bytes, and the distributed layer.

Five tracks, not one course. They are independent — the network track does not need the pattern tracks, and the day numbers below are a reading order, not a countdown. Start wherever the gap is, and finish a track before you open the next one.

Only the two pattern tracks are budgeted in hours, because they are the only ones with problems to grind. Two hours a day is enough there if the time is honest: no editor, no running the code first — paper, the template, and a hand trace. The order front-loads the patterns that appear in the most interviews; if you only have one week, the core track alone covers the majority of what a coding screen will ask.

The systems, network and design tracks are read-and-redraw days instead. They are shorter than a pattern day and there is nothing to submit — the check is whether you can close the page and redraw the mechanism from memory.

the core patterns track (days 1–7)

The eight core patterns in the mandated order, two hours a day. Read the topic page first (~20 minutes), then work the problems: attempt each one on paper before reading the solution, and always hand-run the trace. This is the one track with a real deadline shape to it — seven honest sittings covers the majority of what a coding screen asks.

  1. day_01Foundations skim + first pattern
  2. day_02Dictionaries in anger + the Two Sum tradeoff
  3. day_03Windows + loop mechanics
  4. day_04Boundaries, not values
  5. day_05Pointer surgery on lists
  6. day_06Trees two ways
  7. day_07Array toolbox + recognition review

the rest of the patterns (days 8–14)

The rest of the pattern catalogue: the data-structure patterns and the advanced families. Same discipline, same two-hour shape. Stretch-tier problems (purple badge) belong to whichever later pass you can afford — skip them on the first lap without guilt.

  1. day_08Sorting payoffs + stacks
  2. day_09Heaps and the top-K family
  3. day_10The decision tree
  4. day_11Prefix trees (+ Word Search II capstone)
  5. day_12DP fundamentals
  6. day_13Graphs beyond traversal
  7. day_14Greedy, intervals, bits — the closers

the systems track (days 15–29)

A different kind of study: no problem to solve, a machine to understand. Read the topic page, then actually run the exercises — predict the number before you look at it, and hunt the bug before you scroll. These days are shorter than the pattern days and they compound; the concurrency half only makes sense once the memory half is in your hands.

  1. day_15The machine, from nothing
  2. day_16How one instruction runs
  3. day_17Where your data actually lives
  4. day_18The address space is a lie
  5. day_19Why memory is the bottleneck
  6. day_20Why the CPU cheats
  7. day_21The collector and the bill
  8. day_22What the JIT did to your code
  9. day_23Threads, the pool, and await
  10. day_24Three guarantees, not one
  11. day_25Making one thing indivisible
  12. day_26Inside a lock
  13. day_27How it goes wrong
  14. day_28Doing without locks
  15. day_29Scaling past one core

the network track (days 30–38)

The other half of the machine, assuming nothing: what a packet is, how the layers stack, what a port actually is, how a name becomes an address, and what to run when none of it works. No problems to grind — read the page, then try to redraw the header stack and the resolution walk from memory.

  1. day_30Packets, links, and why layers
  2. day_31One hop: frames, MACs and ARP
  3. day_32Addresses that carry structure
  4. day_33What a port actually is
  5. day_34A stream built on top of loss
  6. day_35Names into addresses
  7. day_36What the stack was carrying
  8. day_37Making it visible when it breaks
  9. day_38The applied path, end to end

the system design track (days 39–49)

The distributed layer. There is no code to run here and no single right answer — the skill is holding a tradeoff in your head and saying out loud what it costs. Read each page, then close it and try to redraw the mechanism from memory; if you cannot, you have not got it yet. The drills on the last day are the rehearsal.

  1. day_39Sizing it before building it
  2. day_40What a database does with a write
  3. day_41ACID past the acronym
  4. day_42More than one copy
  5. day_43More than one machine
  6. day_44What consistency costs
  7. day_45Getting a cluster to agree
  8. day_46Not doing the work twice
  9. day_47Decoupling with queues
  10. day_48Staying up when dependencies do not
  11. day_49Putting it together under pressure

how to run a two-hour block (pattern tracks)

minutesactivity
0–20Topic page: core idea, templates, when-to-reach-for-it. Write the template from memory once.
20–100Problems in order. For each: read the task, attempt on paper (10 min cap), compare with the solution, then hand-run the trace — the trace is where the pattern actually sinks in.
100–120Close the loop: redo the day's hardest problem from a blank page, and skim the cheat card.
Day 8's sorting page is pre-reading more than practice — skim it before bed on day 7 and the heap and intervals days land twice as hard.

how to run a reading day (systems, network, design)

Read the page once end to end without stopping to look anything up. Then close it and redraw the diagram — the header stack, the page-table walk, the write path — on paper from memory. What you cannot redraw is what you have not got yet, so go back for exactly that part. Where the topic has exercises, run them: predicting the answer before you scroll is the whole exercise, and reading the answer first wastes the page.

// connections