On a curated interview list, why does pattern-category coverage beat raw problem count?
answer
- Ask what transfers to a brand-new problem
- The list is a map, not a queue
- Count measures exposure, not span
- An unseen variant still belongs to some category
- A blank category ends the round, a slow one does not
basics
~20 sInterviews hand you an unseen variant, not a problem you have already done. What transfers is the pattern category, so covering every category with fewer problems beats grinding many problems from a handful of categories.
solid answer
~50 sA curated list is a **category map**, not a queue. Its value is that the categories — arrays and two pointers, sliding window, binary search, trees, graphs, heaps, intervals, dynamic programming, backtracking, bit tricks — partition most of what interviews draw from. Since the problem you get is almost always an unseen variant, the transferable unit is the pattern, not the individual solution. A candidate with 250 problems concentrated in four categories has deep grooves and blind holes: hand them something from an uncovered category and they have no starting move. A candidate with two or three problems in every category can at least name the shape, sketch a candidate approach, and reason about cost. Count is a proxy metric that looks like progress and hides gaps; coverage is the thing the proxy was standing in for. Depth still matters — but you buy breadth first, then deepen inside the categories your target loop weights heavily.
go deeper
Be ready to say what a curated list is organized around — categories of technique — and why the count in its name is not the point. Name a few categories out loud without hesitating.
Explain the mechanism: interviews hand you variants, so the pattern transfers and the memorized solution does not. Show how you would tell coverage from volume in your own practice log.
An interviewer expects you to diagnose the avoidance pattern behind a large count, and to describe how you would rebalance the remaining weeks toward the blank categories rather than the comfortable ones.
Own the tradeoff when you set preparation guidance for others: breadth-first spends early time on low-confidence categories and feels slower, and you should be able to defend that against a team that wants a visible problem counter.
## What a curated list actually is Curated interview lists — the classic 75-problem lists, their 150-problem extensions and their descendants — look like homework queues, which is exactly the misreading that wastes months. Structurally they are **compressed category maps**. Someone looked at a large corpus of interview problems, clustered them by the technique that solves them, and picked a small representative sample from each cluster. The original 75-problem list is the short list grouped by topic. The 150-problem extensions expand it, add categories the shorter list under-samples, and order problems inside each category. A schedule-generating variant adds a scheduling layer: you say how many weeks and hours you have and it emits an ordered plan. The differences are real but secondary; the shared idea is that a few dozen well-chosen problems can *span* the space if they are chosen by category rather than by popularity. Once you see the list as a map, the count question answers itself. Seventy-five is not a magic dosage. It is roughly how many problems it takes to touch every cluster two or three times. ## Why the transferable unit is the category An interview almost never hands you a problem you have already solved. It hands you a variant: same skeleton, different dressing, one twist. What survives the change of dressing is the pattern — the reason the technique applies and the invariant it maintains. What does not survive is the memorized sequence of lines. So the question that decides preparation quality is: *when you meet an unseen problem, how many candidate approaches can you generate in the first two minutes?* That number is bounded by how many categories you have internalized, not by how many problems you have closed. Six weeks spent three-deep in every category leaves you with a dozen doors to try. The same six weeks spent forty-deep in three categories leaves you with three doors, opened very smoothly, and a wall everywhere else. ## The two-candidate picture Put two people side by side after the same six weeks. Candidate A optimized count: about 250 problems, drawn mostly from arrays, strings, trees and easy dynamic programming, because those are the categories with the most available problems and the fastest wins. Candidate B optimized coverage: about 90 problems, but two to four in every category on the map, including the thin ones — graphs, intervals, heaps, backtracking, bit manipulation. Hand both an unseen problem whose natural solution is a traversal over an implicit graph. Candidate A has seen no graph problem in weeks and will spend the round rediscovering that a queue-based level-by-level exploration exists. Candidate B has three graph problems in memory, recognizes the shape, states the approach, and spends the round on the twist — which is what the interviewer is actually grading. Now hand both an array problem. Candidate A is faster and cleaner. That is a real advantage, and it is why coverage-first is not depth-never. But the failure mode that ends loops is the blank category, not the slightly-slower familiar one. ## Why count is such a seductive metric Count is visible, monotone and rewarding. Every problem closed increments it. Coverage is invisible unless you deliberately track it, and tracking it means confronting the categories you have been avoiding — which are, almost by construction, the ones you are worst at. Avoidance is the mechanism: people practise what feels good, and what feels good is what they are already able to do. A large count is often *evidence of* an avoidance pattern rather than evidence against it. The practical correction is to track the map instead of the total. A one-line-per-category tally — category name, problems attempted, whether you can currently sketch the approach cold — makes both the progress and the hole legible. When a category shows zero, no amount of total volume compensates. ## What coverage does not mean Coverage is a floor, not a ceiling, and it is not a licence for shallowness: - **One problem per category is not coverage.** A single instance teaches you that problem. Two or three from the same category, spread across easy and medium, is where the shared structure becomes visible. - **Categories are unequal.** Dynamic programming and graphs are broad enough to contain several sub-patterns; a single bit-manipulation problem may genuinely represent most of what that category asks. Sample proportionally to the category's internal variety. - **Coverage does not survive neglect.** A category you covered in week one and never touched again is not covered by week six. - **Breadth first, then weighted depth.** Once every category is non-empty, invest the remaining time where your target loop actually concentrates. ## The honest summary A curated list is finished when the map is filled in and stays filled in, not when the counter reaches the number in the list's name. Count is what you report; coverage is what you are graded on.
- How many problems per category is enough to say the category is covered?Two to three for narrow categories, more for broad ones. One problem teaches you that problem; the shared structure only becomes visible when you see the same technique wear two different costumes. Dynamic programming and graphs each hold several sub-patterns and need proportionally more samples, while a narrow category like bit tricks may be well represented by one or two.
- Does the coverage argument mean depth is worthless?No — it sets the order. Buy breadth first so no category is blank, then spend remaining time deepening where your target loop concentrates. Depth in a covered category makes you faster and cleaner on problems you can already start; depth bought at the cost of a blank category just moves your failure to a different round.
- How would you make coverage visible while you study?Track one row per category rather than a running total: category name, problems attempted, and whether you can currently sketch the approach without looking. The zero rows and the stale rows are the whole signal. A total problem count deliberately hides exactly the information you need, because the categories you avoid are the ones you are weakest in.
Packing for a trip by counting items rather than checking categories: forty shirts and no jacket still leaves you cold on the first evening.
saying these in an interview costs you the question
- Finishing the list means you are interview-ready
- More problems is always better preparation
- Memorizing solutions counts as covering a category
- Skipping a whole category is fine if the total is high
- One problem per category means the category is covered