gitGood.dev
Back to Blog

How to Prepare for a Technical Interview in 2 Weeks

P
Patrick Wilson
10 min read

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 manipulationTwo pointers, sliding window
String problemsHash maps for character counting
Tree problemsBFS vs DFS, recursion patterns
Dynamic programmingStart with memoization, not tabulation
Graph problemsBFS/DFS on adjacency lists
Time complexityBig 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:

  1. Read the problem. Set a 5-minute timer to think about the approach before writing any code.
  2. If you have an approach, implement it. Time yourself - aim for 20-25 minutes per medium problem.
  3. If you're stuck after 5 minutes of thinking, look at the approach (not the code). Then implement it yourself.
  4. After solving, look at the optimal solution. Understand why it's better.
  5. Move on. Don't spend 2 hours on one problem.

Daily structure:

TimeActivity
2 problemsWarm-up: easy problems (under 10 min each)
3-4 problemsCore: medium problems (20-25 min each)
1 problemStretch: hard problem (30 min, then review solution)
20 minReview: revisit problems you struggled with

The patterns that cover 80% of interview questions:

  1. Two pointers / Sliding window - Array and string problems with O(n) solutions
  2. Hash map - Counting, finding pairs, detecting duplicates
  3. BFS/DFS - Tree traversals, graph problems, connected components
  4. Binary search - Sorted arrays, search space problems
  5. Dynamic programming - Overlapping subproblems (start with 1D DP: climbing stairs, coin change)
  6. Stack - Parentheses matching, monotonic stack problems
  7. 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:

  1. Clarify requirements (5 min) - Ask about scale, users, features
  2. High-level design (10 min) - Draw major components
  3. Deep dive (20 min) - Detail specific components
  4. 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:

  1. A hard technical problem you solved
  2. A disagreement with a teammate and how you resolved it
  3. A project you led or drove
  4. A mistake you made and what you learned
  5. A time you helped someone else succeed
  6. A time you dealt with ambiguity or changing requirements
  7. A time you worked under pressure
  8. 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:

DayFocusHours
1Research + diagnostic3
2Fundamentals review3
3Coding: two pointers/sliding window3-4
4Coding: hash maps/binary search3-4
5Coding: trees/graphs3-4
6Coding: dynamic programming3-4
7Coding: mixed timed practice3-4
8System design: learn framework3
9System design: practice designs3
10Behavioral: build stories2-3
11Behavioral: practice out loud2-3
12Full mock interview2-3
13Targeted review3-4
14Light warmup + rest1-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.