How to Practice LeetCode Effectively

Most people do not fail LeetCode because they are not smart enough.

They fail because they practice it the wrong way.

If you're like most people, practicing LeetCode for interviews consists of either:

1. Randomly picking problems
2. Choosing questions based on what feels easier that day
3. Doing only the LeetCode daily question

You spend hours daily over several months grinding questions over and over again. Seeing your solved count go up, you feel like you are making progress. Yet, as your interview date nears, you can only pray that the problems you've seen before will show up.

I have been in that spot myself. I know very well how that feels. The worst is when you walk into the interview, get handed a medium graph problem, and your mind goes completely blank. Not because you have never seen a graph problem before. You have seen dozens. But in that moment, nothing connects.

That is not bad luck. That is what happens when you grind without a system. This is also precisely why only few people can consistently crack LeetCode interviews. Because, unlike school where a curriculum is curated for you to ensure you learn effectively, LeetCode has none. You are left to your own devices to figure out what to practice and how to practice it. Most people go straight into the problems without any plan.

Today, I will share with you my system for practicing LeetCode. If you're like me who abhors the practice of LeetCode, I think you will like this system. It prioritizes maximizing learning while minimizing time spent, because we all have better things to do with our time.

Most people feel stuck because they skip the fundamentals: they are not fluent with the underlying data structures.

So Step 1 is to build a foundation by practicing questions grouped by data structures. Not random questions. Not "whatever looks doable" that day. Pick one structure, stay there long enough that it stops feeling unfamiliar, then move on.

Here are the buckets I recommend, in roughly this order:

1. Arrays & Strings: iteration, indexing, sorting, prefix sums
2. Hash Maps & Sets: membership checks, frequency counts, de-duplication
3. Stacks & Queues: push/pop discipline, ordering constraints, basic queue usage
4. Linked Lists: pointer discipline, inserts/deletes, traversal
5. Trees: recursion, traversals, depth/height, subtree thinking
6. Heaps: top-k, k-way merge, running minimum/maximum
7. Graphs: adjacency lists, traversal, visited bookkeeping

The metric for "I learned this" is not your solve count. It is whether you can explain, without looking, the operations, tradeoffs, and common failure modes for that structure. For example: why a hash map changes a brute force nested loop into a one-pass lookup, or why a stack is the right tool when you need to preserve an ordering constraint.

The order matters. Arrays/strings and hash maps show up everywhere and let you write efficient baseline solutions. Stacks/queues and linked lists build your intuition for pointer movement and ordering. Trees teach recursion and invariants. Heaps and graphs come later because they build on the same ideas but add more moving parts.

Step 2 will introduce named techniques (like sliding window, two pointers, and BFS/DFS) and you will practice them deliberately. But those techniques are not magic tricks. They are reusable ways to combine these same structures. If you do not understand how the structures behave, technique practice turns into memorization.

This foundation is what makes pattern training in the next step click. When you already understand the building blocks, patterns stop being abstract labels and become predictable compositions.

This is where most people go wrong, and it is subtle enough that it does not feel like a mistake while you are doing it.

When you treat every LeetCode problem as something new, as if each one needs to be solved completely from scratch, your brain never builds a filing system. Think of it like this: every time you sit down with a random problem, you are opening a brand new drawer in a cabinet you have never organized. You might solve it, but nothing gets filed anywhere useful. The next problem opens a different drawer. Nothing connects.

Practicing by pattern is the opposite of that. You group problems that share the same underlying approach and work through them in sequence, easier ones first. After your third or fourth sliding window problem, something starts to shift. You begin noticing the signals, the small clues buried in the problem statement that point to a specific approach. A fixed window size. A condition that shrinks the window. You start reaching for the right drawer automatically. You begin to know which techniques to use and how to apply them.

This is what experienced engineers mean when they say they “just knew” which approach to use. They did not magically recognize it. They built that recognition deliberately, one pattern at a time.

Most people have had this experience. You are on a medium problem. You have been at it for 45 minutes. You have tried three different approaches. You keep thinking you are one small step away from cracking it, but that one step keeps moving. An hour later you are no clearer than when you started, and now you are also tired and frustrated. You eventually look at the solution and feel vaguely defeated.

That is not persistence. That is diminishing returns in real time. And the cost is not just the wasted hour; it is the three other problems you could have learned from instead.

The fix is a stop-loss: a hard time limit on each phase of solving. Split your effort into two distinct phases. The first is a pure thinking phase with no coding. You are reading the problem, identifying the pattern, and sketching an approach. If you cannot form a reasonable plan within the time limit, that is information, not failure. It means you are missing something, and a targeted hint or a look at the solution approach (not the full code) will teach you more than another 30 minutes of spinning.

