Algorithm & Data Structure Cheat Sheets

Array fundamentals — in-place rewriting, rotation, partitioning, and the index-as-hash trick. Owns the operations; the pattern families (windows, pointers, prefix sums) each have their own file.

drill 4/15 ok · 3 again · next: LC 88, LC 2657, LC 41

Windows that grow and shrink on a condition — fixed-size, variable-size, at-most-k, and exactly-k by subtraction; owns the expand/contract loop and the seven canonical window templates.

drill 5/14 ok · 4 again · next: LC 438, LC 4067, LC 992

The everyday string catalogue — character-level two-pointer scans, frequency and anagram signatures, run-length grouping, tokenising, parsing and in-place rewriting — while the worked-solution archive, the language-level string API, palindromes, substring search and two-sequence DP each live in their own sheet.

drill 3/13 ok · 3 again · next: LC 696, LC 388, LC 71

The two-pointer family on arrays and strings — opposite-ends convergence, fast/slow, expand-from-centre and the read/write partition, with one canonical template for each; window problems that grow and shrink on a condition live elsewhere.

drill 8/16 ok · 4 again · next: LC 5, LC 647, LC 88

The problems behind array.md's own templates (index as hash, the one-pass running state), each filed under the card it reduces to; an array-tagged problem whose home is another sheet is a one-row pointer here.

The worked-solution archive behind matrix.md: seventeen problems grouped by the geometry or technique each one turns on — traversal order, in-place transformation, staircase search, grid search, 2D DP, and row-pair compression.

The 2D grid as its own topic — traversal geometry (spiral, diagonal, rotate, transpose), in-place marking, and index↔coordinate arithmetic.

The k-sum family specifically — 2Sum through kSum, the sort-then-converge recursion, and duplicate handling.

The palindrome family — expand-from-center, two-pointer verification, palindromic DP, and Manacher — and how to tell which a problem needs.

Prefix / running sums — subarray sums, 2D prefix sums, prefix + hashmap counting.

The six prefix-sum templates that borrow another structure or another identity: the complement trick, the monotonic deque for arrays with negatives, row-pair compression for 2D, prefix XOR, the sparse difference array via a hash map, and the prefix-sum-on-a-tree counting map.

The sliding-window techniques a first pass should skip: the at-most-K-distinct family, exactly-K counting with a forbidden-element reset or in one pass, several non-overlapping windows at once, and windows whose key is a word rather than a character; the seven must-know templates stay in the main sheet, and the advanced shapes another sheet owns (deque extrema, complement windows, value buckets) are pointers here.

The worked sliding-window LeetCode problems that are not a template's anchor, one problem card each, filed under the template in the main sheet it reduces to; the templates, the concepts and the decision tables stay in the main sliding-window sheet.

The worked string LeetCode problems that are not a template's anchor, each filed as a problem card under the string.md template it reduces to; the concepts, the pattern cards and the anchor problems themselves stay in the main string sheet.

The worked two-pointer LeetCode catalogue, one canonical solution per problem, grouped by the template in the main two-pointer sheet that it reduces to; the concepts, pointer types and templates themselves stay in the main two-pointer sheet.

Digit-by-digit addition across the four input shapes an interviewer will hand you: strings, integers, arrays, and linked lists.

O(1) range update, O(n) rebuild — the inverse of a prefix sum.

The worked-solution archive behind prefix_sum.md: the eight problems the templates do not already solve end to end, grouped by which prefix-sum shape they need.

Substring search only — KMP's failure function, Rabin-Karp rolling hash, and the built-in-indexOf-vs-KMP-vs-hash decision.

The language mechanics of strings: Python slicing and methods, Java String and StringBuilder, character classification and case conversion, char arithmetic, the split/join traps and the build-performance rules — not the algorithms that use them.

Heavier string machinery — suffix structures, Z-algorithm, Manacher, and string-DP — the parts too specialised for the main string doc.

Key→value problem patterns — lookup, grouping, index maps, prefix-sum maps, remapping.

