How to Prepare for a Technical Interview in One Week

TL;DR

Day 1: Find out the interview format. Ask the recruiter directly. Everything else depends on this.
Days 2-3: Review the core algorithmic patterns, not random problems.
Day 4: Practice talking out loud on 3-5 problems. This is the step most candidates skip.
Day 5: Do two real mock interviews with a person watching.
Day 6: Review weak spots from mocks, not new material.
Day 7: Rest, review your notes, and prepare the questions you'll ask at the end.

You just got the email. The interview is in seven days. Your first instinct might be to open LeetCode and start grinding. That instinct is wrong, or at least incomplete.

One week is enough time to meaningfully improve your performance in a technical interview. But only if you spend that time on the right things in the right order. Random problem volume is not the right thing. What follows is a structure that works.

Before Anything Else: Understand What You're Walking Into

Technical interviews vary more than most candidates realize. Some companies do 45-minute live coding sessions on LeetCode-style problems. Some do take-home assignments. Some do pair programming sessions on a real codebase. Some do system design. Some do all of the above across multiple rounds.

Your preparation plan depends entirely on what you're actually facing.

On Day 1, before you do anything else, email or message the recruiter with a simple question: "Can you tell me more about the interview format? For example, will there be live coding, a take-home project, or something else?"

Most recruiters are glad to answer this. Some will give you a detailed breakdown of each round. Others will be vague. Whatever you get, it tells you how to allocate your week.

If it's live algorithmic coding: follow the plan below closely.

If it's a take-home: shift your Day 2-4 effort toward reading the problem carefully, planning before coding, and writing clean documented code rather than pattern review.

If it's system design: look at system design for junior engineers for a targeted approach.

The plan below assumes a standard live coding interview, since that's what most entry-level candidates face.

Day 1: Assess and Plan

Morning: Email the recruiter about the format. While you wait for a response, do a quick honest audit of where you stand. Go to LeetCode or a similar platform and attempt one easy and one medium problem cold, without preparation. Don't look anything up. Just code.

This is diagnostic. You want to know: Are you completely lost on mediums? Do you know the patterns but struggle to implement them? Do you implement fine but talk poorly? Your answer shapes what to prioritize.

Afternoon: Research the company's interview style. Check Glassdoor, Blind, or the company's engineering blog. Some companies consistently use specific patterns (sliding window, graphs, dynamic programming). If you can find that signal, you can narrow your focus. If you can't find anything specific, assume a mix of arrays, strings, and hash maps at easy-to-medium difficulty.

Evening: Set up your logistics. Make sure your coding environment works. Know what platform they'll use (CoderPad, HackerRank, a shared doc, their own tool). Practice typing a simple function in that environment if you can access it.

Days 2-3: Core Pattern Review

Do not try to memorize solutions. Do not try to cover everything. Focus on the five patterns that appear most frequently in entry-level coding screens:

1. Hash maps for lookup and frequency problems. If a problem involves finding duplicates, counting occurrences, or checking for membership in O(1), a hash map is almost always involved. Practice this until choosing a hash map is instinctive.

2. Two pointers. Used in sorted array problems, palindrome checks, and problems involving pairs or subarrays. The pattern: start with pointers at opposite ends (or both at the start), move them based on a condition, stop when they cross.

3. Sliding window. For problems involving subarrays or substrings with a constraint (max length, max sum, unique characters). The pattern: expand the window by moving the right pointer, contract it by moving the left pointer when the constraint is violated.

4. Binary search. Not just for sorted arrays. Also for problems where you're searching for a minimum or maximum value in a monotonic space. If the problem says "find the minimum X such that condition holds," binary search on the answer.

5. Basic tree and graph traversal. DFS and BFS on trees is common even in entry-level screens. Know how to traverse a binary tree recursively and how to do BFS with a queue. Graph DFS with a visited set is worth knowing but less common at junior level.

For each pattern, spend about two hours over the two days: review the pattern conceptually, work through two to three problems (one easy, one medium), and write out the template in your own words.

See algorithmic patterns for coding interviews for a deeper breakdown of each pattern with examples.

The goal here is not to solve every problem that uses these patterns. It's to recognize the pattern quickly when you see it, know the general approach, and be able to implement a working version. That takes repetition on a few problems, not breadth across many.

Day 4: Talk Out Loud

This is the step most candidates skip. It is also one of the highest-leverage things you can do.

Take three to five problems you've already solved or looked at before. Solve them again, but this time narrate everything you are doing.

Out loud. Actually say the words. Not in your head.

"Okay, the problem is asking me to find the two numbers in this array that add to the target. My first instinct is a brute force nested loop, which would be O(n^2). But I think I can use a hash map to get this down to O(n). The idea is: for each number, I check if the complement is already in the map. If it is, I've found the pair. If not, I add the current number to the map."

This feels awkward. Do it anyway. Talking while coding is a skill that degrades when you're nervous unless you've built the habit. One day of deliberate practice here dramatically changes your interview performance.

