Questions by pattern
Interviewers reuse a small number of underlying techniques. Each hub lists every question in the bank that exercises one of them, with which companies ask it and at what tier.
Break a problem into overlapping subproblems, solve each once, and reuse the results to build the final answer.
Model entities as nodes and relationships as edges, then traverse, order, or measure the resulting graph.
Trade an O(n) or O(n²) scan for O(1) average lookups by keying a map on the exact fact you need to check.
Explore as far as possible along one branch before backtracking, used across trees, graphs, and grids.
Sizing a system's scale, splitting it into services and data stores, and defending the tradeoffs a real deployment would force.
Build a small class that supports a fixed set of operations, each with its own required time complexity.
A grab-bag label for problems whose real technique is scanning, comparing, or transforming text — the technique itself lives elsewhere.
Binary tree problems built on traversal order, structural recursion, and reconstruction from encoded forms.
Explore a graph or grid one layer of distance at a time to find shortest paths or process things level by level.
Given working-looking code and a symptom, find the root cause and fix it without breaking what already passes.
Make the locally forced or locally best choice at each step, then prove — don't assume — that no later choice can beat it.
Maintain a contiguous range with two pointers, growing and shrinking it instead of rescanning from scratch.
Halve a sorted or monotonic search space on every step to find a target, a boundary, or the smallest value that works.
Trade extra passes or a hash-based lookup for the O(n²) brute force that scanning an array naively tempts you into.
A 2D array is an implicit graph over cells; the fix is naming what an edge means before choosing DFS, BFS, or a 2D DP.
Keep only the extreme elements you need on top, so repeated min/max or top-k queries stay logarithmic.
Build a candidate choice by choice, undoing a choice and trying the next one as soon as it can't lead anywhere valid.
Walk two positions through a sequence, moving one or both based on what you compare, to avoid a nested-loop scan.
Turn a vague scale question into a chain of stated assumptions and multiplications you can defend, then sanity-check the result against a known reference.
Rearrange an array, matrix, or structure using only the memory it already occupies, without a second copy.
Track state with last-in-first-out order to match nested structure, parse expressions, or undo the most recent action first.
Sort a list of ranges by an endpoint, then sweep once to merge, count overlaps, or decide what to keep.
A DP whose state is a pair of positions — usually two prefix lengths — so the table and its dependencies are genuinely two-dimensional.
Rewire next (and sometimes random) pointers directly, using runner pointers instead of copying into an array.
Model one system's classes, states, and interactions in code, with concurrency and extensibility as the real test.
Precompute running totals so any range sum, or any question phrased as one, answers in O(1) instead of a rescan.
A DP whose state is a single prefix index, where each answer is built from a small fixed number of already-computed earlier answers.
Reason precisely about time and space cost — amortized, worst-case, and where a "worse" big-O actually wins.
Coordinate threads sharing state so nothing is lost, no one deadlocks, and no one spins burning CPU while waiting.
Treat a grid as coordinates and boundaries rather than a graph, and get index arithmetic and in-place edits right.
Solve a problem by expressing it in terms of a smaller version of itself, then trust the smaller call to be correct.
Sort first so overlap, order, and pairing questions collapse into a single linear or two-pointer pass.
Explain how a well-known mechanism actually works underneath, with real numbers, not just its name.
Track which elements belong to the same group under repeated merges, answering "same group?" in near-constant time.
Replace a per-element or per-digit loop with operations that act on every bit of a machine word at once.
Match a structure to the operations and scale a scenario actually needs, and defend the trade-off you didn't pick.
Keep a stack whose values only increase or only decrease so you can find each element's next bigger or smaller neighbor in one pass.
Split large or unstructured content into blob storage plus metadata, and design around durability and sync, not just capacity.
Store strings by their shared prefixes in a tree, so lookup, prefix-check, and multi-pattern search all cost proportional to string length, not collection size.
Use the ordering invariant of a BST to prune half the tree or read it in sorted order, instead of a generic tree walk.
Decide, and defend, how strongly different parts of a system must agree on the current state versus how available they stay under failure.
Solve with a numeric property or a counting argument, not a data-structure trick — digit rules, modular arithmetic, exponent halving.
Hand-write a small state machine or grammar walker instead of calling a library evaluator, and let the grammar's own structure (nesting, precedence, digit runs) drive the code's structure.
Decouple producers from consumers with an ordered buffer, from a single-process counter to a durable distributed log.
Order items with pairwise "this must come before that" constraints, and detect when no valid order exists.
Turn a high-volume event stream into fast rolling counts, sums, or top-k rankings, trading exactness for freshness.
When "does this candidate value work" is monotone, binary search the candidate itself instead of searching an array.
Trade a bounded amount of staleness for a large drop in read latency and load on the system of record.
Handle an array whose last element wraps back around to the first, turning a linear technique into two or three linear cases.
Count how many ways, or how many occurrences, without enumerating every possibility one at a time.
Decide whether one write becomes many at publish time, many reads merge at request time, or both — the choice that shapes an entire feed, chat, or notification system.
Use O(1) membership testing to skip a nested scan, whether for duplicates, ranges, or valid splits.
Model real-world entities and their interactions as classes with clear ownership, before any scheduling or persistence logic goes on top.
Follow the problem's stated rules step by step and get the bookkeeping exactly right, rather than deriving a formula.
Name the small set of situations something can be in, then define exactly which transitions between them are legal — as a DP recurrence or as real code.