List: The 70-Problem LeetCode List for Senior Big-Tech Loops

Most “LeetCode for company X” lists are 250 problems scraped from an aggregator, grouped by tag, with no annotation. You finish “two pointers” and the list has nothing to say about what comes next or why. This list is ~70 core problems laid out as one learning path: eleven stages, each reusing the tool the stage before it built, each with a bar that tells you when to move on, and a one-line bridge that tells you why the next stage comes next.

Calibration assumption: you’re targeting a mid-to-senior loop (Meta E4/E5, Google L4/L5, Amazon SDE II/III, or equivalent). New-grad loops ask easier slices of the same stages. Pair it with the coding round guide for how to run the clock once you’re in the room.

How this list is organized

Two orders matter, and they are not the same order:

1. The learning order — the path below. Bedrock first, and every stage leans on the one before: the window in stage 1 is the two pointers from stage 0 moving the same way; the trees in stage 4 are the stack from stage 3 made implicit by recursion; the object designs in stage 10 are assembled from the linked lists, heaps and tries of earlier stages. Don’t reorder the stages — a problem that feels impossible usually means you skipped the stage it builds on.
2. The recognition order — the questions you ask on a problem you’ve never seen, in the room. That’s the Problem Recognition Framework after the path. Each stage is tagged with the category it teaches, so by the end of the path you’ve seen every category recognized from the inside.

Earlier versions of this list mixed the two: the sections followed the recognition order, which put Object Design — the capstone — first and the bedrock sixth. Recognition is how you route a problem; it’s a poor order to learn in.

What’s deliberately out: bit manipulation, math tricks, segment trees, and the long tail of hard DP. They’re real but rare, and they’re ranked in What’s next so you know exactly where the marginal hour goes once the path runs clean.

Start here

The path at a glance

Senior-bar times throughout: easy ≤10 min, medium ≤20–25, hard ≤35–40, including tests and complexity. ”+ 1” counts the follow-up named inside a problem’s note (e.g. 142 after 141) — do it once the main problem is clean.

The path

Stage 0 · Warm-up: hash, stack, linked list, converging pointers

Category: Transformation (pointer rewiring), plus the first State Maintenance reps. Builds on: nothing — this is the floor.

CtCI-era classics that still open phone screens. Blitz them in one timed sitting. The point isn’t to learn them; it’s to confirm none can surprise you, because a fumbled warm-up costs more than a missed hard.

• 1. Two Sum — the hash-map one-liner everyone’s seen. Solve it in 90 seconds and move on; its only job is to not catch you off guard.
• 20. Valid Parentheses — the canonical stack warm-up; stage 3’s 1249 is this problem with one more decision.
• 21. Merge Two Sorted Lists — the two-pointer merge that stage 6’s 23. Merge k Sorted Lists generalizes with a heap. Know this one cold first.
• 88. Merge Sorted Array — in-place merge from the back. A deceptively common Meta/Amazon warm-up where the “fill from the end” trick is the whole signal.
• 206. Reverse Linked List — the most-asked warm-up in history. Iterative and recursive, both in under five minutes; half the linked-list follow-ups rest on it.
• 141. Linked List Cycle — Floyd’s fast/slow pointers. The follow-up 142 (find the cycle start) is the version that actually gets asked at the senior bar.
• 125. Valid Palindrome — two pointers converging from both ends. Stage 9 returns to it as 680, a Meta favorite.

Move on when: every problem above lands in ≤10 minutes with tests, and 234. Palindrome Linked List — which combines fast/slow, reverse, and converging compare — goes clean cold.

Next → In 125 the two pointers walk toward each other. Let them walk the same direction and the gap between them is a window.

Stage 1 · Sliding window

Category: State Maintenance. Builds on: stage 0’s two pointers.

The first coding question of most loops comes from stages 1–3. The bar is 12–15 minutes with clean code; 25 minutes likely fails the round even if the solution works. Solve these in order — each adds one idea to the template.

