On This Page

What to Focus On At Each Level

Not everyone starts from the same place. Figure out where you are, then focus your energy where it matters most.

๐ŸŸข Beginner โ€” "I know what an array is, sort of"
  • Implement basic data structures from scratch
  • Get comfortable with recursion (really comfortable)
  • Build confidence with a varied selection of easy problems before moving on
  • Focus on arrays, strings, hash maps, and linked lists
  • Goal: solve representative easy problems and explain their complexity
๐ŸŸก Intermediate โ€” "I can solve easies but mediums wreck me"
  • Learn the 20 patterns โ€” study 3-4 problems per pattern
  • Focus on trees, graphs, BFS/DFS, and sliding window
  • Start DP (1D first, then 2D)
  • Time yourself: 25 min per medium
  • Goal: solve unfamiliar medium problems independently, then review errors
๐Ÿ”ด Advanced โ€” "I can do mediums, but hards feel random"
  • Hards are usually 2+ patterns combined
  • Master segment trees, monotonic structures, advanced DP
  • Practice under pressure โ€” mock interviews, not solo grinding
  • Focus on communication โ€” explain your approach before coding
  • Goal: explain and implement combinations of patterns on harder problems

The Plans

โš ๏ธ Who This Is For A short review for an interview in a week. This reviews foundational structures and common problem-solving patterns. It is a starting point, not a guarantee of interview coverage. Budget roughly 3โ€“4 hours per day and allow more time for unfamiliar topics.
Day 1 โ€” Foundations

Arrays, Strings, Hash Maps 6 problems

๐Ÿ”ฅ Warm-Up (15 min): Duplicate Scanner, Letter Shuffle
โฑ ~3 hours
Day 2 โ€” Two Pointers & Sliding Window

The O(n) Power Moves 6 problems

๐Ÿ”ฅ Warm-Up (15 min): Valid Palindrome, Stock Trader
โฑ ~3.5 hours
Day 3 โ€” Binary Search & Sorting

Divide and Conquer 5 problems

๐Ÿ”ฅ Warm-Up (15 min): Target Hunt
โฑ ~3 hours
Day 4 โ€” Trees & Graph Traversal

Recursion and BFS/DFS 7 problems

๐Ÿ”ฅ Warm-Up (15 min): Invert Binary Tree, Maximum Depth of Binary Tree
โฑ ~4 hours
Day 5 โ€” Dynamic Programming

The Boss Battle 6 problems

๐Ÿ”ฅ Warm-Up (15 min): Climbing Stairs, House Robber
โฑ ~4 hours
Day 6 โ€” Stacks, Heaps, Linked Lists

Supporting Cast 7 problems

๐Ÿ”ฅ Warm-Up (15 min): Bracket Validator, Reverse Linked List
โฑ ~3.5 hours
Day 7 โ€” Mock Interview & Review

Simulate the Real Thing 3-4 problems (timed)

  • Morning: Review Interview Patterns, Big-O Cheat Sheet
  • Afternoon: 3 timed problems (25 min each) โ€” pick random topics. No peeking at hints.
  • Practice talking: Explain your approach out loud before writing code. Interviewers care about your thought process as much as the code.
  • Review weak spots: Which pattern gave you the most trouble this week? Do 2 more from that category.
โฑ ~3 hours
๐Ÿ’ก Sprint Total: About 40 suggested problem attempts and 24 hours of planned work, including review. Requirements vary by role; extend the plan with graphs, tries, and range-query structures when they are relevant.
๐Ÿ’ก Who This Is For A broader foundation over a month, with roughly 1.5โ€“2 hours per day and 90 suggested problem attempts. Add review time when a topic is unfamiliar; completing the schedule is not the same as mastering it.
Week 1 โ€” Data Structure Foundations ~25 problems
Days 1-2

Arrays, Strings, Hash Maps

๐Ÿ”ฅ Warm-Up: Duplicate Scanner, Letter Shuffle
Week 2 โ€” Core Algorithms ~25 problems
Days 10-11

BFS & DFS on Graphs

Week 3 โ€” Advanced Techniques ~22 problems
Week 4 โ€” Advanced DS & Polish ~18 problems + mocks
Days 25-28

Mock Interviews & Weak Spot Drilling

  • Daily routine: 1 morning mock interview (2 problems, 50 min total) + afternoon weak-spot drilling
  • Mock format: pick 1 medium + 1 medium/hard at random. Timer on. Explain out loud.
  • Review Interview Patterns โ€” for each mock problem, identify which pattern it uses
  • 8 problems from weak areas (whichever topics tripped you up most)
  • Final day: read through every problem you solved this month. Can you describe the approach in one sentence each?
