How to Prepare for a Coding Interview in 4 Weeks

TL;DR: Four weeks is enough if you sequence correctly. Week 1: arrays, strings, hash maps. Week 2: trees, graphs, recursion. Week 3: dynamic programming, binary search, greedy, plus system design basics. Week 4: mocks, review, behavioral prep, taper. Solve 4–6 problems a day, always out loud, always with a retry date. Volume matters less than pattern mastery plus spaced repetition.

Four weeks is not a lot of time, but it is enough — if you spend it deliberately. Most candidates fail interviews not because they lack talent, but because they practice the wrong things in the wrong order. They grind random hard problems, memorize solutions they do not understand, and walk into the interview room having never explained their thinking out loud.

This plan fixes that. It assumes roughly 1.5–2 hours per weekday and 3–4 hours per weekend day. If you have less time, compress each week rather than skipping one. If your interview includes a company-specific online assessment first — Amazon, Microsoft, and Meta all use one for internships — start with the matching guide: Amazon OA, Microsoft OA, or the Meta SWE internship process.

The mindset before you start

Two principles drive everything below:

1. Patterns beat problems. Roughly 80% of interview questions are variations of a small set of patterns: two pointers, sliding window, hash maps, BFS/DFS, binary search, and dynamic programming. Learning 25 patterns deeply is worth more than solving 250 random problems.
2. Interviewing is a performance skill. Reading solutions is not the same as producing them. From day one, talk through your reasoning, write code in a bare editor, and time yourself.

Keep a simple tracker with four columns: problem, pattern, what stumped you, retry date. Spaced repetition is the engine of the entire plan — most forgetting happens in the first week, and one timely retry largely prevents it.

Week 1: Fundamentals and the core toolbox

• Day 1–2: Arrays, strings, and hash maps. 8–10 easy problems on frequency counting, lookups, and deduplication. For every problem, state the brute-force answer before optimizing — interviewers score this explicitly.
• Day 3–4: Two pointers and sliding window. These appear constantly in string and array questions. Do 6–8 problems; pay attention to when pointers move toward each other versus in the same direction.
• Day 5: Linked lists. Reversal, cycle detection, fast/slow pointers. Short problems, but they test pointer discipline that shows up everywhere.
• Weekend: Stacks, queues, and the monotonic stack. Then a review pass: redo every problem you missed during the week, from scratch, without notes.

Checkpoint: implement a hash-map lookup, a two-pointer scan, and a linked-list reversal in under ten minutes each, cold.

Week 2: Trees, graphs, and recursion

• Day 1–2: Binary trees. DFS traversals, tree height, level-order traversal (BFS), lowest common ancestor. 6–8 problems.
• Day 3: Recursion and backtracking. Subsets, permutations, n-queens. The template is always the same: choose, recurse, un-choose. Internalize it until automatic.
• Day 4–5: Graphs. The mental model: adjacency list + visited set + queue (BFS) or recursion (DFS). Connected components, shortest path in an unweighted graph, cycle detection.
• Weekend: Two timed mini-mocks: two medium problems in 45 minutes each. Retry Sunday on every graph problem that beat you.

Week 3: The heavy hitters

• Day 1–2: Dynamic programming, honestly. Learn the recipe: define the state, write the recurrence, identify base cases, then choose memoization or tabulation. Sequence: Fibonacci → climbing stairs → coin change → longest common subsequence → 0/1 knapsack. That covers the vocabulary of 90% of interview DP.
• Day 3: Binary search beyond sorted arrays. "Binary search on the answer" is under-practiced and shows up in harder problems: minimum capacity to ship packages, koko eating bananas, split array largest sum.
• Day 4: Heaps and greedy. Top-k patterns, meeting rooms, interval scheduling. Learn to recognize when a heap is the right tool.
• Day 5: System design fundamentals (mid-level+ roles). Load balancing, caching, databases, message queues. Sketch a URL shortener and a rate limiter on paper. New-grad candidates: replace with another algorithm session, such as the Two Sum walkthrough and its variants.
• Weekend: Two full mock interviews under realistic conditions — camera on, shared editor, 45 minutes, one medium and one medium-hard. With a friend, interview each other; otherwise use a mock platform or record yourself.

