Scrolls
6 min read
On this page

Building a Preparation Plan

Preparing for tech interviews without a plan is like training for a marathon by running random distances on random days. You will get some benefit, but you will plateau early, burn out, and miss the areas that matter most. A structured plan over 8-12 weeks, with deliberate focus on weak areas, will outperform 6 months of unfocused grinding every time.

The Timeline: 8-12 Weeks

Eight weeks is the minimum for a serious preparation push if you have a working programming foundation. Twelve weeks is better if you are rusty or switching domains. Beyond 12 weeks, you hit diminishing returns and risk burnout.

Weeks 1-2:   Assessment & foundations
Weeks 3-6:   Core skill building (data structures, algorithms, patterns)
Weeks 7-8:   System design & behavioral prep
Weeks 9-10:  Mock interviews & weak area drilling
Weeks 11-12: Final review, light practice, rest before interviews

If you have less time, compress — do not skip stages. Two days of system design prep is better than zero.

Week 1-2: Honest Self-Assessment

Before you solve a single problem, figure out where you stand. Spend the first few days doing diagnostic problems across categories:

Category                    Try 2-3 problems    Your level
─────────────────────────────────────────────────────────────
Arrays & strings            Easy + Medium        ___________
Hash maps                   Easy + Medium        ___________
Trees & graphs              Medium               ___________
Dynamic programming         Medium               ___________
Sorting & searching         Medium               ___________
System design               One mock question     ___________
Behavioral stories          List 5 situations     ___________

Rate yourself honestly for each: "comfortable," "shaky," or "lost." This assessment drives your entire study plan. Most engineers are strong in 2-3 areas and weak in the rest. The goal is to eliminate "lost" categories and turn "shaky" into "comfortable."

Daily Practice Structure

Consistency beats intensity. One to two hours per day, six days a week, is more effective than eight-hour weekend binges.

Weekday routine (1.5-2 hours):
  20 min: Review yesterday's problems. Re-solve any you got wrong.
  40 min: Solve 1-2 new problems in your focus area for the week.
  20 min: Study the pattern, not just the solution. Write notes.
  20 min: Read one system design concept or prepare one behavioral story.

Weekend routine (3-4 hours):
  60 min: Solve 2-3 problems, mixing categories.
  60 min: One full mock interview (timed, with talking out loud).
  60 min: System design deep dive on one topic.
  30 min: Review the week. Update your weak area list.

The "review yesterday" step is critical. Spaced repetition is how patterns stick. If you solve a problem on Monday and never revisit it, you will not remember the pattern when it appears in a different form during your interview.

The 100 Problems Approach

There is a widespread belief that you need to solve 300-500 LeetCode problems to be interview-ready. This is wrong. Deeply understanding 100 well-chosen problems across key patterns will prepare you better than superficially grinding 500.

Here is why: interviews do not test whether you have seen the exact problem before. They test whether you can recognize the underlying pattern and apply it. If you solve 50 two-pointer problems without understanding why the two-pointer technique works, you will fail when you see a novel problem that requires it.

The 100-problem breakdown:
  Arrays & strings:            15 problems (5 easy, 10 medium)
  Hash maps:                   10 problems (3 easy, 7 medium)
  Two pointers / sliding window: 10 problems (all medium)
  Trees:                       12 problems (4 easy, 8 medium)
  Graphs:                      10 problems (3 medium, 7 medium-hard)
  Dynamic programming:         15 problems (5 easy, 10 medium)
  Sorting & searching:          8 problems (3 easy, 5 medium)
  Stacks & queues:              8 problems (3 easy, 5 medium)
  Linked lists:                 6 problems (2 easy, 4 medium)
  Greedy & backtracking:        6 problems (2 easy, 4 medium)

For each problem, do not just solve it. After solving (or failing), study the optimal solution and write down:

- What pattern does this problem use?
- How do I recognize this pattern in the future?
- What are the key decisions in the solution?
- What is the time/space complexity and why?

Identifying & Attacking Weak Areas

Most candidates practice what they are already good at because it feels productive. This is the biggest trap. You need to spend the most time on your weakest areas.

Signals that an area is weak:

  • You cannot solve easy problems in that category within 15 minutes
  • You can solve problems with hints but cannot start without them
  • You understand solutions when reading them but cannot reproduce the approach
  • You avoid the category when picking practice problems

How to attack a weak area:

Day 1: Study the theory. Read about the data structure or technique.
        Do not solve problems yet.
Day 2: Solve 2 easy problems. Focus on getting the basic pattern right.
Day 3: Solve 1 easy, 1 medium. If stuck after 20 minutes, read hints.
Day 4: Solve 2 medium problems. Time yourself.
Day 5: Re-solve Day 2-3 problems from memory. If you can't, repeat.
Day 6: Solve 1 medium problem timed, talking out loud as if in an interview.
Day 7: Move to the next weak area. Come back to this one in a week.

System Design Preparation

System design cannot be crammed. It requires a different kind of knowledge — breadth across distributed systems concepts and the ability to reason about tradeoffs.

Core concepts to study (in order):
  1. Scalability basics: horizontal vs vertical scaling
  2. Load balancing: algorithms, health checks, sticky sessions
  3. Caching: cache-aside, write-through, cache invalidation
  4. Databases: SQL vs NoSQL, sharding, replication, consistency
  5. Message queues: async processing, pub/sub, event-driven arch
  6. API design: REST, rate limiting, pagination, versioning
  7. Storage: blob storage, CDNs, data partitioning
  8. Monitoring: metrics, logging, alerting, SLAs

For each concept, you should be able to explain when you would use it, what the tradeoffs are, and how it fits into a larger system. Then practice designing 5-8 complete systems end-to-end, talking through your decisions for 35 minutes each.

