Problem-solving

What this codex is for

Senior software engineer interviews. FAANG, Citadel, Stripe, Two Sigma, Databricks, Anthropic. L5 and above. The audience is somebody already shipping production code at one company who wants to be ready for an onsite at another within 3–6 months. Comfortable with one language, knows what a hash table costs, has written a recursive function that worked.

The expected prep volume is roughly 150–500 problems across 12–20 weeks, depending on rust level and target band. Lower end if you've shipped algorithmically dense code recently. Upper end if your last LeetCode submission was in college. Either way: the pages here assume the reader is willing to spend at least 6 weeks of focused effort and isn't looking for a five-day cram.

This path is also the heart of the apprenticeship's long middle. If you're coming to it from zero rather than from a senior loop, start with task five of the apprenticeship instead — it walks these same patterns on a ten-week budget, with the on-ramps built in.

What this codex is NOT

• Not a CS101 introduction. "What is a linked list" lives on Wikipedia. The data-structure pages here are cost-model references, not first-principles teaching material. If you've never written a function before, this is the wrong site.
• Not a beginner curriculum. Problems start at LC medium difficulty and trend up. Easy problems exist on the canonical lists but are used as warm-ups, not the core material.
• Not a top-100 grinding plan. The patterns-first inversion is deliberate. Grinding the top 100 without pattern classification produces low-retention reps; the codex pushes you to name the pattern before writing code.
• Not a system-design path. System design is the other half of every senior loop and has its own codex — see /codex/system-design/. Cross-link both during prep; don't treat coding as the only signal.
• Not company-specific. "Top 50 Meta problems" lists exist on LeetCode Premium and Glassdoor; the codex is one layer up — the patterns those lists are sampling from. Use both together.

The four phases of preparation

A 12–14 week structured plan. Each phase has a specific objective, daily volume, and exit signal. Don't skip phases by impatience — a candidate who tries to do phase 3 work in week 1 produces low- signal reps and burns out by week 4.

How to use this codex effectively

The codex is structured as a stack: methodology underneath, patterns on top, data structures as side references. Read in that order. The most common failure mode is jumping straight to the pattern pages, grinding 200 problems, and discovering at week 8 that the methodology — spaced repetition, the 20-minute rule, mocks from week 4 — was the part that actually mattered.

1. Read the methodology page first. Before any pattern. 10 minutes to read; the protocol it defines applies to every problem you'll solve over the next 12 weeks. Skipping it is the most common reason candidates do 200 problems and still freeze.
2. For each pattern: read the page top to bottom. Don't skim. The "how to recognise it" section is the single highest-use paragraph; internalise the tells. Take 30 minutes per page — they're dense.
3. Solve the canonical 3–5 LC problems listed on the pattern page. These are chosen as the minimal set that covers the pattern's variants. Solve cold, narrate aloud, time yourself.
4. Then 10–15 more from external lists. Neetcode 150, Grind 75, the LeetCode tag for that pattern. Don't burn through them; use spaced repetition.
5. Finish each pattern with 1–2 hards. Not to grind hards generally, but to stress-test whether you understand the pattern's edges. If a hard feels impossible after 3 mediums, it usually means your medium fluency wasn't deep enough — revisit.
6. Track in a spaced-repetition system. See the methodology spaced-repetition section: touches at day 3, 7, 21, 60. Wrong on review? Restart at day 3. The schedule is the lever.
7. Once a week: "explain it back". Pick three graduated problems. Narrate them aloud as if to an interviewer (recorder on). If you stumble — re-solve. The narration layer is where fluency cracks first under interview pressure.

The 25 patterns at a glance

A flat reference index. Twenty-five patterns, three tiers by frequency. Tier A — every senior interview asks at least one. Tier B — you'll see at least one across a typical 4-round loop. Tier C — niche but distinctive when they appear. LC counts are approximate (LeetCode tag totals, rounded) and useful as relative density signals, not absolute targets.

Tier A patterns alone cover roughly 70–80% of LC mediums. Tier B adds another ~15%. Tier C is the long tail — important for FAANG-tier hards but skippable for non-FAANG loops.

Pattern frequency in interviews

