30-Day Coding Interview Preparation Plan: The Day-by-Day Schedule

You got the call: the interview is in four weeks. Most people react by opening a 450-problem sheet, getting through problem 60, and walking into the interview with half the topics untouched. This plan works the other way round. It starts from the date and the hours you really have, picks the problems that teach the most reusable patterns, and builds in re-solves and mock interviews so that what you practise in week one is still there on interview day.

Below is the full day-by-day schedule with specific LeetCode problems, the routine for each day, the code templates worth memorising, and how to compress or stretch the plan for your situation. It is built for Indian product-company and FAANG-style loops (Amazon, Google, Microsoft, Flipkart, Atlassian, Uber, Razorpay and similar). Service-company OAs and many startups ask the same patterns, just easier.

Before Day 1: Assumptions and a 90-Minute Diagnostic

A one-month plan only works if its starting assumptions match you. This one assumes:

• You are comfortable in one language: loops, functions, classes, and its standard collections (a hash map, a dynamic array, a heap/priority queue, a deque). If you are not sure which language to use, read Java vs Python vs C++ for DSA and pick in one evening. Don't spend a week deciding.
• You have seen arrays, linked lists, trees and recursion before, even if they are rusty.
• You have about 110 hours in total. That is 2.5 hours × 20 weekdays + 6 hours × 10 weekend days, give or take.

Spend 90 minutes on a diagnostic the day before you start. Pick one medium from each of these areas and give yourself 25 minutes per problem: hashing (LeetCode 49 Group Anagrams), sliding window (3 Longest Substring Without Repeating Characters), trees (102 Binary Tree Level Order Traversal) and DP (198 House Robber). Note which ones you solved cleanly, which you half-solved and which you could not start. The topics you could not start get extra re-solve slots in the schedule. The ones you solved cleanly let you skip the warm-up easies for that week.

How the 30 Days Are Built

The plan has three design rules, and each one is there to fix a common way people waste a prep month.

1. Patterns before volume. Interview questions are mostly variations on about 15 patterns. Each day teaches one pattern with one "learn it" problem and then three problems that use it in different ways. The problem list is a curated subset of the well-known lists compared in Blind 75 vs NeetCode 150 vs Striver SDE Sheet, ordered so that each topic builds on the previous one (trees before graphs, recursion before DP).
2. Spaced re-solving. A problem you solved once and never saw again is mostly gone after a week. Each day starts with re-solving problems from 1, 3 and 7 days earlier, from a blank editor, without looking at your old code.
3. Mocks early and often. Solving quietly at your desk and explaining a solution to a stranger in 45 minutes are different skills. You get your first mock on Day 10 and about eight in total.

The Daily Routine (Weekday and Weekend Versions)

The routine matters more than the problem list. Here is the weekday block, built for someone who works full time. If you are a student, run the weekend version every day.

The 25-minute rule for being stuck

Set a timer for each medium. In the first 10 minutes, write down the brute force and its complexity, even if it is obviously too slow. If you have no direction by minute 25, read only the first hint or the topic tag and try for 10 more minutes. If you are still stuck, read the full solution, close it, and write the code yourself from a blank file. Then mark the problem for re-solving. Spending two hours stuck on one problem feels productive, but in a 30-day window it is one of the most expensive mistakes you can make.

The error log: the one artefact that matters

Keep one spreadsheet with these columns: Date | Problem | Pattern | Solved? (Y / hint / no) | Key insight in one line | Mistake | Re-solve dates. "Key insight" is something like "monotonic decreasing deque of indices; pop from front when out of window". If you cannot write that line, you did not really understand the problem. In week 4 this log is your revision material, and it is far more valuable than re-reading editorials.

Week 1 (Days 1–7): Arrays, Hashing, Two Pointers, Sliding Window, Binary Search, Stacks

Week one covers the patterns behind most phone screens and online assessments. Problems marked ★ are core; if you are short on time, do only those.

What you should be able to do by Day 7: on seeing "subarray/substring with a constraint", decide between sliding window (all values non-negative, or the window condition is monotonic) and prefix sum + hash map (negative numbers are possible, or you need an exact sum). That one decision alone covers a large share of array questions. If it still feels shaky, read the sliding window guide on Day 7.