After each problem, review: Did you state the problem back before diving in? Did you mention edge cases? Did you explain why you made the choices you made? Did you say anything when you got stuck, or did you go silent?

Interviewers weight communication heavily. A candidate who talks through a suboptimal solution clearly and thoughtfully often scores better than someone who writes a perfect solution in silence. See what interviewers are actually looking for in a coding screen for why this matters so much.

Day 5: Mock Interviews

Do two mock interviews today. Real ones. With a person watching you.

Practicing alone on LeetCode is useful for building pattern recognition. It does not prepare you for the social and performance pressure of being observed. Those are different skills.

Options for finding mock interview partners:

Ask a friend who codes, even if they're less experienced. They don't need to evaluate your solution deeply. They just need to be watching.
Use a service like Pramp or Interviewing.io, which pair you with another candidate for a mutual mock.
Post in a Discord or Slack community (many have mock interview channels).

The structure for each mock: 30-45 minutes, one problem, they watch and don't help unless you ask, they give you feedback at the end. That's it.

After each mock, get specific feedback: Did you communicate clearly? Did you decompose the problem before coding? Did you handle being stuck well? Were there moments of uncomfortable silence?

Write down the specific things to work on. You'll use those notes on Day 6.

See live coding interview tips for what good real-time performance looks like from the interviewer's perspective.

Day 6: Targeted Weak Area Review

Look at the notes from your mock interviews. Pick the two or three most specific weaknesses and spend today on those. Not on new problems. Not on new patterns.

If you went silent when stuck: practice the "narrating the sticking point" technique. Deliberately put yourself in problems where you don't know the answer immediately and practice saying what you're observing and where you're confused.

If your code quality was poor: take two solved problems and rewrite the solutions with better variable names, cleaner structure, and explicit edge case handling. Read them back as if you're reviewing someone else's pull request.

If your time complexity explanations were weak: spend an hour reviewing Big O notation for the patterns you've studied. Practice saying it out loud: "This is O(n) time and O(n) space because the hash map grows linearly with input." You don't need to derive anything complex. You need to be able to state it clearly for the patterns you use.

If you struggled with a specific pattern: do two more problems in that pattern, focusing on recognizing it quickly and implementing the template.

Do not try to cram new material on Day 6. That leads to confusion and second-guessing during the actual interview. Consolidating what you know is more valuable than adding things you half-know.

Day 7: Rest and Prepare

Do not do hard coding problems today. Seriously.

The last-minute problem grind before an interview is the most common mistake candidates make. You will not solve enough new problems in one evening to move your baseline skill meaningfully. But you will accumulate fatigue and anxiety that will hurt your performance tomorrow.

What to do instead:

Morning: Review your notes from the week. Glance at the pattern templates you wrote. Read through two or three problems you solved cleanly earlier in the week, not to rethink them, just to remind yourself you can do this.

Afternoon: Prepare the questions you'll ask at the end of the interview. This sounds minor. It is not. "Do you have any questions for us?" is its own signal. Good questions show that you researched the company, thought about the role, and are genuinely interested. Prepare three to five questions. More detail on this in questions to ask at the end of an interview that actually matter.

Evening: Logistics. Confirm the interview time and timezone. Know the link or the location. Know what coding environment they'll use. Set your workspace up. Sleep at a reasonable hour.

What Not to Do

A few common mistakes that waste your week:

Don't try to learn new data structures you don't know. If you've never used a segment tree or a trie, week one is not the time. Trying to learn something new under pressure usually results in a shallow, fragile understanding. Work with what you already know and get more fluent with that.

Don't skip the talking-out-loud practice. It feels unnecessary until you're in an interview and go completely silent for two minutes. The habit of narrating only forms through deliberate practice.

Don't grind 50 new problems. Volume has diminishing returns after a point. Reviewing 10 problems deeply is more useful than skimming 50.

Don't ignore the non-technical parts. How you talk about yourself, how you handle small talk at the start, how you respond to questions about your background. These matter and you can prepare for them in 20 minutes.

Don't catastrophize a weak Day 5 mock. If the mock goes badly, that is useful information, not a signal you're going to fail. The purpose of mocking is to surface problems before they happen in the real thing. A rough mock on Day 5 is far better than discovering those problems in the actual interview.

How to Think About the Week Overall

Seven days is enough time to improve meaningfully. It is not enough time to go from zero algorithmic knowledge to strong. If you're finding that the patterns are entirely foreign in Days 2-3, the most honest thing to do is ask if you can delay the interview by a week or two. Many companies will accommodate this, and walking in better prepared is always better than walking in underprepared.

But for most candidates who have done any coding practice before, one focused week is real preparation. The structure matters more than the hours. Forty hours spread randomly across random problems is less useful than fifteen hours spread deliberately across the plan above.

How much LeetCode is actually enough goes deeper on how to think about problem volume over a longer preparation timeline.

The goal going into the interview is not perfection. It is fluency with the core patterns, the habit of communicating your thinking, and the ability to stay engaged and useful when things get hard. One week, done right, can build all three.

If you want structured support through the full technical interview process, here's how the Globally Scoped program works.