The Plan Only Works If You Show Up
Thirty days will not make you a world-class engineer. It will make you dangerous in an interview, which is a different and more useful thing. The trap most people fall into is passive review: rewatching lectures, rereading chapters, nodding along. That builds recognition, not recall. Interviews test recall under a clock while a stranger watches you sweat.
So this plan is built around reps, not reading. Every day you solve problems cold, then review the ones you missed. Budget 90 minutes on weekdays and 2 to 3 hours on weekends. If you can only give 45 minutes, halve the problem counts but keep the structure. Consistency beats intensity every time.
One rule before you start: if a problem beats you in 35 to 40 minutes, stop, read the solution, understand it fully, and re-solve it from scratch two days later. Grinding a problem for two hours teaches you almost nothing except how to feel bad.
The Four-Week Schedule
Each week pairs a topic block with a graded problem set. "Graded" means you track three buckets: solved cold (no help, under time), solved with a nudge (peeked at a hint), and failed (read the full solution). Your only job is to shrink the last two buckets.
Week 1: Foundations and Hashing
Chapters 2 to 4. This is where interviews are won or lost, because most problems reduce to "use a hash map."
- Days 1 to 2: Arrays and strings. 4 easy, 2 medium. Two Sum, valid anagram, best time to buy/sell stock.
- Days 3 to 4: Hash maps and sets. 3 medium. Group anagrams, top-k frequent, subarray sum equals k.
- Day 5: Two pointers and sliding window. 3 medium. Longest substring without repeating characters.
- Weekend: Mock interview #1 plus re-solve every failed problem from the week.
Week 2: Linear Structures and Recursion
Chapters 5 to 7. Stacks, queues, linked lists, then recursion and backtracking.
- Days 6 to 7: Stacks and queues. Valid parentheses, min stack, daily temperatures.
- Days 8 to 9: Linked lists. Reverse a list, detect a cycle, merge two sorted lists. Draw the pointers on paper. Always.
- Days 10 to 11: Recursion and backtracking. Subsets, permutations, combination sum.
- Weekend: Mock interview #2 plus a timed set of 3 mixed mediums.
Week 3: Non-Linear Structures
Chapters 8 to 10. Sorting, searching, trees, heaps, graphs.
- Days 12 to 13: Binary search on the answer, not just sorted arrays. Search in rotated array, koko eating bananas.
- Days 14 to 16: Trees and heaps. Level-order traversal, validate a BST, kth largest, lowest common ancestor.
- Days 17 to 18: Graphs. BFS/DFS templates, number of islands, course schedule.
- Weekend: Mock interview #3 on a topic you dread. Lean into the discomfort.
Week 4: Hard Patterns and Simulation
Chapter 11 plus full-length dress rehearsals.
- Days 19 to 21: Dynamic programming. Climbing stairs, house robber, coin change, longest common subsequence. Derive the recurrence out loud before coding.
- Days 22 to 24: Mixed hard sets, 2 per day, no topic labels. This mirrors reality: you rarely know the category up front.
- Days 25 to 27: Mock interviews #4, #5, #6, one per day, back to back.
- Days 28 to 30: Re-solve your all-time worst problems, polish your intro and questions, rest the day before the real thing.
The dsa-python course maps almost one-to-one onto weeks 1 through 3 if you want guided lessons alongside the reps, and advanced-python-programming helps if your language fundamentals are shaky enough to cost you time.
Mock Interviews Are Non-Negotiable
Solving problems silently in your editor is practice for a test that does not exist. The real test is verbal, watched, and interruptible. Get a friend, use a peer-matching site, or record yourself and play it back.
The single highest-leverage habit: narrate before you type. State your approach, its Big-O, and one edge case, then ask "does that sound reasonable?" before writing a line. Interviewers hire the person they want to debug production with at 2am, not the fastest silent typer.
The Checklist for Any Unseen Problem
When panic hits, you do not rise to the occasion, you fall to your default routine. Make this your routine. Run it top to bottom on every problem, in the interview and in practice, until it is muscle memory.
- Restate it in your own words and confirm with the interviewer. Catch the trick in the wording now, not 20 minutes in.
- Nail down inputs and outputs. Types, ranges, can it be empty, are there duplicates, is it sorted, can values be negative.
- Write two or three examples by hand, including one edge case. A brute-force answer on paper beats a blank screen.
- State brute force out loud with its Big-O. This buys thinking time and shows you can always ship something.
- Look for the pattern. Ask yourself the trigger questions below.
- Talk through the optimization, get a nod, then code.
- Test it by hand on your examples before claiming you are done.
Keep this prompt handy while you practice so pattern-matching becomes automatic:
Given this problem, which pattern likely applies?
- Pairs or subarrays in an array? -> two pointers or sliding window
- "Have I seen this before?" or counting? -> hash map or set
- Sorted input, or "find the boundary"? -> binary search
- Top-k, or a running min/max? -> heap
- Nested choices, "all combinations"? -> backtracking
- "Number of ways" or optimal-value overlap? -> dynamic programming
- Connections, grids, dependencies? -> graph BFS/DFS
Print it. Tape it above your desk. By day 30 you will not need it, and that is exactly the point.
What Good Looks Like on Day 30
You will not have solved every problem type. You will have a reliable routine, a shrinking failure bucket, and six mock interviews of scar tissue. When an unseen problem lands, you will not freeze, you will run the checklist. That composure is the whole game. Now go book a real interview, even one you expect to fail, because nothing sharpens the plan like a live rep with real stakes.