drill 5/16 ok · 4 again · next: LC 347, LC 146, LC 438

LIFO fundamentals and the canonical stack templates: bracket matching, min-stack, the short monotonic-stack form, explicit-stack traversal and the scope/context ledger.

drill 2/12 ok · 5 again · next: LC 155, LC 232, LC 636

The hash-map family's classic LC problems as problem cards, filed under the hash_map.md template each one reduces to; it has no templates of its own.

Cross-collection chooser — which Java / Python container for which job, and the API gotchas of each.

Next greater / previous smaller / span / histogram problems — the stack stays sorted so each element is pushed and popped once.

FIFO fundamentals — BFS queues, deques, circular buffers, queue-backed designs.

The stack-based expression family: the calculators (LC 224 / 227 / 772), decode-string style nesting (LC 394) and postfix / sequential-operand evaluation (LC 150, 682), with the pre_op delay-insert trick that makes operator precedence fall out of a plain stack.

The problem set behind stack.md: the stack problems that are not a template's anchor, each as a problem card under the template it reduces to; the monotonic problems are worked in monotonic_stack.md and only pointed to here.

Hashing internals and counting idioms — hash design, collisions, frequency maps, rolling hash, custom keys.

Sliding-window max/min in O(1) amortised, using a deque that stays monotonic.

Membership, dedup and set algebra — problems where you only need presence, not an associated value.

The worked-solution archive behind set.md: fourteen problems grouped by what the set is being used for — a memory of what has been seen, set algebra, an O(1) index that replaces a scan, or a component inside a larger algorithm.

Pointer surgery on singly and doubly linked lists — reversal, merging, reordering, dummy-head technique, and cycle handling.

drill 4/23 ok · 10 again · next: LC 206, LC 19, LC 143

The problem set behind linked_list.md: each problem filed under the core template it reduces to, as a problem card that names the one step it adds; the templates themselves, and their anchor problems, live in the core sheet.

Two pointers over linked-list nodes — fast/slow cycle detection, middle finding, k-th from end, and offset pointers. No array indexing.

Binary-tree-specific reasoning: which direction DFS state flows (down vs up), plus the 11 structural templates built on that.

drill 13/20 ok · 5 again · next: LC 572, LC 222, LC 652

Ordered trees only — what the left < root < right invariant buys you (O(log n) search, sorted inorder, range pruning, order statistics).

drill 4/12 ok · 5 again · next: LC 230, LC 450, LC 669

Both the heap (the structure) and the priority queue (the ADT it implements), in Python and Java. Formerly split across heap.md + priority_queue.md, which solved the same problems twice.

drill 5/18 ok · 6 again · next: LC 347, LC 23, LC 703

Tree concepts, tree types and traversal-order strategy — the why and which, plus the advanced techniques that are worked here (Morris threading, binary lifting, and re-rooting DP, the home of LC 834). The per-pattern binary-tree templates live in tree2.md.

drill 4/10 ok · 2 again · next: LC 297, LC 99, LC 114

Lowest common ancestor, node-to-node distance, parent-map (bidirectional) traversal and the root-to-leaf path templates — every tree problem whose answer is a path or a meeting point rather than a shape.

drill 8/14 ok · 5 again · next: LC 124, LC 437, LC 1644

The heap patterns a first pass should skip: lazy deletion, sweep-line "alive" heaps, regret greedy, resource-pool allocators, grid best-first search, and the structures beyond a plain binary heap; the six must-know templates stay in the parent sheet.

The BST material a first pass should skip: the lazy O(h)-space iterator, in-order drop detection for a corrupted BST, order-statistic (rank) queries, and the construction variants beyond a sorted array — each with when the simpler bst.md card is enough.

The BST problems that add one step to a template in bst.md, each worked once as a problem card and filed under the card it reduces to; problems a template or an advanced card already works are listed here as pointers, not re-solved.

The problem set for the heap / priority-queue family: each problem filed under the heap.md template it reduces to, with the one step it adds; the templates themselves, and the problems that need an advanced technique, live in the sibling sheets.

