Give the month two slots and two different jobs. Weekdays are 45 minutes of review only, no new problems, because a first attempt at 21:40 after nine hours of meetings teaches you almost nothing and burns the problem permanently. Every new problem lives in one protected four-hour weekend block. Four weeks of that leaves roughly 48 problems rather than 150, and the hard ones have been solved twice from a blank file instead of read once.
Why a workday evening gets no new problems
First contact with a problem is single-use. You get one chance to read it cold and find out which pattern fires, how long you flail first, and whether you say anything useful out loud. Spend that after a nine-hour day and all you learn is what a tired version of you does, and you never get to ask again. Worse, you encode the flailing, so a week later the problem feels familiar in the useless way.
A re-solve is the opposite. You know the shape, so tiredness costs accuracy rather than insight, which is closer to a 5pm onsite anyway. It is also bounded, where a first attempt runs 20 minutes or 70 with no way to tell in advance, making it the worst thing to put in a slot an incident can delete. So the rule is blunt: Monday to Friday you never open a problem you have not seen.
The weekday 45 minutes, minute by minute
0 to 7, cold recall with the card face down
Say five pattern cues aloud from memory. "Sorted array plus a target sum." "Longest run subject to a constraint." No screen, no editor. Two blanks picks tonight's re-solve.
7 to 32, one re-solve, blank file, 25-minute timer
A problem you attempted at the weekend. Type it from nothing, narrating aloud. When the timer ends you stop, whatever state the code is in.
32 to 40, diff it against your weekend version
Find the one line that went wrong and write why in a sentence. Usually an off-by-one in the shrink condition, a visited set added too late, or an unstated base case.
40 to 45, retire it or requeue it
Clean twice in a row and it leaves for good. Anything else goes back in for later in the week. The queue holds five, never more.
That is the whole weekday. No editorials, no new lists, no videos.
The Saturday block: 240 minutes, thirteen new problems
Pick one four-hour window and defend it like a meeting with your director. The block is deliberately mixed: full solves where you write real code, and short sprints where you only decide the approach, because deciding is the part that actually fails in interviews and costs eight minutes to practise rather than thirty.
| Clock | What you do | Output |
|---|---|---|
| 0:00 to 0:15 | Rebuild the pattern card from memory, then check it | One card, ten cues |
| 0:15 to 1:15 | Two full solves: 20-minute hard-capped attempt, then 10 minutes on the editorial and a note | 2 coded and logged |
| 1:15 to 1:55 | Five approach sprints, 8 minutes each: read it, write five lines of approach and complexity, no code | 5 decided |
| 1:55 to 2:10 | Break, away from the desk | Nothing, on purpose |
| 2:10 to 3:10 | Two more full solves, same 20 and 10 split | 2 coded and logged |
| 3:10 to 3:42 | Four more approach sprints | 4 decided |
| 3:42 to 4:00 | Choose the five for next week's weekday queue | The queue |
Thirteen problems touched, four coded end to end. Queue the ones where the sprint note came out vague, not the ones you enjoyed. "Probably DFS, something with a visited set" gets queued; a note naming the state, the transition and the complexity is finished.
What each weekend covers
| Week | Saturday block, first contact | Weekday queue |
|---|---|---|
| 1 | Hash maps, two pointers, sliding window, binary search | The five you handled worst |
| 2 | Trees, BFS and DFS on graphs, heaps, intervals | Week 2's five, plus week 1 stragglers |
| 3 | Recursion and backtracking, 1D dynamic programming, stacks, linked lists | Week 3's five |
| 4 | No new patterns. Two 45-minute mocks, then mixed problems from weeks 1 to 3, unlabelled | Only problems that failed twice |
Week 4 strips the labels on purpose. "Solve a sliding window problem" and "notice that this is a sliding window problem" are different skills, and only the second one gets tested.
The fallback week, when on-call eats three evenings
Assume one week in four goes wrong. You get paged on Tuesday, the release slips to Wednesday night, by Thursday you are too fried to type. This is why the fragile slot holds the cheap work: three lost evenings cost three re-solves, not three first attempts, and re-solves reschedule. The recovery, in order:
- Protect the four-hour block absolutely. If Saturday is gone, move it to Sunday. Never halve it: the sprints are what get cut, and the sprints are the point.
- Drop weekdays to a twelve-minute floor. Cold recall only, card face down, no editor. Twelve poor minutes keep the cues warm and stop you writing the month off on Wednesday.
- Cut that weekend's sprints from nine to five. Spend the recovered 32 minutes clearing the re-solves you missed. New problems that week fall from thirteen to nine, the correct trade.
- Never move a full solve onto a weekday to catch up. Attacking three unseen problems on Thursday night is how people finish the month having read forty problems and owning none.
- Do not add a fifth week. If the date moves, add problems to the weekends, not days to the calendar.
The number that survives
Four clean weeks touch 52 problems, less week 4's swap for mocks, so call it 48. One fallback week takes you to 44, two take you to 40. The honest range is 45 to 55, which looks like failure beside a 150-problem list until you compare what each leaves behind.
| Compared on | The 150-problem list | This plan, 48 problems |
|---|---|---|
| First read of a problem | Whenever you get to it | Saturday morning, rested |
| Times you code a hard one from blank | Once | Twice, a week apart |
| Cost of one lost evening | A problem you now never meet | One re-solve, rescheduled |
| Coverage at the end | Broad, tries and 2D DP included | Tries, union-find, 2D DP, topological sort and bit manipulation untouched |
| State on interview day | Recognition of many, recall of few | Forty-odd you can rebuild aloud, five gaps you can name |
The 150 list wins outright if you genuinely have the hours. With a full-time job you do not, and a half-finished 150 is worse than a finished 48, because you never learn which half you own.
Where this plan, and this tooling, fall down
Four weeks will not make you fluent in a language you are still looking up, and the plan assumes you already write code most weeks. It will not carry a senior system design loop. It leaves five topics untouched by design, so if the recruiter mentions union-find you have bought a gap and should know it.
On tooling, the sharpest limitation is an argument against using ours. During a 20-minute first attempt, Code Copilot is the wrong tool, and reaching for it destroys the single-use diagnostic the month is built around. It earns its place at minute 21, when you want the intuition, a dry run and the Big-O faster than three forum threads. It runs on Windows 10 and 11 only, no macOS, Linux or mobile. Its overlay is excluded from screen capture at the operating-system level, so it is absent from Zoom, Teams, Meet and screen recordings. That is about screen sharing and nothing else: it does nothing about a webcam, a lockdown browser, a proctor in the room, or a second-device camera. Where an assessment forbids outside help, the useful window is the four weeks before it.
What to do in the next hour
Put the four-hour block in your calendar for this Saturday with a real title, decline whatever collides with it, then pick the five weekday slots you can honestly defend. Do nothing else tonight. If a behavioural round is bolted on, week 4's spare evenings are where it belongs, and the company Q&A generator builds a role-specific bank in minutes. The free tier is five minutes a day with no card; paid tiers are on the pricing page.