• 3. Longest Substring Without Repeating Characters — the canonical variable window, asked everywhere. If you can’t write the template in 8 minutes, the rest of the path won’t help. Do this first.
• 567. Permutation in String — the fixed-size window with a character count. Adds “compare two frequency maps in O(1) per step.”
• 438. Find All Anagrams in a String — 567 again, but collect every match. High-frequency at Meta; if 567 was clean, this is five minutes.
• 76. Minimum Window Substring — the hard canonical: grow until valid, shrink while valid. Template for any “smallest window containing all of X.”
• 424. Longest Repeating Character Replacement — the window’s validity is a formula (length − maxCount ≤ k), not a set. Do it cold as the stage exam: it tests whether you understood the template or memorized four problems.

Move on when: 3 is under 8 minutes, and for any window problem you can say the invariant in one sentence — “the window never contains a repeat” — before you write the loop.

Next → A window only works when growing it can only make the condition worse (or only better). Allow negative numbers and that breaks — you need to remember every prefix, not just the current window.

Stage 2 · Prefix sum and hash-map state

Category: State Maintenance. Builds on: stage 1 — this is what you reach for when the window’s monotonicity fails.

One linear pass, one well-chosen piece of state. The skill is naming the state — a map of prefix sums, a derived key, a running minimum — before you write the loop.

• 560. Subarray Sum Equals K — prefix sum + HashMap. The classic “this isn’t actually a window” trap: reach for stage 1 and the negatives break you. Recognizing why is the lesson.
• 49. Group Anagrams — hash map with a derived key (sorted string or character count). Tests whether you can design the right key; transfers to every “group by property” problem.
• 238. Product of Array Except Self — prefix/suffix product without division. The cleanest “maintain state in both directions.”
• 121. Best Time to Buy and Sell Stock — one-pass min tracking. Candidates over-engineer it; the good solution is 10 lines.

Move on when: for each problem you can say the stored state in one sentence (“count of each prefix sum seen so far”) before coding, and 560 lands without trying a window first.

Next → 121 keeps one running value for the whole array. When each element needs its own answer — “the next warmer day after this one” — you need to hold the unresolved elements somewhere until their answer arrives.

Stage 3 · Monotonic stack

Category: State Maintenance. Builds on: stage 0’s stack (20) and stage 2’s one-pass state.

A pattern with rising frequency at Meta, Amazon, and Google. The stack holds elements still waiting for their answer, kept in order so each one is pushed once and popped once — O(n) total.

• 739. Daily Temperatures — the canonical “next greater element.” High-frequency at Amazon. Learn the template here.
• 901. Online Stock Span — the same stack, but as a streaming class: answer one element at a time. A first taste of stage 10’s object design.
• 84. Largest Rectangle in Histogram — the hard monotonic-stack canonical. Understanding why popping gives the rectangle’s width unlocks 42’s stack solution too.
• 42. Trapping Rain Water — an Amazon and Google staple at the senior bar. Solve it twice: converging pointers with running maxes (stage 0), then the stack. Naming the trade-off between them is the senior signal.
• 1249. Minimum Remove to Make Valid Parentheses — high-frequency, especially at Meta: stage 0’s 20 plus “which indices to drop.” Its senior follow-up, 301, waits in stage 9.

Move on when: you can say what the stack holds and why each element is pushed and popped at most once, and 84 lands in ≤35 minutes.

Next → A stack of pending work is exactly what recursion keeps for you implicitly. Trees are where that’s the natural way to write it.

Stage 4 · Tree recursion and BFS

Category: Traversal. Builds on: stage 3 — the call stack is the stack.

The second coding round usually pulls from stages 4–5. The bar shifts: instead of “clean in 12 minutes,” it’s “correct in 25, with a sensible discussion of trade-offs.”

• 543. Diameter of Binary Tree — the “return one value up, bookkeep another globally” pattern in its simplest form. Start here.
• 124. Binary Tree Maximum Path Sum — 543’s pattern, harder: negative values make the “return up” choice non-trivial. High-frequency at Google and Meta.
• 236. Lowest Common Ancestor of a Binary Tree — recursive divide: each subtree reports what it found. Variants (LCA with parent pointers) are common follow-ups.
• 102. Binary Tree Level Order Traversal — the BFS template for trees. Many tree problems reduce to “level order with bookkeeping,” and it’s the backbone of tree serialization (stage 11’s 297).
• 199. Binary Tree Right Side View — level-order BFS or preorder DFS. Practice both — interviewers often ask for the alternative after your first solution.
• 314. Binary Tree Vertical Order Traversal — the Meta tree question: BFS with column tracking. Famous enough that interviewers can tell memorized from reasoned — produce it cleanly on the first try.