Building a binary tree from something flat: two traversal arrays, an index range over one array, or a parenthesised / infix string — the inverse direction of every tree problem that only reads a tree.

An index from every tree pattern to the one card that teaches it, plus the traversal forms no core sheet spells out: iterative pre- and post-order, zigzag levels, the bottom-left value and vertical order.

drill 0/8 ok · next: LC 144, LC 145, LC 103

Turning a tree into a string and back — subtree fingerprints for identity and duplicate detection, and the full encode/decode codec family (parenthesis, comma plus null marker, depth prefix).

The prefix tree — insert/search/startsWith, node layout choices, and the problems where sharing prefixes is the whole trick (autocomplete, word search, XOR trie).

The language mechanics of heaps: every heapq and PriorityQueue call you need, how to fake a max-heap, how to peek without popping, and the traps that come with a partially-ordered container; the algorithms that use them live in the heap sheets.

The binary-tree problem set for the templates in binary_tree.md: each problem is filed under the template it reduces to, with the one step it adds, and the templates themselves are not restated here.

The choose / explore / undo skeleton behind tree path problems and the path state each one carries, with the variants the root-to-leaf cards do not cover: the path to one node (LC 236), implicit trees (LC 386, LC 388); the root-to-leaf cards themselves live in tree_lca_distance.md.

The worked-solution archive behind trie.md: five problems, from building the structure to the grid search where a trie turns "once per word" into one walk.

Redirect only. This file has been merged into heap.md; it exists to point old links at the right sections.

redirect

The main BFS reference: the queue templates, level-by-level expansion, grid and multi-source BFS, and why first visit equals shortest path on an unweighted graph; the heavier variants and the long tail of worked problems live in their own sheets.

drill 4/13 ok · 3 again · next: LC 542, LC 785, LC 752

The main DFS reference: the ten core depth-first templates — tree traversal, grid flood fill, path finding, backtracking, tree modification, post-order aggregation, boundary elimination, shape signatures and weighted-edge traversal — with the recognition table that picks between them.

drill 9/20 ok · 7 again · next: LC 417, LC 124, LC 101

Graph representation, traversal, connectivity, cycle detection and the general graph-problem catalogue.

drill 9/18 ok · 3 again · next: LC 269, LC 785, LC 721

The worked-solution archive behind Dijkstra.md: eleven problems in both languages, grouped by the shape of the search state, since that is what decides whether you need dist[], a second state dimension, or a plain visited[].

Single-source shortest path with non-negative weights, via a priority queue.

Ordering a DAG — Kahn's BFS, DFS post-order, cycle detection, and the scheduling problems built on them.

The problem set behind topology_sorting.md: one problem card per problem, grouped under the template each one reduces to, with no template or theory material of its own.

Disjoint set union — connectivity, component counting, cycle detection in undirected graphs, with path compression and union by rank.

The graph techniques a first interview pass should skip: Tarjan's low-link family (strongly connected components, bridges, articulation points), Euler paths and circuits, and the bipartite extras — parity Union-Find, maximum matching (and the max-flow view of it) and greedy k-colouring.

The BFS techniques a first pass should skip: bidirectional BFS, 0-1 BFS with a deque, multi-source beyond the canonical template, BFS over implicit or augmented state spaces, and all-shortest-path DAG enumeration — the must-know queue templates stay in the main sheet.

The BFS problem set: one problem card per classic level-order, multi-source, state-space and tree-as-graph problem, each filed under the bfs.md template it reduces to — it teaches no templates of its own.

The rare DFS tricks a first pass should skip: two-grid validation, edge-direction tracking, cross-component pair counting, trie-backed wildcard search, post-order distance buckets and N-ary rollups, and trees that arrive encoded as indentation or a parent[] array. Graph theory proper (Tarjan, Euler paths) is in graph_advanced.md.

The problem set for dfs.md: the DFS problems its templates solve, each as one problem card filed under the template it reduces to, plus pointers to the sheet that works a problem when it lives elsewhere.

