A Two-Week Technical Interview Preparation Plan, Day by Day

A good two-week technical interview preparation plan spends about ninety minutes on a weekday and three hours on each weekend day. It rotates between coding, system design, and spoken answers, and it ends with a full mock round rather than more reading. The schedule below is built for a loop with all three.

If you only have one type of round, keep that track and double it. The plan assumes you can already write code in one language and have shipped something real. It is a plan for rehearsing what you know, not for learning a field from scratch.

What the plan assumes

• About ninety minutes on weekdays and about three hours on Saturday and Sunday. That is roughly 30 hours in total.
• One main language for coding rounds. Pick it on day 1 and do not switch.
• A phone timer or a window you can see. Every block below is timed.
• A place to say things out loud. Silent practice does not train the part the interviewer scores.

Two things are deliberately missing. There is no list of 300 problems, and there is no day for reading about the company's culture. A short list practised properly beats a long list skimmed.

How the daily blocks work

Each weekday has the same three parts, so you never spend the first twenty minutes deciding what to do.

• Warm-up, 10 minutes. Re-solve yesterday's problem from a blank page, or re-say yesterday's answer.
• Main block, 60 minutes. The topic for the day, on a timer.
• Write-down, 20 minutes. Three lines: where you stalled, what you said badly, what you will change tomorrow.

The write-down is the part people skip, and it is where the two weeks add up. Without it you repeat the same stall on day 12 that you had on day 2.

Week 1: build the base

Day 1: Set up and take a baseline

Choose your language. Set up the editor you will use in the round, and check that you can run code in it without thinking. Then take one medium-difficulty coding problem cold, talking out loud, with a 35 minute limit. Do not look anything up. The result is your baseline, and it tells you which days below to lengthen.

Day 2: Arrays, strings, and hash maps

Solve three problems that reduce to counting, grouping, or looking things up. Before you write code each time, say the approach in two sentences and the time cost. If the two sentences take you more than a minute, that is the thing to practise, not the code.

Day 3: Two pointers, sliding window, and sorting

Two problems, each solved first the obvious way and then improved. Say why the first version is too slow before you improve it. Interviewers score the move from brute force to better more than the final code.

Day 4: Trees and graph traversal

Pick one problem each for depth-first search, breadth-first search, and a tree recursion. Write the base case first every time. Most recursion bugs under pressure are base-case bugs.

Day 5: Spoken answers, round one

Today is not coding. Write six stories from your own work: a conflict, a failure, a decision you owned, something you led, something you are proud of, and a time you disagreed with a manager. Then say two of them out loud on a fifteen minute clock. The loop in verbal interview practice fits this day exactly: one question, one opener, one follow-up, then stop. If your story shape sounds like a form being filled in, the STAR note covers how to avoid that.

Day 6 (weekend): A first timed coding session

Three hours. Two problems back to back, 40 minutes each, narrating throughout. Then an hour of review where you rewrite your weakest solution cleanly. Narration is a skill of its own, and this post on live coding mocks explains how to rehearse it.

Day 7 (weekend): Rest half, review half

Spend ninety minutes redoing the two problems you found hardest this week, from a blank page. Then stop. A rest day is not laziness. Retention after a break is better than after a long unbroken block, and you have a second week ahead.

Week 2: pressure and integration

Day 8: System design, the frame

Take one familiar problem and run the whole frame on a 45 minute clock: clarify requirements, sketch the high-level pieces, go deep on one or two components, then name the trade-offs. Do not try to draw everything. The timed system design mock post lays out the phase pacing, and the URL shortener walkthrough is a worked example you can compare against.

Day 9: Coding under a harder clock

Two medium problems in 50 minutes total. The goal is to practise the part where time is short and you must choose what to skip. Write the working solution first. Add edge cases after, and say that you are doing so.

Day 10: Your project walkthrough

Most technical loops include a round where you explain something you built. Pick one project. Prepare a five minute opener that covers what it did, what you owned, and one decision with a real trade-off. Then ask a friend, or yourself, the follow-ups: why that choice, what broke, what you would change. The project walkthrough guide covers the probes in detail.

