Practice under pressure — mock interviews, not solo grinding
Focus on communication — explain your approach before coding
Goal: solve 30-40% of hards in 40 min
The Plans
⚠️ Who This Is For
You have an interview in 7 days and need to cram. This covers the highest-ROI topics — the patterns that appear in 80% of interviews. You won't be an expert, but you'll be dangerous. Budget 3-4 hours per day.
Pattern focus: Identify the recurrence — "what decision am I making at each step?" → define dp[i] as the answer considering the first i elements. Start with recursion + memo, then convert to bottom-up if you have time.
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: ~40 problems solved, ~24 hours of work. You'll cover 80% of what interviewers ask. The remaining 20% (advanced graphs, segment trees, tries) rarely shows up at standard FAANG rounds for mid-level positions.
💡 Who This Is For
You have a month to prepare and want solid coverage of all major topics. 1.5-2 hours per day, ~90 problems total. By the end, you'll handle most mediums confidently and some hards.
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: ~90 problems, ~50 hours. Covers every major pattern. You should be able to recognize patterns within 2-3 minutes of reading a problem and have a working approach for most mediums.
💡 Who This Is For
You're preparing well in advance and want mastery, not just competence. 1 hour per day minimum, ~150 problems total. By the end, you'll handle hards consistently and understand why algorithms work, not just how to apply them.
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.
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 the 2-3 minute "approach explanation" before coding — this is what separates a hire from a no-hire
💡 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
Almost everyone makes these. Awareness alone puts you ahead of 70% of candidates.
❌ Grinding random problems without learning patterns
Solving 500 random problems teaches you 500 specific solutions. Solving 100 problems organized by pattern teaches you to solve thousands. Pattern recognition is the whole game.
✅ Organize by pattern. Do 4-5 problems per pattern, not 50 random ones.
❌ Looking at the solution after 5 minutes
Struggling is where learning happens. If you look at the answer after 5 minutes, you've just read a solution — you haven't practiced solving. You'll forget it by tomorrow.
✅ Spend at least 20 minutes before looking at hints. 30 for hards. Your brain needs friction to form memories.
❌ 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. If you can solve it clean both times, it's learned.
❌ Only practicing easy problems
Easies build confidence but not skill. Most interviews are 1-2 medium problems. If you can't solve mediums in 25 minutes, you're not ready — no matter how many easies you've crushed.
✅ 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.
✅ Timer on for every practice session. No exceptions. Train like you fight.
❌ 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. The talker gets the offer.
✅ 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" within 2 minutes.
The Problem-Solving Framework (Use In Every Interview)
Clarify. Restate the problem. Ask about edge cases, constraints, input types.
Examples. Work through the given example by hand. Create your own edge case.
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."
Optimize. Apply pattern recognition. "The sorted input suggests two pointers for O(n)."
Walk through. Explain your optimized approach step by step before coding.
Code. Write clean, readable code with good variable names.
Test. Trace through your code with examples. Check edge cases.
Analyze. State time and space complexity. Mention potential further optimizations.