Skip to main content
Study StrategyPreparationPersonal Experience

5 LeetCode Prep Mistakes I Made — and What I'd Do Differently

· 7 min read

Syed Peera Saheb

Software Engineer · 5+ years in tech interviews

Summary

After 8 months and 500+ problems, here are the five prep mistakes that actually cost me interviews — and the exact fixes.

Mistake 1 — Optimizing problems solved per week

My first four months of prep were a treadmill: 25–30 problems a week, moving on the moment my solution passed. The result was that I could solve problems I had seen and froze on everything else. I changed to a review-first workflow: after each problem I wrote one sentence on the pattern, the trigger keywords, and the one trap I hit. I also re-solved each problem a week later without looking at my old code. That single change — forced recall — did more for my interview readiness than the previous four months of volume.

Mistake 2 — Grinding Hard problems too early

I spent my second month on LeetCode Hards because they felt impressive. This was backwards. Hards are mostly Medium patterns stacked together; without automatic Medium fluency, I could not even recognize the sub-problems. The fix was a 3:1 ratio — three Easy/Medium solves for every Hard attempt — and only touching a Hard once its underlying patterns were fluent. Interview performance is built on automatic pattern recognition, which only comes from volume at the right difficulty.

Mistake 3 — Never timing myself

I practiced untimed for months. My first mock interview fell apart because I spent 25 minutes on a problem I could have solved in 12 — no timer discipline, no sense of when to abandon a dead-end approach. From then on every practice session ran on a timer: 25 minutes for Medium, 40 for Hard, and I treated "time up" as a data point, not a failure. Learning to cut losses and switch approaches under the clock is a skill, and it only develops with a clock present.

Mistake 4 — Solving silently

I did almost all my practice in silence. When a real interviewer asks "what are you thinking?" mid-solution, silence reads as stuck. I forced myself to narrate every practice solve — stating my plan, the pattern I was considering, and why — even when solving alone felt unnatural. It took about ten sessions to stop feeling silly, and the payoff was immediate: interviewers stopped prompting me because the narration answered their questions before they asked.

Mistake 5 — Ignoring the final review week

Before my first loop, I used the last week to attempt new Hard problems, which mostly demoralized me. The week before an interview should be about consolidation: re-read your problem log, re-solve your marked weak spots, run two mocks, and stop. Fresh problems the night before an interview only add noise. The confidence that comes from reviewing a hundred problems you genuinely understand beats any last-minute discovery.

Frequently Asked Questions

Is it better to solve many problems or fewer with deep review?
Fewer with deep review — decisively. The mistake that cost me the most was measuring progress in problems solved per week. Once I switched to 2–3 problems a day with a written one-line summary of the pattern and why it applied, my performance in mock interviews improved within three weeks. Depth of review beats volume of solves.
When should you start mock interviews?
Way earlier than you think. My rule now: start mock interviews at 50% of your planned prep time, not at the end. Mock interviews expose the two skills that grinding alone never trains — talking while coding and handling the clock. Do at least one mock per week in the second half of your prep.
How many problems is enough before applying to top companies?
There is no magic number, but a useful benchmark: 75–150 problems across all core patterns, with the ability to recognize the pattern within a minute. Solving 500+ problems without pattern structure left me worse off than friends who solved 120 with a system. Focus on transferable recognition, not volume.

Syed Peera Saheb

Software Engineer · 5+ years · ServiceNow

Software engineer with hands-on experience passing technical interviews at top tech companies. Built Coding Prep Guide to share the pattern-first prep strategy that actually works. Writes about DSA, system design, and interview strategy.

Buy me a coffee