If you have a full-time job and roughly 8 to 10 hours a week to spare, three months is enough to prep for a serious coding interview loop without torching your evenings. The plan below splits into three phases: four weeks building pattern fluency, four weeks going deep plus mock interviews, and a final month of full-loop simulation and company-specific targeting. The hard part is not the material. It is protecting the time and spacing your reps so you actually retain what you practice.
We run mock interviews all day, and the single most common failure mode we see from working engineers is cramming: 20 problems in a weekend, then nothing for 10 days. You forget the pattern before you need it. A smaller, steadier cadence beats a heroic Saturday every time.
How much time you actually have
Be honest about the budget before you build the schedule. Most people working full time can sustain about 1 hour on weekdays and a longer 3 to 4 hour block on one weekend day. That is roughly 8 to 10 hours a week, or around 110 to 130 hours over 13 weeks. That is plenty if none of it is wasted.
Here is the allocation we recommend across the three months:
| Phase | Weeks | Weekly hours | Focus |
|---|---|---|---|
| 1. Foundations | 1 to 4 | 8 to 9 | Core patterns, one topic at a time |
| 2. Depth + mocks | 5 to 8 | 9 to 10 | Harder problems, first mock interviews |
| 3. Simulation | 9 to 12 | 9 to 10 | Full loops, company targeting, behavioral |
| Buffer | 13 | 5 to 6 | Light review, rest before onsites |
Two rules make this survivable. First, timebox every problem to 35 to 45 minutes. If you are stuck, read the solution, understand it, and move on, then re-attempt it cold three days later. Second, keep weekday sessions short and single-topic so a bad day at work does not blow up your whole plan.
Month 1: build pattern fluency
The goal of the first four weeks is recognition speed, not solving the hardest problems. Interviews reward spotting that a problem is a two-pointer scan or a bottom-up DP within the first two minutes. Pick one pattern per week and drill it until the shape is automatic.
A sensible order for week-by-week focus:
- Week 1: Arrays, hashing, and prefix sums. Start easy to rebuild confidence. "Minimum Amount of Time to Fill Cups" is a clean junior-level greedy warmup that takes 15 minutes and gets you thinking about cases.
- Week 2: Two pointers and sliding window. These two cover a large slice of easy and medium questions.
- Week 3: Trees and traversal. "Find Duplicate Subtrees" is a good stretch here because it combines DFS with serialization into a hash map, a pairing that shows up constantly.
- Week 4: Dynamic programming foundations. "Domino and Tromino Tiling" is an ideal first real DP problem: the recurrence is non-obvious but small, so you learn to derive state transitions rather than memorize them.
Work through these on our practice library so you get AI feedback on your approach, not just a pass or fail. If you want a structured list of problems per topic with counts, the concepts index maps every pattern to its question set. Do not try to be comprehensive in month one. Fluency in eight or nine patterns beats shallow exposure to twenty.
Month 2: go deep and start mocking
Weeks 5 through 8 are where you add difficulty and, critically, start talking out loud. Reading solutions silently builds a false sense of readiness. The interview is a performance, and you need reps under observation.
Spend the weekday hours on harder single problems and the weekend block on one timed mock. Target the staff and mid-senior tier now:
- "Number of Ways to Stay in the Same Place After Some Steps" forces you to define DP state carefully and prune an unbounded index down to a bounded one.
- "Maximum Number of Consecutive Values You Can Make" looks like a greedy trick but rewards proving why the invariant holds, which is exactly the kind of reasoning interviewers probe.
- "Find Critical and Pseudo-Critical Edges in Minimum Spanning Tree" is a genuine staff-level graph problem. If you can explain it cleanly, your graph and union-find fundamentals are solid.
Start your first mock interview in week 5, not week 10. The skill of narrating your thinking while coding is separate from the skill of solving, and it degrades fast under pressure. Do one mock a week minimum. After each, write down the two things that went worst (silent for too long, skipped the brute force, forgot edge cases) and make those your focus for the next week.
This is also when you lock your target companies. Interview processes vary more than people expect. For example, a typical Amazon SDE coding round in 2026 runs about 5 minutes of intros, 40 to 45 minutes on the technical problem, and 10 minutes of behavioral follow-up, with Leadership Principles threaded through every round and a Bar Raiser who can override a hire decision. The Amazon loop also front-loads an online assessment of two coding problems plus a behavioral survey. Knowing the shape of your target loop tells you how to split your remaining time. Our Amazon breakdown and the other company pages lay out the per-round formats.
Month 3: simulate the real loop
The final four weeks are about assembling the pieces under realistic conditions. By now the individual patterns should be automatic, so stop grinding new topics and start running full sequences.
Each weekend, do a back-to-back block: two coding problems in 90 minutes with no breaks, exactly like a real onsite. Mix difficulty the way a real loop does, pairing something like "Minimum Moves to Spread Stones Over Grid" (small search space, easy to overthink) with a heavier implementation problem like "Integer to English Words," which has no clever trick and simply tests whether you can write clean, bug-free code under time pressure. Candidates underrate pure implementation problems and then fumble them in the room.
Weekday sessions in month three shift to three things:
- Behavioral prep. Build a story bank of 8 to 10 situations and tag each to the themes your target companies care about. For Amazon specifically, map stories to Leadership Principles with measurable outcomes. Use the STAR structure so you do not ramble.
- Spaced review. Re-attempt your previously-missed problems cold. Active recall and spaced repetition reliably improve retention compared to passive review, which is the whole reason this plan spreads reps across weeks instead of bunching them.
- Weak-spot patching. Whatever your mocks keep flagging, DP recurrences, graph setup, off-by-one bugs, gets the targeted hour.
Reserve the last week for light review and rest. Walking into an onsite sleep-deprived from a 2 a.m. grind the night before costs you more than the extra problem could ever add.
The weekly cadence that survives a 9-to-5
The schedule only works if it is repeatable on a bad week. Here is the template we recommend holding for all 13 weeks:
- Mon/Tue/Thu: One 45 to 60 minute problem, single topic. Narrate out loud even when solo.
- Wed: Review only. Re-read two past problems and re-derive the key insight from memory.
- Fri: Off. Protect this so the plan does not become something you resent.
- Sat: The long block. Month 1: three problems. Month 2: two problems plus one mock. Month 3: a full timed loop.
- Sun: 30 minutes of spaced review and planning next week's topic.
Miss a day? Do not try to make it up by doubling the next session. Just continue. Consistency over 13 weeks beats intensity over three days, and the engineers who get offers are almost always the ones who kept showing up.
FAQ
Is three months enough if I am rusty?
Yes, for most mid-level and senior roles, assuming you protect 8 to 10 hours a week. If you have never done algorithmic interviews at all, add a two-week on-ramp of easy problems before week 1 so the foundations phase does not feel like a wall.
How many problems should I solve total?
Quality matters far more than count, but a realistic range over 13 weeks is 120 to 160 problems, with heavy re-attempts of the ones you missed. Solving 400 problems once is worse than solving 150 problems you can reliably reproduce.
When should I start mock interviews?
Week 5, not the final stretch. Narrating your thinking while coding is a distinct skill that only improves with observed reps. Starting early also surfaces weak spots while you still have two months to fix them.
How do I prep system design on this timeline if I am senior?
Carve one of your weekly sessions for it starting in month 2, and lean on a focused plan rather than ad hoc reading. Senior and staff loops weight design heavily, so treat it as a parallel track, not an afterthought.
What if my interview gets scheduled early?
Compress, do not panic. Keep the phase order but shorten each: two weeks of foundations, two of mocks, and go straight into simulation. Prioritize your target company's most common round formats over breadth.