๐Ÿ’ก Month Total: About 90 suggested problem attempts and 50 hours of planned work. Revisit any topic you cannot explain or implement independently, then add role-specific practice.
๐Ÿ’ก Who This Is For A longer course with at least an hour per day and about 150 suggested problem attempts. Use the extra time to implement structures, compare approaches, prove invariants, and revisit difficult problems.
Month 1 โ€” Build the Foundation ~50 problems

Weeks 1-2: Every Data Structure, Implemented From Scratch

๐Ÿ”ฅ Before You Start: Implement in your language of choice: dynamic array, singly linked list, doubly linked list, stack (array-based), queue (linked-list-based), hash map (with chaining and resizing), BST with insert/search/delete, min-heap with push/pop, trie with insert/search/startsWith. This takes time, but you'll never forget how these work.
  • Read every guide in the Data Structures section
  • 20 easy/medium problems spanning all basic data structures
  • For each problem: solve it, think of an alternative approach, analyze both complexities

Weeks 3-4: Core Algorithm Patterns

  • Two pointers, sliding window, binary search, BFS, DFS, sorting, backtracking
  • 30 problems โ€” at least 4 per pattern
  • For each problem: solve it, then find a better solution, then explain both approaches out loud
  • End-of-month test: 5 random medium problems, 25 min each, no hints. Target: solve 3 of 5.
Month 2 โ€” Advanced Techniques ~50 problems

Weeks 5-6: Dynamic Programming Deep Dive

  • Week 5: 1D DP โ†’ subsequence DP โ†’ knapsack variants (0/1, unbounded, bounded)
  • Week 6: 2D DP โ†’ interval DP โ†’ bitmask DP (for n โ‰ค 20)
  • 25 problems, escalating difficulty โ€” start with easies, end with hards
  • Focus on identifying the state โ€” what information do you need to make the next decision? That's your dp[] dimensions.
  • For every DP problem: write the recurrence FIRST, then code

Weeks 7-8: Graph Algorithms & Greedy

  • Dijkstra, Bellman-Ford, topological sort, MST (Kruskal + Prim), Union-Find with rank + path compression
  • Greedy: exchange argument proofs, activity selection, Huffman intuition
  • 25 problems โ€” mix of graph + greedy
  • Implement Dijkstra and Kruskal's from memory (then check correctness and explain the invariants)
  • End-of-month test: 5 random medium/hard problems, 35 min each. Target: solve 3 of 5.
Month 3 โ€” Mastery & Competition ~50 problems + mocks

Weeks 9-10: Advanced Data Structures & String Algorithms

  • Segment trees (range query + point update), Fenwick tree (BIT), monotonic deque
  • String matching: KMP, Rabin-Karp, Z-algorithm
  • 20 hard problems โ€” these show up in L5+/Staff interviews at FAANG
  • Read: Segment Trees, String Matching, Network Flow

Weeks 11-12: Mock Interviews & Full Simulation

  • 3-4 mock interviews per week โ€” use Pramp, Interviewing.io, or a friend
  • Time yourself strictly: 20 min for mediums, 35 min for hards. If you can't solve it in time, stop and study the solution.
  • After each mock: write down what pattern it was, what you missed, and what you'd do differently
  • 30 problems from contest archives (LeetCode weekly contests) โ€” trains speed under pressure
  • Practice a short approach explanation before coding, including assumptions and tradeoffs
๐Ÿ’ก Quarter Total: ~150 problems, ~100 hours. You'll have deep pattern recognition, can implement any standard algorithm from memory, and can explain your thinking clearly under pressure. This is the level that gets offers from top companies.

Mock Interview Format

Practicing problems solo is necessary but not sufficient. Real interviews have pressure, time limits, and another person watching. Here's how to simulate that.

Standard 45-Minute Technical Interview

  • 0:00 โ€“ 2:00
    Read the problem. Ask clarifying questions. "Can the input be empty? Are values always positive? Is it sorted?" โ€” even if you think you know, asking shows maturity.
  • 2:00 โ€“ 5:00
    Talk through your approach. "I'm thinking this is a sliding window problem because we need a contiguous subarray. I'll maintain a window and shrink when the constraint breaks." Don't start coding yet.
  • 5:00 โ€“ 7:00
    Discuss complexity. "This approach is O(n) time, O(k) space for the hash map." Interviewer may push for optimization here.
  • 7:00 โ€“ 30:00
    Code the solution. Talk as you go. Name your variables clearly. Handle edge cases inline ("I'll check for empty input here"). Don't go silent for more than 30 seconds.
  • 30:00 โ€“ 38:00
    Test with examples. Walk through your code with the given example step-by-step. Then test an edge case (empty input, single element, all same values).
  • 38:00 โ€“ 45:00
    Discussion. Interviewer may ask: "Can you optimize this? What if the input doesn't fit in memory? What's the worst case?" Have answers ready.

