The Complete Guide to Preparing for a Technical Interview in 2 Weeks

You have two weeks before your technical interview. Maybe you just got the recruiter email, maybe you have been procrastinating, or maybe you switched jobs unexpectedly and the timeline compressed. The reason does not matter. What matters is that two weeks is enough time to prepare well, if you are ruthless about prioritization.

This is not a guide for people with three months. Three months lets you be thorough. Two weeks forces you to be strategic. Every hour you spend on the wrong topic is an hour you cannot get back. The plan below is designed for software engineers preparing for a full interview loop at a tech company, typically consisting of coding rounds, a system design round, and a behavioral round. If your loop is different, you will adapt accordingly, and I will show you how.

The Day-by-Day Plan

Before diving into the schedule, one critical step: triage your interview loop. The single biggest mistake candidates make with limited time is following a generic study plan. Your interview at a 50-person startup is not the same as your interview at Google. Spend 30 minutes doing reconnaissance before you open a single textbook. Ask the recruiter what your loop looks like. If they will not tell you, search Glassdoor, Blind, or Levels.fyi for recent interview experiences at that company. Find out how many coding rounds, whether there is a system design round, what format the behavioral round takes, and whether there are any domain-specific rounds. Then allocate your time proportionally. If your loop has three coding rounds, one system design, and one behavioral, spend roughly 50% of your time on coding, 25% on system design, and 25% on behavioral. If there is no system design round, skip it entirely and reallocate those hours. I have seen candidates spend an entire week studying system design for a company that does not even ask it at their level. Do not be that person.

Here is the full two-week schedule. The sections that follow break down what to do in each phase and why.

Total commitment: roughly 40 to 50 hours across two weeks. If you cannot do 3 to 4 hours a day, compress the coding section first since it scales most linearly with time. Do not skip the mock day or the rest day. Both are non-negotiable.

Days 1-3: Assess, Plan, and Build Foundations

The first three days feel slow. You are not solving hard problems or studying flashy topics. You are building the map that makes the next 11 days efficient. Resist the urge to skip this phase.

Day 1: Diagnostic. Take a timed coding assessment. Pick 3-4 problems spanning easy to medium difficulty across different categories: arrays, strings, trees, and graphs. Give yourself 30 minutes per problem, the same constraint you will face in a real interview. Be honest about the results. Did you solve them cleanly, or did you struggle with the approach? Did you handle edge cases? Could you explain your time and space complexity?

The diagnostic tells you where you stand. If you solved all four cleanly, you can compress the coding section and spend more time on system design or behavioral. If you struggled with trees and graphs, you know exactly where to focus.

Day 2: Plan and gather resources. Based on your diagnostic, adjust the schedule above. If coding is your strength, steal a day from coding and give it to your weakest area. Set up your coding environment the way it will be in the interview. If the company uses CoderPad, practice in CoderPad. If they use a shared Google Doc, practice typing code without syntax highlighting or autocomplete. The less friction on interview day, the more cognitive bandwidth you have for actual problem-solving.

Day 3: Foundations review. If you have been away from data structures for a while, spend this day refreshing the basics. You do not need to relearn everything from scratch, but you do need instant recall on: how hash maps handle collisions, when to use a stack versus a queue, how to traverse a binary tree iteratively, and what the time complexity of common operations is for each data structure. Solve 3-4 easy problems to warm up. These should feel like stretching before a run, not the run itself.

Days 4-7: Coding Patterns That Actually Appear

Four days is not enough to cover every possible coding question. It is enough to cover the patterns that account for roughly 80% of what companies actually ask. Focus here, and you dramatically increase your hit rate.

The coding interview patterns guide covers these in depth, but here is the priority order for a two-week timeline:

High-frequency patterns (must know):

• Two-pointer and sliding window. These appear in nearly every coding interview. They are also the easiest to learn if you do not already know them. Spend Day 4 here. You should be able to recognize when a problem calls for a two-pointer approach within the first minute of reading it.
• BFS and DFS. Graph and tree traversal underpin a huge number of interview problems. Matrix traversal (treat the grid as a graph), shortest path, connected components, tree diameter. Spend Day 5 here. Practice both recursive and iterative implementations.
• Dynamic programming. DP terrifies people, but the reality is that most interview DP problems fall into a small number of sub-patterns: 1D DP (climbing stairs, house robber), 2D DP (grid paths, longest common subsequence), and interval DP. Spend Day 6 on 1D DP only. If you have time, touch 2D DP on Day 7. Do not try to master DP in two days. Instead, learn to recognize when a problem has overlapping subproblems and optimal substructure, define the state and recurrence, and build up from the base case.

