Most people who grind LeetCode for months don't get much better. They solve a few hundred problems, feel busy, and still freeze in interviews. The problem usually isn't effort. It's method.
Here's how I'd practice if I wanted results without burning a season of my life.
Stop counting problems solved
The number on your profile is a vanity metric. Solving 400 problems badly is worse than solving 80 problems well.
A problem only "counts" if you can solve a similar one cold a week later. If you looked at the solution, copied it, and moved on, you didn't learn anything. You rented the answer.
Track something better: how many problems you can re-solve from scratch without hints. That number is the one that shows up in an interview.
Learn patterns, not problems
LeetCode looks like thousands of unique puzzles. It isn't. Most problems are variations on maybe 15 to 20 recurring patterns. Two pointers. Sliding window. Binary search on the answer. BFS and DFS on graphs. Backtracking. Dynamic programming with a few common shapes. Heaps for top-k. Union find.
Once you recognize the pattern, the problem mostly solves itself. So practice by pattern, not at random.
Pick one pattern. Do five or six problems in that family back to back. By the fourth one you'll start seeing the shape before you read the whole prompt. That recognition is the actual skill. Random practice never builds it because you never get enough reps on the same idea in a row.
Use a timer and a hard quit rule
Set a timer for 25 to 30 minutes per problem. If you're stuck with no real progress when it goes off, stop and read the editorial.
This feels like giving up. It isn't. Staring at a wall for two hours teaches you almost nothing and wrecks your motivation. Reading a clean solution, understanding it, then closing it and re-implementing from memory teaches you a lot.
The hard quit rule is the single biggest time-saver here. People lose months because they refuse to look at solutions, so each problem costs them three hours instead of forty minutes.
One caveat. Spend the first 10 minutes genuinely trying before you peek. The struggle is what makes the solution stick when you read it. Skip the struggle and the editorial just slides off your brain.
Always re-solve, never just read
When you read a solution, you are not done. You are halfway.
Close the editorial. Open a blank file. Write the solution yourself. If you can't, you didn't understand it, you just recognized it. Recognition feels like knowledge but disappears under pressure.
Then add the problem to a review list with the date. Come back in a few days and solve it again from scratch. This spaced repetition is how the pattern moves from "I saw this once" to "I know this."
Talk out loud and write by hand sometimes
Interviews aren't silent. You explain your thinking while you code, you handle a curveball, you respond to a hint. If all your practice is silent solo grinding, the live format will throw you.
So practice the way you'll perform. Say your approach out loud before you type. Name the pattern. State the time and space complexity. Do a few mock interviews where someone actually watches you think. The gap between "I can solve this alone" and "I can solve this while explaining it to a stranger" is real, and the only fix is reps under that exact pressure.
A schedule that actually works
If you have six to eight weeks before interviews, here's a plan that respects your time.
- Week 1 to 2: arrays, strings, hashing, two pointers, sliding window. The bread and butter.
- Week 3: stacks, queues, linked lists, binary search.
- Week 4 to 5: trees, graphs, BFS, DFS, backtracking.
- Week 6: dynamic programming. Hardest, save it for when your fundamentals are solid.
- Week 7 to 8: mixed review, timed sessions, and mock interviews. Re-solve from your review list.
Aim for two to three problems a day, done properly, with re-solving built in. That beats ten problems a day done shallow. Quality over volume isn't a cliche here, it's the whole game.
What to skip
Don't chase the hardest problems for ego. Most interviews live in the easy-to-medium range with strong fundamentals. A handful of hards in your strongest pattern is plenty.
Don't memorize solutions to specific problems. You'll get a variant you've never seen and panic. Memorize the pattern, not the answer.
And don't practice in a tool that hides your weak spots. You want to see clearly which patterns you keep failing, then drill those. If you're using gitGood for practice or mock interviews, that's exactly what the review and timing pieces are for.
The honest version of all this: do fewer problems, do them properly, re-solve the ones that beat you, and quit early when you're stuck. That's how you finish in weeks instead of wandering for months.