The Beginning: Where It All Started
I still remember my first LeetCode problem — "Two Sum." It took me nearly 45 minutes to solve a problem that most experienced developers finish in under 5. I remember staring at the screen, confused by the concept of hash maps, wondering if competitive programming was really for me. Looking back, that moment of frustration was the spark that ignited something much bigger.
When I started my second year of B.Tech at AKTU, I realized that knowing how to build websites wasn't enough. Every technical interview, every internship screening, and every coding round demanded one thing: strong DSA fundamentals. I decided to commit to LeetCode seriously — not just as exam prep, but as a daily practice.
The First 100 Problems: Building the Foundation
The first 100 problems were the hardest. Not because the problems were particularly difficult — most were Easy or Medium — but because I was building an entirely new way of thinking. I had to learn to see patterns: when to use a sliding window versus two pointers, when a problem screams "dynamic programming" versus greedy, and why binary search works on sorted search spaces beyond just arrays.
My approach during this phase was simple but disciplined:
- Solve 2-3 problems daily — consistency over intensity.
- Topic-wise practice — I'd spend a full week on arrays, then a week on linked lists, then trees, then graphs.
- Always analyze the editorial — even when I solved a problem, I'd read the official solution to learn better approaches.
- Maintain a problem journal — I kept a notebook where I'd write the problem name, my approach, the optimal approach, and key takeaways.
The Plateau: Problems 100-300
Around the 150-problem mark, I hit a wall. Medium problems that I thought I should be able to solve would leave me stuck for hours. I'd look at the solution and think, "How would I ever come up with this on my own?" This phase tested my patience more than any exam ever did.
What got me through was a mindset shift. I stopped thinking of problem-solving as something you're either "naturally good at" or not. Instead, I started treating it like a skill — something that improves with deliberate, structured practice. I began studying specific patterns:
- Sliding Window — for subarray/substring problems with constraints.
- Monotonic Stack — for "next greater element" style problems.
- Union-Find — for connected component and cycle detection problems.
- Topological Sort — for dependency resolution and course scheduling.
- Interval Merging — for scheduling and overlapping range problems.
Once I internalized these patterns, problems that previously seemed impossible started clicking within minutes. That's the magic of pattern recognition — it turns hard problems into variations of problems you've already solved.
The Breakthrough: Cracking Hard Problems
The real turning point came when I started attempting Hard problems without immediately looking at hints. I gave myself a rule: spend at least 45 minutes thinking before looking at any solution. Sometimes I'd fail. But the problems I solved independently — even if my solution wasn't optimal — gave me a confidence boost that no tutorial could match.
I remember the first Hard problem I solved completely on my own: a dynamic programming problem involving string matching. My solution ran in O(n*m) time and used a 2D DP table. It wasn't the most elegant code I'd ever written, but the "Accepted" verdict on that screen was one of the most satisfying moments of my coding life.
Contest Culture: The Competitive Edge
Weekly LeetCode contests became my weekend ritual. The time pressure — 4 problems in 90 minutes — forced me to think faster and code cleaner. Early on, I'd solve 1-2 problems per contest. Gradually, I started consistently solving 3 problems, occasionally getting all 4.
Contests also taught me something that practice alone couldn't: how to manage pressure. In an interview or a contest, you don't have the luxury of spending 2 hours on a single problem. You need to quickly assess difficulty, choose the right approach, implement it without bugs, and move on. That skill — rapid problem assessment — has been invaluable in my technical interviews.
The Knight Badge: What It Means
Reaching the Knight rating on LeetCode wasn't a single dramatic moment. It was the result of months of consistent effort — daily problems, weekend contests, and countless hours studying algorithms and data structures. The badge itself is just a marker, but what it represents is much more: discipline, persistence, and genuine growth as a problem solver.
Advice for Aspiring Competitive Programmers
If you're just starting out with DSA and competitive programming, here's what I wish someone had told me on day one:
- Consistency beats intensity. Solving 2 problems daily for 6 months is far more effective than solving 20 problems in one weekend and then burning out.
- Don't skip the basics. Arrays, strings, hash maps, and two pointers form the foundation of 70% of interview problems.
- Learn patterns, not solutions. Memorizing solutions is pointless. Understanding why a sliding window works teaches you to apply it to 50 different problems.
- Participate in contests. They build speed, accuracy, and the ability to perform under pressure.
- It's okay to struggle. Every strong competitive programmer has stared at a problem for hours feeling completely lost. That struggle is literally the learning process.
What's Next
Reaching Knight isn't the end — it's a checkpoint. I'm now working toward improving my rating further, diving deeper into advanced topics like segment trees, Fenwick trees, and string algorithms. The journey continues, and honestly, I wouldn't have it any other way.
If you're on a similar path, keep going. The problems get harder, but so do you.