Approach every learning problem with the assumption that you truly do not know. It’s crucial to prevent existing knowledge or past experience from subtly interfering with the learning process. While this mindset can be challenging to adopt, it’s absolutely essential for achieving a genuine paradigm shift and building profound, unshakeable intuition.
Forget just “learning to code”—that’s a foundation I’ve built and honed over years of rapid development and pragmatic problem-solving. I identify deeply with engineers who possess a strong sense of accomplishment about their trajectory. We’ve successfully built applications, navigated complex problems by learning on the fly, and skillfully marshalled resources to deliver. With over a decade of coding experience, I too felt confident in my ability to tackle almost any challenge.
Then, I found myself at a crossroads. I had to confront a reality that shook my confidence: I was not as prepared as I thought when it came to data structures and algorithms (DSA). My coding journey had been more about improvisation than mastery. I had become adept at finding quick fixes, but that wasn’t enough for the next level — Google, Amazon, Netflix, Pinterest, the FAANG interview circuit.
This was a different animal: LeetCode. DSA. Timed algorithmic problems that didn’t just test knowledge—they exposed gaps. Deep, foundational ones.
It often took me several minutes just to understand what a problem was asking—let alone come up with a solution in the time allowed. Needless to say, it felt completely out of reach. I felt stuck, frustrated, even ashamed. The usual tricks—Googling solutions, scanning tutorials, checking syntax examples, or browsing Stack Overflow—weren’t going to cut it anymore. I needed to confront the question that had been lurking in the back of my mind:
How do I truly learn data structures and algorithms?
That was the question. And this—this is the journey of answering it.
Understanding the “Why” Behind the Ordeal
What I realized was that my limitations in DSA weren’t just technical—they were psychological. Over the years, I had developed habits that worked in the short term: looking up quick solutions, learning just enough to get things working, and relying on improvisation under pressure. But those habits created blind spots—especially when it came to solving problems from first principles.
It was humbling. With more than a decade of experience behind me, I didn’t expect to feel lost tackling “fundamental problems”. But that’s exactly what happened. I felt the weight of imposter syndrome—not because I hadn’t worked hard, but because I had sidestepped parts of the journey that now mattered most. The confidence I once had started to feel shaky. My learning had gaps, and I could no longer ignore them.
While I deeply resonate with the frustration many experienced developers face when confronted with LeetCode-esque obstacles, I now clearly understand why big tech emphasizes candidates mastering these concepts. Being fortunate enough to work at Google XWF gives me firsthand insight into how systems are built at scale and the incredible challenges developers face.
A common complaint among engineers is that in their actual jobs, they never “use” DSA—they don’t reverse linked lists or perform binary searches day-to-day. This is absolutely true, but it often masks a deeper ignorance: you simply cannot use what you don’t truly know. To build software that performs at the highest level, these concepts need to become second nature—almost trivial. Like my past self, many developers tend to build very hacky software that simply wouldn’t make the cut if the requirement is to engineer systems that literally drive the world. You might get away with that in environments of less consequence, but for FAANG-level companies, a misstep isn’t just a bug; it’s a global catastrophe.
It’s not that you’ll use these exact algorithms daily—but when you do need them, or their principles, your ability to wield them fluidly and with confidence is what separates an average developer from a world-class engineer. DSA becomes a thinking tool, not just a coding trick.
Most developers do not use DSA in their day-to-day work, not because they don’t need it but because they don’t know it well enough to recognize when they do, should or must.
Following Higher Minds
The very first step on this path was embracing humility. I consciously decided to stop trusting my immediate instinct, precisely because that instinct had been built on shaky ground. Instead, I committed to meticulously following along, step-by-step, with the solutions provided by trusted books and instructors—replicating their logic, their exact code, and their methodical flow.
This wasn’t merely about solving problems; it was about systematically retraining my brain. My goal wasn’t to invent clever answers from scratch, but rather to intimately understand how truly clever solutions are meticulously constructed. And in this deliberate process, slowly but surely, I felt a profound shift begin.
Back to the Way I Learned Math
This shift in approach echoed my high school experience with mathematics. While ‘regular’ math often emphasized memorizing and applying formulas, ‘further mathematics’ was where I truly thrived. There, we delved into the underlying theory, deriving principles, deducing consequences, and exploring identities with a profound sense of play.
This, I realized, is precisely what DSA should be. Without understanding the fundamental root of a solution, even the seemingly trivial becomes unnecessarily difficult. Memorization, in this context, only leads to fragility; you don’t build genuine confidence—you cultivate dependence. But with true insight, everything simply clicks into place.
DSA, much like further mathematics, rdoesn’t reward rote pattern matching, but for truly grasping the ‘why’ that underpins the ‘how.’
Close the Conceptual Gaps
Back in the day, when developing my mathematical intuition, I never accepted solutions without understanding the ‘why and the how’ behind them. I had to know why the formula worked, why the theorem held true, and why the proof was structured that way. This was the essence of learning—an exploration of ideas, not just rote memorization. Later on, I was able to solve compound problems while skipping several steps, because I understood the underlying principles so well that I could intuitively fill in the gaps.
As I embarked on this journey of re-learning DSA, I immediately began to notice persistent conceptual gaps. Even with the aid of helpful visualizations, it was often difficult to discern what was truly unfolding within a problem’s logic. One particular moment, while practicing matrix rotation, vividly illustrated this.
Initially, I learned the ‘trick’: transpose followed by reverse. Yet, the underlying reason why this worked remained elusive until I witnessed a clear animation. Later, when tackling the layer-by-layer rotation method, a similar question vexed me: ‘Why do we loop n/2 times?’ This crucial detail wasn’t explicitly explained, and I found myself wrestling with that single question for days.
I tried simpler problems. I stepped away from my desk. There were even moments I felt like quitting altogether. But I didn’t. I held on because I knew from past experience that leaving challenges unresolved slowly erodes confidence, while pushing through them—even if agonizingly slow—is precisely how true confidence is forged.
Eventually, the solution materialized. The n/2 iterations? They directly correspond to the number of concentric layers present within the matrix. It wasn’t magic; it was pure deduction. That single realization fundamentally changed my perspective, marking a significant gain in insight.
Slow is Smooth, Smooth is Fast
A principle shared by a trainer I deeply admire, Alvin from Structly, resonated profoundly: “If the transition from one idea to another isn’t smooth, then that gap absolutely has to be filled.”
That wisdom stuck with me. From that point forward, there would be no more giant leaps. Only logical, visible steps—like diligently climbing a staircase, rather than attempting to jump a chasm. This precise, step-by-step approach echoed a timeless maxim: slow is smooth, and smooth is fast.
And so, my approach began to transform:
- From rushing to reasoning
- From copying to comprehending
- From pattern-hunting to insight-building
This transformation is far from easy. But, unequivocally, it is worth every ounce of effort.
Reverse Leetcoding and Rewiring Intuition
To solidify this new mindset, I entirely shifted my practical approach. Instead of attempting to solve random LeetCode problems ‘cold,’ I began what I’ve come to call ‘reverse Leetcoding.’
My method involves meticulously going through hundreds of problems, studying their solutions with extreme care. I take detailed notes, ensure I understand every single step, and then meticulously commit these insights to a personal repository, which you can find here: 👉 github.com/eiakoji-me/dsa-fundamentals-01
The core idea is straightforward: don’t waste valuable learning time being constantly stuck. If I don’t yet possess the knowledge to solve a problem effectively, I prioritize studying the most optimal solution. Then, at a later stage, I return to re-implement it myself—now infused with my own developing style, intuition, and unique flavor.
This deliberate, structured approach is working. Slowly, yet undeniably, the intuition is forming. I can now clearly discern the logical path from a solution’s conceptual understanding to its precise code implementation. The pervasive fuzziness that once clouded my understanding is steadily dissipating.
My advice to others embarking on this path is simple: don’t aim to solve a thousand random LeetCode problems. Instead, focus rigorously on learning the fundamentals. Dedicate time to studying core algorithm theory. Engage with carefully guided exercises. And most importantly, always strive to understand the ‘why’ before you even attempt the ‘how.’
LeetCode, remember, is just one valuable tool among many. Platforms like HackerRank, Codeforces, and AtCoder offer numerous variants for practice. The true key to mastery lies in depth of understanding, not sheer volume of problems attempted.
For me, personally, time is a critical constraint. I’m already engaged in active interview processes with companies like Google and Amazon. This is my decisive shot, and therefore, my strategy must be fast, incredibly precise, and highly targeted.
That encapsulates the immense challenge—and the deliberate, focused path I have chosen to overcome it. Above everything, I’m excited to have found the will and the way.
Unburdened by the Old, Liberated by the New
This journey has not just been about mastering DSA. It’s been about confronting who I had become as a learner: someone quick to patch, reluctant to pause, and afraid to feel incompetent. I had built habits that protected my ego but weakened my foundation.
Letting go of those habits—unlearning the shortcuts, silencing the impulse to rush—was hard. But in doing so, I made space—for clarity, for structure, for growth.
Now, every problem is no longer a threat to my confidence but an invitation to think. I’m not chasing cleverness. I’m cultivating insight.
This shift wasn’t fast. It wasn’t easy. But it was necessary. And freeing.
I’ve started to rebuild—not just how I code, but how I learn. Slowly. Deliberately. With humility.
And so, the road continues—not driven by urgency, but by understanding. Not ruled by fear, but guided by purpose.