You use these every day.
You've never seen them run.

Here's the trick that makes it fast: always expand outward from the nearest unfinished node first. Keep a running best-guess distance to every node and a priority queue ordered by that guess. Pop the cheapest one — and here's the magic — because every edge cost is non-negative, nothing you discover later can ever undercut it. No detour through a farther node can loop back and beat a node you've already reached most cheaply. So the moment a node comes off the queue, its distance is permanently settled — proven optimal, never revisited. Each settled node then "relaxes" its neighbors: if going through me is cheaper than their current guess, lower it. You settle nodes in a widening ring of certainty, touching each edge just once. That's why a whole city resolves in milliseconds.

A* adds one number to each node: h, a cheap straight-line "as-the-crow-flies" guess of how far the goal still is. Instead of ranking nodes by cost-so-far g, it ranks them by f = g + h — money already spent plus optimism about what's left. That single addition tilts the whole search toward the goal, like a hiker who always steps toward the mountain they can see. The magic is why it stays correct: as long as h never overestimates the real remaining distance (straight-line distance can't — the road is never shorter than the crow's flight), A* is mathematically guaranteed to return the true shortest path. It's not a heuristic shortcut that "usually works" — it's Dijkstra with a compass bolted on, provably optimal and dramatically faster.

The trick is to stop measuring kilometers and start measuring an angle — the angle between the two points as seen from the Earth's center. Once you have that central angle, the surface distance is just angle times radius, the same rule as an arc on any circle. Haversine's clever move is a numerically-stable way to get that angle from raw lat/long: it builds a quantity a from the half-differences of latitude and longitude (the "haversine" of each gap), squaring sines so everything stays positive and well-behaved even for tiny nearby points. Then atan2 turns a back into the central angle c, and multiplying by Earth's radius (6371 km) gives the great-circle distance. The whole planet's geometry collapses into six lines of arithmetic — no trig tables, no map projection, no square-rooting your way through 3D space.

Bresenham never computes the true y. Instead it carries one integer, D, that measures how far the real line has drifted above the current pixel's center — but scaled up by 2·dx so the fraction vanishes and everything stays a whole number. Each step right adds the rise 2·dy to D (the line climbed a little). The instant D crosses zero, the true line has drifted past the halfway line to the next row, so we step y up and subtract 2·dx to re-center the accountant on the new pixel. That's the whole trick: the sign of one running integer answers "is the line now closer to the row above?" using only adds, subtracts, and a compare-to-zero — no multiply, no divide, no float, ever, in the inner loop.

The trick is that connectivity is transitive, and you can chase it with a to-do list. Keep a stack of cells to inspect. Pop one; if it is still the target color, repaint it and drop its four neighbors onto the stack — you do not check whether they belong yet, you just promise to look later. Two things make this bulletproof. First, the repaint is the visited-mark: a filled cell fails the "still open?" test the next time it is popped, so the flood can never loop and every reachable cell is touched exactly once. Second, wall cells are never the target color, so when they surface they are popped and thrown away — which is precisely why the fill halts at the outline with zero boundary-detection code. Swapping recursion for an explicit stack moves the frontier from the fragile call stack into ordinary heap memory, so a giant region costs RAM, not a crash.

A trie flips the cost from "how big is the dictionary" to "how long is your prefix." Instead of storing words as separate strings, it stores them letter by letter as a tree of nested maps: every word that shares a prefix shares the same physical path down the tree, so cat, car and card all walk through the one c → a branch before splitting. To autocomplete ca you don't search at all — you take exactly two hops, c then a, landing on the single node that is the shared prefix. Now every completion lives in the subtree hanging off that node, and nothing else in the dictionary can possibly match. A tiny end-of-word marker ('#') tags which paths are real finished words, so collecting the suggestions is just gathering the marked leaves below where you stand. The dictionary could hold a billion words and reaching the ca node still costs two hops.

