The 15 LeetCode Problems to Do the Week Before Your Interview

June 7, 202610 min read
interview-prepdsaalgorithmsleetcode
The 15 LeetCode Problems to Do the Week Before Your Interview
TL;DR
  • Week before = consolidation, not exploration: your goal is cementing patterns you've already seen, not adding new ones to the pile
  • 15 high-signal problems: each is solvable in 20-30 minutes once you own the pattern and maps to a technique that generalizes to dozens of variants
  • Day-by-day structure: basics first (Two Sum, Valid Parentheses, Climbing Stairs), then core patterns, then combination problems, then advanced (LRU Cache, two heaps)
  • Solve out loud: after each problem, state the pattern and key insight in one sentence to build recall over recognition — recognition breaks on the first twist
  • No new patterns the final week: no hard problems you've been curious about, no breadth expansion — consolidation only
  • Gap is communication, not solving: if you know the approach but freeze narrating it, more LeetCode won't help — that needs a different kind of practice

You've been grinding for weeks. Maybe months. The interview is in seven days and your instinct is to add more problems to the pile, because surely 312 is better than 311. It's not. Stop.

A week out, your goal is consolidation, not breadth. Cement the patterns you've already seen, find your actual gaps, and rebuild confidence before the real thing. Fewer problems. The right problems.

