How to prepare for a coding interview in one week

The recruiter email lands, the date is next Thursday, and you have not opened LeetCode in months. Or ever. You are far from the only one. These are real posts from people in exactly that spot:

“How to prepare in 1 week”

Reddit, r/leetcode

“Never Done Leetcode, Interview is in 4 days”

Reddit, r/leetcode

A week is not enough to learn data structures from zero. It is enough to learn the handful of patterns that cover most interview problems, practise saying your thinking out loud, and walk in with a plan for the moment you get stuck. That is what this page gives you, day by day.

How cooked am I with only a week?

“Google interview in 4 days, barely leetcode, how cooked am I?”

Reddit, r/leetcode

Less than you think, if you spend the week on the right things. Here is what decides it. Someone who already knows what a hash map and a queue are, and has written code for a living or for a degree, can get interview ready on the common patterns in seven focused days. Someone who cannot yet explain what a binary tree is will struggle, and should say yes to the interview anyway and treat it as practice, or ask to move the date.

The bigger trap is spending the week the wrong way. People grind random problems, watch six hours of video, or start a 150 problem list and get through 30 of them in order, which means they never reach graphs. The plan below goes wide first. Every pattern gets touched by day six, so no whole category is a surprise on the day.

Budget honestly. A working person can usually find two to three hours on weekdays and more at the weekend. The plan assumes about three hours a day. If you have more, add problems inside the same patterns rather than adding new topics.

What are coding interviewers really grading?

Not just whether the code works. The Tech Interview Handbook, which collects how large tech companies grade, lists four things: communication, problem solving, technical competency and testing. Two of those four have nothing to do with typing. A candidate who reaches a correct answer in silence can score lower than one who reaches a slightly rougher answer while explaining every choice.

Microsoft says the same thing in its own hiring tips: ask clarifying questions, come up with a plan before you implement, and write clean, concise, bug free code, all inside what it calls a short 45 minute round. Amazon’s preparation page says its interviewers are not checking whether you memorised every detail but whether you can apply what you know to solve problems, and it suggests practising outside an IDE, because autocomplete will not be there to save you.

So the week has two jobs. Learn the patterns, and practise the performance: speaking, testing by hand and stating complexity without being asked. If you only do the first, you risk becoming the person in the CoderPad question further down.

Which LeetCode patterns should you learn first?

A large share of interview problems are one of about eight patterns wearing a costume. Learning to spot the costume is the whole game. This is the short version of what to look for:

• Hashing. “Have I seen this before?” or “count how many times”. A hash map turns a second loop into a lookup.
• Two pointers. A sorted array, or a string you check from both ends. One pointer at each end, move the one that makes things better.
• Sliding window. “Longest” or “shortest” contiguous substring or subarray with some rule. Grow the right edge, shrink the left when the rule breaks.
• Binary search. A sorted input, or an answer you can test with yes or no (“can we finish in k days?”). Halve the range each step.
• BFS and DFS. Trees, grids, networks of friends or courses. BFS when the question says “shortest” or “level”, DFS when you need to explore everything.
• Heaps. “Top k”, “kth largest”, or always needing the smallest item next.
• Intervals. Meetings, bookings, ranges. Sort by start time first, then walk through once.
• Basic dynamic programming. “How many ways” or “the minimum cost to reach the end”, where each answer builds on smaller ones.

Stacks and linked lists come up too, but they are small enough to fold into the days below. If you can name the pattern within the first two minutes of hearing a problem, you are most of the way to an approach.

What does a 7-day coding interview plan look like?

One rule runs through every day. Give each problem 25 minutes. If you are stuck at 25, read a solution, close it, and write it again yourself from a blank editor. Then put it on a list to redo two days later without help. Reading answers is fine at this stage; it is the fastest way to learn a pattern. Redoing them is what makes it stick. Do the problems in a plain editor or on paper for at least half the time, out loud.

Day 1: hashing and two pointers

