For most junior and mid-level interviews, 150 to 250 well-understood problems, organised by pattern, are enough. The number matters far less than whether you can recognise the pattern, explain your approach aloud and solve a similar problem a week later without help.
What people tell me
I have solved a lot of problems, somewhere over a hundred, but when I see a new one I still often do not know where to start. Some people say you need 500 or even 1,000 problems, which feels impossible alongside everything else. I also catch myself looking at the solution after a few minutes and then moving on. I want to know how many is actually enough and how to practise so it sticks.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- For most junior and mid-level interviews, 150 to 250 problems covered properly by pattern is enough.
- The count matters less than retention: can you solve a similar problem a week later without help?
- Practise by pattern, with a timer, and say your approach aloud as if in an interview.
- When you look at a solution, re-solve the problem from scratch later. Otherwise it does not count.
- Track problems you could not solve and revisit them on a schedule.
The number people quote is the wrong target
You will see people online with 800 or 1,500 problems solved. Some of them are genuinely strong. Many solved hundreds of problems in a way that did not stick: glance at the problem, get stuck, read the solution, submit, move on. That builds a big number and very little skill.
For most junior and mid-level interviews, somewhere around 150 to 250 problems, chosen to cover the common patterns and practised properly, is enough. Some very competitive companies may push you towards the higher end or beyond, but even there, quality beats quantity.
If you are still at the stage where you cannot solve easy problems at all, start with How do I start DSA when I cannot solve problems? first. This answer assumes you have the basics and want to practise well.
What "enough" actually looks like
Instead of a count, use these checks. You have practised enough when:
- Given a new medium problem, you can name the likely pattern within five minutes most of the time.
- You can explain a brute force and an improved approach before writing code.
- You solve most mediums in your target patterns within 30 to 40 minutes.
- You can re-solve a problem you did two weeks ago without looking anything up.
- You can state time and space complexity and justify it.
Practise by pattern, not at random
Random problems feel like progress but make patterns hard to see. Group your practice:
| Pattern | Rough number of problems | Signals in the problem |
|---|---|---|
| Arrays and hashing | 15 to 20 | Counting, lookups, duplicates |
| Two pointers | 10 to 15 | Sorted input, pairs, in-place changes |
| Sliding window | 10 to 15 | Contiguous subarray or substring, "longest" or "at most" |
| Binary search | 10 to 15 | Sorted data, or "minimum value that works" |
| Stacks and queues | 10 | Matching brackets, next greater element |
| Linked lists | 10 | Pointer manipulation, cycles |
| Trees (BFS and DFS) | 20 to 25 | Hierarchies, levels, paths |
| Graphs | 15 to 20 | Connections, grids, shortest paths |
| Heaps | 10 | Top k, merging sorted items |
| Backtracking | 10 | All combinations or permutations |
| Dynamic programming | 20 to 30 | Overlapping choices, "number of ways", "minimum cost" |
| Intervals and greedy | 10 to 15 | Scheduling, merging ranges |
That adds up to roughly 150 to 200 problems. Fifteen problem shapes and the move that solves each explains how to recognise these shapes quickly.
How to practise one problem properly
- Read and restate the problem in your own words, including edge cases.
- Set a timer for 25 to 30 minutes on a medium.
- Say your approach aloud before coding: brute force first, then an improvement.
- Code it cleanly, then test with a normal case and an edge case.
- If you are stuck at the timer, read only the approach, not the code, and try again.
- If you still need the full solution, read it, close it, and write it yourself from memory.
- Log it: pattern, what you missed, and a date to retry.
- Retry after three days and again after two weeks, from scratch.
Step 8 is the one most people skip, and it is why their count goes up while their skill does not.
A simple tracking sheet
Keep a spreadsheet with these columns: problem, pattern, solved alone (yes or no), time taken, what I missed, retry date. Every week, sort by retry date and redo the ones that are due. After a month you will see which patterns are weak, and that tells you where the next problems should come from.
A six-week plan
| Week | Focus | Target |
|---|---|---|
| 1 | Arrays, hashing, two pointers | 15 problems, all logged |
| 2 | Sliding window, binary search, stacks | 15 problems plus retries from week 1 |
| 3 | Linked lists, trees | 15 problems plus retries |
| 4 | Graphs, heaps | 15 problems plus retries |
| 5 | Dynamic programming basics, backtracking | 12 to 15 problems plus retries |
| 6 | Mixed timed sets, spoken aloud, two mock interviews | 10 new problems and a full review of weak patterns |
That is around 85 to 90 new problems in six weeks, plus retries. Repeat the cycle with harder problems in your weak patterns, and you will be in the 150 to 250 range with far better retention than 400 rushed ones. The free DSA and problem solving roadmap covers the same patterns in order.
Common mistakes
- Reading the solution after two minutes. Struggle is where the learning happens. Give yourself real time.
- Solving silently. In interviews you must explain. Practise talking from the start.
- Only doing easy problems because they feel good. Most interviews are mostly mediums.
- Ignoring retention. A problem you cannot redo is not really solved.
- Grinding problems while ignoring projects. Most roles still ask about what you have built.
If you are still stuck
If you practise well at home but freeze in interviews, I get interviews but keep failing the technical round covers that gap specifically. For a practice plan built around your target companies and weak patterns, join Sefism; it is free to learn, you get credits on joining and your first roadmap is free. As a member you can book a 1:1 session for a mock problem-solving round and honest feedback.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.