You just got the email. Your technical interview is in two weeks. Maybe you've been too busy with work to study. Maybe you procrastinated. Maybe the recruiter moved fast.
Whatever the reason, you have 14 days. That's tight but it's enough - if you focus on what actually matters and cut everything that doesn't.
This isn't a comprehensive study guide. This is triage. We're optimizing for maximum interview readiness in minimum time.
The Reality Check
Two weeks is not enough to learn data structures from scratch. It's not enough to become a system design expert. But it IS enough to:
- Sharpen fundamentals you already know
- Develop a consistent problem-solving approach
- Prepare strong behavioral stories
- Build enough system design intuition to have a solid conversation
- Walk in feeling prepared instead of panicked
If you have genuine gaps (you've never seen a linked list, you've never written SQL), be honest with yourself about what's realistic and focus on your strengths.
The Plan: Day by Day
Days 1-2: Assessment and Foundation
Day 1 - Morning: Know your battlefield
Research the company's interview process. Look for:
- How many rounds? What types?
- What languages are allowed for coding?
- Is there a system design round? (Usually yes for mid-level and above)
- Company engineering blog posts - what tech do they use?
- Glassdoor and Blind for recent interview experiences
This research directly shapes where you spend your remaining 13 days.
Day 1 - Afternoon: Diagnostic coding session
Solve 3 problems - one easy, one medium, one hard. Time yourself. Be brutally honest:
- Can you solve easy problems in under 15 minutes?
- Can you identify the right approach for medium problems?
- Do you know when to use which data structure?
Where you struggle is where you study. Don't waste time on topics you're already strong in.
Day 2: Fill the gaps
Based on your diagnostic, review the fundamentals you're weakest on:
| If you struggle with... | Review... |
|---|---|
| Array manipulation | Two pointers, sliding window |
| String problems | Hash maps for character counting |
| Tree problems | BFS vs DFS, recursion patterns |
| Dynamic programming | Start with memoization, not tabulation |
| Graph problems | BFS/DFS on adjacency lists |
| Time complexity | Big O for common operations |
Don't try to learn everything. Pick your 2-3 weakest areas and get them to "functional."
Days 3-7: Coding Practice (The Core)
This is where most of your time goes. 3-4 hours per day of focused practice.
The approach that works:
- Read the problem. Set a 5-minute timer to think about the approach before writing any code.
- If you have an approach, implement it. Time yourself - aim for 20-25 minutes per medium problem.
- If you're stuck after 5 minutes of thinking, look at the approach (not the code). Then implement it yourself.
- After solving, look at the optimal solution. Understand why it's better.
- Move on. Don't spend 2 hours on one problem.
Daily structure:
| Time | Activity |
|---|---|
| 2 problems | Warm-up: easy problems (under 10 min each) |
| 3-4 problems | Core: medium problems (20-25 min each) |
| 1 problem | Stretch: hard problem (30 min, then review solution) |
| 20 min | Review: revisit problems you struggled with |
The patterns that cover 80% of interview questions:
- Two pointers / Sliding window - Array and string problems with O(n) solutions
- Hash map - Counting, finding pairs, detecting duplicates
- BFS/DFS - Tree traversals, graph problems, connected components
- Binary search - Sorted arrays, search space problems
- Dynamic programming - Overlapping subproblems (start with 1D DP: climbing stairs, coin change)
- Stack - Parentheses matching, monotonic stack problems
- Recursion/Backtracking - Permutations, combinations, sudoku
If you can recognize which pattern applies, you're 70% of the way to the solution.
Problem selection:
Don't pick random problems. Focus on:
- Top questions for your target company (searchable on LeetCode and other platforms)
- Problems that exercise the patterns above
- Problems similar to ones you've struggled with
Day 3: Two pointers + sliding window (5-6 problems)
Day 4: Hash maps + binary search (5-6 problems)
Day 5: Trees and BFS/DFS (5-6 problems)
Day 6: Dynamic programming basics (4-5 problems)
Day 7: Mixed practice - simulate a real interview (3-4 timed problems)
Days 8-9: System Design
If you're interviewing for a mid-level or senior role, you'll likely have a system design round.
Day 8 - Learn the framework:
System design interviews follow a pattern:
- Clarify requirements (5 min) - Ask about scale, users, features
- High-level design (10 min) - Draw major components
- Deep dive (20 min) - Detail specific components
- Discuss tradeoffs (10 min) - What are the weaknesses?
Know these building blocks:
- Load balancers (distribute traffic)
- Caches (Redis - fast reads, reduce DB load)
- Message queues (Kafka/SQS - async processing)
- Databases: SQL vs NoSQL and when to use each
- CDNs (serve static content globally)
Day 9 - Practice 2-3 common designs:
Pick from this list based on your target company:
- URL shortener (great starting point - covers core concepts)
- Chat application (WebSockets, message ordering)
- News feed / Twitter (fan-out, caching, feeds)
- Rate limiter (algorithms, distributed state)
For each one, practice talking through your design out loud for 35-40 minutes. The "talking through it" part is crucial - system design is as much communication as it is technical knowledge.
Days 10-11: Behavioral Preparation
Day 10 - Build your story bank:
Write down 6-8 stories from your work experience:
- A hard technical problem you solved
- A disagreement with a teammate and how you resolved it
- A project you led or drove
- A mistake you made and what you learned
- A time you helped someone else succeed
- A time you dealt with ambiguity or changing requirements
- A time you worked under pressure
- A project you're proud of
For each story, write the STAR bullet points:
- Situation: 1-2 sentences of context
- Task: Your specific role/responsibility
- Action: What YOU specifically did (use "I" not "we")
- Result: Quantifiable outcome + lesson learned
Day 11 - Practice out loud:
Set a timer for 2 minutes per story. Practice speaking your answers. Record yourself and listen back. You'll notice:
- Filler words ("um," "like," "you know")
- Stories that ramble past 2 minutes
- Missing specifics ("I improved things" vs "I reduced latency by 60%")
Fix these. Do another round. Behavioral practice out loud is 10x more effective than rehearsing in your head.
Days 12-13: Mock Interviews and Review
Day 12 - Full mock interview:
Simulate a real interview. Set a timer. Do the whole thing:
- 5 minutes: introductions and small talk
- 45 minutes: coding (2 problems, one easy + one medium)
- 30 minutes: system design (one question)
- 15 minutes: behavioral (3-4 questions)
- 10 minutes: your questions for the "interviewer"
If you have a friend who can play interviewer, great. If not, use an AI mock interview tool or just talk through problems out loud to yourself. The point is to simulate the pressure and time constraints.
Day 13 - Targeted review:
Based on your mock interview, identify your weakest area and spend today shoring it up:
- If coding was shaky: do 4-5 more medium problems
- If system design felt uncertain: practice one more design, focusing on tradeoff discussions
- If behavioral felt unpolished: do another round of story practice out loud
Also: prepare 3-5 thoughtful questions to ask the interviewer. Good questions show genuine interest:
- "What does the team's development cycle look like?"
- "What's the most challenging technical problem the team is working on?"
- "How do you balance tech debt with feature development?"
Day 14: Rest and Prep
Morning:
- Do 2-3 easy coding problems to stay warm. Nothing hard.
- Review your behavioral stories one more time.
- Prepare your interview logistics (links, environment, IDE setup).
Afternoon:
- Go for a walk. Exercise. Do something not related to coding.
- Get your clothes ready, check your tech setup, charge your devices.
Evening:
- Go to bed at a reasonable hour. Seriously.
- Sleep is worth more than one more LeetCode problem.
The Daily Schedule
Here's a realistic daily commitment. You need about 3-4 hours per day:
| Day | Focus | Hours |
|---|---|---|
| 1 | Research + diagnostic | 3 |
| 2 | Fundamentals review | 3 |
| 3 | Coding: two pointers/sliding window | 3-4 |
| 4 | Coding: hash maps/binary search | 3-4 |
| 5 | Coding: trees/graphs | 3-4 |
| 6 | Coding: dynamic programming | 3-4 |
| 7 | Coding: mixed timed practice | 3-4 |
| 8 | System design: learn framework | 3 |
| 9 | System design: practice designs | 3 |
| 10 | Behavioral: build stories | 2-3 |
| 11 | Behavioral: practice out loud | 2-3 |
| 12 | Full mock interview | 2-3 |
| 13 | Targeted review | 3-4 |
| 14 | Light warmup + rest | 1-2 |
Total: about 40-45 hours across 14 days.
What to Cut
When time is limited, knowing what NOT to study is as important as knowing what to study.
Skip these:
- Obscure data structures (tries, segment trees, Fenwick trees) unless specifically relevant
- Hard-level problems you can't solve in 30 minutes - the learning curve is too steep for two weeks
- Memorizing solutions - understand patterns instead
- Perfecting your setup (custom vim config, IDE themes) - use whatever you're comfortable with now
Deprioritize these:
- Bit manipulation (rarely tested, low ROI)
- Advanced graph algorithms (Dijkstra's, topological sort) unless you're aiming at Google-tier companies
- Concurrency and multithreading (usually not in coding rounds)
Focus on these:
- Problems you can almost solve but need a nudge - that's your growth edge
- Communication: explaining your approach before coding
- Edge cases: empty inputs, single elements, duplicates
- Time/space complexity analysis for your solutions
Interview Day Tips
Before the interview:
- Eat a real meal. Low blood sugar kills your problem-solving ability.
- Do one easy warm-up problem 30-60 minutes before. Like a runner stretching.
- Have water nearby. Use drinking water as a natural pause when you need to think.
During coding rounds:
- Clarify the problem before coding. Repeat it back. Ask about edge cases.
- Talk through your approach first. Get a thumbs-up before writing code.
- Start with a brute force solution if you don't see the optimal one immediately. A working O(n^2) beats an unfinished O(n).
- Test your code with an example. Walk through it line by line.
During system design:
- Ask questions for the first 5 minutes. Don't start drawing immediately.
- Start high-level, then go deep. Don't jump into database schema before drawing the architecture.
- Discuss tradeoffs unprompted. "The downside of this approach is..." shows senior-level thinking.
During behavioral:
- Pause for 3-5 seconds before answering. Collect your thoughts.
- Use the STAR structure. It's a crutch - use it.
- Keep answers under 2 minutes. The interviewer will ask follow-ups if they want more detail.
You're More Ready Than You Think
Two weeks of focused preparation is better than two months of unfocused studying. Most candidates waste time doing random LeetCode problems without a plan, never practice speaking their answers out loud, and walk into system design rounds cold.
You have a plan. Follow it. You'll walk into that interview confident.
Practice coding problems and mock interviews at gitGood.dev. Build the skills that actually get you hired.