Problem sets

A curated list is only useful if each problem teaches something the previous ones did not. This file maps the canonical lists onto the patterns in Algorithm patterns, Graphs and trees and Dynamic programming, so you practise a pattern rather than accumulating solved problems.

It also starts with what interviews actually look like now, because “grind 500 problems” is 2019 advice and the format has moved.

Table of contents

• 1. What technical interviews look like in 2026
• 2. Which list, and how to use it
• 3. The core 80, by pattern
• 4. The second 70: pattern depth
• 5. Language-specific practice
• 6. Implement-from-scratch drills
• 7. Debug-and-fix and code-review drills
• 8. How to practise one problem properly
• 9. Sources

1. What technical interviews look like in 2026

Worth reading before you pick a list, because it changes what to optimize for. The consistent themes across current write-ups (see Sources — and note that much of this is practitioner observation rather than published data):

• Algorithm rounds still exist at large companies, but grinding alone is no longer sufficient. The same patterns are tested; the questioning around them got harder.
• Live coding has been made AI-resistant in three ways: broken code you must debug and fix, real-time “why this data structure and not that one” probing, and collaborative framing where the interviewer changes the requirements mid-problem to see how you adapt.
• A new “AI-assisted” round exists at some companies: you are given the tools and evaluated on judgement — what you delegate, what you verify, whether you can defend the generated design. Take-home exercises now often expect AI use and ask you to justify the choices.
• System design moved earlier. What used to be a senior-only round now appears at mid-level and occasionally new-grad, because it is harder to fake.
• Behavioural rounds got heavier and more structured — specific stories, measurable outcomes, follow-up probes.
• Onsites came back at some companies, partly because remote rounds were being gamed.

What this means for your prep, given that the thing you are rusty on is fundamentals:

The corollary that matters for someone who has been vibecoding: the parts an AI does well for you (typing out a known algorithm) are the parts that are now least valued in the room, and the parts it cannot do for you (choosing, justifying, adapting, debugging live) are the parts being tested harder. That is good news — it means fluency in fundamentals is worth more, not less.

2. Which list, and how to use it

All of them organize around the same ~14 patterns, which are the ones in Algorithm patterns §1. The lists differ in depth per pattern, not in coverage.

The honest recommendation for your situation (experienced, rusty on fundamentals rather than new to them): do not start with a list at all. Start with the implement-from-scratch drills in section 6 — you will recover far more per hour by rebuilding a heap, a trie and a DSU than by solving three medium problems. Then work section 3 for coverage, and only go to NeetCode 150/250 for depth on the patterns that still feel slow.

The rule that makes any list work: solve, then re-solve from a blank file the next day. Pattern recognition comes from retrieval, not from reading solutions. That is what the spaced-repetition schedule in the study plan is for.

3. The core 80, by pattern

One or two problems per pattern, chosen so that each teaches a distinct technique. This is roughly Blind 75 reorganized so the pattern is the unit, plus a few additions where Blind 75 has a gap. Each row names the transferable idea, which is the thing to be able to state after solving it.

Arrays and hashing

Two pointers

Sliding window

Stack

Binary search

Linked list

Trees

Tries

Heap / priority queue

Backtracking

Graphs

1D dynamic programming

2D dynamic programming

Greedy

Intervals

Bit manipulation and math

4. The second 70: pattern depth

Once every row in section 3 is comfortable, the value is in variations — the same pattern where a small change in the problem forces a change in the technique. This is what NeetCode 150/250 adds over Blind 75, and it is where pattern recognition becomes automatic.

The “exactly K = atMost(K) - atMost(K-1)” reduction in the sliding-window row is worth calling out — it converts a problem the window cannot solve directly into two problems it can, and it generalizes to a surprising number of counting questions.

5. Language-specific practice

Problems whose point is a language feature rather than an algorithm. These are the ones that make the difference between “knows algorithms” and “writes idiomatic TypeScript / Python”.

TypeScript and JavaScript

Python

6. Implement-from-scratch drills

Do these before the problem lists. Each one is 15-40 minutes, and each rebuilds a specific piece of machinery you will otherwise fumble under pressure. Do them in both languages at least once; do the starred ones in both languages every review cycle.

Every one of these has a tested reference implementation in this guide, so you can diff your version against something that provably runs.

7. Debug-and-fix and code-review drills

A real round now. Practise by writing the bug yourself and fixing it a day later, or by reviewing code that contains one of these classic defects. Each of these is a bug from the measured sections of this guide, so you know the failure mode is real.

The exercise is not just “find the bug” — it is “say what the failure mode is, how you would have caught it, and what test you would add”. That is what the round is actually scoring.

8. How to practise one problem properly

flowchart TD
    A["1. Restate problem +<br/>ask clarifying questions"] --> B["2. State brute force<br/>and its complexity"]
    B --> C["3. Name the pattern<br/>and why"]
    C --> D["4. State the invariant<br/>before coding"]
    D --> E["5. Write it<br/>(narrate only the interesting lines)"]
    E --> F["6. Trace a small example,<br/>including an edge case"]
    F --> G["7. State time/space<br/>and the bottleneck"]
    G --> H["8. Close the file"]
    H -.->|"next day, from a<br/>blank file"| A

The difference between an hour that builds fluency and an hour that does not:

1. Restate the problem and ask two clarifying questions before writing anything. Input size? Sorted? Duplicates? Negative values? In-place allowed? This is now explicitly scored — “more emphasis on clarifying questions before coding” is one of the documented 2026 shifts.
2. Say the brute force and its complexity out loud, even when it is obviously too slow. It establishes a baseline and often reveals the redundancy the real solution removes.
3. Name the pattern and why. “Contiguous subarray plus a monotone constraint, so sliding window.”
4. State the invariant before coding. “The window [left, right] always contains at most k distinct characters.” Bugs come from not having one.
5. Write it. Talk through the interesting lines only; narrating a for loop wastes the room’s time.
6. Trace one small example by hand, including an edge case (empty, single element, all equal).
7. State time and space, and where the bottleneck is. Volunteer the follow-up: “the n log n is only the sort; if the input arrived sorted this is linear.”
8. Then, away from the interview: close the file and rewrite the solution from scratch the next day. Retrieval is what builds the reflex; re-reading a solution builds only recognition.

Two habits worth adopting specifically because of how interviews changed:

• Defend a data-structure choice unprompted. “I’m using a Map here rather than an object because the keys are dynamic, and a plain object used as a dictionary goes into slow mode anyway.” That sentence is the differentiator now.
• Practise being interrupted. Have a friend or a model change the requirements halfway (“now the input is streaming”, “now the values can be negative”, “now it has to be O(1) space”) and adapt out loud. The collaborative-framing round is exactly this.

Track your progress by pattern confidence, not problem count. A simple table with the 14 patterns and a 1-5 confidence score, updated weekly, tells you what to practise next far better than a streak does. The study plan has a version of that table plus the review schedule.

9. Sources

Facts about list composition and the 2026 format shift come from:

• LeetCode 75 vs Blind 75 vs NeetCode 150 (2026) — problem counts and difficulty splits
• What Actually Changed in Tech Interviews in 2026 — AI-assisted rounds, debug-and-fix formats, system design moving earlier, return of onsites. Note this piece offers no quantitative data on format prevalence; treat it as informed observation
• Blind 75 original post — the original list
• LeetCode vs real-world interviews (2026) — the “grind is no longer enough” argument

Next: Cheat sheets for the quick reference, or Study plan and flashcards to schedule the work.