Day 11: System design, second pass

Take a different problem from day 8, and this time start the deep dive earlier. At the end, list the two places you would revisit with more time. Naming your own weak points is a sign of judgement, and it is something interviewers write down.

Day 12: Spoken answers, round two

Say four of your six stories again, including the two from day 5. Time each one. Aim for about ninety seconds before the follow-up. Then do the common openers: tell me about yourself and a failure story, such as the one in this note on the time you failed.

Day 13 (weekend): A full mock loop

Run the loop you actually expect, in order, with breaks as short as the real ones. A typical order is a spoken round, a coding round, and a design round. Do not pause the clock. When something goes wrong, keep going, because recovering mid-round is exactly what you are rehearsing. If the freeze shows up, why you freeze is worth reading the night before.

Day 14 (weekend): Light review and logistics

One hour only. Re-read your write-downs from the fourteen days and pick the three patterns that repeat. Check the practical things: the link, the time zone, your camera and microphone, your charger, a glass of water. Then stop preparing. Tired candidates do worse than slightly underprepared ones.

How to choose problems without a giant list

Pick problems by pattern, not by fame. For each day in week 1, choose one easy problem you should finish in ten minutes, one medium, and one stretch. Do the easy one as a speed check, the medium as the real block, and attempt the stretch only if time remains. If you fail the medium, do not move on. Read the solution once, close it, and rewrite it from memory the next morning as the warm-up.

Keep a short log with three columns: the problem, the pattern, and whether you needed a hint. After ten days you will see which patterns keep needing hints. Those get the extra time in week 2, and nothing else in the log matters.

How to score a mock round honestly

After every timed block, give yourself a yes or no on five questions. Did I state the approach before coding? Did I say the time cost? Did I test with a small example before declaring done? Did I stay calm when stuck, meaning I said what I was trying rather than going silent? Did I finish inside the time? Five yeses is a good round. Two or fewer tells you what to repeat tomorrow.

Be strict about the first question. Candidates who jump straight to code lose points even when the code works, because the interviewer never heard the reasoning. The fix is mechanical: say the approach first, every time, even in practice, until it is a habit.

What to do on the day before the interview

Do one light block only: re-say your opener for tell me about yourself, re-read your six story headlines, and solve one easy problem to confirm your editor setup works. Sleep matters more than another medium problem. If the round is remote, test the video link and your audio at the same hour as the interview, so you know the room light and the noise level then.

Where URHIRED.AI fits in the plan

The plan works with a phone timer and a notebook. If you want the practice to happen on the same tool you will open on the day, URHIRED.AI is a desktop app for macOS and Windows with four surfaces: Verbal, Live coding, System design, and Project. Practice and the live session run in the same app, and you speak or type every answer yourself.

• Days 5 and 12 map to the Verbal surface.
• Days 1, 6, and 9 map to the Live coding surface.
• Days 8, 11, and 13 map to the System design surface.
• Day 10 maps to the Project surface.

The free plan gives you 15 session minutes a day with no credit card, across all four surfaces. That is enough for the warm-up and a short main block, not a full 60 minute block. Mock interviews, where the app asks the questions, require Pro or higher. See pricing for the current plans, and how mock and live differ before you decide what you need.

If you have less than two weeks

Keep the order and cut the repeats. With one week, run days 1, 2, 4, 5, 8, 10, and 13 and skip the rest. With three days, do the baseline, one system design frame, and one spoken round, then spend the last day on logistics. What you should never cut is the timed, spoken practice. Silent reading feels productive and transfers worst.

Common mistakes in a two-week plan

• Switching languages halfway. Pick one on day 1.
• Only practising what you are already good at. The baseline on day 1 exists to stop this.
• Skipping the write-down. It is 20 minutes and it carries the other 70.
• Studying on the final night. Day 14 is light on purpose.
• Practising silently. Say the approach out loud even when you are alone.

Where to go next

Start with day 1 today. If you want a free place to run the spoken and coding blocks, download the desktop app and use the 15 daily minutes, or read how the free practice plan works first. The how to set up guide covers the first launch, and the FAQ answers the usual questions about plans and platforms.