Medium-frequency patterns (know the basics):

• Binary search. Not just on sorted arrays. Binary search on answer space is a common pattern that many candidates miss.
• Greedy. Interval scheduling, activity selection, and similar problems where a locally optimal choice leads to a globally optimal solution.
• Backtracking. Permutations, combinations, and constraint satisfaction. Know the template.

Spend Day 7 covering these and reviewing anything from Days 4-6 that did not stick.

How to practice effectively:

• Time every problem. 25 minutes for medium, 15 for easy. If you cannot solve it in time, read the solution, understand it, then solve it again from scratch the next day without looking.
• After solving a problem, explain your approach out loud as if you were in an interview. This is critical. Many candidates can solve problems silently but fall apart when they have to narrate their thinking in real time.
• Do not just chase volume. Solving 5 problems deeply (understanding the pattern, being able to apply it to variations) is worth more than solving 15 problems superficially.

The goal of coding prep is not to have seen every possible question. It is to have internalized enough patterns that when you encounter a new problem, you can map it to a known approach within the first two minutes.

Days 8-10: System Design Fundamentals

Three days is not enough to become a system design expert. It is enough to avoid the most common failure modes and demonstrate structured thinking. If your interview loop does not include system design, skip this section entirely and use these days for more coding practice or mock interviews.

Start with the system design introduction to understand what interviewers actually evaluate and how the scoring rubric works. Then focus on these areas in order of priority:

Day 8: Learn the framework. Every system design answer should follow the same structure: clarify requirements (5-8 minutes), estimate scale (2-3 minutes), design the high-level architecture (10-15 minutes), deep dive into 1-2 components (15-20 minutes), and discuss scaling and trade-offs (5-10 minutes). Practice this framework on a simple problem like a URL shortener. The framework is your skeleton. Everything else is muscle you build on top of it.

Day 9: Work through classic problems. Pick two of the following: URL shortener, chat system, news feed, notification system, or rate limiter. For each one, work through the full design yourself before looking at any reference solution. Set a 45-minute timer, just like the real interview. Draw diagrams. Talk out loud. Then compare your design to a reference and note where you diverged.

Day 10: Trade-offs and building blocks. Spend this day on the components that come up in every design: SQL versus NoSQL (when to use each and why), caching strategies (write-through, write-behind, cache-aside), load balancing approaches, and message queues. You do not need to know the internals of every technology. You need to know which tool fits which problem and be able to articulate why. Practice 1-2 more problems with a focus on defending your choices when challenged.

Three days of focused system design prep, combined with whatever real-world experience you have, is usually enough to produce a passing performance at the L4-L5 level. For L6 and above, you need deeper preparation, and two weeks may not be sufficient for system design alone.

Days 11-12: Behavioral Prep That People Skip

Behavioral interviews are the round that most engineers under-prepare for and the round with the most predictable questions. This is a gift. You can prepare for behavioral interviews almost entirely in advance because the questions are variations of the same 8-10 themes: conflict resolution, failure, leadership, working under ambiguity, disagreement with a manager, tight deadlines, mentoring, and cross-team collaboration.

Day 11: Write your stories. You need 6-8 STAR stories from your experience. Each story should map to at least two of the themes above so you can reuse stories across different questions. For each story, write out:

• Situation: The context. Keep it to 2-3 sentences. Interviewers do not need the full backstory of your company's org chart.
• Task: What was your specific responsibility? Not the team's goal. Yours.
• Action: What did you actually do? Be specific. "I collaborated with the team" is useless. "I set up a weekly sync with the data engineering team, created a shared dashboard to track the pipeline failures, and wrote the migration script myself when we were behind schedule" is concrete.
• Result: Quantify it. "Reduced pipeline failures by 73%" or "Shipped the feature two weeks ahead of schedule, which became the second-highest revenue driver that quarter." This is the section most candidates skip. Do not skip it.