Rough share of typical interview pools. Numbers below are averaged across published company-tagged LC lists (Meta, Google, Amazon circa 2024–2025); your single-company exposure will differ, but the ranked order is stable across companies.

The "long tail" — backtracking, heap, monotonic stack, greedy, union-find, trie, topo sort, bit, linked list, tree DP, graph algos, math, segment tree, string matching, advanced DP, computational geometry, advanced graph — collectively make up the remaining ~21%, but no single one of them dominates the way hash map does.

Real-world signal — where these patterns show up in production code

LC patterns aren't toy puzzles; they're the algorithmic primitives powering the systems you ship. The interview is sampling for "can this candidate recognise these primitives in a new context" — the same skill that distinguishes engineers who write the obvious O(n²) loop from those who notice the union-find lurking in a deduplication pass. Anchors:

• Hash maps in caching. Redis, Memcached, Caffeine, Guava cache — every cache implementation is a hash map with eviction policy bolted on. The "two-sum" pattern is the same complement-lookup trick a cache uses to find an entry by key.
• Two pointers in stream merging. Kafka log compaction merges sorted segment files using two-pointer iteration. So does LSM-tree compaction in RocksDB and LevelDB. So does the merge step of external sort. "Merge two sorted arrays" is the LC abstraction of a daily database-internals operation.
• Sliding window in rate limiting. Token-bucket rate limiters maintain a sliding-window count of recent requests. The exact LC sliding-window template (advance right, shrink from left when a condition breaks) is what's running in your nginx limit_req module.
• BFS in dependency resolvers. Terraform, Bazel, Maven, npm — they all compute a topological order by BFS over the dependency DAG. Detecting cycles is the same Kahn's-algorithm check that LC asks via "course schedule".
• Union-find in distributed membership. Cluster membership protocols (SWIM, gossip-based systems like Consul) maintain partitioned views of who's connected to whom. Merging partitions when split-brains heal is a union operation. So is graph-based image segmentation in computer vision.
• Segment trees in time-series databases. Prometheus, InfluxDB, TimescaleDB use segment-tree-like structures (range trees, R-trees, interval skiplists) for fast range queries over time windows. The LC "range sum query mutable" problem is literally the abstraction of a metrics rollup query.
• Topological sort in build systems. Bazel, Buck, Make — every modern build system computes the build order by topo-sorting the action graph. Incremental rebuild is the same algorithm restricted to the changed subgraph.
• Tries in autocomplete. Every text-input autocomplete (search bars, code editors, command-line completion) is a trie traversal. Variations: ternary search trees, radix trees (used by HTTP routers like httprouter and Trie-based Linux IP routing).
• Binary search in observability. Datadog, Honeycomb, Loki — finding a log entry by timestamp in a sorted segment is the canonical Shape A binary search. Repeated billions of times per day.
• Dynamic programming in genomics. Smith-Waterman, Needleman-Wunsch — sequence-alignment algorithms used in BWA, BLAST, minimap2 — are 2D DP on the edit-distance recurrence. Same shape as LC "edit distance" / "longest common subsequence".
• Heaps in Kubernetes scheduling. The kube-scheduler maintains a priority queue of pending pods. Same with task queues (Celery, Sidekiq), OS schedulers (Linux's CFS uses a red-black tree as a priority queue), and event-loop timers.

The 80/20 of senior-interview prep

If you only have six weeks and have to ship a passable loop, this is the shortlist. Not the complete plan — the complete plan is the four-phase curriculum above. This is the triage version: what to do when you don't have time for the full path.

• Master 5 Tier A patterns. Hash map, two pointers, sliding window, binary search, BFS/DFS. These cover ~70% of mediums. Skip the rest of Tier A and all of Tier B/C in this triage path.
• 50 well-spaced LC mediums covering all 5. Roughly 10 per pattern. Use the canonical 3–5 from each pattern page plus 5–7 more from Neetcode 150 / Grind 75 with the corresponding tag. All on a timer. All reviewed at day 3, 7, 21.
• 10 mock interviews. Two per week for weeks 3–7. Pramp or interviewing.io. Don't skip these — the round-versus-solo gap is where most candidates lose offers.
• 5 system design rounds. Even for L5 IC roles, system design is half the loop. Five mocks at one per week from weeks 2–6 is the minimum. Cross-reference /codex/system-design/ for the playbook.
• Behavioural prep — 8 stories, STAR-format. Conflict, leadership, failure, impact, ambiguity, deadline, mentorship, technical-call you made. Write them, time them at 90 seconds each. Most rejections at senior level cite "values fit" — that's behavioural, not coding.
• One full-loop dry run. Two weeks before onsites, do a back-to-back four-round day with a friend or a paid coach. Surfaces stamina issues that a single mock doesn't.

Common anti-patterns in self-study

The failure modes that produce the "I did 300 problems and still bombed the interview" outcome. Each is fixable but invisible until named.

• Grinding without review. Every problem solved once, never revisited. You'll re-solve the same medium twice from scratch three weeks later and not remember you saw it. Without spaced repetition, retention decays to ~30% in a month. Fix: schedule reviews at day 3, 7, 21, 60.
• "Easy mode" practice. No timer. IDE autocomplete on. Standard library at fingertips. Compiler catching syntax. None of that exists in the interview window — most onsites are whiteboard or a constrained CoderPad with no autocomplete. Fix: practise on paper, or in a plain text editor with the timer running.
• Avoiding mock interviews. Solo for 12 weeks then discovering at the round that you freeze when an interviewer is silent. The verbal-narration skill is disjoint from "I can write the code". Solo practice will never surface it. Fix: weekly mocks from week 4, 2–3/week in the final fortnight.
• Neglecting medium "trick" patterns. Monotonic stack, prefix sums, sweep line, difference arrays. They appear in ~10% of mediums but the trick is non-obvious — if you've never seen the pattern you'll spin for 40 minutes. Fix: read the Tier B pattern pages even if you don't drill them.
• Skipping behavioural prep. "I'm an engineer, my code is the signal." False at senior level. Behavioural rounds are scored on the STAR-quality of your stories, and stories you haven't written down sound like stream-of-consciousness in the room. Fix: 8 stories written, rehearsed, timed at 90 seconds.
• Cramming patterns the week before. Trying to learn DP three days before onsite. Won't work — DP fluency takes weeks to compound. Either drill it during phase 2, or commit to "I'll bomb the DP question and pass the others". Fix: respect the lead time of each pattern.
• Ignoring language fluency. Not knowing your interview language's stdlib — Python's heapq, defaultdict, bisect, Counter; Go's sort.Slice, container/heap; Java's TreeMap, PriorityQueue. Half your speed disappears looking up syntax. Fix: one focused day on stdlib idioms in your interview language.
• Treating LC count as the metric. 300 problems sounds impressive on a tracker; it doesn't predict interview outcome. Pattern fluency does. Two candidates with 300 problems — one with spaced repetition and 8 mocks, one without — have wildly different pass rates. Fix: measure pattern fluency (can you name and solve in 25 min cold), not count.

Twelve mental models

The intuitions every problem rests on. Tagged Day-zero (foundations every candidate needs), Practitioner (you write working code under a timer), Operator (you've shipped and grown muscle memory).

1. 01 · Day-zero

   Read input size first

   Constraints decide the bucket. n ≤ 20 → exponential is fine. n ≤ 5,000 → O(n²). n ≤ 10⁵ → O(n log n) is the ceiling. n ≤ 10⁹ → O(log n) only. Read constraints before designing.

2. 02 · Day-zero

   Brute force before optimising

   State the obvious O(n²) out loud. Most interview signal comes from showing you can articulate it before you skip past it. Don't skip the speech.

3. 03 · Day-zero

   The pattern is the answer

   Pattern recognition is the lever. Two pointers, sliding window, hash map, binary search, recursion — most LeetCode mediums fall cleanly into one of twenty patterns. Naming the pattern is half the battle.

4. 04 · Practitioner

   Two pointers is half the array problems

   Pair sums, palindromes, sorted-merge, partition, dutch flag. Whenever the input is sorted, two pointers is your first guess.

5. 05 · Practitioner

   Hash maps trade memory for time

   Counting, dedupe, complement-lookup. The pattern that turns O(n²) into O(n) by the cost of a constant-factor map.

6. 06 · Practitioner

   Sort first, then think

   A surprising fraction of mediums simplify enormously after a sort. The cost is O(n log n) — usually free given the constraints.

7. 07 · Practitioner

   Recursion is a contract

   Trust that the recursive call solves its subproblem. Write the base case first, then write the recurrence assuming the children are correct. Tree problems collapse this way.

8. 08 · Practitioner

   DP is "memoise the recursion"

   Most DP problems start as a recursion. Write the recursion, identify the state, cache it. Only then convert to bottom-up tabulation if needed.

9. 09 · Practitioner

   Greedy needs a proof

   Greedy is the easiest algorithm to write wrong. If you reach for greedy, articulate why the local choice is globally optimal — exchange argument, matroid, the canonical "if greedy were wrong here's the construction".

10. 10 · Operator

    Tree DFS is just recursion

    Pre-order, in-order, post-order — each is a one-line variation. The "trust the recursion" mindset turns half the tree problems into three lines.

11. 11 · Operator

    Graph BFS is queue + visited

    Most graph problems are unweighted shortest path or connected components. BFS handles both. Visited set is non-negotiable; forgetting it is the most common bug.

12. 12 · Operator

    Edge cases are part of the answer

    Empty input, single element, duplicates, all-same, sorted, reverse, negatives, zeros, overflow, off-by-one. Walk the list every time. Interviewers score on whether you bring them up unprompted.

Big-O, in one table

Five complexity buckets cover 99% of LeetCode. Read the input size; pick the ceiling; the pattern usually follows.

A 1-second LC time budget executes roughly 10⁸ simple operations. Read the constraint, divide by 10⁸, that's your complexity ceiling.

Reading a problem — the seven-thing checklist

What the interviewer wants to hear before code, in order. Every step is a chance to score signal.

1. "Can I confirm…" Restate the problem in your own words. Catches misreadings before they cost 20 minutes.
2. "What about edge cases?" Empty, single, all-same, sorted, duplicates, negatives, overflow. Bring them up unprompted.
3. "Brute force first." Articulate the obvious O(n²) before optimising. The interviewer scores this even if you skip past it.
4. "I notice…" The observation that unlocks the better approach — sortedness, monotonicity, repeated subproblems, fixed alphabet.
5. "I'll use X because…" Name the structure with a reason. Heap because top-k. Hash because complement-lookup. Binary search because monotone predicate.
6. "Time / space complexity is…" State both, before they ask.
7. "Let me trace through an example…" Verbal dry-run before typing. Catches off-by-one and base-case bugs.

Edge-case discipline

A list to walk every single time. The candidate who passes brings these up before being asked.

• Empty input. Return what? Empty list? Zero? Null? Specific sentinel? Confirm.
• Single element. Two-pointer / sliding-window invariants often break at n=1.
• All-same elements. Tests dedupe handling, BST balance, hash collisions.
• Sorted / reverse-sorted input. Where many algorithms have their worst case (quicksort, BST insert).
• Duplicates. Set vs multiset semantics. Hash key collisions. "Find all" vs "find one".
• Negatives, zeros. Range-based assumptions that break.
• Integer overflow. Sums of large ints; multiplication; (low + high) / 2 classic bug — use low + (high - low) / 2.
• Off-by-one at boundaries. Inclusive vs exclusive. < vs <=. The single most common LC bug.

The practice rules — methodology that actually works

More candidates fail because of how they practise than what they practise. The protocol below is what separates "did 200 problems" from "passes the round".

• The 20-minute rule. Spend at most 20 minutes stuck on a new problem before peeking at hints. Past that, you're rehearsing confusion. Peek at the pattern only — not the solution. Try again with the new prompt for another 20 minutes.
• Spaced repetition for problems. Review intervals: 3 days → 7 → 21 → 60. Wrong on a review? Restart at 3. Tools: Anki, Notion, a spreadsheet.
• "Explain it back." After solving, narrate the solution out loud as if to an interviewer. If you stumble, you don't fully own it.
• Always practise on a timer. A medium you can solve in 60 minutes is a medium you can't solve in the 25-minute interview window.
• Mocks from week 4. Solo practice is the unit test; mocks are the load test. Don't discover you freeze under verbal pressure during the actual interview.

The methodology is detailed at length in the methodology page — the most distinctive section of this path. Skipping it is the most common reason people grind 200 problems and still freeze.

Books, papers, talks

A short list. Most LC-prep books are interchangeable; these are the ones worth the shelf space.

• McDowell — Cracking the Coding Interview. The classic. Read once for the methodology chapters; the problems are dated but the framing isn't.
• Aziz, Lee, Prakash — Elements of Programming Interviews. Harder than CTCI; the problems are more representative of real onsites.
• Sedgewick & Wayne — Algorithms (4th ed). The reference. Read chapters as needed when a structure feels mysterious.
• CLRS — Introduction to Algorithms. Keep on the shelf as a dictionary; don't try to read it cover to cover.
• Skiena — The Algorithm Design Manual. Underrated. Part 1 is a textbook; Part 2 is an annotated index of algorithms.
• Roughgarden — Algorithms Illuminated. Companion to his Coursera course. Friendlier than CLRS without dumbing down.
• Bentley — Programming Pearls. A book of essays on the craft; not LC-shaped but trains the mindset.
• Talk: Marcus du Sautoy — "What we cannot know" (Royal Institution). Tangential, but useful for re-grounding the why behind algorithms.

Hands-on tools & sources

What to install and what to grind on. The list of "places to do problems" is the single most-asked question in interview prep.

• LeetCode. The default. Top-100 list, contest archive, premium-tier company-tagged questions.
• Neetcode 150. Curated 150-problem list grouped by pattern. The single best free LC roadmap.
• Blind 75. The "if I had to do 75 problems" canonical list. A subset of Neetcode 150.
• Pramp. Free peer mock interviews. Match with another candidate; one of you interviews, then swap.
• interviewing.io. Anonymous mocks with engineers from FAANG-tier companies. Free tier exists.
• Hello Interview. Mock walkthroughs and structured prep, especially strong for system design.
• VisuAlgo. Pure algorithm visualisations. Step through sort, BFS, DFS, Dijkstra. Free.
• Excalidraw. The hand-drawn diagram tool every system-design interview ends up using.

Reuse what's already on the site

The site's existing simulators map cleanly onto common patterns. Use them as the visual companion to the written deep dives.

• Heap pattern. Try the live heap simulator — heapify, sift-up, sift-down, top-K extract.
• Tree pattern. The balanced-tree simulator shows BST and red-black rotations.
• Recursion pattern. The recursion simulator visualises the call tree filling in.
• Hashing. The consistent-hashing simulator isn't LC-shaped but builds the cost-model intuition.
• Tries. The suffix-tree simulator — adjacent to the trie pattern, useful for word-search problems.
• Binary search. The binary-search simulator — the canonical trace through a search.
• Reference: the data-structures cabinet. One-page-per-structure cost-model reference. Skim this before starting any new pattern.

Eight common mistakes

• Grinding without patterns. 200 problems with no pattern classification is rehearsal without learning. Always name the pattern out loud before coding.
• Reading solutions too early. The 20-minute rule. Read after struggle, not before. Pattern recognition is built only by the struggle.
• Skipping edge cases. Edge cases are part of the answer, not a bonus. Walk the checklist every time.
• Optimising before brute force. Interviewers want to hear the obvious approach first. State it; then optimise.
• Memorising solutions. Re-solve from scratch on review. "I've seen this" without re-derivation is useless when a variant lands.
• Mocking too late. Solo practice for 12 weeks then discovering you freeze in the round. Mocks from week 4.
• Practising untimed. A 60-minute medium is unsolvable in 25. Always run a timer.
• No language fluency. Knowing your interview language's algo standard library — heapq, defaultdict, bisect, Counter in Python — is half the speed.

Adjacent paths

• System design. The other half of every senior+ loop. Walk the system-design playbook in parallel.
• Computer architecture. Where the cost model comes from — caches, branch prediction, the latency hierarchy.
• Distributed systems. Theory layer above LC; relevant for the distributed-systems coding round at infra-flavoured loops.
• Data structures cabinet. The reference index — every structure with its cost model.