How to study LeetCode effectively
Solve fewer problems, better. Learn the patterns, give each problem an honest attempt, explain your approach out loud, and come back to it before you forget.
Updated · 8 min readThe short version: most people who grind hundreds of LeetCode problems and still freeze in interviews were memorising solutions, not learning patterns. Study by pattern, time-box each attempt, use hints one small step at a time, say your approach out loud, and review each problem a few times over the following weeks.
Given a 1-indexed array of integers numbers sorted in non-decreasing order, find two numbers that add up to target.
Input: numbers = [2,7,11,15], target = 9 Output: [1,2]
Input: numbers = [2,3,4], target = 6 Output: [1,3]
1. Study patterns, not problems
Interview problems are variations on a few dozen ideas. Learn them one at a time, with several problems each, until you can say which one a new problem needs:
- Arrays and hashing, two pointers, sliding window
- Binary search, stacks (including monotonic stacks), heaps
- Linked lists, trees, tries
- Graphs: BFS, DFS, topological sort, union-find
- Intervals, greedy, backtracking
- Dynamic programming, one- and two-dimensional
A curated list keeps you honest: LeetCode’s own LeetCode 75 study plan, Blind 75 or NeetCode 150. Finish one before starting another.
2. Time-box each attempt
Give an easy problem about 15 minutes and a medium about 25 to 30. If you have no idea at all after 15 to 20 minutes, take a hint. Not the solution: a hint. Staring for two hours teaches less than a nudge at the right moment.
3. Take hints in small steps
Climb the ladder one rung at a time, and stop as soon as you can move again:
- Restate the problem and the constraints in your own words.
- The name of the pattern (“this is a two-pointer problem”).
- The key observation (“the array is sorted, so…”).
- Pseudocode for the tricky part.
- The full solution, last, and only after you’ve tried again.
4. Talk it through, out loud
In an interview you have to explain your thinking while you code. Practise that from the start: say the brute force, its complexity, and why you can do better, before you type. Saying it out loud also finds the hole in your reasoning faster than thinking it, which is why rubber-duck debugging works.
5. Write down what you learned
After each problem, four lines are enough:
- The pattern.
- The key insight, in one sentence.
- The mistake you made, if any.
- Time and space complexity.
6. Review with spaced repetition
Re-solve each problem from scratch a day later, again a week later, and again a month later. Turn the key insight into a question (“Which pointer moves when the sum is too big?”) and review it with your other cards. Problems you can redo cold are the ones you’ll have in the interview.
7. Don’t grind alone
A study partner makes all of this easier: someone to explain your approach to, who gives a hint instead of the answer. That’s what we built Pen Buddy for. On the Mac, Buddy follows the problem you open, listens while you talk it through, and sees your test runs. It gives hints before answers, writes every session into your notes, and turns them into review cards. On iPad it draws the pointers, trees and DP tables. More on the LeetCode page.