Move on when: 124 lands clean in ≤25 minutes, and you can write the DFS-return template and the BFS-queue template from a blank page.

Next → A tree is a graph with one root and no cycles. Drop both guarantees — add a visited set and allow many starting points — and you have graphs.

Stage 5 · Graphs and grids

Category: Traversal. Builds on: stage 4’s DFS and BFS templates.

• 200. Number of Islands — the canonical grid traversal, asked everywhere. Solve with both DFS and BFS and you’ve covered most grid questions.
• 994. Rotting Oranges — multi-source BFS, an Amazon favorite. “Start BFS from every source at once” transfers to most shortest-time-on-grid problems.
• 133. Clone Graph — traversal with a HashMap from original to copy. The cloning is bookkeeping; the trap is getting the recursion-vs-iteration trade-off wrong out loud.
• 207. Course Schedule — cycle detection / topological sort, a Google and Amazon staple. Know Kahn’s algorithm (BFS on in-degrees); the follow-up 210 asks for the ordering itself.
• 323. Number of Connected Components in an Undirected Graph — BFS/DFS or union-find. Practice the union-find version: 15 minutes to learn, and it appears at Google, Meta, and Databricks surprisingly often.

Move on when: you pick BFS or DFS out loud with a reason before coding, and Kahn’s algorithm comes out without looking anything up.

Next → BFS processes nodes in order of distance. When the order that matters is something else — smallest end time, highest priority, k closest — you sort, or you keep a heap.

Stage 6 · Intervals and heaps

Category: Ordering. Builds on: stage 0’s merge (21) and stage 5’s “process in order” instinct.

Correctness depends on seeing elements in a particular order. Strong candidates distinguish themselves here by choosing the structure — sort, heap, or quickselect — and saying why.

• 56. Merge Intervals — the canonical interval problem, high-frequency at every company. Sort + linear merge.
• 57. Insert Interval — 56 when the input is already sorted: no sort, three phases.
• 435. Non-overlapping Intervals — sort by end, not start. Why that’s the correct greedy is the whole question.
• 253. Meeting Rooms II — min-heap on end times: “what’s the smallest end time that’s free” → heap. The bridge from intervals to heaps.
• 973. K Closest Points to Origin — the canonical top-k. Solve with both a size-k heap and quickselect; the streaming follow-up is really asking why you chose the heap.
• 215. Kth Largest Element in an Array — quickselect is the canonical answer. The follow-up is always “how do you avoid O(n²)?” — randomized pivot. Name it before you’re asked.
• 23. Merge k Sorted Lists — stage 0’s 21 with a heap of heads. An Amazon and Google staple; the k-way-merge template also underlies external-sort follow-ups.

Move on when: for each problem you can say which of sort, heap, or quickselect you chose and what the other two would cost.

Next → Once data is sorted you don’t have to look at all of it — binary search discards half each step. The same trick works on any space that’s ordered, including a space of possible answers.

Stage 7 · Binary search and careful arithmetic

Category: Search, plus Transformation. Builds on: stage 6’s sorted data and stage 2’s prefix sums (528).

The easiest pattern to fail on a typo and the cleanest template to memorize. The two string-arithmetic problems ride along here because they test the same thing: exact boundary handling under the clock.

• 33. Search in Rotated Sorted Array — the canonical “binary search with a twist,” asked everywhere. The duplicates variant 81 is a common follow-up.
• 528. Random Pick with Weight — stage 2’s prefix sum, then binary search into it. High-frequency at Meta; the setup is half the problem.
• 50. Pow(x, n) — halve the exponent each step: binary search’s halving, applied to computation. Bug-prone; practice negative n.
• 415. Add Strings — manual carry arithmetic (no BigInteger). A common warm-up whose follow-up is 43. Multiply Strings.

