Two-Week Coding Interview Prep: The Day-by-Day Plan

You just scheduled the interview. It's in 14 days. Your first instinct is to open LeetCode and start grinding whatever the daily problem happens to be, because there are 2,500 problems in the queue and surely the one that will save you is somewhere in there.

That instinct will waste roughly half your time.

Two weeks isn't enough to learn everything. It is enough to cover what actually shows up. Those are different goals, and the difference determines whether you come out of this with signal or with a 3 AM panic attack on day 13.

This Plan Has Prerequisites

If you've never implemented a binary tree, don't understand what O(n log n) means, or haven't written code seriously in the last couple of years, two weeks won't get you there. This is a compression plan for people with a foundation that needs sharpening, not a from-scratch curriculum. "I have a CS degree and coded professionally for a year" is a foundation. "I once took a Java class and retained the part about curly braces" is not.

If you have a CS degree, prior prep experience within the last two years, or at least a year of engineering experience, this plan applies to you. If you're starting from scratch, ask for more time. Three to four weeks gives you room to actually learn rather than memorize. No amount of scheduling fixes a missing foundation.

If you fall somewhere in the middle, lower your outcome expectations and be ready to request a follow-up round if the first one doesn't go well.

Fifty Problems. That's the Budget.

Fourteen days. Three to four hours per day. Roughly one quality problem per hour, including reading the solution, tracing through it, and understanding why it works. That's 50 problems.

Fifty deeply understood problems beats two hundred skimmed ones. Pattern recognition transfers to new problems. Memorization doesn't. Candidates who grind 300 problems in 6 weeks and still freeze learned to recognize specific solutions, not underlying structure. Candidates who do 50 problems deeply can adapt when a variant shows up. This distinction is the entire game.

Spread across 10 patterns, that's 5 problems per pattern. Enough to see the shape, hit a variant, and build enough muscle memory to recognize the cue mid-problem.

The structure: 7 days of core foundations, then 7 days of harder topics and execution practice.

Week 1: Core Foundations

Days 1-2: Arrays, Strings, Hash Maps

Everything in DSA interviews is built on arrays. Hash maps, sliding window, and two pointers all live in this space. Start here because the vocabulary transfers to every subsequent topic.

Do 8 to 10 problems across easy and medium difficulty. You're not hunting for tricky problems. You're building fluency: how to traverse, how to use a frequency map, how to think about subarrays.

Good starting problems: Two Sum, Longest Substring Without Repeating Characters, Valid Anagram, Product of Array Except Self, Group Anagrams.

Days 3-4: Binary Search + Linked Lists

Binary search is the most misapplied pattern in interview prep. People learn the algorithm but can't apply it when the array isn't sorted or when the answer itself is the search space. If you've only done "find the target in a sorted array," you've done the tourist version.

Spend a day on binary search that includes at least one non-obvious application: peak element, rotated sorted array, or binary search on the answer (Koko eating bananas is the canonical one). That second category is what shows up in mediums.

Linked lists get one day. Fast and slow pointers solve a specific family (cycle detection, middle of list, k-th from end) that appear with surprising regularity. Five problems is enough.

Days 5-6: Trees

Trees are where most candidates either earn or lose the interview.

BFS and DFS are the core operations. Everything else, path sums, level order output, lowest common ancestor, validating a BST, builds on those two traversals.

If you can implement DFS and BFS on a tree from memory and identify which one a given problem wants, you've unlocked the majority of tree and graph problems. Do 8 to 10 tree problems. Prioritize: maximum depth, invert binary tree, level order traversal, lowest common ancestor, validate BST, path sum variants.

Day 7: Stop and Recover

Not optional. Sleep consolidates what you've practiced. Go back over problems you partially understood, re-read solutions you copied without fully seeing. Do not start new patterns today.

You will want to. That feeling is wrong.

Three Patterns Cover Half Your Interviews

Before week 2, one non-obvious number.

Data from coding interview problem sets at companies like Amazon and Meta shows that Two Pointers, DFS, and BFS together account for roughly half of all problems asked. Not a plurality. Half.

This isn't a reason to skip everything else. It's a reason to make sure you've internalized those three before treating anything else as urgent. Walk out without leaving points on those three families, and you've covered the median outcome at most target companies. Your Dijkstra anxiety is mathematically premature.

Week 2: Execution Under Pressure

Days 8-9: Graphs

Graphs extend trees. The algorithms are the same: DFS and BFS. The wrinkles are tracking visited nodes, handling cycles, and reading adjacency list representation naturally.

Problems that belong here: number of islands, clone graph, course schedule, word ladder, Pacific Atlantic water flow. About 8 problems total. Focus on the visited set pattern.