Week 4: Peak performance and polish

No new topics. Convert skill into performance.

• Day 1–2: Company-focused review. Study your target's style — some favor graphs, others love behavioral-first loops. Redo your full "missed problems" list from weeks 1–3. If you have an OA coming, work through the matching assessment guide (for example, the Google STEP guide for early-year Google candidates).
• Day 3: Behavioral stories. Prepare five STAR stories: conflict, failure, leadership, ambiguity, and a technical deep-dive. Keep each under two minutes. If your target company is Amazon, extend this into a full Leadership Principles session using the Amazon LP interview guide.
• Day 4: Speed drills. Five easy/medium problems in one hour. Zero hesitation on setup: restate the problem, propose a brute force, name the complexity.
• Day 5 (48+ hours before the interview): light review only — notes, pattern quick reference, stories. Sleep is a study tool.
• Interview day: one easy warm-up problem you know well, to prime your fingers and confidence. Nothing new.

Topic checklist

| Topic | Key patterns | Target fluency by | | --- | --- | --- | | Arrays & strings | two pointers, sliding window, hashing | End of Week 1 | | Linked lists | reversal, fast/slow, cycle | End of Week 1 | | Stacks & queues | monotonic stack, BFS layering | End of Week 1 | | Trees & graphs | DFS/BFS, LCA, components | End of Week 2 | | Recursion & backtracking | choose/recurse/un-choose | End of Week 2 | | Dynamic programming | state → recurrence → base cases | End of Week 3 | | Binary search | sorted input, search on answer | End of Week 3 | | Heaps & greedy | top-k, intervals, scheduling | End of Week 3 |

The loop for every problem

Whatever week you are in:

1. Attempt first, untimed. Struggle 20–30 minutes before looking at anything.
2. Study the solution actively. Close it and re-implement. If you cannot, you did not learn it.
3. Explain it out loud. Answer the imaginary follow-up: "why a hash map and not a sorted array?"
4. Schedule a retry. Log it with a date 4–7 days out.

Common mistakes to avoid

• Grinding by volume. One hundred deeply understood problems beat five hundred skimmed ones.
• Ignoring complexity analysis. Interviewers ask about it on nearly every problem; practice stating it the moment you finish coding.
• Testing only the happy path. Always walk through one normal example and one edge case (empty, single element, duplicates) before declaring done.
• Going silent while coding. Narrate — an interviewer can only help you if they can follow you.
• Skipping behavioral prep. Companies reject strong coders daily for weak communication or self-awareness.
• Ignoring the OA stage. For internship and new-grad roles, the online assessment is the first filter — prepare it deliberately, not accidentally.

A note on using AI tools

AI assistants can accelerate preparation enormously — if you use them as a coach rather than a vending machine. Ask for a hint instead of the answer, ask the AI to grill you with follow-up questions, and have it explain why an approach works. When every solution is a lesson rather than a shortcut, four weeks of focused practice really is enough to walk into your interview with genuine confidence.

Frequently Asked Questions

Is 4 weeks really enough to prepare for a coding interview?

Yes, for most candidates and most roles, if the time is sequenced well and spent deliberately. Fundamentals in week 1–2, heavy hitters in week 3, and performance conversion in week 4 beats eight unfocused weeks of random grinding.

How many problems should I solve per day?

Aim for 4–6 quality problems on weekdays and a review-focused weekend. Depth plus scheduled retries matters more than raw volume; 80 deeply learned problems is a strong foundation.

What if my interview is system design heavy?

Extend week 3's system design day into a full week: study load balancing, caching, databases, and queues, then practice sketching designs out loud. For new-grad and intern roles, pure algorithms usually dominate anyway.

How do I practice behavioral questions?

Use the STAR format (Situation, Task, Action, Result) with five stories: conflict, failure, leadership, ambiguity, and a technical deep-dive. Practice them out loud against a timer — two minutes each — and adapt them to common questions like "tell me about yourself."

Should I use paid platforms to prepare?

Paid question banks are useful but not required; the free ecosystem covers the same patterns. Where tools earn their cost is realistic, timed practice with feedback — the same effect you get from mock interviews and AI-assisted practice sessions.