Start easy so you build momentum: Two Sum, Contains Duplicate, Valid Anagram, then Group Anagrams. Move to two pointers with Valid Palindrome, Container With Most Water and 3Sum. 3Sum is the first “real” one; it combines sorting with two pointers and has a duplicate trap that catches a lot of people. Our worked Two Sum walkthrough shows the follow-ups you should expect even on an easy problem.

Day 2: sliding window and binary search

Best Time to Buy and Sell Stock, then Longest Substring Without Repeating Characters, then Longest Repeating Character Replacement. For binary search: plain Binary Search, Search in Rotated Sorted Array, and Koko Eating Bananas, which teaches you to binary search on the answer rather than the array. Read Minimum Window Substring if you have time left, but do not lose an evening to it.

Day 3: stacks, linked lists and trees with DFS

Valid Parentheses and Reverse Linked List first, because they are short and come up often. Then trees: Maximum Depth of Binary Tree, Invert Binary Tree, Validate Binary Search Tree and Lowest Common Ancestor of a Binary Search Tree. By the end of the day you should be able to write a recursive tree function without thinking about the shape of it.

Day 4: BFS and DFS on graphs and grids

Binary Tree Level Order Traversal and Binary Tree Right Side View to learn BFS on something familiar. Then Number of Islands, Rotting Oranges, Clone Graph and Course Schedule. Course Schedule is the one that makes graphs click for many people, since it is really asking “is there a cycle?”. Redo the day 1 and day 2 problems you got stuck on.

Day 5: heaps and intervals

Kth Largest Element in an Array, Top K Frequent Elements and K Closest Points to Origin for heaps. Merge Intervals, Insert Interval and Meeting Rooms II for intervals; the last one uses a heap too, which is why these two sit together. Redo the day 3 list.

Day 6: basic dynamic programming, and your weakest pattern

Climbing Stairs, House Robber, Coin Change and Word Break. Do not try to master DP; aim to recognise it and write the simple bottom up version. Spend the second half of the day on whichever pattern scared you most this week. A second pass at your weak spot is worth more than a first pass at something new.

Day 7: two mock interviews and a light review

Ask a friend, a colleague or a peer from a mock interview site to give you two problems you have not seen, 45 minutes each, while watching you on a video call. They should interrupt and ask “why?”. Then stop. Skim your redo list, read your notes, and do not start anything new after dinner.

If you have four days instead of seven, merge them: days 1 and 2 together, then 3 and 4, then 5 with one DP problem, then the mock day. You lose depth but keep every pattern on the map.

Which problems should you skip?

With a week, what you leave out matters as much as what you do. Skip these unless the recruiter has told you otherwise:

• Hard problems. One hard can eat an evening and teach a trick you will not see again.
• Advanced structures. Segment trees, Fenwick trees and advanced string algorithms rarely show up in a general software engineering loop.
• Clever bit tricks and maths puzzles. They feel impressive and transfer to nothing.
• Heavy backtracking. Do one, such as Subsets, so you know the shape. Skip N Queens and Sudoku Solver.
• Long video courses. Watching someone else solve problems feels productive and builds very little. Use video only to unblock a problem you already tried.
• Contests. Speed runs against strangers train a different skill from explaining one problem calmly to one person.

One exception: if the job description names a domain, such as “graph heavy routing” or “string processing”, add two extra problems there. Job descriptions are often more honest about the interview than people expect.

How do you talk while you code?

This is the skill people skip, and interviewers notice it fast. A simple order works for almost every problem:

1. Restate it. “So I get an array of numbers and a target, and I return the indices of two numbers that add up to it. Right?”
2. Ask two or three questions. Can the input be empty? Are there negative numbers or duplicates? How big can it get? The answers often tell you the intended solution.
3. Do one small example by hand. Out loud, with real numbers. This is where you usually spot the pattern.
4. Give the simple version first. “The brute force checks every pair, which is O(n squared). I think a hash map gets this to O(n).” Naming the slow version shows you know why the fast one is better.
5. Ask before you type. “Does that approach sound OK, or would you like me to go another way?” Interviewers sometimes steer you here, and that steer is free.
6. Narrate intent, not syntax. Say “now I store each number’s index as I go”, not “open bracket, i equals zero”.
7. Test by tracing. Walk your example through the code line by line, then try an edge case. Find your own bug before they do.
8. State time and space complexity before they ask.