The trick is to stop thinking about whole words and think about prefixes. Define one number, dp[i][j]: the cheapest way to turn the first i letters of A into the first j letters of B. Now stare only at the last move of the best alignment — it can be exactly one of three things: match or substitute the final letters (step diagonally), delete A's last letter (step down), or insert B's last letter (step left). Whatever that last move is, everything before it must itself be an optimal alignment of the smaller prefixes — so each cell is just min(delete, insert, substitute) of its three already-solved neighbours, plus 0 if the two letters happen to match. Because millions of long alignments share the same little prefix subproblems, you solve each of the n×m cells once, and the exponential search collapses into a grid you fill left-to-right, top-to-bottom.

The trick is to throw away the vowels and the spelling entirely and keep only the skeleton of consonant sounds — because vowels are precisely what drift between spellings, while the sequence of consonant articulations stays stable. Soundex buckets consonants your mouth forms almost identically into one digit: lip sounds b, p, f, v → 1; hisses and clicks c, s, z, k, q, x → 2; and so on. It keeps the first letter as an anchor, then squashes any run of the same code down to a single digit, so a doubled or silent letter can't change the answer. What's left — one letter plus three digits — is a phonetic fingerprint, and now "sounds the same" has become "equal string," which any database index answers in one hop.

Here's the trick: when the pattern mismatches after matching a run of characters, those already-matched characters ARE text you've read — so you already know them for free. If the matched prefix has a piece at its end that also appears at its start (a "border"), then that border is already aligned with the text; you can slide the pattern forward to reuse it instead of rescanning. KMP precomputes, for every position in the pattern, the length of the longest such border — the LPS table — in one linear pass over the pattern alone. Then during the scan the text pointer never moves backward: on a mismatch it doesn't rewind the text, it just drops the pattern pointer j to lps[j-1] and keeps going. Because i only ever advances, and j rises at most once per step and can only fall back total-times-it-rose, the whole search is linear — you read each text character essentially once, forever.

Turn every window of text into a single number — a polynomial hash, like reading the characters as digits in base 256. If two windows have different numbers, the strings are definitely different, so one integer comparison rejects a mismatch instead of m character checks. The magic is the word rolling: when the window slides one step right, you don't recompute the number from scratch. The outgoing character contributed c · base^(m-1) to the total, so you subtract exactly that, multiply the rest by base to shift every remaining digit up a place, and add the incoming character — all arithmetic kept small with mod M. That's O(1) per slide regardless of how long the pattern is. Because mod can make two different strings collide, a hash match only means "maybe" — so you verify the actual characters just once, on the rare hit. Billions of positions, each dismissed by one subtraction and one addition.

Here's the trick that dissolves the circularity. Picture a random surfer clicking links forever; PageRank is just the fraction of time they spend on each page. A page splits its own importance evenly among its out-links and passes it along — so a link from a heavyweight is worth more than a link from a nobody, automatically. You don't solve the circular equations directly; you guess (everyone starts at 0.25), then let importance flow through the links once, and again, and again. Each round the numbers lurch, then wobble less, then stop moving — they've found the one distribution that reproduces itself, the network's fixed point (mathematically, the dominant eigenvector of the link matrix). The magic: you land on the same ranking no matter where you started. The damping factor (0.85) models the surfer occasionally teleporting to a random page — that one tweak rescues dead-ends like page D and guarantees the whole thing converges.

Split "importance" into two forces that multiply. Term frequency (TF) asks: how much does this word fill this document? Inverse document frequency (IDF) asks: how surprising is the word across the whole corpus, computed as log(N / df) where df is how many documents contain it. The magic is the log ratio: a word in all N documents gets log(N/N) = log(1) = 0 — multiply by zero and it vanishes, automatically, with no hand-built stopword list. A word in just 1 of 3 documents gets log(3/1) ≈ 1.099, a big weight. So the silences itself and cat shines — purely from arithmetic. The corpus itself decides which words are noise.

Picture each person as an arrow in "ratings space": Alice's arrow points to [5,3,0,1], Bob's to [4,0,0,1]. Cosine similarity throws away how long each arrow is and measures only the angle between them. The dot product on top rewards every dimension where both people lean the same way; dividing by the two magnitudes below cancels out the raw loudness of their scores, leaving pure direction. So a harsh critic who rates 5,3 and a generous softie who rates 4,2 collapse onto the same arrow and score a perfect 1.0 — because taste is direction, not volume. That one division turns the fuzzy question "do these two agree?" into clean geometry: the closer the angle to 0°, the closer the taste.

