For a long time, I felt deeply limited — even afraid — when it came to coding interviews. Though I was confident in my logical reasoning, my understanding of data structures and algorithms was superficial at best. Over the years, I became highly effective at solving problems using Google, Stack Overflow, and intuition. That worked well enough in real-world coding, where creativity and resourcefulness often mattered more than academic precision.
But everything changed the moment I stepped into the world of timed interviews — stripped of autocomplete, documentation, or internet access. These environments felt alien. Without a strong foundation in DSA, even understanding the questions felt overwhelming, let alone solving them under pressure.
I still remember my first LeetCode problem: Longest Substring Without Repeating Characters. It took me eight hours to brute-force a solution — and to this day, I couldn’t tell you how I got there. DSA became not just a knowledge gap, but a source of anxiety. Even the most basic software roles required solving medium or hard algorithm problems. That reality was disheartening. My frustration grew.
Worse still, I started turning down or delaying interviews with companies I deeply admired — Google, AWS, Netflix, Pinterest — not because I lacked interest, but because I knew failure was guaranteed.
Eventually, it all came to a head.
In one interview for a role I genuinely wanted, I faced a DSA problem — Jack and Jill. For nearly an hour, I was paralyzed, trying to figure out a solution. No insights surfaced, no direction emerged, and I couldn’t write a single line of meaningful code. Just the rising tide of panic and the slow, brutal unraveling of my confidence.
I walked away from that experience defeated — but not destroyed.
That failure didn’t mark the end. It marked the beginning of a different path with a clear resolution:
It’s time to go back to the fundamentals.
Where It All Began
Back in high school, I was passionate about mathematics, physics, and sciences in general. I often represented my school in competitions — and won. I liked collecting and recycling paper, not for crafts or notes, but because I needed something to solve equations on. This passion for problem-solving naturally evolved into a love for coding, which shaped my career choice.
Back to the fundamentals meant rediscovering that early approach — immersing myself, practicing with intensity, and learning by doing — the same way I once dominated math.
A Familiar Crossroads
The resolution made, clarity settled on what came next. In a way, I recognized this feeling; I’d navigated a similar moment earlier in life.
Though I concluded primary school as the top student of my generation, a review of previous years' secondary school entrance exams unveiled a stark reality: I was completely unprepared across mathematics, quantitative, and qualitative reasoning. The confidence I’d built didn’t translate into the competence the exams demanded. This unpreparedness for the academic leap felt profoundly humbling, and I was afraid of failing and felt ashamed. The problem with being “the best” is that anything less than excellence feels like failure.
What changed my trajectory was tutoring and mentorship. I filled the gaps through focused practice. I started reading chapters in my math textbooks, learning through worked examples, and solving exercises at the end. I picked up valuable techniques from my father and older brother. Later, I found peer mentors in further mathematics, friends who challenged and motivated me, and teachers who instilled a deeper hunger for mastery. It worked.
So, when I say “Back to the fundamentals,” I mean doing exactly that — but this time with DSA.
The Cost of Being Self-Taught
I’m not a CS major. I’m a largely self-taught programmer. In Mechatronic Engineering, many of us saw programming as trivial — just a tool to control robots, simulate systems, or manipulate data. Some even underestimated CS as a field. We felt intellectually superior because of the depth and diversity of our engineering challenges.
Yet I grew an affinity for programming, built projects, and helped my CS colleagues with their assignments. In the process, I absorbed parts of their curriculum. That shaped my career path. But the problem with being self-taught and overly reliant on Google and Stack Overflow is this: you accumulate shortcuts, not foundations.
By raw intelligence and passion, I’ve solved hard problems on real-world projects. But I did it without ever gaining significant mastery of data structures and algorithms, system design, or the “good stuff.” Over the years, I developed habits that masked my weaknesses. So when DSA showed up as a requirement, it wasn’t just a challenge — it was a reckoning.
Back to the fundamentals demanded a paradigm shift. Unlearn the shortcuts. Rethink the problem. Rebuild the base.
Questioning the Common Wisdom
Beyond the endless advice and noise, one question remained: how do I actually learn this — in a way that endures?*
I scoured the internet: YouTube videos, competitive programmers vlogs, blogs. Everyone echoed the same refrain:
“Grind LeetCode. Do the Blind 75. Finish the Top 150. Practice 300 problems.”
It didn’t work for me.
Not because I didn’t try — but because I soon realized there was a massive gap between where I was and what these problems assumed. Worse, I was overwhelmed by the sheer volume of opinions, techniques, and contradictions. Every new voice seemed to offer a different strategy. Instead of learning, I felt like I was chasing hacks.
I wasn’t building understanding — I was trying to keep up. And slowly, it began to feel like the only way forward was to memorize solutions.
That’s when the core insight landed:
LeetCode is not where you go to learn what you don’t know. It’s where you go to practice what you already do.
Trying to learn DSA on LeetCode is like grabbing a bull by the horns — and ensuring it pierces your stomach. Back to the fundamentals means grabbing the bull by the tail — or the base. It means learning how to see problems the way mathematicians do: breaking them down, spotting patterns, reducing ambiguity.
I realized I didn’t need another problem list. I needed clarity.
That meant stepping back. Slowing down. Understanding before practicing. Filtering the noise. Letting go of guilt. And rebuilding trust in my own learning process.
Back to the fundamentals is not a grind. It’s not a sprint. It’s a deliberate return to clarity.
A New Approach to Mastery
Ultimately, this all comes down to technique — not just solving problems, but training the mind to think clearly and consistently under pressure.
One key shift in my approach is using books as my primary resource. Not just to read — but to redo exercises using the author’s solutions. Why? Because authors don’t just present answers. They demonstrate patterns, thought processes, and structured ways of approaching problems.
I’ve realized that trying to learn from scattered solutions online rarely builds intuition. But when I internalize how a well-structured mind approaches a problem — when I absorb an author’s rhythm, choices, and reasoning — I’m not just practicing. I’m retraining how I think.
This is how I plan to move forward:
- Follow structured, progressive problem sets from trusted books.
- Solve each exercise with the goal of understanding the author’s method.
- Identify gaps, pause, reflect, revisit — until my own thinking aligns with clarity.
Authors can be mentors. Their patterns of thinking are teachable. Their explanations are footprints. If something doesn’t make sense, it means I can pause, zoom in, identify what I’m missing — and bridge the gap.
Alvin Zablan, in his Structy tutoring program, said it best:
“Don’t memorize problems. Master patterns.”
That clicked.
Suddenly, the weakness of my weakness became visible — not as a failure, but a signal of strength left undisciplined. What once felt overwhelming now feels approachable. I’m no longer driven by fear. In its place is a growing hunger to understand, a passion for learning deeply, and the confidence that comes from knowing how to move forward.