The problem set for graph.md: one problem card per problem, grouped under the graph.md template each one reduces to, with no template or theory material of its own.

Minimum spanning trees on undirected weighted graphs: the cut property, Kruskal (sorted edges + Union-Find) and Prim (heap or dense array), each traced step by step with its variants, and the problem shapes built on them — complete geometric graphs, a virtual source node, critical edges and bottleneck trees.

Decision doc only, and the one home of the shortest-path comparison — which shortest-path algorithm for which problem shape, and where the naive choice is wrong; Dijkstra.md, Bellman-Ford.md and Floyd-Warshall.md point here instead of keeping their own comparison tables. No full implementations.

Decision doc only — topological sort vs union-find: what each answers, where the naive choice is wrong, and problems solvable by both.

The worked-solution archive behind union_find.md: seventeen problems grouped by what a node represents — a vertex, a grid cell, or a variable carrying a ratio — since that is the only thing that changes between them.

Single-source shortest path that tolerates negative weights, and detects negative cycles. Also the k-hop-bounded variant.

All-pairs shortest path by DP over intermediate vertices — O(V³), dense graphs, transitive closure.

Halving a monotonic search space — the loop-invariant reasoning behind l <= r vs l < r, the boundary (lower/upper bound) templates, rotated arrays, and floating-point and 2D search.

drill 8/20 ok · 4 again · next: LC 300, LC 35, LC 702

Binary searching a range of candidate answers against a monotone feasibility predicate — the canFinish / isValid framing, the minimise-maximum vs maximise-minimum decision, the [max(nums), sum(nums)] boundary recipe, and counting predicates over a value domain.

drill 3/14 ok · 5 again · next: LC 1552, LC 378, LC 2616

The problem set for binary_search.md: each problem filed under the index-space template it reduces to, as one problem card with one canonical solution, plus the few answer-space problems that are not worked on binary_search_on_answer.md.

The card-game algorithm behind O(N log N) longest increasing subsequence: the piles, the tails array they collapse to, recovering the subsequence itself, and the problem family that reduces to it.

Partition-based selection: finding the kth largest, kth smallest or k closest element in O(n) average time by keeping only one side of a quicksort partition, with the partition schemes it can use and the median-of-medians pivot that makes the worst case linear. It owns LC 215's quickselect answer; the heap answer is in heap.md.

drill 3/9 ok · 1 again · next: LC 347, LC 1985, LC 1337

Sorting algorithms and sort-adjacent techniques — comparison sorts and their stability, counting/bucket/radix, quickselect, custom comparators, and cyclic sort.

Divide-and-conquer beyond merge sort — the recursion-with-merge shapes (count-while-sorting, closest pair, matrix D&C, D&C on expressions) and their recurrences.

Redirect only. This sheet was renamed to quickselect.md in Nov 2026; it exists to point old links at the right sections.

redirect

用中文把 0/1 背包從「物品重量價值」一路講到 LC 494／416 的解題流程，重點放在 state 怎麼定義、「拿或不拿」的轉移、以及為什麼內層 loop 一定要倒序；完全背包（Unbounded）與排列／組合的 loop 順序規則不在這裡展開。

Systematic search with undo: the choose/explore/un-choose skeleton, start_idx control, duplicate skipping, pruning, and exactly one canonical template per must-know shape — the long tail of worked solutions and the hard-tier state-carrying templates live in its two satellites.

drill 4/23 ok · 5 again · next: LC 39, LC 17, LC 131

The main DP sheet — state design, the pattern catalogue, and one canonical template per must-know DP family; the worked-solution archive, the rare techniques, and the five heaviest sub-topics live in their own sheets and are linked from here.

drill 11/30 ok · 14 again · next: LC 91, LC 139, LC 300

The knapsack family in full: 0/1 vs unbounded vs bounded vs group, the subset-sum reduction, why the 0/1 inner loop runs backward, and the loop-order rule that separates combinations from permutations.

drill 2/13 ok · 6 again · next: LC 322, LC 416, LC 279