The trick is to make every commitment tentative until the music stops. Men propose down their list in order, never asking the same woman twice; each woman simply holds her best offer so far and throws back anything worse — but she can dump a fiancé the instant someone better knocks. The magic is monotonicity: a woman's held partner only ever gets better, and a man's target only ever gets worse. That single fact does two jobs at once. It forces termination — each man can be rejected only finitely often before he exhausts his list — and it kills every blocking pair. Because if some man secretly preferred a woman to his final partner, he'd have proposed to her earlier (he works top-down), and she'd have either kept him or dumped him for someone she liked even more. Either way she already holds a man she prefers to him — so no couple can profitably defect. Stability isn't checked at the end; it's manufactured by the order of proposals.

Elo's trick is to turn the rating gap into a probability. It runs the difference (B − A) through a logistic curve, so expected_A is literally "the chance A should win" — and the scale is tuned so every 400 points means 10× the odds. Then it does the only fair thing: reward the surprise. Your new rating moves by K × (what happened − what was expected). Beat someone you were 64% likely to beat and you barely rise (+11); pull off an upset and you leap. The beauty is it's self-correcting and zero-sum: the points A gains are exactly the points B loses, and once your rating matches your true skill, expected equals actual on average and you stop drifting. The number finds its own level, no database required.

RSA splits the key in two using a one-way street in arithmetic. Pick two primes and multiply them: 61 × 53 = 3233. Publishing 3233 and a public exponent e = 17 is safe, because encryption is just c = m^e mod n — easy to run forwards, but to reverse it you'd need the private exponent d. And here's the hinge: d can only be computed from φ = (61−1)(53−1) = 3120, and getting φ requires knowing the two original primes — i.e. factoring n back apart. Multiplying two primes takes a microsecond; splitting a 617-digit product back into its primes would outlast the universe. So the public key locks (65 → 2790) and the private key — riding on the same modular symmetry e·d ≡ 1 (mod φ) — unlocks (2790 → 65), yet neither reveals the other. The lock is public; the key is a secret nobody can back-solve.

The trick is a math operation that's cheap forward and ruinously expensive backward. Both sides publicly agree on a base g=5 and a modulus p=23. Alice keeps a secret a=6 and shouts her mixed color A = 5⁶ mod 23 = 8; Bob keeps secret b=15 and shouts B = 5¹⁵ mod 23 = 19. Now the magic: Alice raises Bob's number to her secret, 19⁶ mod 23; Bob raises Alice's number to his, 8¹⁵ mod 23. Both are really 5^(6·15) mod 23 — the same number, 2 — because exponents commute. The eavesdropper heard 5, 23, 8, and 19, but to find the shared secret they'd have to undo mod exponentiation and recover a or b — the discrete logarithm problem, which has no known fast solution. Forward: one pow(). Backward: brute-force every exponent.

The trick is you never build the giant number, and you never do that many multiplies. Two ideas combine. First, take the remainder after every multiplication — since (a·b) mod m = ((a mod m)·(b mod m)) mod m, the running numbers never grow past the modulus. Second, read the exponent in binary: 13 = 1101₂ = 8 + 4 + 1, so 7¹³ = 7⁸ · 7⁴ · 7¹. Each of those powers is just the previous one squared — 7¹→7²→7⁴→7⁸ is four squarings, not thirteen multiplies. So you walk the exponent's bits: square the running base every step, and fold it into the answer only where a bit is 1. A 2048-bit exponent collapses from ~2²⁰⁴⁸ multiplications to about 2048 squarings.

The trick is to give alternating positions different weights: walking from the right, every second digit gets doubled before it joins the sum. Now position matters — a digit in a "doubled" slot contributes differently than the same digit in a "plain" slot, so swapping two neighbours shifts the total and breaks the check. The doubling can overflow past 9, and the fix — "subtract 9 if it's over" — is secretly just summing the digits of the doubled value (18→1+8=9, 12→1+2=3), which keeps every contribution a clean single digit. Finally, a valid number is engineered so the whole weighted sum lands on a multiple of 10; change any one digit and you knock the total off that multiple, so total % 10 == 0 instantly fails. One elegant alternating double turns a dumb sum into a position-aware error detector.

