To get better at LeetCode, stop measuring progress by problems solved and start measuring it by problems you can re-solve from a blank editor a week later. In practice that means learning one pattern at a time, capping each attempt at about 25 minutes before you take a hint, reading solutions for the key idea instead of the code, re-solving on a schedule, logging exactly why you got stuck, and saying your reasoning out loud.
If you can do easies but freeze on mediums, nothing is wrong with you. Mediums mostly test whether you recognize which technique a problem needs, and recognition is a trainable skill. Here is the method, step by step.
Why you keep getting stuck on mediums
“Stuck” usually has one of five causes. Working out which one you are hitting tells you what to fix:
| Symptom | Real cause | Fix |
|---|---|---|
| Blank page, no idea where to start | You have not learned the pattern yet, or have not seen it enough times | Learn patterns by topic (Step 1) |
| Hours on a single problem | No time box, so you keep struggling long after it stops teaching you anything | The 25-minute rule (Step 2) |
| Right idea, code would not work | Implementation gaps: indices, boundaries, edge cases, language APIs | Re-solve and log the bug type (Steps 4 and 5) |
| Solved it, failed a similar one a week later | You recognized the solution but never practiced retrieving it | Spaced re-solves (Step 4) |
| Fine alone, fall apart when explaining | Solving and narrating are separate skills | Practice out loud (Step 6) |
Step 1: Learn patterns by topic, not random problems
Random problems feel productive but teach slowly, because every one is a fresh puzzle. Batch four to six problems from the same pattern in a row instead, so the shared structure becomes obvious. The Tech Interview Handbook makes the same recommendation: study a topic, then immediately solve problems on it, and learn the approach rather than memorizing answers.
What you are really building is a lookup table from wording in the prompt to a technique. Write yours down. A starter version:
| If the prompt says… | Try first | Classic example |
|---|---|---|
| Longest or shortest contiguous subarray or substring that meets a condition | Sliding window | Longest Substring Without Repeating Characters |
| Sorted array, find a pair that hits a target | Two pointers | Two Sum II (sorted input) |
| “Have I seen this value before?” or counts of values | Hash map or set | Two Sum |
| Sorted input, or “smallest value that still works” | Binary search, including on the answer | Koko Eating Bananas |
| Next greater, next smaller, next warmer | Monotonic stack | Daily Temperatures |
| Top K, kth largest, merge K sorted lists | Heap | Kth Largest Element in an Array |
| Grid of cells, connected regions, fewest steps | BFS or DFS | Number of Islands |
| Generate all subsets, permutations or combinations | Backtracking | Subsets |
| Count the ways, or minimum cost, with overlapping choices | Dynamic programming | Coin Change |
| Overlapping ranges or meeting times | Sort, then merge intervals | Merge Intervals |
Our guide to the 15 core LeetCode patterns goes deeper on each row. If you are just starting on mediums, the two patterns that unlock the most problems early are the sliding window and two pointers. Leave dynamic programming until those feel automatic.
Step 2: Use the 25-minute rule
Struggle is useful up to a point; past it you are just waiting. A time box keeps the useful part. Our rule of thumb:
- Minutes 0–5: understand. Restate the problem, read the constraints and work one or two examples by hand. Input size is a clue: if n can reach 100,000, an O(n²) approach is usually too slow.
- Minutes 5–15: brute force, then find the bottleneck. Describe the obvious solution and its Big-O. Ask which part repeats work, and which pattern from your table removes it.
- Minutes 15–25: commit and code. Pick an approach and implement it, even if you are not sure it is optimal.
- At 25 minutes with no working approach: take one hint. Many LeetCode problems list hints under the description. Read one, then give yourself another 10 minutes.
- At around 40 minutes: read the solution using the method in Step 3. The problem goes into your log either way.
If nothing comes in the first 15 minutes, run the Tech Interview Handbook's list for getting unstuck: draw the problem out, solve the example by hand, come up with more examples, break the problem into smaller parts, and try common data structures one at a time, starting with a hash map.
Why 25 minutes? The Tech Interview Handbook puts a typical coding round at 30 to 45 minutes, and you need part of that for clarifying and testing. Other prep guides use different cutoffs. The exact number matters less than having one and sticking to it.
Write down why you are stuck before you open anything. “I don’t know how to avoid re-scanning the window” is far more useful than “I couldn’t do it.” That one sentence becomes your mistake log entry and tells you exactly what to look for in the solution.
Step 3: Read solutions the right way
Reading a solution is not the failure; reading it passively is. Rereading is one of the study habits that a 2013 review of learning research by John Dunlosky and colleagues, published by the Association for Psychological Science, gave a low utility rating. Use this sequence instead:
- Read for the key idea only. Stop as soon as you can state the insight in one sentence, such as “track the last index of each character so the window’s left edge can jump forward.”
- Close the tab and write the code yourself. If you get stuck again, peek at the smallest piece you need, then close it again.
- Explain every line. If you cannot say why a line is there, for example why the loop uses
lo < hiand notlo <= hi, you have not learned it yet. - Compare with your failed attempt. Find the exact moment your approach went a different way. That gap is the lesson.
- Look at one alternative. Knowing two approaches makes the trade-off discussion easy in an interview.
- Write the trigger. Which words in the prompt should have pointed you here? Add them to your pattern table from Step 1.
Step 4: Re-solve on a schedule
A green checkmark proves you solved a problem once, with the idea fresh in your mind. Solving it from a blank editor days later is what the interview tests. The same 2013 review gave its highest ratings to practice testing (pulling information from memory) and distributed practice (spacing sessions out over time). Re-solving on a schedule is both at once. The intervals below are a simple starting point rather than a research-derived formula, so stretch or compress them to fit your timeline.
| When | What to do | If you fail |
|---|---|---|
| Next day | Re-solve from scratch, no notes | Read your log entry, then re-solve again the same day |
| About 1 week later | Re-solve on a 25-minute timer | Restart the schedule from the next-day step |
| About 3 weeks later | Re-solve, then explain it out loud | Go back to the 1-week step |
Count a problem as learned only after it passes the three-week re-solve. “Problems I can re-solve” is a far more honest progress number than your total solved count.
Step 5: Keep a mistake log
A mistake log turns vague frustration into a short list of specific weaknesses. One row per problem you struggled with is enough, and a spreadsheet works fine:
| Problem | Pattern | Why I got stuck | Key insight |
|---|---|---|---|
| Daily Temperatures | Monotonic stack | Tried nested loops; did not see it as “next greater element” | Keep a stack of indices with falling temperatures and pop when a warmer day arrives |
| Koko Eating Bananas | Binary search on the answer | Searched the array instead of the range of possible speeds | If speed k works, every faster speed works too, so you can binary search the range of speeds |
Add the re-solve dates from Step 4 as extra columns. Then tag each “why” with one category:
- Did not recognize the pattern
- Picked the wrong data structure
- Off-by-one or boundary error
- Missed an edge case (empty input, duplicates, negatives, a single element)
- Correct but too slow
- Language or library gap
After 20 or 30 rows, count the tags. If most say “did not recognize the pattern,” you need more mixed practice. If most are boundary errors, slow down and dry-run before you submit. If one sub-skill keeps failing, such as binary search boundaries, practice that piece on its own with a tiny program until it is boring.
Step 6: Narrate while you solve
Interviews grade your reasoning, not only your final code. Google’s 2018 interview preparation guide for technical internship candidates asks candidates to explain their thought process and decision making, to think out loud, to start with a brute-force solution if needed and then discuss trade-offs, and to test their own code. Solving silently at midnight trains none of that.
Use the same spoken script on every practice problem:
- Restate the problem and ask about input size and edge cases.
- Walk through a small example by hand.
- Say the brute force and its time and space complexity.
- Name the bottleneck and the pattern that removes it.
- Code while saying what each block does.
- Dry-run one normal case and one edge case.
- State the final Big-O.
Recording yourself works, and so does a friend. Or practice talking through your approach in a free AI mock interview in CoPilot Interview: set the question mix to coding, and the AI interviewer reads each question aloud, you answer out loud, and every answer gets a score with what worked and what to improve.
Step 7: Move from easy to medium to hard on evidence
Staying on easies too long feels good but stalls you; jumping to hards too early just produces more stuck time. Move up when the evidence says you are ready. The thresholds below are our rules of thumb, not official benchmarks:
| Stage | Focus | Move on when |
|---|---|---|
| Easy, by topic | Basic operations on each data structure | You solve most new easies in a topic in about 15 minutes, no hints |
| Medium, by topic | One pattern at a time, four to six problems per batch | You solve a new medium in that pattern within 25 minutes about two times out of three |
| Medium, mixed | Random mediums across topics, so you have to identify the pattern yourself | You name a workable approach in the first 5 to 10 minutes most of the time |
| Hard, selectively | Problems that combine two patterns, or topics your target companies are known for | Optional for many roles |
The mixed stage is the one most people skip, and it is the one that matches a real interview: nobody tells you the topic. Topic tags are useful while you learn a pattern, so stop looking at them once you move to mixed practice.
On hards, the Red-Green-Code LeetCode blog notes that they usually need an algorithmic or mathematical insight rather than a familiar pattern. It suggests optimizing for breadth instead, mastering many topics at the medium level, and points out that hard problems are less common in real interviews.
Putting it together: a one-hour daily routine
- 10 minutes: re-solve one problem that is due from your log.
- 25 to 40 minutes: one new problem, using the time box from Step 2.
- 10 minutes: write the log entry and the trigger, then explain the solution out loud in under two minutes.
Once or twice a week, swap the new problem for a timed mixed set of two mediums, narrated from start to finish. The Tech Interview Handbook estimates about 30 hours of prep to cover the bare minimum and around 100 hours to be well prepared, so an hour a day gets you to the first number in about a month and the second in a little over three. When you are ready for a structured list, the Blind 75 works well with this routine.
Practice the explanation, not just the code
CoPilot Interview's AI mock interview reads coding questions aloud, has you talk through your approach out loud and scores each answer with what worked and what to improve. The free plan gives you 15 minutes a day with no credit card.
Try a free AI mock interviewFAQ
How long should I spend on a LeetCode problem before looking at the solution?
About 25 minutes of focused effort, then one hint, then the solution at around 40 minutes if you are still stuck. The Tech Interview Handbook puts a typical coding round at 30 to 45 minutes, so practicing inside that window builds the right pace.
Why can I solve easy LeetCode problems but not mediums?
Easies usually ask you to implement what the prompt describes, while mediums ask you to recognize which pattern applies. Learn patterns in topic batches first, then switch to mixed problem sets so you practice the recognition step itself.
Is it bad to look at LeetCode solutions?
No. Reading a solution is fine if you read for the key idea, close it, write the code yourself and re-solve the problem a few days later. Reading without re-solving is the part that does not work.
How many LeetCode problems should I do to get good?
There is no magic number, and a smaller set you can re-solve from scratch beats a large set you solved once. The Tech Interview Handbook estimates about 30 hours of prep for the bare minimum and about 100 hours to be well prepared.
Should I practice hard LeetCode problems?
Only once you are consistent on mixed mediums. For many interviews, breadth at the medium level matters more than depth on hards, but expectations vary by company and team, so check what your target role is known to ask.
Do I need to memorize LeetCode solutions?
No. Memorize the trigger and the key insight for each pattern, not the code. If you understand why each line exists, you can rebuild the code from the idea.