When I first told myself I was going to learn how to program, I knew I didn’t want to only learn how to write code. I wanted to understand why code works. For me, that meant learning the fundamentals of computer science: data structures and algorithms.
I knew it was going to be hard, but that was kind of the point. I wanted to challenge myself with something that felt intimidating. Something that would force me to slow down, think differently, and build a stronger foundation instead of just memorizing syntax and hoping for the best.
Because programming is not just about writing code that runs. It’s about learning how to think through problems.
How I approached learning DSA
I treated DSA like an actual class. I watched MIT OpenCourseWare lectures, read books like Grokking Algorithms and Introduction to Algorithms, took notes, worked through assignments, and even did quizzes.
quiz review and quizzes
I was waking up at 4 AM to watch lectures before work. Which sounds a little intense now that I’m typing it out, but honestly… I loved school. So giving myself structure made the whole thing feel more real. It wasn’t just “I should learn algorithms someday.” It became something I actually had to show up for.
My routine looked something like this:
Watch two lectures a week
Take notes
Work through assignments
Review concepts
Practice with LeetCode problems
Write everything out by hand when I got stuck
Writing things out helped me slow down. It forced me to actually read the problem, understand the inputs and outputs, and think through the approach instead of jumping straight into code.
The LeetCode Era
Ahhh, LeetCode. Stressful, humbling, weirdly fun.
I completed 100 problems, which may not sound like a lot to some people, but for me, it felt huge. I’m proud of it because I know how much effort went into every single one.
My favorite problems were graph problems.
They were also the ones that humbled me the most.
At first, graphs felt so abstract. Nodes, edges, visited sets, queues, stacks, cycles… it was a lot. But once I started recognizing the patterns, it became easier to know where to begin.
Is this a BFS problem? Is this a DFS problem? Am I tracking visited nodes? Am I looking for a path, a cycle, or connected components?
And then, right when I thought I understood graphs, another problem would humble me again.
Which honestly became part of the fun.
I liked that graph problems forced me to think visually. They made me slow down and map things out. Once I could see the shape of the problem, the solution felt less mysterious.
People would ask me what I did over the weekend, and I’d be like, “Oh, I worked on LeetCode problems.”
Which, understandably, made my friends look at me like I was a little weird.
But to me, it felt like solving a puzzle. A very frustrating puzzle, but still a puzzle. Sometimes I would stress myself out thinking about a problem, but looking back, I’m like…
Wow. I really stressed myself out for fun.
But that stress taught me something.
It taught me how to sit with confusion. It taught me how to break a problem down instead of panicking. It taught me that not knowing the answer right away doesn’t mean I’m bad at it. It just means I need to keep working through it.
What LeetCode taught me
My approach to solving problems became much more intentional over time. Instead of immediately trying to code, I started asking:
What is the input?
What is the output?
What is the problem actually asking?
Are there any constraints?
What patterns do I recognize?
Why would I choose one approach over another?
Then I would try a solution, test it, and figure out why it was right or wrong.
That process mattered more than getting the answer quickly.The more problems I practiced, the more I realized that problem solving is not magic. It’s a series of small steps. You break the problem down, identify what you know, test your assumptions, adjust, and keep going.And honestly, that applies to so many things beyond LeetCode.
When something breaks in my own code, I’m doing the same thing. I’m asking: What was supposed to happen? What actually happened? Where did it go wrong? What can I test? What do I know so far?
But it also applies outside of programming.
Learning DSA taught me how to approach hard things with more patience. It taught me how to stay curious when I’m confused, how to keep trying when the answer isn’t obvious, and how to trust the process of breaking something big into smaller pieces.
That’s probably my biggest takeaway.
DSA didn’t just teach me algorithms.
It taught me how to think.