TL;DR: Years ago I wrote an essay called Grokking LeetCode: A Smarter Way to Prepare for Coding Interviews, arguing that you should learn 25 reusable patterns instead of grinding hundreds of unrelated problems. The argument held up. The list did not stay at 25. It is now 42, because interviewers started leaning on shapes that barely appeared back then: monotonic stack, prefix sum, greedy, and a whole advanced tier for senior loops. This page is the honest update: what got added, what got renamed, what got absorbed, and what running the method looks like today.
Every so often a piece of writing outlives the facts inside it. That happened to mine.
The original essay, Grokking LeetCode, opened with a question I still think is the right one to ask: to LeetCode or not to LeetCode? What do you do when there are hundreds of problems in front of you, no obvious order, and a real interview on the calendar? My answer then was that the problems are not the unit of study. The patterns behind them are, and there were 25 worth knowing.
That answer was right, and I would make the same argument today. But the specific list of 25 has grown to 42, and enough people still find the original essay first that it is worth writing down exactly what changed and why. If you have already read it, this page is the delta. If you have not, read it first; it is where the idea is laid out from scratch, one pattern at a time.
What "grokking" LeetCode actually means
The word is doing real work in that title, so it is worth being precise about it.
To grok something is to understand it so completely that you no longer have to reason your way back to it. It is the difference between knowing that a heap gives you the smallest element in O(log n) and reaching for a heap without deciding to, because the problem said "k largest" and your hands moved.
Grinding LeetCode produces the first kind of knowledge. You solve a problem, you understand the solution, the counter goes up, and three weeks later you could not reproduce it. Grokking LeetCode produces the second kind. You are not trying to accumulate solutions; you are trying to install recognition, so that an unfamiliar problem resolves into a familiar shape in the first thirty seconds.
That distinction is the entire thesis, and it is the part of the original essay that has aged perfectly. Interviewers do not hand you problems you have seen. They hand you variations, deliberately, because variations are how you separate the two kinds of knowledge.
The original 25
Here is the list as the essay laid it out, in its original order:
Sliding Window, Two Pointers, Fast & Slow Pointers, Merge Intervals, Cyclic Sort, In-place Reversal of a Linked List, Tree Breadth-First Search, Tree Depth-First Search, Two Heaps, Subsets, Modified Binary Search, Bitwise XOR, Top 'K' Elements, K-way Merge, 0/1 Knapsack, Unbounded Knapsack, Fibonacci Numbers, Palindromic Subsequence, Longest Common Substring, Topological Sort, Trie Traversal, Number of Islands, Trial & Error, Union Find, and Unique Paths.
Read that list today and the striking thing is how much of it survived untouched. Twenty of those twenty-five are still on the current map under the same name and doing the same job. This was not a list that needed rescuing. It needed extending.
What got added, and why
Nine patterns joined the common tier, and a tenth category appeared above it. These are the ones that matter, roughly in order of how often they now decide an interview.
Monotonic Stack. The biggest single omission in the original list, and the one I would most want to go back and add. Next-greater-element, daily temperatures, largest rectangle in a histogram, and stock-span problems all collapse to one template that keeps a stack in sorted order. It was a niche competitive-programming trick when I wrote the essay. It is now routine at Meta and Google, and it is the pattern candidates most often fail to recognize because nobody taught it to them as a pattern. It has its own deep dive now for exactly that reason.
Prefix Sum. Range-sum queries and "count the subarrays summing to k" problems have a linear solution that most people reinvent badly under pressure. Once you see prefix sums paired with a hash map, an entire family of problems stops requiring cleverness.
Greedy Algorithms. The original list handled optimization almost entirely through dynamic programming. But a large class of interval, scheduling, and allocation problems have a correct greedy solution, and the interview skill is knowing which is which. Reaching for DP when greedy suffices costs you time; reaching for greedy when it is wrong costs you the offer.
Monotonic Queue. The sliding-window-maximum family, which the original essay's Sliding Window entry gestured at but did not separate out. It deserves its own name because the data structure is genuinely different.
Hash Maps and Stacks as named patterns. These felt too fundamental to list as "patterns" originally. That was a teaching mistake. Treating them as first-class patterns, with their own tells, is what lets a beginner see that "two sum" and "valid parentheses" are pattern instances rather than trivia.
Level Order Traversal split out from Tree BFS, Graphs promoted to a standalone family alongside the Islands and Topological Sort entries it used to hide behind, and Ordered Set added for problems that need sorted-with-mutation access.
And an advanced tier of 10. Counting, Simulation, Linear Sorting, Meet in the Middle, Serialize & Deserialize, Clone, Articulation Points & Bridges, Segment Tree, Binary Indexed Tree, and MO's Algorithm. None of these show up in a typical new-grad loop. Several of them show up in senior and staff loops at companies that want to see depth, and their absence from the original list is the clearest sign that it was written for a slightly easier era of interviewing.
What got renamed or absorbed
Some of the change is bookkeeping rather than new material, and it is worth being clear about which is which so the original list still reads correctly:
- Trial & Error is now called Backtracking, which is what everyone else calls it. The original name described the feeling; the new one describes the technique.
- Number of Islands became Island (Matrix Traversal), because the pattern is grid traversal generally, not one famous problem.
- Trie Traversal is just Trie.
- Unique Paths, Longest Common Substring, and Unbounded Knapsack were absorbed into the six dynamic programming families. Listing them as peers of Sliding Window overstated how separate they are; they are shapes within DP, and teaching them that way is what finally makes DP tractable for most people.
So the honest arithmetic is not "25 became 42 because I found 17 new things." It is closer to: twenty survived as-is, five were renamed or folded into a family, nine genuinely new common patterns were added, and an advanced tier of ten was built for senior loops. Current canonical count: 42, made of 32 common patterns plus 10 advanced ones. The complete list with the tell for each one is the reference page; I will not reproduce all 42 here.
What did not change at all
The method. Every load-bearing claim in the original essay is still true:
Problems are variations, not originals. Your interviewer took something known and changed a constraint. If you learned the template, that is a small edit. If you memorized the instance, it is a new problem.
The list is finite. This is the whole psychological point. "LeetCode has more than 3,000 problems" is paralyzing. "There are 42 shapes, and the core dozen or so cover most of what gets asked" is a plan.
Recognition beats volume. Most engineers are ready after roughly 100 to 150 pattern-organized problems, not the 500 that panic suggests. Organization is what makes the smaller number work, because problems grouped by pattern compound and problems drawn at random do not.
Mapping new to known is the actual skill. The line I still get the most mail about is that the patterns "helped me nurture my ability to map a new problem to an already known problem." That is the skill. Everything else is scaffolding for it.
What changed about LeetCode itself
Two things, and they both argue for the method rather than against it.
The catalog got much bigger. More than 3,000 problems now, which makes an unstructured approach worse than it was when the essay was written, not better. The larger the pile, the more the ordering matters.
The median question got harder. What used to be an easy is now a warm-up, and the standard onsite question is a medium with a follow-up attached. Follow-ups are precisely where pattern knowledge separates from memorization, because a follow-up is a variation by definition.
There is a third shift, which is that some companies now run AI-assisted coding rounds where you are allowed to use an assistant. That sounds like it should make preparation obsolete. It does the opposite: when the typing is cheap, the interview grades what remains, which is whether you can choose the right approach and defend it. Choosing the right approach is pattern recognition with a different name.
How to run the method today
The original essay told you what to learn. Here is the loop for actually doing it, which is the part people ask about most:
- Work one pattern at a time, in blocks. Five to eight problems from the same family, back to back. Mixed practice feels more like a real interview and teaches recognition far more slowly. Do the blocks first; interleave later.
- Write the tell down before you write code. In one sentence: what in the problem statement told you it was this pattern? If you cannot write it, you did not recognize the pattern, you recalled the problem.
- Drill diagnosis separately from solving. Open ten unfamiliar problems and, for each, name the pattern and stop. No coding. Ten minutes total. This trains the exact skill the first three minutes of an interview tests, and it is the highest-leverage drill I know.
- Review failures on a spacing schedule. Anything you got wrong comes back after a day, then a week. Anything you got right on the first try does not need to come back at all.
- Add timed pressure last. Recognition first, speed second. Reversing that order builds anxiety instead of skill.
If you want that turned into a calendar rather than a list of habits, the 4-week study plan is the day-by-day version, and how long it actually takes sets honest expectations by situation.
Where to go from here
The original essay remains the cleanest short introduction to the idea, and I would still start there if you are meeting it for the first time: Grokking LeetCode: A Smarter Way to Prepare for Coding Interviews.
From there, the complete list of all 42 patterns is the current reference, with the tell for each one and a printable cheat sheet. If you would rather have the templates in code, they are written out for Java and for Python. And if dynamic programming is the part that defeats you, the six DP families are where the original list's four DP entries went.
Learn all 42 the way this method describes: Grokking the Coding Interview is the course the original essay pointed to, now covering all 42 patterns (32 common plus 10 advanced) across 300-plus problems, in six languages with in-browser playgrounds, for a one-time $79. For the DP families specifically, Grokking Dynamic Programming goes deeper. Missing the foundations underneath the patterns? Start with Grokking Data Structures. On a short timeline? Grokking 75 is the triage version. If you are unsure which of those fits you, this guide sorts them out.
FAQs
What does "grokking LeetCode" mean? It means learning LeetCode through its underlying patterns until recognition becomes automatic, rather than solving problems one at a time and hoping the right one appears in your interview. To grok something is to understand it deeply enough that you no longer reason your way back to it. Applied to LeetCode, that means seeing "k largest" and reaching for a heap without deciding to.
Are there 25 coding patterns or 42? Both numbers are correct for their moment. The original essay named 25, and twenty of those are unchanged today. The current canonical list is 42: 32 common patterns plus 10 advanced ones, after nine common patterns were added, several were renamed, and a few DP entries were folded into the DP families.
Which patterns were added after the original 25? Monotonic Stack, Prefix Sum, Greedy Algorithms, Monotonic Queue, Hash Maps, Stacks, Level Order Traversal, standalone Graphs, and Ordered Set, plus an advanced tier of 10 aimed at senior loops. Monotonic Stack and Prefix Sum are the two that most changed what a typical interview asks.
Do I need all 42 patterns? No. The core dozen or so cover the bulk of what gets asked in most loops, and the advanced tier is aimed at senior and staff interviews. The value of knowing the full map is triage: when a problem defeats you, it usually belongs to a named family you have not installed yet, which is a much more actionable diagnosis than "I am bad at this."
Is pattern-based preparation still relevant with AI-assisted interviews? More relevant, not less. When an assistant makes the typing cheap, what remains gradable is whether you pick the right approach and can defend it under follow-ups. That is pattern recognition. The companies running these rounds are explicitly testing judgment rather than recall.
Where do I find the full list with examples? The complete pattern guide has all 42 with the tell that identifies each one from the problem statement, a cheat sheet mapping problem phrasing to pattern, and links to the individual deep dives.