Intro
Initially, when I started studying DSA I made a lot of mistakes that made me quit DSA after a week of “solving” problems.
Some of the mistakes that I made:
- Picking random problems from the list: Picking a Mid Tree question without knowing what a Tree is
- Jumping straight to coding without having an understanding of the problem: I read the problem once and tried to brute-force a solution without understanding what the problem is asking for.
- Not spending enough time trying to solve the problem: On problems that I cannot solve, I copy-pasted the solution and called it a day
A year later, I decided that it is finally time to study DSA if I want to do anything different than changing the color of a header and centering a div. Therefore, I started again, this time with a plan (if you fail to plan, you plan to fail)
My (new) approach of solving DSA problems
My new plan consisted of four simple things:
Study problems by topic and difficulty
My initial step was to select a specific topic, such as easy array problems, and further narrow them down by choosing ones with a higher acceptance rate (since those tend to be more straightforward). This methodical approach helped me steadily build both my confidence and my ability to spot patterns related to each topic. Once I’d completed about 30 to 50 questions in one area, I moved on to another; for example, tackling easy string problems using the same strategy.
I only considered a problem “solved” if I managed to pass it on my first try; otherwise, I added it to a separate list to revisit and review later.
Write on paper
Personally, I’ve found that putting pen to paper makes a huge difference in truly understanding what I’m learning, so I made it a regular habit. My process starts by copying down the problem and its examples by hand. Then, I carefully work through each example step by step, looking for patterns, and I try to describe those patterns in my own words. Once the problem makes sense, I write out my code solution on paper first. After finishing the solution, I walk through the examples again to manually check my logic and hunt for any errors. Only then do I type my code into LeetCode and submit it. If my answer is wrong, I return to paper and debug using the failing test case.
If you find yourself stuck on problem after spending more than 30 minutes on it, take the time to look at the provided solution and focus on understanding the reasoning behind each step. Make sure to write down the solution in your notes, and walk through the sample examples to see how the approach actually works in practice.
Pattern list
As I work through several problems within a topic, I begin to recognize recurring patterns. Whenever I notice one, I make sure to record it in a dedicated list of patterns. Later, if I get stuck on a problem, I refer back to this list for guidance.
Spaced repetion & The list with failed problems
I try to make it a daily routine to attempt at least one new problem and also revisit a previously solved one (though I’m not always consistent). From time to time, I review the list of problems I’ve gotten wrong. If I notice a certain pattern appearing repeatedly among my mistakes, I make a point to focus my study on that area—for example, right now, I’m finding topological sort particularly challenging.
Key takeaways after solving 500+ problems
The journey of learning DSA is a long-term commitment, so be patient and allow yourself the space to progress gradually. Embrace the process of writing things out by hand; it can genuinely deepen your understanding. Don’t hesitate to supplement your learning with additional materials, such as Beyond Cracking The Coding Interview book, which may introduce you to new strategies or patterns.