The 30-Day Coding Interview Prep Plan: Study These, Skip the Rest

You got the recruiter email. The interview is in a month. You open LeetCode, see 3,000+ problems, and your brain immediately starts calculating how many you could solve per day if you never slept and also stopped eating. Stop. This is the 30-day coding interview prep plan that actually works.

Thirty days is enough to get competitive if you're strategic. It is not enough to study everything. That's the whole game: knowing what to cut so you can go deep on what actually shows up. This is a week-by-week roadmap for someone with solid programming fundamentals who needs to ramp fast, without taking leave from work or sacrificing their social life entirely. (You'll sacrifice most of it. Just not all.)

What This 30-Day Coding Interview Prep Plan Assumes

You can write code. You know what a function is, you understand recursion at a basic level, and you've seen a for loop before. You are not starting from "what is an array."

What this plan does not assume: that you remember how to detect a cycle in a linked list, implement a heap from scratch, or think in graphs. That's what the next thirty days are for. The target is one to two focused hours per day, every day, no exceptions on weekdays. If you can do more on weekends, do it on review, not new material.

Stop Here: The Triage You Must Do First

Before you open any problem set, decide what you are not studying. This sounds backwards. It is not.

The topics that are safe to skip in a 30-day sprint: bit manipulation (beyond the XOR-to-find-unique trick), geometry problems, 2D dynamic programming beyond grid paths, segment trees, Fenwick trees, AVL and Red-Black tree implementation, advanced graph algorithms like Bellman-Ford and Floyd-Warshall, and string matching algorithms like KMP. These appear in a small fraction of interviews. Spending a week on them in a compressed timeline is how people end up shaky on trees and solid on topics they'll never see.

The Tech Interview Handbook makes the priority hierarchy explicit: arrays, strings, trees, graphs, and sorting are high priority. Dynamic programming, binary operations, math, and geometry are the lowest. That ranking is earned from real interview data, not intuition. Trust it.

What you are studying: two pointers, sliding window, hash maps, binary search, linked lists, stacks, queues, trees (all four traversals, BST operations), graphs (BFS and DFS), heaps, backtracking, 1D dynamic programming, greedy, and interval problems. That's the whole plan.

Week 1: Foundations That Are Not Actually Easy

Days 1 through 7. Topics: arrays, strings, hash maps, two pointers, sliding window.

Most people blow through this week thinking it's the warmup. It is not. The problems labeled "easy" are the ones interviewers use to filter out candidates who never internalized the patterns. Two Sum is a hash map problem, not a brute force problem. Longest substring without repeating characters is a sliding window problem with a shrinkable window, not two nested loops. LeetCode's "easy" label has done more psychological damage to interview candidates than any hard problem ever could.

The goal this week is to nail the techniques, not the solutions. When you finish a two-pointer problem, you should be able to explain: why two pointers, what invariant they maintain, and which constraint tells you to advance which pointer. If you can't say that out loud, do the problem again.

Daily target: three problems per day, mix of easy and medium. Never easy only. Use the time constraint as signal, not a cap: if you're regularly finishing mediums in under fifteen minutes, you're grinding easy problems dressed in medium clothing. Push harder.

Our post on the sliding window algorithm covers the shrinkable vs fixed window distinction that trips people up in real interviews.

Solving a "hard" LeetCode problem vs what it actually looks like for everyone else

That mansion-sized Zelda logic gate build is what LeetCode Hard problems feel like on the solution tab. What you've actually built is one wooden door.

Week 2: Trees, Binary Search, and the Data Structures You Think You Know

Days 8 through 14. Topics: binary search, linked lists, stacks, queues, binary trees.

Binary search is not "find a sorted element." Binary search is a template for eliminating half a search space based on a predicate. Rotated arrays, finding the first/last position, the leftmost insertion point: they all use the same invariant. Spend a day on binary search variations before you touch trees. It will save you later.

Trees are the single highest-yield topic in actual interviews. You need all four traversals (preorder, inorder, postorder, level-order), the difference between recursive and iterative, BST insertion/deletion/validation, and LCA. That's a week of problems on its own. Give trees three days here and you'll revisit them again in week 3 when they connect to graphs.

Linked lists appear less frequently than they used to, but reversal patterns, finding the middle node, and cycle detection still show up. A half-day is enough if you've seen them before. Two hours if this is new.

Daily target: three problems per day, mostly medium. By the end of this week, do your first timed mock. Full 45 minutes, one problem you haven't seen, out loud narration. Record it if possible. The point is not to do well. The point is to find out what breaks under pressure before you need it to work.

This is also when you start behavioral prep. Fifteen minutes per day, no more. Write six STAR stories covering: a hard technical problem you solved, a conflict with a teammate, a time you shipped something with incomplete information, a time you changed your own mind, a time you failed, and a project you're proud of. That's the entire behavioral playbook for most companies. Yes, all of them.

Week 3: Graphs Are Just Trees Without Rules

Days 15 through 21. Topics: BFS, DFS on graphs, backtracking, heaps, Dijkstra.

Most prep plans treat graphs as a brand new scary topic. They are not. If you understood trees in week 2, graphs are the same concept with the constraint removed. A binary tree is a directed acyclic graph. The jump from tree DFS to graph DFS is tracking visited nodes. That's the entire conceptual delta. It feels bigger than it is because "graphs" sounds more academic than "trees," and someone at some point decided to give nodes and edges intimidating names.

BFS and DFS on graphs each take a day. Then the specific patterns: number of islands (DFS flood fill), course schedule (cycle detection, topological sort), word ladder (BFS shortest path). These are the canonical graph interview problems. Solve them until the approach is automatic.

Backtracking deserves two days. The pattern is always the same: choose, recurse, undo. What varies is the pruning logic. Subsets, permutations, combinations, letter combinations of a phone number. Do these in order. They build on each other. See our backtracking algorithm post for the three tree shapes that cover every backtracking problem.

Heaps come up in "top K" problems, median-finding, and merge K sorted lists. You need: how to build a min/max heap, when to use one, and how to use your language's priority queue API. Do not implement a heap from scratch unless you have extra time. Know the interface. Know O(log n) push and pop.

Daily target: three problems per day. Start timing every problem: 45 minutes for medium, 60 for hard. If you go over, stop and read the solution. Time is practice, not pride.

Week 4: DP, Mocks, and the Last 15% That Closes the Gap

Days 22 through 30. Topics: 1D dynamic programming, greedy, intervals, and two full mocks per week.

Learn exactly three DP frameworks and drill them until you could write them sleeping: the 1D linear scan (climbing stairs, house robber, coin change), the two-sequence comparison (longest common subsequence, edit distance), and the bounded knapsack. Skip bitmask DP, interval DP, and DP on trees. They exist. They are not in your 30-day plan.

See our dynamic programming framework post for the recursion-with-memory mental model that makes DP problems feel like directed recursion instead of magic.

Greedy and interval problems take two days combined. Greedy interview problems are recognizable by a single property: the locally optimal choice is always globally optimal, and you can usually prove it by contradiction. If you cannot prove it, it's probably DP, not greedy. Interval problems (merge intervals, meeting rooms, minimum number of platforms) are a distinct pattern worth knowing.

Mocks in week 4: two per week, full format. Use SpaceComplexity or a peer. Voice narration, 45-minute clock, problem you haven't seen. The narration requirement is not optional. Interviewers are evaluating your thinking, not just your output. The candidate who explains a wrong turn clearly and recovers often beats the candidate who silently produces correct code.

When you're 30 minutes into the interview and the candidate is still coding their fizzbuzz solution but you have to stay professional

This is your interviewer when you forget how to reverse a linked list in week 4. Do the mocks.

Daily target: two problems plus one mock every three days.

The Review Loop Most Plans Forget

One thing tanks otherwise solid 30-day preps. You solve a sliding window problem on Day 4, move on to trees on Day 12, and by Day 28 you've forgotten 70% of what you knew. The Ebbinghaus forgetting curve is not a metaphor. Memory decay is rapid and predictable, and it does not care that you have an interview on the 31st.

Allocate 20% of every study session to reviewing problems you solved five to seven days ago. Not re-reading them. Recoding them from scratch, cold, timed. Studies on spaced repetition in skill learning show that reviewing 80 problems with spaced repetition produces better retention than grinding through 200 problems sequentially. The math works against you if you treat each day as a clean slate.

One practical implementation: keep a running problem log in a spreadsheet. Date solved, topic, difficulty, whether you got it clean or needed hints. Every day, pick two to three problems from five to seven days ago and redo them without looking at your old solution. This is the unglamorous part of the plan. It is also the part that separates people who feel ready from people who actually are.

Start Timing at Week 3, Not Before

Weeks 1 and 2: do not time individual problems. You're building understanding, not speed. Looking at a clock while you're trying to figure out why your sliding window is off by one adds stress without adding value.

Week 3: set a soft cap. 45 minutes for medium, 60 for hard. If you hit the cap, stop, look at the solution, understand it, close the tab, rewrite it from scratch. Closing the tab is load-bearing. You will not rewrite it if the answer is still visible.

Week 4: full interview simulation. 45-minute clock, one problem, voice narration from the first second. Zero exceptions. The switch from "practicing problems" to "practicing interviews" is the transition most people delay too long. You are not ready when you feel ready. You are ready when you've done it enough times that the format stops feeling weird.

Your Six Stories, Rehearsed Out Loud

You have six STAR stories from week 2. Spend the last week mapping each story to your target companies' values. Amazon's Leadership Principles are public. Google's behavioral rubric is not secret. Map your stories before you need to recall them under pressure.

One thing that actually matters and almost no one does: practice your stories out loud, not in your head. Reading a story and saying a story use different retrieval paths. The one that works under interview pressure is the one you've rehearsed verbally. "But I know it," you will say. "I know it" and "I can say it fluently while nervous" are different things. One of them gets you an offer.

Before You Close This Tab

What to skip: bit manipulation, geometry, 2D DP, segment trees, Fenwick trees, advanced graph algorithms, string matching algorithms
High priority order: arrays/strings/hash maps (week 1), trees/binary search/linked lists (week 2), graphs/backtracking/heap (week 3), 1D DP/greedy/intervals (week 4)
Daily target: three problems per day weeks 1-3, two problems plus mocks in week 4
Review loop: 20% of each session on problems from five to seven days ago
Start mocks at Day 14, not when you feel ready
Behavioral: six STAR stories, mapped to company values, rehearsed out loud
DP: learn three frameworks (1D linear, two-sequence, bounded knapsack), skip the rest
Start timing at week 3, full interview format in week 4

Practice problems on LeetCode using the Blind 75 or Grind 75 list as your guide, and when week 3 hits, layer in timed mock interviews. One month is tight. It's also enough if you know what you're cutting.