You've solved a hundred easy problems, maybe more. Two Sum, Reverse Linked List, Valid Parentheses. You can look at a problem, recognise the pattern, write the solution. It feels like progress. Then you open your first medium and everything stops working.

You know enough. That was never the issue. Mediums test a skill that easy problems never train.

Why Solving More Easy Problems Won't Fix It

Easy problems have a structural feature that makes them solvable even without deep understanding: they announce their category. A problem titled "Merge Two Sorted Lists" tells you it's a merge problem. A problem in the "Stack" section that asks you to validate bracket pairs tells you to use a stack. The constraints, the title, and often the tags give away the approach before you've read the full description.

That's intentional. Easy problems are supposed to work that way. Easy problems test whether you can apply a known technique correctly. They assume you already know which technique to use.

Medium problems don't require more knowledge. They require a different skill: identifying which pattern applies when the problem doesn't tell you. The constraint shape looks the same as easy problems, but the labels are stripped off. You're on your own.

So you solve a hundred easy problems and still freeze on your first medium. You haven't gotten worse. You've just hit the point where a skill you never trained is the bottleneck.

Some engineers do cross this boundary through sheer volume. After 400 or 500 problems, the identification skill develops accidentally through enough exposure to enough variations. That's a real path, and it works for some people. But it's also why the advice "just grind more problems" persists. The engineers who give that advice survived the gap through brute force and assume everyone else can too. Deliberate practice on the specific missing skill just gets you there faster than unstructured exposure does.

What Medium Problems Actually Test

Take Longest Substring Without Repeating Characters. It's one of LeetCode's most-attempted medium problems. The description asks you to find the length of the longest substring without repeating characters.

Nothing in that description says "sliding window." Nothing says "use two pointers." You're expected to read the constraints and figure it out yourself.

Here's what the identification process looks like in practice. You notice the problem asks for a contiguous range (substring, not subsequence). It involves a constraint on uniqueness (no repeating characters). And it wants you to maximise length. Those signals together point to variable sliding window. Contiguous range plus bounded constraint plus optimise length is the trigger.

An engineer who's trained on identification reads those constraints and the shape clicks. "Contiguous range with a bound. That's a window problem. The bound is uniqueness, so the window expands until a character repeats, then contracts from the left." The problem is half-solved before any code is written.

An engineer who's only solved easy problems reads the same description and thinks: "I could use a hash map to track characters. Maybe nested loops?" They start coding without a structural plan. They might get somewhere, but it's trial-and-error rather than pattern-driven. When they eventually check the solution and see "sliding window," they think "I sort of knew that." But they didn't. They recognised the answer after seeing it, which isn't the same as identifying the right pattern before coding.

That gap between recognising a solution after seeing it and identifying the method before you start is the entire difficulty spike at medium. Most preparation never addresses it directly.

What Changes When You Train Identification

Once you start treating identification as its own skill rather than something that shows up after enough volume, the experience of opening a new problem shifts.

You stop reading the problem title first. Constraints come first now. Is this asking for a contiguous range, a subset, or an optimal ordering? Is there a comparison between elements or a constraint that limits choices? The problem type emerges from those signals, not from the title or the tags.

We can see this in the data. Across 200,000+ submissions on Codeintuition, engineers who complete the identification lessons for a pattern before attempting problems pass at noticeably higher rates than those who skip straight to solving. Not because identification lessons teach more content. They teach a different process. Instead of "this is how sliding window works," the lesson covers "this is how you recognise that a problem requires sliding window, and how you distinguish it from problems that look similar but need a different approach."

There's a reason this works. Cognitive science calls it the testing effect. When you're forced to retrieve the correct pattern from ambiguous cues rather than being told which one applies, the retrieval itself strengthens the connection between problem features and technique. You can't build that connection through passive recognition. It only forms when you're doing the identifying yourself.

After training identification, you open a medium you've never seen. Constraints first, not the title. Two candidate patterns emerge from the constraint shape. You eliminate one based on a distinguishing feature, say the problem asks for a single optimal value rather than all valid combinations, which rules out backtracking. The solution builds from the remaining pattern's invariant. Twelve minutes, no hints.

That's a trained skill. Once you have it, the medium-difficulty wall just stops being there.

Where to Go from Here

If the identification gap sounds familiar, the fix isn't more problems. It's structured practice on the skill that's actually missing.

Codeintuition's learning path is built around this progression. Understand why a pattern exists, train yourself to identify when it applies, then solve problems with increasing difficulty. Every pattern-based module includes an explicit identification lesson before any problem is attempted. That's the piece most platforms skip.

The free Arrays and Singly Linked List courses include the identification training described in this article for patterns like variable sliding window, two pointers, and interval merging. Each pattern module teaches the triggers before you see a single problem. Enough to test whether training identification changes how you approach your next unfamiliar medium.

If those describe your experience, you don't have a volume problem. You have a method problem. The question worth asking isn't how many more problems to solve. It's whether you've ever trained the skill those problems actually test.