Solving vs Understanding a Problem

The debate around LeetCode problem solving vs understanding shows up every time an engineer freezes in an interview on a problem they've "solved" before. One engineer had solved 300 LeetCode problems. She couldn't explain why merge intervals requires sorting. She'd write the code from memory, get the green checkmark, and move to the next one. Another engineer, 80 problems total, could derive the sorting invariant from scratch on a problem she'd never seen. They both practised intervals, but they built completely different skills.

Solving and understanding are different things, and that's easy to miss. The right answer feels like transferable learning. It usually isn't.

What problem solving actually means on LeetCode

Solving a problem means producing the correct output. The code passes all test cases, the platform marks it green, and you move to the next one.

That sounds like learning. But think about how many problems you've "solved" by recognising the pattern from a previous attempt, recalling steps from a discussion post, or following a template you'd memorised. The output was correct. But the reasoning that produced it was probably shallow.

This distinction matters more than you'd think. You can produce the correct output without any real grasp of why the algorithm is correct. Understanding means you could derive the solution for a variant you've never seen. That gap determines whether practice transfers to interviews.

There's nothing wrong with solving as a starting point. Early in your preparation, getting problems right builds confidence and exposes you to patterns. Solving 50 easy problems gives you a working vocabulary of common patterns, data types, and implementation idioms. But it's easy to never move past this stage without realising it.

The tell is simple: if someone changed the problem slightly, could you still construct the solution? Could you build it from the underlying invariant, without reaching for a memorised template?

The understanding gap in LeetCode problem solving

Understanding requires something solving doesn't. You need knowledge of why the algorithm works, beyond just knowing what it does.

Take the Merge Intervals problem as an example. If you've solved it, you can probably describe the steps: sort by start time, iterate through, merge overlapping intervals. You can write the code from memory, and you've solved the problem.

But understanding it means answering a different question: why does sorting by start time work? What invariant does it create?

Most people can't give this answer clearly. Sorting by start time guarantees that for any interval you're examining, every interval that could overlap with it comes immediately after it in the sorted order. You won't encounter an interval later in the list that overlaps with one you've already processed and moved past. That's the invariant, and it's why a single linear pass is sufficient after sorting.

Now apply the transferability test. Someone gives you Insert Interval, a problem where you're given a sorted list of nonoverlapping intervals and asked to insert a new one, merging where necessary. If you understood the sorting invariant from merge intervals, you recognise immediately that the sorted order is already given to you, so you only need to find the insertion point and handle the overlapping neighbours. You don't need to recall having seen this specific problem before. You construct the solution from the invariant you understood.

If you only solved merge intervals, Insert Interval looks like a new problem that requires a new solution.

So you go looking for it in a discussion post.

Why LeetCode problem solving doesn't build understanding

This problem isn't your fault, and it's worth understanding why. It comes down to measurement.

Platforms track what's easy to measure: problems solved, acceptance rates, streaks. Every one of these metrics rewards solving. You get a checkmark when you produce the correct output. Nobody asks whether you understood why the solution was correct, whether you could explain the invariant, or whether you could handle a variant.

The result is predictable. Engineers optimise for what the platform measures. They solve a problem, see the green checkmark, and move on. After 200 problems, they have an impressive solve count and a fragile grasp of the underlying patterns.

That's the solve count illusion at work. An engineer with 300 solved problems feels prepared. But the number measures quantity of correct outputs produced. It tells you almost nothing about depth of algorithmic understanding built. These two things correlate weakly at best. Research on interleaving shows that mixing problem types during practice forces you to identify which pattern applies before reaching for a solution. But most practice environments serve you problems within a category, which means the pattern is preidentified. You're practising application without ever practising identification.

And identification is the skill that interviews actually test. When you open a problem in a real interview, there's no category label. There's no hint about which data structure to use. You have to read the constraints, recognise the key signals, and derive the right technique from scratch.

The 200,000+ submissions across Codeintuition's courses reveal a consistent pattern. Engineers who complete the identification lessons before attempting problems pass assessments at 58% across 60,000+ timed submissions. That's against an industry average around 20%. The variable isn't problem count. It's whether the practice actually trained identification and derivation, or just output production.

Where the solving understanding gap hits hardest

This difference shows up at the worst possible moment. In an interview, you can't pick the problem. There's no category label telling you which technique to use, and there's no discussion post to check after your first attempt fails.

Interviewers at companies like Google and Amazon have started designing questions specifically to test understanding over recall. They'll give you a standard problem, wait for you to solve it, and then ask a follow up variant that changes one constraint. If you understood the original, the variant takes 2-3 minutes. If you only memorised the original, the variant feels like an entirely new problem.

The 300 problem engineer freezes. She solved the original quickly because she recognised it. But the followup doesn't match anything she's seen before, and she doesn't have a memorised solution to reach for. The 80 problem engineer handles it because he understood why the first solution worked, and that understanding carries over to the variant.

Solving versus understanding is the difference between passing and failing when the interviewer goes off script. Good interviewers always go off script. They don't care whether you've seen the problem before. They want to know if you understood the pattern deeply enough to adapt it under pressure.

How understanding gets built

Understanding doesn't happen by accident. Solving more problems doesn't gradually convert into understanding. You can solve 500 problems without ever practising the skill of deriving why a solution works.

The difference comes from deliberate construction: you encounter a pattern, trace how it works step by step, identify the structural triggers that make it applicable, and then apply it to problems of increasing difficulty.

The order matters more than most preparation advice acknowledges. If you start with problems before understanding the invariant, you're training recall. This applies across every topic, from hash tables to binary trees to recursion. Flip that order, and you're training the ability to construct solutions from first principles.

Consider the merge intervals problem again. Before you ever see the problem itself, you'd study the interval merging pattern: what class of problems it solves, what invariant makes it correct (sorted order guarantees overlap adjacency), and what structural features in a problem statement signal that this pattern applies (collections of ranges, overlap detection, consolidation language). When you finally reach the problem, you're applying a principle you already understand. That feels completely different from memorising a procedure.

This three phase progression is what Codeintuition's learning path is built around. Understand the invariant, identify when it applies, then apply it under increasing pressure. 75+ patterns across 16 courses, each taught this way. The free Arrays and Singly Linked List courses cover 15 patterns with this same structure. You'll know within the first identification lesson whether this kind of practice changes how you handle unfamiliar problems.

Six months from now, you're in a coding interview. The problem describes a set of time ranges and asks you to find the gaps between scheduled meetings. You've never seen this exact problem. But you recognise the interval structure, recall the sorting invariant, and derive the solution in your head before writing a single line. That isn't talent. That's what understanding, built through deliberate practice, actually produces.