Use the Day 7 weekend hour for your introduction and project story. Write a 90-second "tell me about yourself" and practise it out loud once. It sounds unrelated to DSA, but every round opens with it, and getting it ready early frees up week 4.

Week 2 (Days 8–14): Linked Lists, Trees, Heaps, Backtracking

Week two is about recursion and pointers. The key skill is trusting the recursion: you define what a function returns for a subtree and stop trying to trace the whole call stack in your head.

Mock #1 on Day 10 should be gentle. Ask a friend, a colleague, or use a peer platform, and solve one medium out loud in 30 minutes. The point is not to pass. It is to find out what goes wrong when someone is watching: going silent, jumping to code, forgetting edge cases. Write down three things to fix. The think-out-loud guide is worth reading the night before.

On Day 14 you should be able to state, for any tree problem, what the recursive function returns and what it updates globally. Diameter (543) and Max Path Sum (124) are the same shape: return the best single downward path, and update a global answer with the path that bends through the node. If you can see that link, trees are done.

Week 3 (Days 15–21): Graphs, Tries, Intervals, Greedy, Dynamic Programming

Week three is the heaviest. Graphs and DP are what separate a pass from a strong pass at product companies, and they are also what most people leave until it is too late. If week 2 ran over, cut Day 18's optional problems, not the DP days.

For DP, use one procedure every time: (1) define the state in words ("dp[i] = fewest coins to make amount i"), (2) write the transition, (3) write the base cases, (4) code it top-down with memoisation, (5) only then convert to bottom-up if the interviewer asks. Interviewers care much more that you can say the state out loud than that you can produce an optimised 1-D table straight away. The DP interview questions guide goes deeper into the families.

Weekend hours in week 3 are for system design fundamentals if you have 2+ years of experience (load balancing, caching, database choice, one classic design such as a URL shortener or rate limiter). Freshers should use them for OS/DBMS/CN basics or for an extra DP session.

Week 4 (Days 22–30): Mocks, Weak Spots, Company Prep and Revision

No new topics after Day 25. Week four turns what you know into performance under interview conditions.

How to get eight mocks without paying for eight

Mix three sources. Peers: pair with a friend on the same timeline and swap roles; being the interviewer teaches you what a good candidate sounds like. Peer-matching platforms: free mock platforms pair strangers, which is useful because you lose the comfort of a friend. One or two paid or senior mocks: an engineer who has actually interviewed at your target company gives calibrated feedback a peer cannot. For structure and how to debrief, see the mock interview strategy guide.

The last 24 hours checklist

• Re-solve three problems you know well. The point is warm hands, not new learning.
• Re-read your error log "key insight" column top to bottom (about 20 minutes).
• Remote interview: test camera, mic, internet, the coding pad (CoderPad, HackerRank, Google Docs or whatever the invite says), and keep a phone hotspot as backup.
• Prepare two questions to ask the interviewer (see 30 smart questions to ask).
• Stop by 9 pm. A tired brain loses more points than one more problem could add.

Code Templates Worth Memorising in Week 1–3

Templates are not for copy-pasting into interviews. They are there so your hands already know the boilerplate and your attention can go to the problem-specific part. These are the three with the highest payoff. Write each one from memory on the day you learn it and again on Day 27.

1. Variable-size sliding window (Day 4)

Example: length of the longest substring without repeating characters (LeetCode 3). The window [left, right] grows on the right; while it is invalid, shrink it from the left.

def length_of_longest_substring(s: str) -> int:
    last_seen = {}          # char -> most recent index
    left = best = 0
    for right, ch in enumerate(s):
        if ch in last_seen and last_seen[ch] >= left:
            left = last_seen[ch] + 1   # jump past the duplicate
        last_seen[ch] = right
        best = max(best, right - left + 1)
    return best

#include <string>
#include <unordered_map>
#include <algorithm>
using namespace std;

int lengthOfLongestSubstring(const string& s) {
    unordered_map<char, int> lastSeen;
    int left = 0, best = 0;
    for (int right = 0; right < (int)s.size(); ++right) {
        auto it = lastSeen.find(s[right]);
        if (it != lastSeen.end() && it->second >= left)
            left = it->second + 1;
        lastSeen[s[right]] = right;
        best = max(best, right - left + 1);
    }
    return best;
}