Move on when: 33 lands with zero off-by-ones in 15 minutes, and you can name your boundary convention before writing mid.

Next → Binary search works because one half can be thrown away safely. When no choice can be thrown away — each one changes what’s possible later — you keep the answers to the sub-problems instead.

Stage 8 · Dynamic programming

Category: Decision / Optimization. Builds on: stage 4’s recursion (top-down DP is recursion plus a cache).

A smaller slice than the internet suggests. Every company asks some DP; none of the mainstream loops ask the hardest tier. One problem per shape below covers most of what appears — in this order, each adds one dimension.

• 70. Climbing Stairs — 1D DP with two-state memory. Trivial, but the frame for everything after.
• 198. House Robber — the cleanest take/skip decision; the circular variant 213 is a fair follow-up.
• 62. Unique Paths — the first 2D table; the obstacle variant 63 falls out.
• 322. Coin Change — unbounded knapsack. Internalize the bottom-up table; iterative is what you write under the clock.
• 139. Word Break — DP over a string with hash-set lookup. The bridge to stage 9.

Move on when: for every problem you say what dp[i] means and its transition before writing code, and 322 lands bottom-up in ≤25 minutes.

Next → 139 asks whether the string can be split. Its sibling asks for every split — and once you must list all the answers, you can’t compress them into a table; you enumerate.

Stage 9 · Backtracking

Category: Enumeration. Builds on: stage 8’s 139 and stage 4’s recursion.

The answer is every valid configuration. Cover the template once; the senior-bar variants are about pruning, not exotic puzzles.

• 17. Letter Combinations of a Phone Number — the friendliest backtracking question and a frequent warm-up. Learn the choose / explore / un-choose shape here.
• 78. Subsets — the canonical template. Solve with include/exclude recursion and the 5-line bitmask version — interviewers remember the second.
• 46. Permutations — the swap-in-place version is cleanest; the duplicates variant 47 is the common follow-up and the first real pruning rule.
• 140. Word Break II — stage 8’s 139, now listing every split: backtracking with memoization. The exact point where DP and enumeration meet.
• 212. Word Search II — backtracking on a grid, pruned by a Trie. Senior-loop tier.
• 301. Remove Invalid Parentheses — stage 3’s 1249, now returning every minimal answer. The senior follow-up to a Meta favorite.
• 680. Valid Palindrome II — stage 0’s 125 with a budget of one deletion: a branch you may take at most once. Short, but it’s how Meta tests whether you branch cleanly.

Move on when: you state the pruning rule and the complexity before coding, and 212 lands in ≤40 minutes.

Next → 212 only worked because you built a Trie to a spec — insert, search, prefix. Designing a data structure to an API, with every operation at a target complexity, is the last stage.

Stage 10 · Object design (capstone)

Category: Object Design. Builds on: everything — stage 0’s linked lists, stage 3’s stack, stage 6’s heaps, stage 9’s Trie.

You’re handed an API spec and asked to implement the class. The work is picking the backing structures and keeping their invariants in sync. Meta and Amazon lean on these; Google uses them as follow-up scaffolding. For senior backend candidates they also test API design and extensibility.

• 155. Min Stack — the five-minute design warm-up: an auxiliary stack kept in sync.
• 146. LRU Cache — the canonical “design + code in 30 minutes,” asked everywhere. Doubly-linked list + HashMap; write it clean from a blank page.
• 380. Insert Delete GetRandom O(1) — HashMap + array swap-with-last. The duplicates variant 381 is a fair senior follow-up.
• 295. Find Median from Data Stream — two heaps from stage 6. Any “online aggregate over a stream” reduces to two heaps or a sorted structure.
• 208. Implement Trie (Prefix Tree) — the structure you leaned on in 212, now built to its spec. Under 10 minutes from scratch.
• 355. Design Twitter — object modeling, heap merge (stage 6’s 23), and API design in one. A senior backend favorite: it tests whether you design holistically or hack the test cases.

Move on when: LRU Cache lands from a blank page in ≤20 minutes, and for each design you can name the invariant that ties its structures together.

Next → The path is done. Stage 11 tests it at full difficulty, one hard problem per earlier stage.