If you do have a plan, move to the implementation phase, again with a hard stop. If you still cannot finish within that window, stop and learn from the solution deliberately.

The stop-loss feels uncomfortable at first, especially if you have been trained to think that giving up early means you did not try hard enough. But the goal is not to brute force your way through every problem. The goal is to cover as many problems as possible for each pattern while spending adequate time to understand and attempt to solve them. Time limits enforce that.

Get a learning buddy, or even ChatGPT for this step. Getting stuck is inevitable. What matters is what you do when you are stuck.

Think about the last time you were completely blocked on a problem and then a friend casually asked, “Have you thought about what happens if you use two pointers here?” Suddenly everything clicks. You see it immediately. That one nudge was worth more than another 30 minutes of spinning in circles on your own.

The key detail is that you made the connection yourself. The hint pointed you at the right door, but you walked through it. That moment of clicking is where real learning gets encoded. Reading a full solution straight is like being carried through the door. Technically you get to the other side, but you will not remember how you got there.

Whether it is a friend, a study partner, or guided hints in a tool, the goal is small nudges, not answers. Get just enough to unstick your thinking, then work the rest out yourself.

There will be problems you cannot solve within the time limit. That is expected and completely fine. What matters is what you do next.

Reading a solution is deceptively satisfying. You follow the logic step by step, it all makes sense, you nod along, and you think you get it. Then you close it and try to write it yourself and realize you can only get halfway. This gap between recognizing and recalling is the main reason people can grind 200 problems and still blank in interviews. They have seen the solutions. They have not built the muscle.

Instead of just reading and moving on, slow down and ask yourself three questions: What pattern is being used? Why did I not think of it? Did I misunderstand the problem? Then close the solution and reimplement it from memory.

This step forces you to process the idea deeply instead of passively absorbing it. Spend roughly 10 minutes understanding the approach and 10 minutes reimplementing it, then move on. If it still does not fully click, mark the problem and come back to it later. Learning is iterative and that is fine.

After you have some experience with core data structures and algorithms, curated lists can be very helpful in giving you a good exposure to many patterns and it saves you the time and mental energy deciding what to practice.

Curated lists like Blind 75, Grind 75, and NeetCode 150 have done the filtering for you. They are not random collections. They are structured around the patterns that actually appear in interviews, organized so that you build on what you learned in the previous problem. The decision of what to practice next is already made.

If you are short on time, Blind 75 is the standard. If you have more runway, NeetCode 150 gives you deeper coverage. Either way, the principle is the same: remove the decision-making overhead so your entire session is spent on learning, not on navigation.

Once you have worked through curated lists and built a real foundation in the core patterns, it is time to test yourself. But this transition should happen gradually.

If you make the mistake of jumping straight from structured pattern practice to fully random problems too early, the patterns may not have stuck yet and every new problem may feel like starting from scratch all over again. The jump is too big.

Instead, move through a progression. Each phase removes one layer of scaffolding until you are operating under conditions that closely resemble a real interview.

By the time you reach fully random problems, pattern recognition feels natural rather than forced. Now you are not learning new concepts. You are sharpening recognition and decision-making speed, which is exactly what interviews test.

As you get closer to your target interview, your focus narrows one more time.

At this stage you should already be comfortable with most patterns. What you want now is familiarity with how your specific target company asks questions. Google and Amazon ask very different things. Meta leans heavily into graphs and dynamic programming. Stripe tends toward problems with a more practical, systems-aware flavor. Treating all companies as identical wastes preparation time you cannot afford to lose at this point.

Top candidates research their target company, identify the question archetypes that company favors, and weight their final weeks of practice accordingly. Practicing recent questions from that company, especially from the past few months, gives you the best possible signal for what is actually being asked right now.

If you follow this approach, something starts to shift. You will begin to understand why engineers at top companies can solve problems effectively even when they have practiced fewer questions than you. The difference is not that they have seen everything before. It is that they have trained themselves to see problems differently.

They sit down with a problem they have never seen, read it once, and immediately knows how to approach the problem because pattern recognition behaves like muscle memory to them. They don't need to think about it, they just know.

By the time they start writing code, half the battle is already won with a clear plan in mind. The other half is simply to explain their approach to the interviewer and implementing it, which is much easier when you already have a clear way of solving the question.

That is what interviews are actually testing. And that is what a system builds.

• Personal experience
• 10+ top LeetCode patterns (2026) · educative.io
• Master 15 LeetCode Patterns · lockedinai.com
• Best practice questions · Tech Interview Handbook
• Stop Mindlessly Grinding LeetCode · Better Programming
• LeetCode strategies from a senior engineer · Grokking