Days 10-11: Dynamic Programming Fundamentals

DP is the most feared topic and the most misrepresented in prep guides.

The common mistake is trying to learn DP by memorizing solutions to specific problems. It doesn't transfer because DP is a problem structure, not a recipe. Two questions unlock almost every basic DP problem: does this have overlapping subproblems? Can I define the answer in terms of smaller versions of itself?

For a 2-week window, skip bitmask DP, interval DP, and state machine DP entirely. Stick to five classical patterns: Fibonacci, climbing stairs, coin change, longest increasing subsequence, and 0/1 knapsack. These five carry most of the DP intuition that shows up at medium level, and understanding them well beats skimming fifteen.

Days 12-13: Mock Interviews

This is where most crash-course plans fall apart. A schedule that ends with "review your weak areas" is asking you to guess what's wrong while a timer ticks somewhere you can't see it.

Tom and Jerry meme: I would do absolutely anything to prepare for the interview except do a single timed mock

Two weeks of prep, zero minutes of performing under pressure. This is a real strategy people use.

Start mock interviews on day 12, not day 14. The first mock will feel bad. That's the point. You need to find out what breaks under pressure before the real interview breaks it for you, in front of a stranger who is writing things down.

Schedule 2 to 3 mocks across these two days. Do voice-based mock interviews on SpaceComplexity for rubric-backed feedback on communication and approach, or grab a peer and take turns. The format matters less than the exposure to performing under real conditions.

One thing to practice specifically: the pause. Successful candidates in interviewing.io's analysis waited until roughly 27% into the interview before running code, compared to 23.9% for unsuccessful ones. That gap is under 4% of total interview time. Train the pause deliberately. Talk through the problem before you touch the keyboard.

Day 14: Light Review, Then Stop

Go through your pattern notes. Look at problems you flagged as weak. Re-read any solutions you're shaky on. Then stop.

Your brain needs recovery before a high-stakes performance. A full night of sleep before the interview is worth more than two more hours of grinding.

What to Cut

Two weeks forces real choices. Here's what doesn't make the cut:

Advanced graph algorithms. Dijkstra, Bellman-Ford, Union Find. These appear in roughly 10 to 15% of interviews and take significant time to internalize. Skip them unless the role description explicitly signals graph-heavy work.

Advanced dynamic programming. Bitmask DP, interval DP, digit DP. Elegant algorithms with very low ROI in a 2-week window.

Segment trees and Fenwick trees. These come up at specialized companies. If that's your target, this plan doesn't apply.

System design. If your role requires it, that's a separate prep track. Two weeks isn't enough for both. Pick one.

Hard problems. The interview is mostly mediums. Hards take three to four times as long per problem and don't proportionally increase your readiness. One or two are fine for stress-testing a pattern you've already learned. More than that is procrastination with extra steps.

Butterfly meme: software engineer with 5 years of experience looking at a small farm asking Is this a viable retirement plan

What trying to cover Dijkstra, segment trees, bitmask DP, and system design in two weeks does to a person.

How to Know You're Ready

On day 12 or 13, run this test.

Pick a medium problem you haven't seen. Set a 30-minute timer. Solve it out loud, explaining your thinking as you go, as if there's an interviewer in the room. No solution tab. No hints. Write the code cleanly.

If you can do this consistently across three or four different problems from different patterns, you're ready. Not perfect. Ready.

If you can't finish in 30 minutes, identify what actually went wrong. Pattern recognition (you didn't know which approach to try) and execution (you knew the approach but couldn't code it cleanly) are different problems with different fixes. Recognition means more exposure to varied problems. Execution means more drilling of algorithms you already know.

If you want to understand what the interviewer is actually scoring during this process, the interview rubric breakdown covers the five signals that decide your outcome beyond getting the answer right.

Your 14-Day Schedule

Days 1-2: Arrays, Strings, Hash Maps (8-10 problems)
Days 3-4: Binary Search, Linked Lists (8-10 problems)
Days 5-6: Trees, BFS/DFS (8-10 problems)
Day 7: Rest and light review only
Days 8-9: Graphs (8-10 problems)
Days 10-11: DP fundamentals (8-10 problems)
Days 12-13: 2-3 mock interviews, identify gaps
Day 14: Light review, then stop
Skip: Advanced graph algorithms, bitmask DP, segment trees, system design, hard problems
Readiness signal: Medium problem, cold, 30 minutes, out loud, no hints

If you have more time after this plan, the 30-day prep guide goes deeper on each pattern without changing the order. And if you're figuring out what timeline fits your background, this guide on how long prep takes breaks it down by experience level.