Data structures, three passes
Five weeks, nine structures, and the same drill for each: read the idea until you can state its costs, push on it in a simulator until you have seen it bend, then build it from a blank file with tests and no peeking. The list itself is the standard one, nothing exotic. The three passes are the difference between knowing the names and having the structures available under pressure.
The list
Arrays, stacks, queues, linked lists, hash tables, trees and BSTs, heaps, graphs, and disjoint sets. That is the whole list, and it is the same list every serious guide converges on, because interviews and real systems converge on it too.
What is deliberately not on it: implementing AVL or red-black rebalancing. The old C++-first guides were right about this one; the reward-to-effort ratio on balanced-tree internals is minuscule. You need the general concept — a tree that fixes its own height so lookups stay logarithmic — and you need to know the standard library ships one. The rotation case analysis you can meet in pass two with a simulator and then politely leave there.
Pass one: the idea
Work through the data structures shelf, one structure at a time. The goal of this pass is modest and precise: for each structure, you can say what it is, which operations it offers, what each costs, and the one situation where it is the obviously right answer. Arrays buy O(1) indexing by paying on insert; hash tables buy O(1) lookup by giving up ordering; heaps keep the extreme element on top and nothing else sorted.
Write each structure's one-situation answer down in your own words. A structure whose use case you cannot state in a sentence is a structure you have only watched, and pass one is not finished with it.
Pass two: push on it
Reading tells you what a structure does. Watching it under load tells you why. Take each structure into its simulator and push until you see the behaviour the textbook sentence was compressing. Watching a B-tree split a node does in thirty seconds what a chapter does in an hour.
- Linked list — watch pointer surgery, and watch what "O(1) insert" actually requires you to already have.
- Queue and stack — same data, opposite ends, completely different uses.
- Hash tables — buckets, collisions, and resizing, which is where the magic O(1) earns its asterisk.
- B-tree — insert until a node splits; that one moment is the entire reason databases look the way they do.
- Heap — push, pop, and watch the sift restore the invariant every single time.
- BFS / DFS traversal — the queue and stack from earlier, secretly running the two fundamental graph orders.
- Balanced tree — your scheduled one meeting with rotations: watch them, get the concept, move on.
For each session, predict before you click. Say out loud what the structure will do — the habit from task 1 applies to simulators too — and treat a wrong prediction as a gift: it just showed you the exact edge of your model.
Pass three: the blank file
Now build each one from scratch in your language: a working implementation, tests included, no peeking at references. This is the pass most people skip and the pass that actually deposits the structure in your hands. jwasham's best line covers the why: "you're not being hired for knowledge, but how you apply the knowledge." Pass three is application practice in its purest form, plus a quiet workout for the testing habit you will need forever.
And do not run the passes as three sealed phases. While a structure is fresh, solve two or three practice problems that use it, the same week. This was jwasham's biggest stated regret, his loudest don't-make-my-mistake: he learned everything first and started problems after, and the knowledge had gone cold by the time it was needed. Implementation plus immediate problems is the combination that sticks.
The one external course seat
A lecture track alongside this task is genuinely useful: someone else's ordering and someone else's diagrams catch what your primary path misses. So take one seat in any single well-reviewed DSA course, finish it, and that is the whole policy. One.
The policy has a hard edge because the failure mode is so common it deserves its plain name: collecting courses is procrastination with a receipt. The third purchased course is not a study plan, it is an anxiety purchase, and it costs you the only currency this plan runs on, which is hours at the keyboard with a blank file.
Frequency reality check
Before anxiety budgets your remaining weeks, look at what companies actually test. HackerRank's interview-kit data, drawn from what their customers screen with, prints the distribution:
| Structure | Share of companies testing it |
|---|---|
| Arrays | ~70% |
| Hash maps | ~40% |
| Sorting | ~40% |
| Strings | ~40% |
| Trees | ~12% |
| Linked lists | ~8% |
Read that twice, because it is the inverse of where anxious students spend their time. The internet's nightmare topics, tricky tree problems and linked-list reversals, sit at the bottom of the table, while the workhorses everyone considers beneath them sit at the top. Weight your pass-three problem reps accordingly: arrays, hash maps, and strings are not the warmup before the real material. They are the real material, and the next task is where you go to volume on them.