Hard-tier backtracking that carries extra state through the recursion — a Trie node, the previous operand, a deletion budget — plus constraint propagation, memoised search and the generic partitioning templates a first pass should skip; none of the must-know shapes are repeated here.

The DP appendix — techniques a first pass should skip: game-theory / minimax DP, tree and re-rooting DP, interval and string DP deep dives, probability and step-indexed counting DP, monotonic-queue and stack-carried DP, and the long-form derivations trimmed out of the main sheet.

Why a bottom-up DP's loop nesting and direction are forced by its own transition, the four ways a wrong order fails, and LC 139 Word Break worked in five orders — including the one that looks right, passes "leetcode", and silently fails the problem's own Example 2.

Template index — one short section per classic DP pattern (Kadane, LIS, MCM, LCS, knapsack, state machine, grid, bitmask, digit, tree DP, regex, interval scheduling, split, memoised DAG).

Recursion as a mechanism — base case, state passed down vs returned up, call-stack cost, and converting to iteration. The pattern families that use recursion each have their own file.

The mechanical pipeline: recursion → memoisation → tabulation → space-optimised, applied to one problem at a time.

DP over one or two strings: the dp[m+1][n+1] two-sequence grid, prefix-based (1-indexed) table design, and the worked patterns for LCS, edit distance, interleaving and wildcard/parenthesis matching.

The backtracking problems that are not a template's anchor (LC 17, 784, 996, 93, 140, 980, 22), each as a problem card filed under the backtrack.md template it reduces to; the anchors themselves are worked on their cards there, and this sheet teaches no templates of its own.

DP where the state is a subset encoded in an integer: mask operations, submask enumeration, TSP and assignment templates, and the n <= 20 sizing rule.

The classic DP problems that are not a template's anchor (LC 343, 91, 62, 279, 276, 1137), each as a problem card filed under the dp.md template it reduces to, plus an index of where every other common DP problem is worked; no templates or theory of its own.

The maximum-subarray family in depth — Kadane and its variants (product, circular, with deletion, 2D).

Problems where a monotonic stack carries a DP value: "how many rounds does this element survive", largest-rectangle-style area DP, and the maximal-square / count-squares grid recurrences.

The LC 121/122/123/188/309/714 buy-and-sell family, unified under one dp[i][k][hold] state machine.

Counting how many numbers in a range satisfy a digit-level property: the tight/started/position state, the universal top-down template, and the count(R) - count(L-1) range trick.

Taking the locally best choice and the exchange argument that proves it safe — interval scheduling, jump games, task assignment — plus how to spot when greedy fails and DP is required.

Sort-then-merge interval problems — merge, insert, count overlaps, minimum removals.

The worked-solution archive behind greedy.md: fourteen problems grouped by the shape of the greedy choice — extend a reach, accumulate and reset, interleave by frequency, sort and take, or commit while scanning.

Line sweep — turn each interval into +1 / -1 events, sort by coordinate, sweep once.

The worked-solution archive behind scanning_line.md: six problems grouped by what the sweep is actually counting — overlap depth, a weighted sum, a heap of live jobs, or the intersection of two sorted lists.

Redirect only. This sheet was renamed to array_overlap_explanation.md in Nov 2026 to fix the misspelt filename; it exists to point old links at the right sections.

redirect

One idea only — the interval-overlap predicate: closed [a,b] vs half-open [a,b), and which one each LC problem needs.

The Fenwick tree specifically — i & -i index arithmetic, point update + prefix query, and the problems it is the tidiest answer to.

Range query + range update structures — the segment tree, lazy propagation, and the BIT-vs-segment-tree-vs-merge-sort decision.

What to do when the input does not fit in RAM: bit vectors, bucket-then-refine passes, sharding a file by hash, and external merge sort — the techniques that still return an exact answer by paying with extra passes.

Algorithms constrained to one pass and sub-linear memory — reservoir sampling, Boyer-Moore majority, weighted random pick, and approximate counting.