The fix is one extra scrap of text — a salt — glued to the password before hashing. A hash is a one-way blender: easy to run forwards, effectively impossible to reverse. The database stores only hash(salt + password) plus the salt in the clear. To check a login, it re-blends the salt with whatever you just typed and compares the two digests — it never needs the original password back, so it never keeps it. The magic is the salt being different per user: hunter2 salted with a1b2 and the same hunter2 salted with z9y8 blend into two totally unrelated digests. That single change detonates the attacker's economics — their one precomputed rainbow table is now worthless, because they'd need a fresh multi-terabyte table for every salt, i.e. for every single user. They're forced back to guessing one account at a time.

Build the tree from the bottom up by a shockingly simple rule: repeatedly grab the two rarest symbols and fuse them into one node whose frequency is their sum. Do it again and again until one tree remains. Two things fall out for free. First, because the rarest pair is merged earliest, they end up deepest in the tree — longest codes — while frequent symbols float near the root and get the shortest codes. Second, every real symbol is a leaf, never on the path to another symbol, so no code can ever be a prefix of another — decoding is never ambiguous. Label every left branch 0 and every right branch 1, walk root-to-leaf, and read the code straight off. The twist: you construct it from the rarest symbols upward, but you read it from the top down — and a greedy exchange argument proves this "merge the two smallest" gives the mathematically optimal number of bits, every time.

Here's the click: 3 bytes are 24 bits, and 24 divides evenly by 6. So instead of reading the bits in the usual 8-at-a-time grid, you re-slice the exact same bits into four groups of 6. Why 6? Because 6 bits count from 0 to 63 — exactly 64 values — and 64 is precisely how many safe, printable characters you can agree on (A–Z, a–z, 0–9, plus + and /). Each 6-bit chunk becomes an index into that alphabet, and out pops one harmless letter. You're not compressing and not encrypting — you're re-tiling the same bits onto a coarser grid where every tile has a printable name. The number 24 is the magic: it's the least common multiple of 8 (bits per byte) and 6 (bits per character), so the two grids line up perfectly every 3 bytes.

Hamming's move is to use several parity bits, each guarding a different overlapping subset of positions — chosen so every position gets a unique fingerprint. Place the parity bits at the power-of-two positions 1, 2, 4; the parity at position 2ᵏ checks exactly those positions whose index has bit k set. So position 6 (binary 110) is watched by parity-4 and parity-2, but not parity-1. When one bit flips, precisely the checks that cover it fail — and if you read the failed checks back as a binary number, they spell out the position of the guilty bit. The parities don't merely shout "wrong!", they vote in binary, and the votes literally are the address of the broken bit. Flip that one bit back and the data is whole again — no resend.

Here's the trick: treat the entire message as one gigantic binary number and divide it by a fixed divisor — the remainder is your fingerprint. But it's a special arithmetic with no carries, where subtraction is just XOR. So "long division" collapses into something a child could do: wherever the leading bit is 1, XOR the divisor in and slide along; wherever it's 0, skip. The remainder is only a few bits, yet it depends on every bit of the message, because each XOR ripples its effect forward down the whole number. Now the beautiful part — append that remainder to the message and the combined codeword becomes exactly divisible by the divisor. So the receiver doesn't need to know the answer in advance; it just divides again and expects a remainder of zero. Any burst of errors shorter than the divisor mathematically cannot divide evenly, so it can never fake a zero by accident.

Here's the trick: sorting the rotations sorts each character by the text that follows it. In English every 't' that precedes "he" ends up next to every other such 't' — so in the last column of the sorted table, all those t's stack into one long run. Scattered letters become the repetition a compressor devours. And the shuffle is perfectly reversible: the last column holds, for each sorted rotation, the character that precedes its first character, so a single stable sort of that column reconstructs the whole chain of "what came before" and walks the original string back out — not one bit lost. You rearranged the text into something near-repetitive without destroying it.