When you are stuck, say what you are thinking rather than going quiet: “I’m wondering if sorting first helps, but that loses the original indices.” That sentence gives the interviewer something to work with. Silence gives them nothing, and many will offer a hint once they can see where you are. Taking a hint is fine. Needing five is the problem.

Practise this out loud every day of the plan, even alone. It feels silly for about two days. By day seven it will feel normal, and that is the point.

Why do you solve it 20 minutes after the interview ends?

“Why is it that every time I fail a coding interview via Coderpad, I solve it within 20 minutes after the interview is over?”

Quora

Because being watched is a different task from solving. Researchers at North Carolina State University and Microsoft tested this in 2020 with 48 computer science students. Half solved a problem on a whiteboard with an interviewer present, half solved it alone in a private room. The watched group performed about half as well on the same task, and their measured stress was higher. It was a small study, but anyone who has blanked in an interview and then solved the problem on the bus home will recognise it.

You cannot remove the stress in a week. You can get used to it. That is why day 7 is mock interviews with a real person watching. Two other habits help. First, time yourself on every problem, so a clock ticking feels ordinary. Second, decide in advance what you will do when your mind empties: go back to the small example and work it by hand. It gives your hands something to do while your head catches up. For more on that moment, see our guide on what to do when your mind goes blank.

How do you prepare for system design in a week?

“I suck at System design interviews”

Reddit, r/ExperiencedDevs

If your loop has a design round, take 90 minutes on the evenings of days 4, 5 and 6 for it. For a mid-level role, nobody expects you to have run a global system. They expect you to drive a sensible conversation from a vague prompt to a reasonable design and explain what each choice costs. Most people who “suck at system design” know enough pieces. What they lack is a structure, so they wander.

A structure for 45 minutes

The widely used System Design Primer on GitHub breaks it into four steps. Rough timings are mine.

1. Use cases and constraints (5 to 10 minutes). Who uses it, how many users, how many reads per write, what must never be lost. Write the answers down where they can see them.
2. High level design (10 minutes). Boxes and arrows: client, load balancer, service, database, maybe a cache. Define the main API calls and the core tables before anything clever.
3. Core components (15 minutes). Go deep on the one or two parts that make this problem hard. For a URL shortener that is generating short keys and serving redirects fast.
4. Scale it (10 minutes). Find the bottleneck and fix it: caching, read replicas, sharding, a queue for slow work. Say what each fix costs you.

The pieces you need to know

Load balancers, caching and cache invalidation, SQL versus NoSQL and when each fits, replication, sharding, message queues, CDNs and rate limiting. You need one or two sentences on each: what it does and when you would not use it. One estimation habit pays off too. A day has 86,400 seconds, so a million requests a day is only about 12 a second on average. Saying that out loud early shows you size things before you build them.

Four designs to practise

Pick three, one per evening, out loud with a timer, starting with the one closest to the company’s product: a URL shortener, a notification system, a news feed and a file storage and sync service. Between them they cover reads, writes, fan out and syncing, which is most of what mid-level prompts test. Our system design interview page goes further into how these rounds run live.

What changes for Google, Amazon, Meta and Microsoft?

The patterns are the same everywhere. The wrapping differs, and it is worth an hour of your week to know which wrapping you are walking into. Each company below has a page of worked questions on this site.

Amazon

Amazon’s own page lists the technical topics (data structures, algorithms, object oriented design, databases, distributed computing, operating systems and more) and says most technical interviews include coding and system design whiteboard exercises. Many candidates first take an online assessment on HackerRank, and Amazon offers a sample challenge so you can get used to it. Behavioural answers are judged against its Leadership Principles, so prepare stories alongside problems. See the Amazon interview questions.

Google

Google has long described four things it looks for: general cognitive ability, role related knowledge, leadership and “Googleyness”. In coding rounds the first one means it cares how you reason through a problem you have not seen. Candidates often report writing code in a shared document with no way to run it, so practise in a plain editor and trace by hand. Sundar Pichai has also said Google wants some interview rounds back in person, so check the format with your recruiter. See the Google interview questions.

