I used to take 90 minutes to solve Medium problems. Sometimes longer. I'd stare at the screen, try random approaches, and eventually Google the solution.
After 6 months of deliberate practice, I got that down to 25-30 minutes for most Mediums. The difference wasn't raw intelligence—it was technique.
Speed matters in interviews. You typically get 45 minutes per problem, including discussion. If you can't reach a working solution in 25-30 minutes, you won't have time for optimization, edge cases, or follow-up questions.
Here's what I learned about getting faster—and what doesn't work.
If you can't start problems (blank page syndrome):
You're missing pattern recognition. Focus on learning patterns, not grinding random problems.
If you start okay but get stuck midway:
You're probably overcomplicating. Practice the "brute force first, optimize second" approach.
If you solve problems but too slowly:
Your implementation speed is the bottleneck. Practice typing solutions without looking anything up.
If you run out of time debugging:
You're writing buggy code. Slow down during implementation to prevent errors, not fix them.
If you freeze when the problem is novel:
You need more pattern exposure. 100+ curated problems, not random grinding.
| Difficulty | Target Time | What That Includes |
|---|---|---|
| Easy | 10-15 min | Understand, code, test, discuss complexity |
| Medium | 20-30 min | Understand, approach, code, test, discuss |
| Hard | 35-45 min | Same, but interviewer often helps guide you |
For a 25-minute Medium problem:
| Phase | Time | What's Happening |
|---|---|---|
| Read + Understand | 2-3 min | Clarify inputs, outputs, constraints |
| Think + Approach | 5-7 min | Identify pattern, discuss with interviewer |
| Code | 10-12 min | Implement solution |
| Test + Debug | 5-8 min | Walk through example, fix bugs |
The key insight: If your "Think" phase takes 15+ minutes, you'll run out of time for implementation. Pattern recognition needs to be fast.
Simple tracking method:
Do this for 20 problems. Calculate your average by difficulty. That's your baseline.
The symptom:
You read a problem and have no idea how to start. You try random approaches—brute force loops, hoping something works.
Why it happens:
You haven't internalized the common patterns. There are ~14-16 core patterns that appear in 90% of interview problems. Without them, every problem feels new.
The fix:
Study patterns explicitly. NeetCode organizes problems by pattern. Do 5-10 problems per pattern before moving on.
The core patterns to know:
Time to fix: 4-6 weeks of pattern-focused practice
The symptom:
You spend 20 minutes trying to find the optimal solution without writing any code. Then you run out of time.
Why it happens:
You're trying to be smart instead of systematic. In interviews, a working brute force is better than an incomplete optimal solution.
The fix:
Always start with brute force. Code it. Then optimize if time permits.
The process:
Why this works:
The symptom:
You know the approach but take 20+ minutes to code it. You look things up (syntax, library functions). You make typos. You write code, then rewrite it.
Why it happens:
Implementation isn't muscle memory yet. You're thinking about syntax instead of logic.
The fix:
Practice typing solutions from scratch. After solving a problem, close the solution and re-implement it from memory. Do this until it's automatic.
The drill:
Focus areas for speed:
The symptom:
You write code, it fails, and you spend 15+ minutes figuring out why. Off-by-one errors. Wrong variable names. Logic bugs.
Why it happens:
You're writing fast but sloppy. Then you pay the price in debugging.
The fix:
Slow down during implementation. Check each line as you write. It's faster to write carefully once than to debug carelessly twice.
Specific techniques:
i, j for everything)The symptom:
You spend 5-10 minutes re-reading the problem, missing constraints, misunderstanding what's being asked.
Why it happens:
You're reading passively instead of actively extracting information.
The fix:
Use a reading checklist:
Time saved: 2-3 minutes per problem (adds up over an interview)
The practice:
Before coding, explicitly name the pattern: "This is a sliding window problem" or "This is backtracking."
Why it works:
Naming the pattern narrows your search space. Instead of trying everything, you're applying a known template.
The drill:
For 2 weeks, before each problem, write down:
Then solve the problem. Review: was your pattern guess correct?
The practice:
Give yourself exactly 5 minutes to identify an approach. If you don't have one, fall back to brute force.
Why it works:
Prevents the trap of thinking forever without coding. Action beats paralysis.
The rule:
After the time box, you must have SOMETHING to code—even if suboptimal.
The practice:
Use the same structure for every problem:
1. UNDERSTAND (2-3 min)
- What are inputs? Outputs?
- What are constraints?
- Walk through one example
2. APPROACH (5 min max)
- What pattern applies?
- What's the brute force?
- What's the optimal?
- State time/space complexity
3. CODE (10-15 min)
- Write clean, commented code
- Handle edge cases first
4. TEST (5 min)
- Trace through with example
- Test edge cases
- State complexity againWhy it works:
Structure prevents wandering. You always know what step you're in and when to move on.
The practice:
Re-implement solved problems without looking at the solution.
The specific drill:
Target: Implement common patterns in under 5 minutes without looking anything up.
Patterns to speed-drill:
The practice:
Focus on one pattern or problem type for a session. Don't jump between trees, dp, and graphs in the same hour.
Why it works:
Your brain builds pattern recognition faster when problems are clustered. Switching destroys momentum.
The practice structure:
Goal: Establish baseline and start pattern learning
Activities:
Problems per day: 3-4 (quality over quantity)
Tracking: Log time for each problem
Goal: Get faster at coding known patterns
Activities:
The rule: When time runs out, stop. Review the solution. Re-implement tomorrow.
Problems per day: 4-5
Goal: Get faster at identifying the right approach
Activities:
Problems per day: 5-6
Focus: If pattern selection takes >5 min, you need more pattern exposure (not more thinking time)
Goal: Put it together under interview conditions
Activities:
Time targets:
Tracking: Compare to Week 1 baseline
What happens:
"I'll just do 500 LeetCode problems and I'll get fast."
Why it fails:
Random problems give random practice. You don't build pattern recognition because patterns aren't clustered.
The fix:
Curated, pattern-organized practice. NeetCode 150 or similar.
What happens:
"I'll just practice until I'm ready." You solve problems with no clock.
Why it fails:
You don't know your actual speed. Interview day is the first time you're under time pressure.
The fix:
Always time yourself. Use the benchmarks above.
What happens:
"I'll just Google how to implement a heap real quick."
Why it fails:
You can't Google during interviews. If you practice with lookups, you'll panic without them.
The fix:
Practice without references. If you can't remember, complete the problem, then drill that gap.
What happens:
You solve a problem, move on, never revisit it.
Why it fails:
You remember the solution, not the pattern. You can't generalize.
The fix:
Re-implement solved problems. Spaced repetition builds speed.
Short answer: 20-30 minutes for interview readiness.
Breakdown:
If you're consistently at 40+ minutes, focus on pattern recognition first.
Short answer: You're probably comparing to people who have solved similar problems before.
When someone solves a problem in 10 minutes, they've likely seen the pattern before. Speed comes from recognition, not intelligence.
The fix: Solve more problems in clustered patterns. Speed will come.
Short answer: Yes, but loosely.
When learning a new pattern, give yourself extra time. But still track:
This tells you what to practice.
Short answer: For most interviews, yes.
Hard problems rarely appear in interviews (they're too hard to evaluate in 45 min). Focus on Medium-level speed first.
Exceptions: Staff+ roles, specific companies known for Hard problems.
Short answer: Re-implement solved problems from memory.
The drill:
Do this for 10-15 core problems. Implementation speed will jump significantly.
After going from 90-minute Mediums to 25-minute Mediums, here's what actually worked:
Mistake #1: Grinding random problems
Mistake #2: Never timing myself
Mistake #3: Looking things up during practice
| Where I Started | Where I Ended | Timeframe |
|---|---|---|
| Easy: 30 min | Easy: 10 min | 4 weeks |
| Medium: 90 min | Medium: 25-30 min | 8 weeks |
| Hard: Often incomplete | Hard: Brute force + partial | 12 weeks |
If you're just starting:
Time yourself on 10 problems to get a baseline. Then follow the 4-week plan.
If Easy problems take 30+ min:
You need fundamental pattern practice, not speed drills.
If you know approaches but code slowly:
Focus on implementation re-drilling.
If you get stuck on novel problems:
You need more pattern exposure (100+ curated problems).
If you debug forever:
Slow down during implementation. Prevention beats debugging.
Last updated: January 13, 2026. Based on personal speed improvement journey (6 months of deliberate practice), timing data from 200+ problems, and feedback from engineers who improved their interview speed. Your improvement rate may vary based on starting point.
LeetCopilot is a free browser extension that enhances your LeetCode practice with AI-powered hints, personalized study notes, and realistic mock interviews — all designed to accelerate your coding interview preparation.
Also compatible with Edge, Brave, and Opera
Add to Chrome for free