Stage 11 · Hard reps, one per stage

Not new techniques — the hard version of each stage, so a miss points you straight back to the stage to re-do.

Done when: two cold mocks in your target company’s round shape pass within time. Then, and only then, spend down What’s next.

The Problem Recognition Framework

The path is how you learn. This is how you route a problem you’ve never seen, in the blank-page minute before you’ve picked an algorithm. It mirrors the system design patterns framework: recognize the pattern before choosing the design. Here: recognize the problem before choosing the algorithm.

Tags like “array, dfs, two-pointer” describe a solution after you have it; they don’t help when you don’t yet know what kind of problem you’re looking at. The recognition questions do, because each one is answerable from the problem statement alone.

Run the questions in this order and take the first one that fits. The specific, high-precision questions come first so a broad one can’t grab a problem a sharper one should own:

flowchart LR
  Root([Recognize the problem]) --> D1[1 · Object Design]:::design
  Root --> D2[2 · Enumeration]:::enum
  Root --> D3[3 · Traversal]:::traversal
  Root --> D4[4 · Ordering]:::ordering
  Root --> D5[5 · Transformation]:::transform
  Root --> D6[6 · State Maintenance]:::state
  Root --> D7[7 · Decision / Optimization]:::decision
  Root --> D8[8 · Search]:::search

  classDef design    fill:#f3ecfb,stroke:#8250df,stroke-width:2px,color:#1f2937;
  classDef enum      fill:#eafaf0,stroke:#1a7f37,stroke-width:2px,color:#1f2937;
  classDef traversal fill:#e8f1fd,stroke:#0969da,stroke-width:2px,color:#1f2937;
  classDef ordering  fill:#e6f6f4,stroke:#0e7490,stroke-width:2px,color:#1f2937;
  classDef transform fill:#fdeef6,stroke:#bf3989,stroke-width:2px,color:#1f2937;
  classDef state     fill:#fdf0e6,stroke:#9a6700,stroke-width:2px,color:#1f2937;
  classDef decision  fill:#fdeaea,stroke:#cf4b2e,stroke-width:2px,color:#1f2937;
  classDef search    fill:#eef2f1,stroke:#2c5f5d,stroke-width:2px,color:#1f2937;

These eight cover the recurring reasoning patterns of mainstream big-tech loops. Bit manipulation and pure math are deliberately not categories — they test narrow tricks, not transferable recognition, and live in the low-frequency tier below.

What’s next: the last 20% (more effort, less gain, still real)

Nothing here is worthless — it’s the diminishing-returns tier. Each group below does appear in loops, just rarely enough that it’s a poor trade against the core list. Work these only once the core runs clean under the clock, and prioritize top-down: the earlier groups earn their marginal hour more than the later ones.

• Hard DP. 312. Burst Balloons, 44. Wildcard Matching, the 188. Stock IV variants. Try these if: Edit Distance and Regex Matching from stage 11 are clean and you have hours to spare, or you’re targeting a Google loop that likes to mutate a DP into a harder one. Wildcard Matching is the closest sibling to stage 11’s Regex Matching — start there.
• Advanced graph algorithms. 743. Dijkstra (Network Delay Time), Bellman-Ford, Kruskal/Prim MST. Try these if: you’re targeting an infrastructure, maps, or logistics team, or a Google loop specifically — they earn their place there and almost nowhere else. Start with Dijkstra via Network Delay Time; it’s the one that actually appears.
• Advanced union-find. You’ve got the canonical 323 on the core list. Try next: 721. Accounts Merge and 305. Number of Islands II — the applied variants that actually show up (Meta likes Accounts Merge). Skip the weighted/path-compressed-with-rank competitive-programming tier.
• Bit manipulation. 136. Single Number is a fine warmup. Try next if Google-bound: 201. Bitwise AND of Numbers Range and 190. Reverse Bits — occasional at Google, near-absent elsewhere. One pass for recognition.
• Math / implementation. 12. Integer to Roman, 13. Roman to Integer, 171. Excel Column Number. These test careful implementation over pattern transfer. Low priority, but a fast confidence pass the week before if you have an idle evening.
• Hard backtracking. 51. N-Queens, 37. Sudoku Solver, 425. Word Squares. Try these if: Subsets and Permutations are automatic and you want to stress- test your pruning. N-Queens is the one interviewers occasionally reach for.
• Segment / Fenwick trees. 307. Range Sum Query - Mutable, 315. Count of Smaller Numbers After Self. Mostly competitive-programming territory. Try these only if: you’re targeting a quant/HFT or specialist infra loop that’s known to ask them — otherwise the marginal hour is far better spent on system design.
• The full Blind 75 / NeetCode 250, for completeness. Fine pattern catalogs that overlap this list heavily at the core — if you’ve done one, you’ve built the foundation. Finishing all 250 as a goal optimizes problem count over pattern fluency. If you have genuine surplus time, cherry-pick the handful they cover that this list doesn’t; don’t grind the whole set.
• Mock-interview platforms beyond a few sessions. Two or three are worth it for calibration. After that, marginal value drops sharply; real timed reps beat watched ones.