Behavioral Preparation

Engineers consistently underinvest here. Behavioral rounds are weighted equally to technical rounds at most companies. You need 8-12 prepared stories that you can adapt to different questions.

Story categories to prepare:
  - A project you led or drove
  - A technical disagreement and how you resolved it
  - A time you failed and what you learned
  - A time you dealt with ambiguity
  - A time you helped a teammate
  - A time you had to push back on requirements
  - A time you made a tradeoff under pressure
  - A project you are most proud of and why

For each story, use the STAR format (Situation, Task, Action, Result) and practice telling it in 2-3 minutes. The most common mistake is rambling for 8 minutes without a clear structure.

Mock Interviews

Mock interviews are the highest-leverage activity in your preparation. Solving problems alone does not simulate the actual experience of coding while explaining your thinking to another person under time pressure.

Start doing mock interviews by week 5. Aim for at least one per week, increasing to 2-3 per week in the final weeks.

Mock interview options (in order of quality):
  1. Practice with a friend who also interviews (free, mutual benefit)
  2. Paid mock interview platforms (Interviewing.io, Pramp)
  3. Record yourself solving a problem and watch it back (painful but free)
  4. Explain your solution to a rubber duck (better than nothing)

After each mock interview, get specific feedback:

  • Was my communication clear throughout?
  • Did I ask enough clarifying questions?
  • Did I consider edge cases?
  • Was my pacing appropriate?
  • How was my code quality?

The Diminishing Returns Problem

There is a point — usually around 100-150 problems — where additional grinding yields minimal improvement. If you have deeply understood the core patterns, solving problem #151 teaches you almost nothing new.

Problems solved    Marginal value of next problem
───────────────────────────────────────────────────
  0 - 30           Very high (learning core patterns)
 30 - 80           High (reinforcing & extending patterns)
 80 - 120          Moderate (filling gaps, building speed)
120 - 200          Low (diminishing returns setting in)
200+               Minimal (better spent on other areas)

Once you hit diminishing returns on algorithms, redirect that time to:

  • System design (most candidates need more prep here)
  • Behavioral stories (most candidates need way more prep here)
  • Mock interviews (the closest simulation to the real thing)
  • Company-specific preparation (understanding their products, values, and culture)

Week-by-Week Plan

Week 1:  Diagnostic assessment. Study plan creation.
         Easy problems across all categories. Theory review.

Week 2:  Arrays, strings, hash maps. 10-12 problems.
         Start reading system design fundamentals.

Week 3:  Trees and graphs. 10-12 problems.
         Continue system design reading.

Week 4:  Dynamic programming. 8-10 problems.
         Start preparing behavioral stories.

Week 5:  Sorting, searching, stacks, queues. 8-10 problems.
         First mock interview.

Week 6:  Mixed practice. Focus on weak areas identified in weeks 2-5.
         System design practice: design 2 systems.

Week 7:  System design deep dive. Design 3-4 systems.
         Behavioral story refinement. Mock interview.

Week 8:  Mixed algorithm practice. All medium difficulty, timed.
         System design practice. Mock interview.

Week 9:  Weak area drilling. 2 mock interviews.
         Company-specific research begins.

Week 10: Mock interviews (2-3). Timed problem sets.
         Refine behavioral stories.

Week 11: Light practice. 1 problem per day. 1 mock interview.
         Logistics: schedule interviews, plan travel, prepare questions.

Week 12: Rest. Light review only. Trust your preparation.
         Get good sleep. Exercise. Stay calm.

Tracking Progress

Keep a simple log. Nothing elaborate — a spreadsheet or text file works.

Date    | Problem           | Category  | Result      | Pattern   | Notes
────────┼───────────────────┼───────────┼─────────────┼───────────┼──────
04/01   | Two Sum           | Hash map  | Solved 8min | Complement| Easy
04/01   | 3Sum              | Two ptr   | Needed hint | Sort+scan | Review
04/02   | LCA Binary Tree   | Tree/DFS  | Solved 25min| Recursion | Medium

Review this log weekly. Patterns will emerge: "I consistently struggle with graph BFS problems" or "I am fast on arrays but slow on trees." This data drives your weak area focus.

Common Pitfalls

  • All LeetCode, no system design or behavioral: The most common preparation mistake. You need all three to pass an onsite.
  • Practicing easy problems too long: Easy problems are for warm-up and learning new patterns, not for building interview readiness. Move to mediums quickly.
  • Never doing mock interviews: Solving problems alone is fundamentally different from solving them while communicating under time pressure. You must practice the real format.
  • Ignoring the review step: Solving a problem and moving on wastes most of the learning. The review — understanding the pattern, writing notes, re-solving later — is where the real learning happens.
  • Burnout from overtraining: Two hours a day is sustainable. Six hours a day is not. Rest days matter. If you start dreading practice, take a day off.
  • Waiting until you feel "ready": You will never feel fully ready. Start scheduling interviews by week 8-9. Real interviews, even ones you are not fully prepared for, teach you more than any mock.

Key Takeaways

  • Eight to twelve weeks of structured daily practice (1.5-2 hours on weekdays, 3-4 hours on weekends) is the proven formula. Less time requires compression, not skipping.
  • Deeply understanding 100 problems across core patterns beats superficially grinding 500. The goal is pattern recognition, not problem memorization.
  • Spend the most time on your weakest areas, not your strongest. Self-assessment at the start and ongoing tracking make this possible.
  • Mock interviews are the single highest-leverage activity. Start them by week 5 and do at least one per week.
  • Algorithm grinding has sharply diminishing returns past 100-150 problems. Redirect that time to system design, behavioral prep, and mock interviews.