Meta

Since October 2025 Meta has been replacing one of its two onsite coding rounds with an AI-enabled round: about 60 minutes in CoderPad with an AI assistant built into the page. The assistant can see the project files but only answers in a chat panel, so you still write every line. Meta said the format is “more representative of the developer environment” its engineers work in. The interviewer reads your prompts, so they are judging how you use the tool. The other round stays classic, and candidates report two problems in 45 minutes, which makes speed on mediums matter. See the Meta interview questions.

Microsoft

Beyond the clarify and plan advice above, Microsoft’s tips add two specific rules: do not write pseudocode, and code only in a language you are strong in. With 45 minutes, they also tell you to manage your time, so watch the clock and leave room to test. See the Microsoft interview questions.

For Indian service companies and startups the mix is often different: more weight on core subjects such as OOP, DBMS and operating systems, and sometimes a machine coding round where you build a small working app in two hours. Ask your recruiter what the rounds are called, then search for that exact name.

What should you do the day before and the day of?

The day before

• No new problems. Redo five you have already solved, quickly, to go in feeling fluent rather than shaky.
• Prepare the non-coding parts. Many coding interviews open with “tell me about yourself” or a project you worked on, and many close with your questions. Our guides on tell me about yourself and questions to ask the interviewer cover both.
• Test the setup on the actual platform if you have the link: camera, microphone, screen sharing, the editor. Know your editor’s language setting.
• Sleep. It does more for recall than one more problem at midnight.

The day of

• An hour before, solve one easy problem you know well, out loud. It warms up the speaking part as much as the coding part.
• Keep a sheet of paper next to you with your checklist: restate, clarify, example, brute force, approach, code, trace, complexity. When your head goes empty, read the next word.
• Join five minutes early with water nearby and notifications off.
• If a round goes badly, let it go before the next one. Rounds are usually scored one by one, so a weak one does not have to sink the whole loop.

If your interview is literally tomorrow, our interview tomorrow guide is a shorter version of this for the last 24 hours.

How can PiriPiri AI help in a coding round?

PiriPiri AI is a desktop app for macOS and Windows that listens to both sides of a live call and puts short prompts on a small overlay on your screen. In a coding round it helps in three specific ways.

• Analyze screen (Cmd+Shift+Space, Ctrl on Windows). It reads the coding question off your screen, including the examples and constraints pasted into the editor, and outlines an approach: the pattern, the data structure, the edge cases worth asking about and the complexity. That is the same order as the talking checklist above, so it gives you the next thing to say.
• It hears the follow-ups. When the interviewer asks “what if the input is sorted?” or “can you do it without extra space?”, the question appears in the live transcript and a short answer is drafted while they are still speaking.
• Deep dive (Cmd+Shift+6). Re-asks for a fuller explanation of the answer on screen. This is most useful during the week: run a practice problem on a call with a friend and use it to understand why an approach works.

The overlay is excluded from screen capture by the operating system, so it does not appear when you share your screen or record. After the call, the transcript and notes are saved to your account, so you can see exactly which follow-up tripped you up.

PiriPiri AI cannot understand the code for you, and in a coding round that is the whole test. You will be asked why a line is there, what happens on an empty input, and how you would change it. If you cannot answer, no prompt will hide that. Pasting a full solution is easy to spot: a finished block that appears all at once looks nothing like real typing, and some platforms keep a replay of every edit (see the first question below). Use it the way you would use a note card, glanced at when you are stuck, then put in your own words. Some employers have rules about AI help in interviews, and some rounds (like Meta’s AI-enabled one) supply their own assistant. Check the rules first and follow them. Our coding interview page covers the live round in more detail, and this guide covers what interviewers notice.

Questions people ask

Where to go next

For the wider technical round, including how to explain past projects, see technical interviews. If this is your first job hunt, the fresher guide covers placements and HR rounds.

PiriPiri AI costs about $2.50 an interview, in one-time packs that never expire, no subscription required. New accounts get 3 free sessions, so you can try it on a practice problem first.