How I Solve Any Algorithm Problem

Let me guess: you open an algorithm question, read it three times, and still have no idea what it wants from you. You stare at the screen, Google it, find a wall of code on StackOverflow, and somehow feel even worse.
Same.
I used to feel like I just wasn't "wired" for this stuff. But over time, I figured out a process that actually works for me. It's not perfect, and I'm still learning, but this five-step method helped me go from stuck and stressed to solving algorithm problems with a bit more confidence (and way less doomscrolling).
Here's exactly how I approach any algorithm exercise now:
Step 1: Visualize it (seriously, stop reading)
The biggest mistake I made was trying to understand everything by reading. I'd read the problem over and over expecting it to magically make sense. It rarely did.
Now I immediately try to draw it , not fancy diagrams, just scribbles. Arrows, boxes, little notes like "here's where we loop," or "this updates each round." If I'm still confused (which happens a lot), I use a tool called Reelith. It lets me turn my notes into a short animated explainer video, with AI narration and visuals. For some reason, hearing the steps out loud while watching them makes everything click faster.
It’s like having someone walk me through the logic, and it works especially well for harder stuff like dynamic programming or graph traversal.
Step 2: Break the problem into micro-steps
Every hard algorithm problem looks scary as one giant thing. So I break it into tiny chunks:
What’s the input? (List? Graph? Tree?)
What’s the goal? (Max? Count? Sort?)
What do I do at each step? (Loop, compare, update?)
What’s the data structure doing the heavy lifting? (Queue, stack, set?)
Once I know those, I write a super simplified version in plain English.
Example:
Problem: Find the longest increasing subsequence.
Breakdown:
Loop through the array
For each number, check what came before it
Track the length of the best sequence ending at that index
Suddenly, the giant wall of logic becomes three smaller ideas I can handle.
Step 3: Test it on a tiny example
Forget their giant inputs. I make my own baby example:
A 3-node graph
A 4-number array
A short string
Then I walk through it manually, step-by-step. I even write down what variables change. It's boring, but it's gold. Every time I do this, I catch something I didn't think of before — a hidden edge case, a loop that runs one too many times, a wrong base case, etc.
Step 4: Code it, don’t just plan it
I used to plan forever, then panic when I started coding.
Now I jump into code early. I write the basic structure, then fill in one piece at a time. I print everything: indices, arrays, intermediate values. Even stuff like:
print("i =", i)
print("dp =", dp)
It looks messy, but I can actually see what my algorithm is doing. If something’s off, the debug output tells me exactly where it went wrong.
Step 5: A LOT of debug
Once it “works,” I don’t stop. I start throwing weird test cases at it:
Empty input
One element
All equal values
Negative numbers
Giant inputs
This is where I usually catch the final bugs. But more importantly, fixing those edge cases helps me understand the algorithm way better. I see where it breaks and why, and that’s what really makes the learning stick.
Final Thoughts: I’m still not a genius at algorithms, and I still mess up a lot. But this system saved me from giving up, and tools like Reelith really helped me “see” what was going on when nothing made sense on paper.
Hope this helps someone else out there who's tired of feeling stuck.
If you’ve got your own system for tackling algorithm problems, I’d love to hear it!
Subscribe to my newsletter
Read articles from Houssem Rabah directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
