Track which pattern you fail, not how many problems you did

Why problem counts are the wrong metric

"I did 300 problems" tells you nothing about readiness, because it does not distinguish between 300 problems in the patterns you already know and 300 spread across the ones you do not. Volume without a diagnosis produces a common and frustrating outcome: a large solved count and a consistent failure on any problem phrased slightly unfamiliarly.

The reframe is simple. An interview problem is a pattern wearing a costume. Your job in the first two minutes is to identify the pattern; the implementation afterwards is mechanical if you have drilled it. So practice should be organised around recognising patterns and around finding the ones where your recognition fails.

The recurring patterns

That table is most of the surface area of a standard software interview loop. The remaining problems are usually combinations — a BFS whose frontier is a heap, a DP over intervals, a binary search whose predicate runs a greedy check.

The two-minute recognition drill

Recognition is a separate skill from implementation and it is the one that fails under pressure. Drill it separately: read a problem, spend two minutes deciding the pattern and the complexity target, write it down, then check. Do not implement. You can run twenty of these in the time one full solution takes, and it trains exactly the step interviews test first.

For each problem, before coding, answer four questions: 1. What is the input shape? sorted / graph / intervals / string 2. What is being asked? exists / count / optimum / enumerate 3. What complexity is plausible? n log n suggests sort or heap or binary search 4. Which pattern fits? name it, out loud, before typing

Question 3 does more work than people expect. If the constraints allow n up to 10^5, an O(n^2) solution is not the intended one, and that single observation frequently identifies the pattern on its own.

Keeping a failure log by pattern

The whole method rests on one artefact: a log where every problem you attempt is tagged with its pattern and an outcome. Not a count — a per-pattern record.

1. Tag every attempt with one of the ten patterns.
2. Record the outcome honestly: solved unaided, solved with a hint, or failed.
3. Record where it broke — recognition, approach, implementation, or edge cases. These are different problems with different fixes.
4. Review weekly and look for the pattern with the worst ratio. That is your next week.
5. When a pattern reaches a run of clean unaided solves, stop drilling it and let spaced repetition maintain it.

The failure location matters as much as the failure. If you recognise sliding window instantly but keep mishandling the shrink condition, you do not need more sliding-window problems — you need to write the template once, correctly, and rehearse it. If you never recognise it in the first place, the fix is the opposite.

Spaced repetition, because you will forget

Algorithm knowledge decays like anything else. A problem solved cleanly in March is often a blank in June. Spaced repetition solves this cheaply: re-attempt solved problems on an expanding schedule rather than solving new ones forever.

The practical shape is a Leitner system: boxes with review intervals, a problem moves forward on a clean solve and drops back to box one on a failure. Twenty minutes of review before new problems each session is a better use of the hour than another fresh problem.

A weekly structure that works

• Start every session with review, not new material. Fifteen to twenty minutes on due problems.
• One target pattern per week, chosen from the worst ratio in the log, not from a curriculum order.
• Recognition drills in bulk — a batch of twenty problems where you only name the pattern.
• Two or three full timed solves, out loud, since interviews are verbal and silence reads as being stuck.
• Write the template once per pattern — the canonical implementation, from memory, until it is automatic.
• Stop tracking total solved. It is the metric that feels like progress and measures nothing.

The honest test of readiness is not a solved count. It is whether you can be handed an unfamiliar problem in any of the ten patterns and name the pattern within two minutes, then implement its template without looking it up.

The rest of the search — which roles, which deadlines, and the sponsorship questions if you need them — is covered in the internship guide, and the pipeline itself lives in Apply OS.

Tools referenced in this guide

• Apply OS — application pipeline and deadline radar, free and browser-only.
• Internship guide — the timeline and sponsorship mechanics around the interviews.
• Resume rebuild — the document that gets you to the interview in the first place.