Stop solving random problems. Learn one data structure at a time, then study problems by pattern so each question points you to an approach. Two focused hours on weekdays for eight to ten weeks, with re-solving and spaced review, is enough to go from stuck to steady.
What people tell me
I know a programming language, but when I open a LeetCode problem I have no idea where to start, and even after reading solutions I cannot tell which method a question needs. I want to know how many hours a day it takes to get comfortable in about two months. Honestly DSA also feels boring, and I am not sure whether I should focus on it or on development projects first.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Being stuck at the start is normal. Pattern recognition is a learnable skill, not a talent you either have or lack.
- Learn in this order: language basics, complexity, one data structure at a time, then patterns.
- Solve 4 to 6 problems per pattern, then re-solve them a few days later without looking.
- Around 2 hours on weekdays and 4 on weekends for 8 to 10 weeks covers the core for most people starting fresh.
- Do DSA and development together: DSA for screening rounds, projects for proof and motivation.
Why it feels impossible at first
Almost everyone opens their first medium problem, stares at it, reads the solution, understands it, and then cannot solve the next one. That is not a sign you are bad at this. It happens because problem solving has two separate skills: knowing the tools (data structures and techniques) and recognising which tool a problem is asking for. Most beginners try to learn the second before the first, by grinding random questions.
Fix the order and it gets dramatically easier.
The learning order that works
- Language fluency. Loops, conditions, functions, recursion, and your language's lists, sets, dictionaries or maps. If you still look up how to sort a list, start here.
- Complexity. Big O for time and space, well enough to compare two approaches.
- Core data structures, one at a time. Arrays and strings, hash maps and sets, linked lists, stacks and queues, trees, heaps, graphs.
- Patterns. Reusable approaches that map problem shapes to solutions.
- Mixed practice. Random problems only once patterns are familiar, so you practise recognition.
Patterns: how you know which method to use
A pattern is a signal in the problem statement that suggests an approach. Once you know around fifteen of them, most interview-style questions stop looking unfamiliar.
| If the problem says or implies | Try this pattern |
|---|---|
| Sorted array, find a pair or triplet | Two pointers |
| Longest or shortest contiguous subarray or substring | Sliding window |
| Sorted input, or "minimum value that satisfies a condition" | Binary search |
| Count or look up seen elements quickly | Hash map or set |
| Next greater or smaller element, matching brackets | Stack (monotonic stack) |
| Top K, K-th largest, merging sorted lists | Heap |
| Shortest path in an unweighted grid or graph | BFS |
| All paths, connected regions, tree traversal | DFS |
| All combinations, permutations, subsets | Backtracking |
| Overlapping subproblems, "number of ways", min or max cost | Dynamic programming |
| Detect a cycle, find the middle of a linked list | Fast and slow pointers |
| Overlapping ranges, meeting rooms | Sort then merge intervals |
| Dependencies, ordering of tasks | Topological sort |
Use the pattern and topic tags on LeetCode to find problems for each one, and curated lists such as Blind 75 or NeetCode 150 once you have the basics.
How to practise a single problem
- Read the problem, write two examples and one edge case.
- Spend up to 20 minutes trying. Write the brute-force approach even if it is slow.
- If stuck, read only a hint or the approach, not the code, and try again.
- If still stuck, study the full solution until you can explain every line.
- Re-solve it from scratch after two or three days. This is the step most people skip, and it is where learning actually sticks.
- Keep a short note per problem: pattern, key insight, mistake you made.
How many hours, and for how long
For someone who knows a language but is new to DSA:
| Weeks | Focus | Weekday time | Weekend time |
|---|---|---|---|
| 1 to 2 | Complexity, arrays, strings, hash maps | 2 hours | 4 hours |
| 3 to 4 | Two pointers, sliding window, binary search, stacks | 2 hours | 4 hours |
| 5 to 6 | Linked lists, trees, BFS and DFS, heaps | 2 hours | 4 hours |
| 7 to 8 | Backtracking, graphs, introductory dynamic programming | 2 hours | 4 hours |
| 9 to 10 | Mixed timed practice and re-solving weak topics | 2 hours | 4 hours |
If you are revising rather than starting fresh, you can compress this. The hours matter less than focus: two hours with your phone in another room beats five with notifications on.
DSA or development first?
Both, in parallel. Screening rounds at many companies still use problem solving, so ignoring it closes doors. But projects are what you talk about in interviews and what keep you motivated. A simple split works well: weekdays for DSA, weekends for your project, or the reverse if that suits your energy.
What to do when it feels boring
- Track visible progress. A streak calendar or a list of patterns you now recognise turns vague effort into something you can see.
- Practise with a friend and explain solutions to each other. Teaching is more engaging than reading.
- Connect it to real code. When you use a hash map to fix a slow lookup in your project, DSA stops feeling abstract.
- Keep sessions short and frequent. Boredom often means the session is too long, not that the subject is wrong for you.
If you are still stuck
The full list of problem shapes with worked reasoning is in Fifteen problem shapes and the move that solves each, and Choosing a data structure is choosing what to make cheap explains the thinking behind picking one. Roadmaps and practice resources are in the resource library. If consistency is the real issue, book a free 1:1 session and we can build a plan you will actually follow.
Was this answer helpful?
Read next
- Fifteen Problem Shapes and the Move That Solves EachThe usual way to learn algorithms is to work through a long list of problems and hope something generalises, which leaves most people with a hundred solutions memorised and no idea what to do with the hundred and first. There are perhaps a dozen shapes of problem, each with a move that usually works. Fifteen of those shapes and how to recognise them.
- Choosing a Data Structure Is Choosing What to Make CheapMost people learn data structures as a list of things to implement, forget nearly all of it, and go back to using an array for everything. Implementation is the least transferable part: you will implement a hash map approximately never and choose between one and something else roughly every second week. Twelve pairings for making that choice.
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 to X and Instagram followers and university students. Prefer to talk? A free call works too.