This list has three criteria: frequency (these appear constantly at Meta, Google, Amazon, and Microsoft), pattern generalizability (each teaches a technique that applies to dozens of variants, not just itself), and diagnostic value (if you can't solve it cleanly, you know exactly what to fix).

What Qualifies for the Week Before?

Most "top 100" lists conflate practice volume with interview readiness. A week out, you want maximum signal per minute. The right problem is solvable in 20-30 minutes once you own the pattern, shows up in at least 40% of real interviews at top companies, and produces something you can explain out loud while coding.

Hard problems with niche insights don't qualify. Neither do trivial ones that just confirm you can type. This is also not the week to finally learn suffix arrays or whatever cursed thing your Blind thread said Google is asking lately.

#ProblemPatternDifficulty
1Two SumHash map complementEasy
2Valid ParenthesesStack matchingEasy
3Climbing StairsFoundational DPEasy
4Longest Substring Without Repeating CharactersVariable-width sliding windowMedium
5Maximum SubarrayKadane's / DPMedium
6Merge IntervalsSort and scanMedium
73SumTwo pointers + dedupMedium
8Number of IslandsGrid DFS/BFSMedium
9Binary Tree Level Order TraversalBFS with queueMedium
10Search in Rotated Sorted ArrayBinary search variantMedium
11Coin ChangeUnbounded knapsack DPMedium
12Course ScheduleGraph cycle detectionMedium
13Word SearchBacktracking on gridMedium
14LRU CacheHash map + doubly linked listHard
15Find Median from Data StreamTwo heapsHard

Day 1: Prove You Own the Basics

These three should take 20 minutes each. If any of them takes longer, that's your signal before the rest of the week begins. Yes, even Two Sum.

Two Sum (#1)

Pattern: hash map complement lookup.

Two Sum gets a lot of grief. "They asked me Two Sum at [company]!" Yes. Because a nested loop tells the interviewer you haven't thought about hash maps. For each number, check if target - current exists in the map and store as you go, one pass. This complement check is the foundation for a huge family of two-element problems, from pair sum variants to counting pairs with constraints. If you reach for a nested loop here, the rest of the week will be rougher than it needs to be.

Valid Parentheses (#20)

Pattern: stack for matching and nesting.

You've probably solved this one six times already. The goal isn't to solve it again. The goal is to solve it in four minutes so the stack-for-nesting pattern is locked before a harder version shows up. Push opening brackets, pop on closing, verify the pair. The mistake to watch is forgetting to check for an empty stack before popping. It'll pass most test cases and blow up on "]".

Climbing Stairs (#70)

Pattern: foundational DP.

The recurrence is f(n) = f(n-1) + f(n-2). Almost embarrassingly simple. That's the point. Before you touch a harder DP problem, you should be able to state the state definition, the transition, and the base cases for this one in under 30 seconds. If that sentence made you nervous, Coin Change is going to be a rough morning.

Days 2-4: Core Patterns You Must Own

Longest Substring Without Repeating Characters (#3)

Pattern: variable-width sliding window.

Maintain a window with a set or hash map. Expand right, shrink left when you hit a duplicate. Simple to explain, subtle enough that most people implement it wrong under pressure. This is the canonical variable-width window: every "longest substring satisfying property X" problem uses this exact frame. The window contract condition changes with the problem. The structure never does. For a deeper breakdown, see Nested Loops Will Cost You the Offer. The Sliding Window Algorithm Won't.

Maximum Subarray (#53)

Pattern: Kadane's algorithm.

Running sum that resets when it goes negative, tracking the maximum seen. A negative prefix can only hurt you, so you discard it. The implementation is five lines but the insight is clean DP: the state is "best subarray ending at this index" and the transition is max(nums[i], prev + nums[i]). Initialize to nums[0], not zero, or you'll get the wrong answer on all-negative arrays. This exact bug lived in Java's standard library for nine years.

Merge Intervals (#56)

Pattern: sort and scan.

Sort by start time. Merge any interval whose start falls within the previous interval's end. The sort-first step is what makes linear merging possible, and it's the step that's easiest to skip when you're panicking and just want to start coding. This pattern covers meeting room scheduling, calendar systems, and range-union questions.

3Sum (#15)

Pattern: two pointers on a sorted array.

Fix one element, run two pointers on the remainder. The algorithm itself is 15 minutes. The dedup is where interviews go to die. Skip duplicates for the fixed pointer and for both inner pointers after a match. Most broken implementations pass the happy path and silently return duplicates on arrays like [-1, -1, 0, 1, 1]. Spend time specifically on the dedup this week. The core algorithm is a warm-up. The dedup is 30 minutes of deliberate practice that pays off more than any other 30 minutes on this list.

Number of Islands (#200)

Pattern: DFS or BFS on a grid.

For each unvisited '1', launch a DFS that marks the entire connected component visited. Count how many fresh DFS calls you make. That's the answer. This flood fill is the foundation for every grid traversal problem, from Pacific Atlantic Water Flow to Rotting Oranges. The only variation across problems is what counts as a valid neighbor and what "visited" means.

Binary Tree Level Order Traversal (#102)

Pattern: BFS with queue and level tracking.

Use a queue. For each level, record the current size, drain exactly that many nodes, enqueue their children. The "record the level size before draining" step is the one people blank on under pressure. Every "group nodes by depth" tree problem uses this frame. Right side view, zigzag traversal, and level averages all reduce to this structure with a different aggregation step at the end.

Days 4-5: Pattern Combinations

These require combining two techniques. That combination is exactly where most mediums live.

Search in Rotated Sorted Array (#33)

Pattern: binary search with a broken invariant.

This one eats people alive. The array was sorted, then rotated at some unknown pivot. One half is always fully sorted. Check which half by comparing the midpoint to the boundaries, then decide whether your target falls in the sorted half. The key move is committing to exactly one half based on the sorted side, not hesitating and testing both. Any hesitation produces an infinite loop. Practice saying the condition out loud before you code it.

Coin Change (#322)

Pattern: unbounded knapsack DP.

dp[amount] holds the minimum coins to reach that amount. For each amount from 1 to target, try every coin. Initialize with infinity except dp[0] = 0, and any entry still at infinity after the loop means that amount is unreachable. Most bugs are wrong initialization or confusing this with the 0/1 knapsack. For the full DP framework, Dynamic Programming Is Just Recursion With a Memory. Here's the Framework. is worth a reread the night before.

Course Schedule (#207)

Pattern: cycle detection in a directed graph.

Run DFS with three-color marking (unvisited, in-progress, done) or Kahn's algorithm with in-degree tracking. A cycle means the courses can't all be completed. The course scheduling wrapper is decoration. The real problem is cycle detection. Recognize the costume and you've already solved half of it. This pattern covers dependency resolution, build systems, and compilation order questions at every company.

Word Search (#79)

Pattern: backtracking on a grid.

DFS from each cell. Mark visited in-place (overwrite the character temporarily). Explore all four directions. Restore before returning. The restoration step is what separates backtracking from plain DFS. Skip it and your algorithm reports false negatives on paths that revisit cells. Commit the mark-then-restore idiom to muscle memory. It shows up every time backtracking runs on shared state.

Days 6-7: Advanced Patterns

LRU Cache (#146)

Pattern: hash map plus doubly linked list.

Hash map gives O(1) lookup by key. Doubly linked list gives O(1) eviction and promotion because you hold direct pointers to each node. Sentinel head and tail nodes eliminate edge cases for insertion and deletion. You'll probably implement this twice before you get it right. Do it twice this week, not twice in the interview. This is the pattern-of-patterns for "design a structure with O(1) constraints," and it appears verbatim at Google and Meta.

Find Median from Data Stream (#295)

Pattern: two heaps.

Maintain a max-heap for the lower half and a min-heap for the upper half, balanced so they differ by at most one element. The median is the top of the larger heap, or the average of both tops when equal. No Fibonacci heaps needed. Two normal heaps. Any time you need running access to the median or k-th smallest element of a growing dataset, two heaps are the answer. This also applies to sliding window median variants at the harder end.

How to Actually Practice These

Don't re-read solutions you've already seen. That's recognition, not recall, and recognition fails the moment the problem has a small twist.

For each problem this week:

  1. Set a 25-minute timer.
  2. Write the approach in two sentences before touching code.
  3. Code it, trace one example by hand before running.
  4. After you finish, say the pattern and the key insight out loud in one sentence.

Step 4 is the one that feels awkward and the one that actually works. The deliverable isn't 15 solutions. It's 15 pattern explanations you can speak while coding. That's what the interviewer is evaluating.

If a problem feels shaky, don't move on. Find one more problem from the same pattern family and solve it first.

Stop Adding to the List

No new patterns. No hard problems you've been curious about. The week before is consolidation, not exploration.

If your gap is communication rather than problem-solving (you know the approach but freeze when narrating it), more LeetCode won't fix it. SpaceComplexity runs voice-based mock interviews with rubric feedback on communication, problem-solving, code quality, and testing, so you can get that repetition in before the real thing.

For the full week-before framework, including how to audit your pattern coverage before selecting what to drill, see Seven Days Before the Interview: Audit First, Grind Second.

Further Reading