The pattern behind this tier: mainstream big-tech loops test breadth and speed, not depth in any one technique. These problems are real but rare — so the ordering above is deliberate. Spend down from the top only after the core list is fluent, and stop when the marginal hour would buy more on system design than on one more exotic technique.

Per-company emphasis

• Meta — two problems per 35-minute round; speed is the whole game. Over-index on arrays/strings and trees; expect the tagged Meta favorites above (Valid Palindrome II, Vertical Order Traversal, Minimum Remove, Find All Anagrams).
• Google — one problem that mutates: after your solve, constraints change (“what if it doesn’t fit in memory?”, “what if updates arrive concurrently?”). Practice extending your own solutions; toposort and search-on-answer binary search appear more here than anywhere.
• Amazon — one problem plus leadership-principle questions in the same hour, graded on maintainability as much as correctness — see the logical & maintainable guide. BFS-on-grid, k-way-merge, and monotonic stack are house staples.
• Apple / Netflix — team-driven and practical; the Object Design category above is the highest-yield group, and language fluency counts double.

Priority 10 by company

If you only have time for 10 problems per target company, these are the highest-ROI picks from the list above:

What senior candidates do differently

The same problem, solved by a mid-level and a senior candidate, looks different in the interviewer’s notes:

The pattern: at senior, every standard move comes with one extra sentence of meta-reasoning. See the coding round guide’s senior differentiation section for how to practice this.

How to use this list

Walk the stages in order and don’t advance until the stage’s Move on when bar holds. If you’re stuck on a problem, go back one stage, not forward — every stage names what it builds on, and skipping a prerequisite is almost always why a problem feels impossible.

If you have 6 weeks (60–80 hrs):

If you have 2 weeks (20–25 hrs): stages 0–6 and stage 10’s LRU Cache and Insert/Delete/GetRandom, ~35 problems. Skip DP beyond House Robber and backtracking beyond Subsets — the goal is speed on the highest-frequency stages, not completeness.

If you have 3 days: stage 0 (half a morning), stages 1–2, five problems from stages 4–5 (543, 236, 102, 200, 994), and two from stage 10 (146, 380). You’re refreshing speed, not preparing a loop. Don’t touch the “what’s next” tier.

The self-paced interview-prep program in the members’ dashboard runs these same stages, in this order, as its coding track — stage 2’s 560 rides along with the window chain in week 2, the rest of stages 2 and 3 share week 3, and stage 11 gets two.

For all timeframes: time yourself. The difference between solving a problem in 18 minutes and solving the same problem in 38 is the difference between a hire and a no-hire, at every company on this list. Untimed practice teaches the wrong skill.

Related

• Guide: The Senior Coding Interview at Big Tech — how to run the clock: round shapes by company, the 6-step structure, the follow-up ladder, and the moves that read senior.
• Guide: Amazon’s Logical & Maintainable Coding Interview — the company specialization where clean, extensible code is the explicit rubric.
• Plan: Senior Backend Software Engineer Interview Prep — the broader 12-week plan across coding, system design, and behavioral.
• Framework: Patterns and Tradeoffs in System Design — the system design counterpart: recognize the path pattern before choosing the design.