Most engineers do interview prep in short bursts.

One intense weekend. Three exhausted weekdays. Then nothing for ten days. Then panic-solving random hard problems the week before interviews.

The issue is not effort. It is system design.

A 90-day plan works because it is long enough to build pattern fluency, short enough to stay urgent, and structured enough to measure whether you are actually improving.

This post gives you a plan you can run as-is, then adapt to your constraints.

The objective for 90 days

By day 90, you want four outcomes:

Reliable pattern recognition across common interview categories.
Clear communication process (clarify, plan, code, reflect).
Stable coding speed under time pressure.
A review loop that prevents forgetting.

If your plan does not explicitly target all four, it is incomplete.

The 90-day operating system

Break the prep into three phases:

Days 1-30: Foundation
- Build core patterns and syntax fluency.
- Prioritize correctness over speed.
Days 31-60: Integration
- Mix patterns in unpredictable sets.
- Add timed constraints and communication drills.
Days 61-90: Interview simulation
- Run full mocks, refine weak spots, and stabilize confidence.

This progression prevents a common failure mode: doing hard mixed sets before fundamentals are automatic.

Weekly structure that actually works

A repeatable week beats a "motivation-based" week.

Recommended baseline (adjust volume, keep structure):

4 focused problem-solving days
1 review and rewrite day
1 mock interview day
1 recovery/light reading day

On focused days, solve 2-3 problems around one pattern cluster instead of random topics. Randomness feels realistic, but early on it often slows learning.

On review day, revisit mistakes and rewrite at least one prior solution from scratch without notes. That rewrite is where retention happens.

12-week blueprint

Weeks	Focus	Output target	Quality bar
1-2	Arrays, hashmaps, two pointers	12-16 problems	80% correct with clear explanation
3-4	Sliding window, prefix sums, binary search	12-16 problems	Can identify pattern in <3 minutes
5-6	Trees, recursion/iteration conversions	10-14 problems	Can discuss time/space without prompting
7-8	Graph basics, heaps, intervals, greedy	10-14 problems	Fewer than 2 major logic bugs per week
9-10	Dynamic programming fundamentals	8-12 problems	Explain state and transition clearly
11	Mixed medium sets under time	6-8 timed sets	Consistent pacing and clean communication
12	Full mock loops and targeted patching	3-4 full mocks	Interview-ready process, not just answers

Do not obsess over exact counts. Obsess over consistency and quality bar.

Daily session template (75-120 minutes)

Use this checklist so sessions do not drift:

Warm-up (10 min): one easy problem or quick pattern recall.
Main solve block (45-70 min): 1-2 medium problems, full explanation out loud.
Reflect block (15-20 min): write what failed, what pattern cue you missed, and one fix.
Spaced revisit (10-20 min): redo one old problem without looking.

Skipping the reflect block is the most common reason people plateau. Solving alone is not feedback.

Metrics to track each week

Track small, decision-useful metrics:

Pattern recognition time: how long until you choose an approach.
First-pass correctness: did your initial implementation pass core cases.
Bug category: off-by-one, wrong data structure, missed edge case, complexity mismatch.
Communication quality: did you explain tradeoffs and complexity clearly.

If recognition time is high, do more clustered practice. If correctness is low, slow down and add dry-runs before coding. If communication is weak, do more mock narration, not more random problem volume.

How to handle bad weeks

You will miss sessions. Assume this now.

Do not "catch up" by cramming six problems in one day. That creates shallow reps and fatigue.

Instead:

Resume the next scheduled session.
Reduce volume by 20% for one week.
Keep review and mock day intact.

The system survives inconsistency when structure remains intact.

Mock interviews: start earlier than you think

Many candidates wait until the final month for mocks. Start light mocks by week 3-4.

Why early:

You expose communication gaps before habits harden.
You normalize pressure instead of treating it as a final-stage shock.
You collect realistic feedback loops while there is time to improve.

A simple mock rubric:

Clarification quality
Plan quality
Coding correctness
Debugging calmness
Reflection depth

Score each 1-5 after every mock. Improvement trend matters more than any single score.

Personalization rules

The blueprint is a base layer. Adjust using these rules:

Less than 6 hours/week available: cut problem count, keep daily template and weekly mock.
Strong at coding, weak at communication: add 10 minutes of verbal planning per session.
Strong at mediums, weak at DP: shift one weekly day from random sets to DP state-design drills.
Interview in under 45 days: compress phases, but keep review and mock loops non-negotiable.

The mistake is customizing too early from emotion. Run the base plan for two weeks, then adjust from data.

Final 10-day taper before interviews

In the final stretch, do not chase novelty.

Focus on:

high-frequency patterns
recently missed edge cases
communication rhythm

Avoid pulling in brand new advanced topics unless role-specific requirements demand it.

Your goal is stable execution, not maximum topic coverage.

Closing thought

A good prep plan is less like a sprint and more like a training cycle.

You are building decision speed, not just collecting solved problems. You are training how to think out loud under constraints. And you are creating enough review pressure that knowledge sticks when interviews get stressful.

Ninety days is enough to transform outcomes, but only if the process is deliberate.

Ship the system first. Results follow.

Practice next

Start with the Arrays & Strings practice set.
Track mistakes in /dashboard and plan the next block in /roadmap.
SophoCode picks: