While preparing for interviews, I realised that a lot of my LeetCode practice started feeling like mugging up rather than actual problem solving. I could recall patterns, recognise question types, and sometimes even remember solutions—but that didn’t always translate to confidence in an interview setting. If a problem was slightly twisted, I would struggle, not because I didn’t know the concept, but because my understanding was too tightly coupled to specific questions instead of the underlying idea.
That’s what led me to the idea of building a module-by-module, solution-oriented LeetCode of my own. Instead of just tagging a problem as “DP” or “Knapsack,” the platform will focus on how to recognise that a certain pattern applies. For example, if a problem requires dynamic programming with a knapsack-style transition, it should explicitly guide you through identifying the state, the transition, and the constraint that makes it a knapsack problem. The goal is to break problems down into conceptual building blocks rather than treating them as standalone puzzles.
By structuring problems around modules like DP, knapsack, greedy, or graph traversal—and showing how these modules combine in real questions—I want to shift the practice from memorisation to reasoning. I’m still in the early stages of building this, but even designing problems this way is changing how I think about solutions. Instead of asking “Which problem is this similar to?”, I’m training myself to ask “Which concepts are involved here, and how do they fit together?” That, to me, feels like much closer to how real interviews—and real engineering problems—actually work.
Top comments (0)