How to Practice Solo

  • Set a timer. 25 minutes for mediums, 40 for hards. When it dings, stop โ€” even if you're close. This trains you to work under pressure.
  • Talk out loud. Sounds silly alone, but it builds the habit. In the real interview, going silent for 5 minutes kills your chances.
  • Write on paper or a plain editor. No autocomplete, no syntax highlighting for at least some practice sessions. Interview whiteboards don't have IntelliSense.
  • Grade yourself honestly. If you looked at a hint, that's a fail โ€” mark it for re-attempt in 3 days.
  • Review optimally. After solving, always check if a cleaner solution exists. Study it. Can you write it from memory tomorrow?
๐ŸŽฏ The #1 Mock Interview Tip When stuck, don't go silent. Say: "I'm considering two approaches โ€” [X] and [Y]. Let me think about the tradeoffs." Then actually think. Interviewers want to see your reasoning, even when it's messy. Silence makes them nervous.

Common Mistakes in Interview Prep

Use these checks to keep practice focused and identify what needs another attempt.

โŒ Grinding random problems without learning patterns

Group problems by pattern, but include unfamiliar variants so you practice choosing an approach rather than recalling a solution.

โœ… Organize by pattern. Do 4-5 problems per pattern, not 50 random ones.

โŒ Looking at the solution after 5 minutes

Give yourself time to state a baseline solution and explore alternatives before reading a hint. If you are stuck, use the smallest useful hint, then solve it again independently.

โœ… Try a focused 20-minute attempt, then adjust the limit to the problem and your experience.

โŒ Never revisiting problems you got wrong

You solved it with help on Monday. By Friday, can you solve it again from scratch? Probably not, unless you revisited it. Spaced repetition matters.

โœ… Re-attempt failed problems 3 days later, then 7 days later. Keep revisiting any approach you cannot yet explain or reconstruct.

โŒ Only practicing easy problems

Easy problems develop fundamentals. Add medium problems and occasional harder combinations once those fundamentals are reliable; actual interview formats vary.

โœ… Spend 60% of your time on mediums, 20% on easies (warm-up), 20% on hards (stretch).

โŒ Not practicing under time pressure

You can solve a medium in 45 minutes at home with Stack Overflow open? Great, but the interview gives you 25 minutes with someone watching. The pressure changes everything.

โœ… Include timed mock sessions alongside slower learning and review sessions.

โŒ Ignoring communication skills

Two candidates solve the same problem. One silently codes for 20 minutes. The other explains their thought process, discusses tradeoffs, and walks through test cases. Same code, different outcomes. Clear explanations make your reasoning and tradeoffs easier to assess.

โœ… Practice explaining your approach out loud, even when alone. It's a skill that atrophies without practice.

โŒ Starting to code before having a plan

You read the problem, immediately start typing, realize your approach doesn't work at line 30, and now you've wasted 15 minutes. This happens in real interviews and it's devastating.

โœ… Spend 3-5 minutes thinking BEFORE writing any code. Write pseudocode or a bullet-point plan. Confirm the approach with the interviewer. Then code.

โŒ Skipping complexity analysis

You solved the problem! But when they ask "what's the time complexity?" you mumble "uh, O(n)... I think?" This signals you don't understand what you wrote.

โœ… Analyze time AND space complexity for every problem you solve. Make it automatic. Check the Big-O cheat sheet until it's second nature.

๐ŸŽฏ The Meta-Strategy Don't just solve problems โ€” categorize them. After solving a problem, ask: "What pattern is this? What similar problems exist?" The goal is building pattern recognition, not memorizing solutions. When you see a new problem in an interview, you should think "this looks like a sliding window variant" before committing to an implementation.

The Problem-Solving Framework (Use In Every Interview)

  1. Clarify. Restate the problem. Ask about edge cases, constraints, input types.
  2. Examples. Work through the given example by hand. Create your own edge case.
  3. Brute force. State the obvious approach and its complexity. "I could check all pairs in O(nยฒ), but let me see if I can do better."
  4. Optimize. Apply pattern recognition. "The sorted input suggests two pointers for O(n)."
  5. Walk through. Explain your optimized approach step by step before coding.
  6. Code. Write clean, readable code with good variable names.
  7. Test. Trace through your code with examples. Check edge cases.
  8. Analyze. State time and space complexity. Mention potential further optimizations.