How integers are represented in bits (two's complement, fixed width, shifts) and the operations and tricks built on that — masks, XOR identities, lowest set bit, subset enumeration, and bitmask DP.

The worked-solution archive behind bit_manipulation.md: nineteen problems grouped by which property of the bit operators they lean on — XOR cancelling pairs, clearing the lowest set bit, carry-free arithmetic, an integer standing in for a subset, or a hand-built mask editing a bit field.

Numeric manipulation in interviews — digit extraction, overflow-safe arithmetic, base conversion, roots, and pow. Formula-level counting lives next door.

Counting and number theory as they appear in interviews — modular arithmetic, GCD/LCM, sieves, nCr, reservoir sampling, and basic geometry.

The four moves that solve brainteaser-style questions: counting how much information one test buys, balancing the worst case, finding the invariant, and using linearity of expectation. It teaches the moves, not a riddle list.

The worked "design a X" problems behind design.md, one problem card each, filed under the structure pair (design.md's patterns) that each one forces.

LC "design a X" problems — reading the required operations off the problem and picking the structure combination that makes every one of them O(1) or O(log n); the worked designs themselves live in the examples sheet.

The low-level-design round — class modelling, SOLID, and the design patterns interviewers actually ask for (strategy, observer, factory, state), with worked designs.

The iterator contract — hasNext/next with lazy state, flattening, peeking, and merging — one idea, in isolation.

The distributed-systems patterns that get asked as coding questions — consistent hashing, token-bucket and leaky-bucket rate limiting, and the load-balancing algorithms — with runnable implementations and the trade-offs an interviewer follows up on.

The handful of Java concurrency problems that appear at L4+ — ordered printing, producer/consumer, read-write coordination and deadlock avoidance — plus the primitives they need.

Problems where the answer is the faithful step-by-step execution — state machines, robot/grid walks, game rounds, iterative rewriting — plus how to keep such code shrinkable.

What every Python built-in and container operation actually costs, and why: the per-call tables for the built-in functions, list, str, dict/set, tuple, deque, heapq, bisect and int, the CPython layout each cost follows from, and the seven idioms that quietly turn an O(n) solution into an O(n²) one.

The Java library APIs for holding data: arrays and 2D arrays, lists, maps, queues, heaps, stacks and pairs — how to initialise, copy, iterate and index each one, and the traps in doing so.

Java String and StringBuilder work — converting to and from char[], slicing, parsing, building and mutating — together with everything comparator-shaped: array, collection and map sorting, and the return-value rules that decide the order.

The Java language semantics that decide whether a correct algorithm produces a correct answer: characters as integers, value vs reference, and integer arithmetic. The library APIs live in two companion sheets.

The two things that produce most wrong answers in Python solutions that are otherwise correct: where an insertion actually lands, and whether an index range means a count or a distance.

The library-by-library reference: heapq, sortedcontainers, the built-in sort (sorted / list.sort), bisect, collections, itertools, functools and datetime — the calls, their complexity, and the idiom each one exists to replace.

The Python language idioms that come up while solving problems — copying, string handling, sort keys, integer arithmetic, comprehensions and scope — grouped by what you are trying to do. The standard library, the index arithmetic and the cost of each operation have their own sheets.

Python behaviours that silently cost you a passing submission — mutable defaults, closure late-binding, integer caching, copy semantics — plus the GIL and Python's concurrency story.

Lookup tables — Big-O of every common data structure and classic algorithm, plus the math intuitions behind them.

The front door: from a problem statement to the card that solves it — the signal in the wording, the constraint cue, the pattern, a link to its card, and the look-alike that is not it. A router only: every template lives in the card a row links to.

drill 14/27 ok · 11 again · next: LC 206, LC 322, LC 347

Walkthroughs — how to argue the complexity of an actual LC solution, one classic per technique.

20 self-test drills — read the snippet, state the complexity, check yourself.

Redirect. The six-step interview loop moved into lc_pattern.md, which is the page you actually open when starting a problem.

redirect

A pointer to the wisdompeak problem taxonomy, and a map from its 29 categories to the cheatsheet in this repo that teaches each one. The taxonomy itself is not mirrored here.

redirect