Read alongside
LeetCode 75 study plan
Compact official problem pool for a first mixed pass across the core patterns, used without looking at the section labels first.
Objectives
- Map common problem signals (sorted input, contiguous range, top-k, dependencies, minimum steps, count the ways) to candidate patterns and their invariants.
- State, for each candidate, the condition that makes it applicable, such as a monotone predicate, non-negative values, unit weights or overlapping subproblems.
- Run mixed-practice sessions in which the pattern is unknown in advance, and record which signal led to the right approach.
- Maintain a review rotation that revisits each pattern through a different problem at increasing intervals.
- Design stateful data structures by combining a hash map with a linked list, heap or sorted structure, and analyze every operation.
- Diagnose weak patterns from a practice log and adjust the plan, using official study plans as problem pools.
Why it matters
Interview problems come from a large space, and you will rarely meet one you have practiced. What transfers is the ability to read a statement, notice its signals and test a few candidate techniques against their preconditions. Memorizing solutions, or lists of questions said to be used by particular companies, does not build that ability and fails as soon as a problem is altered. Learning research also generally favors interleaved practice and spaced review over blocked repetition: mixing problem types forces you to choose the technique, which is precisely the skill being tested.
Core ideas
Signals, candidates, conditions. Read the constraints and the question, map them to a short list of candidates, and check each candidate's condition before committing.
| Signal | Candidate patterns | Condition or invariant to check |
|---|---|---|
| Complement lookup, duplicates, grouping | hashing, frequency counting | Equal keys identify equivalent items |
| Pairs in sorted input, in-place partitioning | two pointers | Each move discards candidates that cannot improve the answer |
| Contiguous subarray or substring | sliding window, prefix sums | Window validity is monotone (often needs non-negative values); otherwise prefix sums with a hash map |
| Sorted input, or smallest feasible value | binary search, binary search on the answer | A predicate that flips from false to true exactly once |
| Overlapping ranges, many range updates | sorting, interval merging, sweep line | Sort key matches the objective |
| Nested structure, matching, undo | stack | Top is the most recent unresolved item |
| Next greater or smaller, window extremes | monotonic stack or deque | Stored indices stay in monotone order |
| k largest, running median, merging streams | heap selection, two heaps | Heap top is the current extreme; size stays bounded |
| Reordering a list, cycles, middles | linked-list pointers, fast and slow pointers | Save next before rewiring; fast moves twice as far |
| Hierarchy, subtree answers | tree DFS or BFS, BST invariant | Each subtree returns a summary its parent can combine |
| Many prefix queries over words | trie | Each node represents one prefix |
| Minimum steps, grids, transformations | graph BFS or DFS, grid as implicit graph, multi-source BFS | Unit weights; mark visited on enqueue |
| Prerequisites, dependencies | topological ordering, cycle detection | An order exists only for a DAG |
| Groups merging over time | union-find | Undirected, unions only |
| Cheapest weighted route | shortest paths | Weight sign decides Dijkstra or Bellman-Ford |
| All combinations or placements | backtracking | Choose, recurse, undo; prune early |
| Count ways, best total over choices | DP (1D, grid, strings, knapsack) | Overlapping subproblems with a valid evaluation order |
| A locally best choice looks safe | greedy | An exchange argument exists |
| Independent halves, k-th order statistic | divide and conquer | Subproblems do not overlap; write the recurrence |
| Parity, small sets encoded as masks | bit manipulation | Width and signedness are explicit |
| Fast operations on changing data | stateful design | Map plus list, heap or sorted structure kept consistent |
Constraints narrow the list: n up to about 20 allows exponential search, n around 10^3 allows O(n^2), and n around 10^5 or more needs O(n log n) or better.
Mixed practice routine. Once several topics are studied, stop practicing only by topic. A session is three unseen problems from different patterns, 25 to 35 minutes each, with the pattern unknown in advance; the official LeetCode 75 and Top Interview 150 plans and the extra items in each topic are good pools. Before coding, write the signals you noticed and two candidates with the reason for your choice. Afterwards, log the problem, the pattern, whether you recognized it unaided, the time taken and the bug class.
Review rotation. Revisit each pattern at growing intervals, for example after about 2, 7 and 21 days, through a different problem each time. If you learned sliding windows on Longest Substring Without Repeating Characters, review with Permutation in String, then Minimum Window Substring; for BFS, follow Number of Islands with Rotting Oranges, then 01 Matrix. Re-solving the same problem mostly tests memory of that answer. Patterns you recognized late or solved with bugs come back sooner.
Stateful design problems. LRU Cache, Time Based Key-Value Store, Snapshot Array and LFU Cache combine patterns: a hash map for direct access plus a linked list, heap or sorted list for order. State the invariant that links the structures and the cost of every operation.
Common misconceptions
- "The strategy is to memorize the questions a company uses." Such lists cannot be verified, and you will rarely see the same problem; recognition and clean execution transfer.
- "More problems solved means more progress." Many problems practiced by topic, always knowing the pattern beforehand, build less recognition than fewer problems practiced mixed.
- "Review means re-solving the same problem." That rehearses one answer; review the pattern through a new problem.
- "A signal determines the pattern." Signals suggest candidates; the applicability condition decides.
How to approach it
Start mixed practice once arrays and hashing, two pointers, trees, graph traversal and basic DP are studied, and run two or three mixed sessions per week alongside topic study. When a pattern fails repeatedly, return to its topic notes instead of grinding more problems of the same kind. Mid and senior loops typically add design-flavored problems and follow-up extensions, so keep stateful design in the rotation.
Self-check before you finish
- Which signals suggest a sliding window, and what condition makes it valid?
- When does a minimum-steps problem need Dijkstra instead of BFS?
- Which signals point to DP rather than greedy, and how would you check?
- Which patterns did you recognize late in your last mixed session, and why?
- Why is reviewing a pattern through a new problem more useful than re-solving an old one?
- What invariant links the hash map and the linked list in an LRU cache?