The long middle

The spine everyone agrees on

Lay the big study lists side by side and a shared skeleton falls out. Nearly every serious curriculum walks the same road: arrays and hashing first, then the two-pointer family, then sliding window, then stacks, linked lists, and binary search, then trees, then graphs and backtracking, and dynamic programming last.

That order is not fashion. Each stage is a prerequisite for the next. Two pointers assume you are fluent with arrays. Sliding window is two pointers with a constraint attached. Tree problems are recursion with a picture. Graph problems are tree problems where you have to track what you have already visited. DP sits at the end because it quietly assumes everything before it: recursion, memoised lookups in a hash map, and the patience to draw the state space before writing code.

So the spine is settled. Whatever list you pick, do not reorder it out of boredom. The interesting disagreements are about everything else.

Where the canon genuinely diverges

Three schools, three different bets about what makes practice transfer:

• NeetCode's roadmap is a dependency DAG. Topics are nodes, arrows are prerequisites, and you are meant to master a node before moving along an edge. It optimises for mastery: no problem should require a tool you have not been handed yet.
• Tech Interview Handbook priority-ranks. Yangshun Tay's plan grades every topic by how often it actually appears in interviews, and is comfortable telling you to cut. Its most heretical call: dynamic programming is marked low priority, with the note that many DP questions can be solved with plain recursion and backtracking anyway. More on that heresy below.
• The 14-patterns school drops topic order entirely. Fahim ul Haq's "14 Patterns to Ace Any Coding Interview Question" reframes the whole exercise as recognition: stop sorting problems by data structure, sort them by the shape of the question. Its lasting contribution is the cue list, which we steal wholesale a few sections down.

These are not really in conflict. The DAG tells you what to learn first, the priority ranking tells you what to skip under deadline, and the pattern school tells you what to practise noticing. A good plan uses all three.

Our order: follow the playbook

This site already has its own answer, and the plan simply points at it: the problem-solving study path and its twenty-five-pattern playbook, ranked by how often each shape shows up in real interviews. Every pattern page has its own progression, so you are never staring at a blank problem list wondering what is next.

Walk it in playbook order. The early weeks live in hash maps, two pointers, and sliding window. The middle weeks are linked lists, binary search, DFS and BFS on trees. The back half is graphs, backtracking, heaps, and finally dynamic programming.

The methodology page covers the session mechanics: how long to struggle before reading a solution, how to review, how to keep a mistake journal. Read it once at the start of this task and again around week five, when your habits have drifted.

How many problems, and which ones

The original Blind 75 post had one thesis: 75 well-chosen problems beat 500 random ones. The list itself encodes a judgement about where interview weight actually sits: roughly ten array problems, eleven DP, fourteen tree, eight graph, with the rest spread across strings, intervals, linked lists, and bit tricks. Notice what that distribution says: trees and DP together are a third of the list.

NeetCode 150 is the natural superset: Blind 75 plus 75 more, each with a video walkthrough, arranged along the roadmap DAG. If you want one list and no decisions, it is the safe default.

Grind75's real innovation is that it is not a list at all. It is a generator: you tell it how many weeks you have and how many hours a week, and it emits a schedule drawn from an importance-ranked pool. That is the right abstraction. A list assumes everyone has the same deadline; nobody does.

Recognition cues worth memorising

The 14-patterns school's lasting gift is this table. The skill being tested in a coding interview is mostly recognition: reading a problem statement and knowing, within a minute, which family it belongs to. These cues are the lookup keys.

Memorise these the way you would memorise vocabulary. Then the real practice, from week six onward, is testing whether the cues fire on problems you have never seen.

The DP wall, properly

Everyone hits the wall here, so here is the actual method instead of vibes.

Dumitru's classic Topcoder tutorial reduces every DP problem to two questions: what is the state, and what is the recurrence. That's the whole discipline. When you are stuck, the move is almost always the same: take whatever constraint you are failing to respect and add it to the state. "Max profit" becomes "max profit, holding or not holding". "Ways to reach cell (i, j)" becomes "ways to reach (i, j) with k moves left".

aatalyk's Dynamic Programming Patterns post then shows there are really only about five shapes, each with a recurrence skeleton you can learn once: min/max path (take the best of the cells that reach you, plus your cost), distinct ways (sum the ways that reach you), merging intervals (try every split point k between i and j), DP on strings (two indices, match or skip), and decision making (take it or leave it, state carries the consequence). Try the LCS simulator to watch the strings shape fill its table cell by cell.

Method in practice: write the brute-force recursion first, get it correct on small inputs, then memoise it. Top-down with a cache is a legitimate final answer in almost every interview; converting to bottom-up tables is an optimisation, not a requirement. The recursion simulator makes the call tree you are memoising visible.

Binary search as a predicate

The single most underrated upgrade in this whole task. lovro's Topcoder binary search tutorial teaches the generalised version: forget "find the element", define a predicate p(x) over your search space such that the answers form a run of no-no-no-yes-yes-yes, and binary search finds the boundary.

This converts optimisation problems into decision problems. "Minimise the maximum load" becomes "can we do it with max load x?", which is usually a greedy check you can write in five lines. Ship capacity, Koko's bananas, splitting arrays: all the same trick. Once you see it, a whole category of scary mediums becomes mechanical.

Two hygiene rules: always test your loop on a two-element array, because that is where the infinite loop lives (mid rounding toward the bound you are not moving), and decide before you write the loop whether you are finding the first yes or the last no. The binary search simulator and the pattern page both drill this.

From week six: add randomness

Curated lists have a failure mode: you always know which chapter the problem came from, so the hardest part of the interview, recognising the pattern cold, never gets trained. From about week six, fix that deliberately:

• Topic-blind problems. A few times a week, take a random medium with no idea which pattern it wants. The first two minutes of staring is the rep.
• One contest most weekends. Live timer, unseen problems, mild adrenaline. Your contest placement is irrelevant; the format is the point.
• The daily warm-up stays in the routine from here through the end of the plan.

The metric for this whole task is recognition speed on unseen problems. Solved-count is vanity; it measures the past, not the interview.

The pitfalls wall

• Memorising solutions. If you cannot re-derive it a week later from the pattern, you stored a string, not a skill.
• Topic-hopping. Three problems of trees, two of DP, one of graphs in a day feels productive and builds nothing. Stay on one pattern until it bores you.
• No review loop. A problem you failed and never revisited is a problem you will fail again. Re-attempt failures after three days, then after two weeks.
• Marathon sessions. Five focused 90-minute sessions beat one heroic Saturday. Recognition is built by spaced exposure, not by suffering.
• Premium FOMO. Company-tagged question lists are stale and over-traded. The patterns are free and they are the durable asset.
• Comparing counts. Someone on the internet has solved 1,400 problems. They are not interviewing instead of you. Two unseen mediums in 70 minutes, talking aloud, is the bar; nothing else is.

Further reading

• The original Blind 75 post — the curation thesis, from the source.
• NeetCode roadmap — the dependency DAG, with the 150 attached.
• Tech Interview Handbook — coding interview study plan — the priority-ranked schedule, including the DP heresy.
• Dumitru — Dynamic Programming: From Novice to Advanced — state and recurrence, the two questions.
• lovro — Binary Search (Topcoder) — the predicate formulation that generalises everything.
• aatalyk — Dynamic Programming Patterns — the five shapes with recurrence skeletons.