The STAR method mastery guide covers this framework in detail with examples of strong and weak answers side by side.

Day 12: Practice out loud. Reading your stories silently is not enough. You need to practice telling them out loud, under time pressure. Each answer should be 90 seconds to 2 minutes. If it takes longer, cut details from the Situation section first. The most common failure mode in behavioral interviews is rambling, spending 3 minutes on context and 15 seconds on the result. Practice with a timer until you can deliver each story cleanly within 2 minutes.

Pay attention to filler words while you practice. "Um," "like," "you know," and "so basically" undermine the confidence of otherwise strong stories. Record yourself and listen back. It is uncomfortable. It is also the fastest way to improve.

Days 13-14: Mock Day and Rest

Day 13 is the most important day of the entire plan. This is where you simulate the real interview under realistic conditions. Do not skip this day or replace it with more studying. Studying builds knowledge. Mocking builds performance under pressure. They are different skills.

Run a complete mock loop:

• One coding round (45 minutes, 2 problems, timed)
• One system design round (45 minutes, one problem you have not practiced)
• One behavioral round (30 minutes, 4-5 questions)

The ideal setup is to do these with a real person, a friend who is also interviewing, a colleague, or a paid mock interviewer. If that is not available, Hoppers offers AI mock interviews across all three formats that simulate the interview experience with real-time follow-up questions and post-session analytics. The analytics are particularly useful on mock day because they give you a concrete picture of what to review tomorrow: your filler word count, whether you completed the STAR framework in behavioral answers, and whether you addressed all phases of a system design problem.

After the mock, review your performance ruthlessly. What went well? What fell apart? For coding, did you manage your time or spend too long on one problem? For system design, did you start with requirements or jump straight to architecture? For behavioral, did your stories have quantified results?

Write down 3 things to review tomorrow. Not 10. Three. You do not have time for more.

Day 14: Rest. This is not a suggestion. It is essential. Your brain consolidates learning during rest. Cramming the night before an interview produces anxiety, not competence. If you have followed this plan for 13 days, you have put in 40-plus hours of focused preparation. The material is in your head. Your job on Day 14 is to let it settle.

What to do:

• Spend 30 to 60 minutes reviewing your notes lightly. Re-read your STAR stories. Glance at the coding patterns you practiced. Do not solve new problems.
• Prepare logistics. Know the interviewer names. Test your video and audio setup. Have water, a pen, and paper ready.
• Exercise. Go for a walk, run, or do whatever helps you feel physically settled.
• Sleep. This is the most important preparation you will do today. Seven to eight hours minimum. A well-rested brain solves problems faster, communicates more clearly, and handles curveballs with composure.

The interview is tomorrow. You are as prepared as two weeks allows. Trust the process.

Practical Tips Across All Phases

A few principles apply regardless of which phase you are in:

Study in focused blocks, not marathons. Two 90-minute sessions with a break between them are more effective than four straight hours. Your brain needs time to encode what you have learned. If you find yourself re-reading the same paragraph or solving problems mechanically without understanding, stop and take a break.

Explain everything out loud. The interview is a spoken performance. If you can solve a problem silently but cannot explain your approach in real time, you will underperform. Practice narrating your thought process: "I notice this problem has overlapping subproblems, so I am going to try dynamic programming. My state will be the index, and at each step I can either take or skip the current element." This is the single highest-leverage habit you can build in two weeks.

Do not chase perfection. You will not cover everything. You will walk into the interview with gaps. That is fine. The goal is to maximize the probability that the questions you get fall within the areas you prepared. The 80-20 approach described above is designed for exactly this tradeoff.

Track your weak spots. Keep a simple list of topics where you struggled during practice. Review this list every evening and prioritize those areas in the next day's session. If you keep failing at graph problems, spend more time on graphs, even if it means cutting something else. Generic preparation is the enemy of limited-time preparation.

Simulate pressure. Always practice under time constraints. Always practice out loud. Always practice with unfamiliar problems rather than re-solving ones you have already seen. Comfort in practice does not transfer to comfort in the interview. Mild discomfort in practice does.

Two weeks is tight. It is also more than enough for a disciplined candidate who knows exactly what to study, practices under realistic conditions, and does not waste hours on topics that will not appear in their specific interview loop. Start with the triage. Follow the plan. Trust the rest day. You have got this.