How to Actually Practice LeetCode: The 30-Minute Method

Stop staring at one problem for hours. Cap every attempt at 30 minutes, learn the approach, then prove it stuck with spaced repetition.

The most common way people practice LeetCode is also the worst one. Open a problem, stare at it for two hours, give up, read the solution, feel bad, repeat. You burn a whole evening and learn one problem.

The fix is a hard time limit and a schedule for coming back.

The rule: 30 minutes, no exceptions

Set a timer. Then follow the same eight steps for every problem.

Read it carefully. Write down the inputs, outputs, and constraints.
Name the pattern. Two pointer? Sliding window? HashMap? BFS/DFS? Say it out loud.
Try your approach. Code it up and talk through your thinking, even if you're alone.
Hit 30 minutes? Stop coding. This is the step that matters. No shame. Move on to step 5.
Read the approach, not the code. What pattern does it use, and why does it work? A NeetCode video is great for the intuition.
Close everything and implement it yourself. No peeking. Write your own code from the idea you just learned.
Analyze it. State time and space complexity, and explain why this approach is optimal.
Log the pattern. Pattern name, problem, confidence level.

Step 4 is the whole trick. Past 30 minutes you're usually not learning, you're just stuck. Looking at the approach and rebuilding it yourself teaches more than another hour of guessing.

Solving it once means nothing

You need to prove you can do it again without help. I use a three-touch schedule:

When	What
Day 1	First attempt, using the 30-minute method.
Day 3	Try again with no notes. Can you recall the approach and implement it?
Day 7	Final check. Nail it and it's locked in. Miss it and restart the cycle.

If you can solve it on Day 7 cold, you actually learned the pattern.

Track patterns, not problem counts

Keep a simple tracker in Notion or a spreadsheet. One row per pattern, with the key insight and a status: Strong, Learning, or Weak. Then spend about 80% of your time on whatever isn't Strong yet.

Pattern	Key insight
Two Pointer	Sorted arrays, shrink from both ends
Sliding Window	Contiguous subarray or substring, expand and shrink
HashMap	O(1) lookups, complements, frequency counts
BFS / DFS	Trees and graphs, level-order vs. depth-first
Binary Search	Sorted data, shrinking the search space
Backtracking	All combinations or permutations, prune early
Dynamic Programming	Overlapping subproblems, optimal substructure
Greedy	Local optimum is the global optimum, usually sort first
Heap / PQ	Top-K, merging sorted lists, scheduling
Stack	Matching brackets, monotonic stack, undo

What to practice, in what order

Don't grind random problems. Use a curated list. Blind 75 is the shorter starting point. NeetCode 150 is the full version, organized by pattern, with a video for every problem. Grind 75 builds a schedule around how many hours you have.

Build the foundation before the hard stuff:

Easy topics: arrays, strings, hashmaps, two pointers, stacks, linked lists, binary search.
Medium: sliding window, trees (BFS/DFS), graphs, backtracking, heaps, intervals, greedy.
Hard: dynamic programming, tries, segment trees, union find, topological sort, bit manipulation.

Rough time targets once you're warmed up: about 15 minutes for an Easy, 25 for a Medium, 40 for a Hard.

Mindset

Not solving a problem isn't failure. It's data. Now you know what to study.
Understanding why beats memorizing how. If you can explain it to someone, you know it.
Two problems a day beats ten on Saturday.
Easy problems aren't beneath you. They drill patterns that show up in mediums and hards.
Talk out loud while you solve. Interviews require it, so practice it from day one.

A tutor that won't just give you the answer

I built a Claude Code skill, interview-prep, that acts like a tutor for this. It gives hints instead of answers, makes you explain your thinking, and catches logic errors so you get to the solution yourself.