Here's the trick: don't store the items at all — store fingerprints of them in a shared bit array. Each item is run through a few fixed hash functions, and each hash points at one slot; adding an item just flips those slots to 1. To check membership, you look at the same slots. If any of them is still 0, then this item was never added — because adding it would have forced that bit to 1. That's the magic asymmetry: a 0 is a mathematical proof of absence. The filter can never miss something that's really there. It can be fooled the other way — a stranger's bits might collide with slots earlier items already lit up, giving a false "maybe" — but it will never wrongly say "no". So it's the perfect bouncer at the door: it lets you skip the expensive database lookup entirely for the huge majority of things that definitely aren't there, and only the rare "probably yes" gets the slow, careful second check.

Reservoir sampling keeps a single slot. When the i-th item arrives, it replaces whatever's held with probability exactly 1/i. Grind the algebra and every item — the first and the millionth alike — ends up with an identical 1/N chance of being the survivor, in one pass using O(1) memory. It stays fair without ever learning how long the stream was.

Stop hashing keys to servers. Instead, hash both onto the same circle — a ring of positions 0..99. Each server lands at a fixed spot; each key lands at its own spot and is owned by the first server you meet walking clockwise. Now the trick: a server only owns the arc between it and its neighbor. So when you add a new node, it drops onto one point of the ring and steals just the keys in that single arc from one neighbor — everybody else's keys never move. You've turned "remap almost everything" into "remap one slice," because ownership is defined by local neighbors on a circle, not by a global count N that every key depends on.

Picture a duel. You keep one candidate and a count of its un-cancelled copies. Every element that isn't the candidate steps forward and annihilates one copy of it (count minus one); every matching element reinforces it (count plus one). When the count hits zero, everyone so far has paired off and mutually destroyed — so you adopt the very next element as the fresh challenger. Here is why it's guaranteed to work: if one value truly holds a strict majority — more than half of everything — then even in the worst case where every other element pairs off and cancels one of its copies, there are simply more of the majority than there are cancellers. It cannot be fully annihilated. The last one standing must be it. And the punchline: count is not how many times the majority appeared — it's how many of its copies survived all the cancellations. One pass, one candidate, one integer.

Fisher-Yates fixes the bias with one disciplined rule: walk from the last slot down to the first, and swap each card only with a card at or before it — never one already locked in. Each position then draws a truly uniform pick from the shrinking pool of unplaced cards, so all n! orderings come out exactly equally likely — provably, in a single O(n) pass.

Sort by finish time, then repeatedly take the next meeting that starts after your last pick ends. The magic is why earliest-finish is unbeatable: whichever meeting ends first leaves the maximum amount of runway free for everything after it. So there is always an optimal schedule that includes it — if some other optimal schedule skipped it, you could swap that schedule's first meeting for the earliest-finishing one without losing a slot, because it frees up at least as much room. That swap argument means the greedy choice never paints you into a corner; each locally-first-to-finish pick provably extends to a globally maximum set. One pass, no backtracking, guaranteed best answer.

Here's the trick that makes it fall out in one pass. For each task, count its in-degree — how many prerequisites still point at it. A task whose in-degree is 0 has nothing blocking it, so it's safe to schedule right now. The magic is what happens when you finish it: completing a task removes exactly one arrow from each of its dependents, so you just decrement their in-degrees. Any dependent that drops to 0 has, in that instant, become unblocked — add it to the ready pile. It's a chain reaction of "you're cleared to go" rippling outward along the arrows. Each node and each arrow is touched once, so it's linear time, not factorial. And the cycle detector is free: if the ready pile empties while tasks remain, those leftovers all point at each other in a loop — the same machine that orders the schedule proves when no schedule can exist.

Stop enumerating bags. Instead keep one number per capacity: dp[c] = the best value you can pack into c kilos. Now add items one at a time. For a new item of weight w, value v, the best bag of size c is just the better of two choices — skip it (keep the old dp[c]) or take it (dp[c−w] + v, reusing the already-solved best packing of the leftover room). Because dp[c−w] is itself already optimal, the new dp[c] is too: every answer is built from smaller answers you've already nailed, so nothing is ever re-guessed. The one subtle move is to sweep c from high down to low — that keeps dp[c−w] pointing at a bag made without this item, which is exactly what forbids using the same item twice and makes it 0/1. The whole thing costs items × capacity, not 2ⁿ.