Dry run on "abba": right=0 'a' → window "a", best 1. right=1 'b' → "ab", best 2. right=2 'b' was seen at 1 ≥ left 0, so left=2 → "b". right=3 'a' was seen at 0, but 0 < left 2, so left stays 2 → "ba", best stays 2. Without the >= left check, left would jump backwards to 1 and you would get 3. That is the classic bug, and it is exactly what this dry run catches.

2. Binary search on the answer (Day 5)

When the question says "minimum X such that a condition holds" and the condition is monotonic (true for everything above some threshold), binary search over X. Koko Eating Bananas (875):

def min_eating_speed(piles: list[int], h: int) -> int:
    def hours(k: int) -> int:
        return sum((p + k - 1) // k for p in piles)   # ceil(p / k)

    lo, hi = 1, max(piles)
    while lo < hi:                 # find first k with hours(k) <= h
        mid = (lo + hi) // 2
        if hours(mid) <= h:
            hi = mid               # mid works; maybe smaller works too
        else:
            lo = mid + 1
    return lo

#include <vector>
#include <algorithm>
using namespace std;

int minEatingSpeed(const vector<int>& piles, int h) {
    auto hours = [&](long long k) {
        long long total = 0;
        for (int p : piles) total += (p + k - 1) / k;
        return total;
    };
    int lo = 1, hi = *max_element(piles.begin(), piles.end());
    while (lo < hi) {
        int mid = lo + (hi - lo) / 2;
        if (hours(mid) <= h) hi = mid;
        else lo = mid + 1;
    }
    return lo;
}

Complexity: O(n log M) where M is the largest pile. Note the long long in C++: the hour total can overflow int when piles are up to 10⁹. Saying that out loud is the kind of detail that earns a "strong" on coding quality.

3. BFS on a grid (Day 15)

Multi-source BFS from Rotting Oranges (994) also covers shortest path in an unweighted grid, "walls and gates", and nearest-zero distance.

from collections import deque

def oranges_rotting(grid: list[list[int]]) -> int:
    rows, cols = len(grid), len(grid[0])
    q, fresh = deque(), 0
    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == 2:
                q.append((r, c))
            elif grid[r][c] == 1:
                fresh += 1
    minutes = 0
    while q and fresh:
        for _ in range(len(q)):            # one BFS level = one minute
            r, c = q.popleft()
            for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)):
                nr, nc = r + dr, c + dc
                if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] == 1:
                    grid[nr][nc] = 2       # mark when enqueuing, not when popping
                    fresh -= 1
                    q.append((nr, nc))
        minutes += 1
    return minutes if fresh == 0 else -1

Mark a cell visited when you enqueue it, not when you pop it. Otherwise the same cell is added several times, and on large grids that blows up both time and memory. A full walkthrough is in LeetCode 994 explained.

Adjusting the Plan for Your Situation

If you only have 14 days

Do only the ★ problems and merge days in pairs: Days 1+2, 3+4, 5+6, 8+9, 10+11, 13+14, 15+16, 19+20. Keep at least three mocks. Drop Days 12, 17 and 25. Drop the 2-D DP day only if your target company is known for lighter DSA (many mid-size startups and service-company lateral roles).

If you only have one hour a day

Stretch to six weeks: 2 new problems + 1 re-solve per weekday, and the full weekend blocks. Don't cut re-solves to make room for more new problems. That trade feels faster and is slower.

Target-specific tweaks

Company processes change, so confirm the round structure with your recruiter early. They will usually tell you the number and type of rounds if you ask.

If you are working full time

Mornings tend to beat evenings for the "solve" block, because problem-solving quality drops sharply after a workday. A pattern that works for many people is a 6:30–8:00 am solve block plus a 30-minute evening re-solve and log. More on fitting prep around a job is in preparing while working full time.

Mistakes That Waste a 30-Day Prep Window

If you finish the 30 days and the interview gets postponed, which happens often, don't start a new sheet. Keep the routine at half intensity: two re-solves and two fresh mixed mediums a day, plus one mock a week. That keeps you at peak without burning out.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.