Union-Find refuses to remember friendships at all. Instead every element points at a representative, forming little upward-pointing trees, and the only fact that matters is: two elements are connected exactly when they climb to the same root. Merging two groups is then a single pointer flip — hang one root under the other — and a connectivity query is just “walk up, compare roots.” The magic is path compression: while you're climbing to find the root anyway, you re-point every node you pass directly at the root, so the tree collapses flatter each time you touch it. Do that (with union-by-size) and the amortized cost per operation is the inverse Ackermann function α(n) — a number that stays below 5 for any n you could physically store. Effectively O(1), forever.

Kruskal fuses two ideas. First, greedy by weight is provably optimal here: by the cut property, the cheapest edge crossing any split of the nodes must belong to some minimum spanning tree — so taking the globally cheapest safe edge never has to be regretted later. Second, and this is the sleight of hand, it tests "are these two ends already connected?" in almost constant time using Union-Find. Every node points to a representative of its group; find() just follows those pointers up to the group's root. Two nodes are connected if and only if they share the same root — so a cycle is exactly the case where both endpoints already report the same boss, and you skip it. Adding an edge is equally cheap: point one root at the other, and two groups instantly become one. You never traverse the graph — you only ever compare and merge roots.

Here's the whole trick, and it's almost unfair how simple it is. Walk left to right carrying one number, cur: the best sum of any run that ends exactly here. At each new value x you face one binary decision — extend the run you were building (cur + x), or throw it away and start fresh at x. You pick whichever is bigger: cur = max(x, cur + x). The genius is why you can forget the past: the instant cur goes negative, any run carrying it forward is strictly better off cutting it loose — a negative prefix can only drag down whatever comes next, so it's provably safe to discard, forever. A separate best just quietly remembers the high-water mark of cur as you pass. One variable decides, one variable remembers, and a single left-to-right pass — O(n) time, O(1) memory — nails the optimal window out of the ~n²/2 possible ones without ever looking back.

Two moves turn this inside out. First, take the logarithm of each rate: because log turns products into sums, a loop's profit (a product of rates) becomes a sum of logs. Negate them, and a profitable loop (product > 1) becomes a cycle whose edge-weights sum to a negative number. Suddenly "find free money" is literally "find a negative cycle in a weighted graph." Second, Bellman-Ford finds negative cycles almost for free: relax every edge V−1 times and all true shortest distances settle. Then try one more pass — if any distance still drops, no finite shortest path exists, and the only thing that can keep shrinking a distance forever is a negative cycle circling underneath. That single extra relaxation is the alarm bell for arbitrage.

Look at two neighbouring windows: [10,12,14] then [12,14,13]. They share everything but two numbers — one old value slid out the left, one new value slid in the right. So you never need to re-sum. Keep a single running total; at each step subtract the value that left and add the value that arrived (total += new - old). That's one subtraction and one addition per output — O(1) regardless of window size, whether the window is 3 or 3 million. The whole trick is realising the overlap between adjacent windows is the answer you already computed.

Turn "find √2" into "find where the curve f(x) = x² − 2 crosses zero." From any guess, follow the curve's tangent line straight down to the axis — where it lands is your next guess. For square roots that tangent step collapses into something you can do in your head: x → (x + 2/x)/2, the plain average of your guess and 2/guess. Here's why it can't miss: if x is too big, then 2/x is too small (they multiply to exactly 2), so √2 is always trapped between them — and their midpoint is closer than either. The real magic is the rate: each step roughly squares the error, so correct digits go 1 → 3 → 6 → 12 → done. Accuracy doubles per stroke.

Send two walkers down the same path: a tortoise that steps one node at a time and a hare that steps two. If the path is a straight dead-end line, the hare just runs off the end — no cycle. But if the path bends back into a loop, both get trapped circling inside it forever, and here's the magic: the hare gains exactly one step on the tortoise every tick. Their gap grows 1, 2, 3, … and because they're on a ring of fixed size, that gap is really measured modulo the loop length — so it must eventually hit zero. When the gap is zero, they're standing on the same node. A collision is mathematically guaranteed, and it needs just two integer pointers — no list of visited nodes, no memory that grows with the input.