A Four-Week Interview Preparation Timeline

Why a timeline beats cramming

Most people prepare for interviews by doing a frantic burst of work the night before and hoping. A spread-out plan works far better, because the skills involved, coding under pressure, explaining a design, telling a clear story, all improve with spaced practice rather than a single long session. The effect is well documented in learning research as the spacing effect: distributing the same total study time across several sessions produces stronger recall than packing it into one block. Four weeks is enough time to build real readiness without your life grinding to a halt, and it is short enough to stay motivated throughout.

There is a second reason a timeline wins. Interview ability is not one skill but a stack of them, recall of fundamentals, problem decomposition, thinking aloud, time management, and composure, and each sits on top of the one below. You cannot meaningfully practise thinking aloud about a graph problem until you can solve the graph problem at all. Cramming collapses that stack into a single anxious evening; a timeline lets each layer settle before you load the next one on top.

This plan assumes you have roughly one to two hours on weekdays and a longer block at the weekend, alongside a job. Scale it to your situation. If you only have two weeks, compress weeks one and two together. If you have longer, stretch the practice phase. The structure matters more than the exact dates: foundations first, then stories, then heavy practice, then polish and logistics.

The engineers who interview well are rarely the ones who prepared the most in total. They are the ones who prepared the right things, in the right order, with enough practice under pressure that the real thing felt familiar.

How the four weeks fit together

Before the week-by-week detail, here is the shape of the whole plan and roughly where your hours should go.

The percentages are deliberately rough. The point is the drift: heavy on fundamentals early, heavy on rehearsal and research late, with behavioural work threaded through the middle rather than bolted on at the end.

Week one: foundations and a map

The first week is for orientation and the basics, not for grinding hard problems. Rushing into difficult practice before you have a map of what you are preparing for wastes effort on the wrong things. Plenty of people spend three weeks drilling dynamic programming for a role whose loop is mostly system design and product sense.

Spend this week on:

• Working out what kinds of interview you will face, coding, system design, behavioural, role-specific, and roughly in what proportion. Recruiters will often tell you the format if you ask, including round count, language expectations, and whether the coding round uses a shared editor or a whiteboard.
• Doing an honest self-assessment of where you are weak. Be specific. "Bad at system design" is less useful than "I freeze when asked to estimate scale."
• Refreshing the fundamentals that underpin everything else, the core data structures and algorithms for coding roles, the building blocks of distributed systems for design rounds.
• Setting up the practical side: a practice environment, a notebook for tracking progress, and a rough schedule for the next three weeks.

A useful exercise here is to score yourself out of five on each likely topic before you do any real practice. Arrays and hashing, four. Graphs, two. System design estimation, one. Behavioural storytelling, three. The numbers will be wrong, but they force a decision about where the limited hours go, and you can correct them as week three reveals the truth.

End the week with a plan that points your limited time at your actual gaps rather than at whatever you happen to enjoy practising. The pull towards comfortable practice is the single most common way people waste a preparation month.

Week two: build your stories and core skills

Week two has two threads running in parallel: deepening your technical practice and, crucially, preparing your behavioural material, which people consistently leave too late. Behavioural rounds are where strong engineers most often underperform, not because their experience is thin but because they have never said it out loud in a structured way.

On the behavioural side, build a small library of real stories from your experience. Aim for six to eight situations covering common themes: a hard technical problem, a conflict, a failure, a leadership moment, a time you influenced a decision. Write them in a clear structure so each has a situation, your actions, and a concrete result. You are not memorising scripts, you are making sure you have strong material ready so you are not inventing examples under pressure. A structured approach such as the STAR method is worth learning here; see the STAR framework for behavioural interviews.

What a weak story sounds like, and a strong one

The gap between a forgettable answer and a memorable one is rarely the underlying experience. It is structure, specificity, and ownership. Take a classic failure many data teams have lived through: a revenue dashboard silently dropping a few percent of orders because a nightly batch job times out. Here is that situation told two ways.

Weak: "Our nightly reports were often wrong, so the team looked into the data and eventually got it sorted. It was a good learning experience and the numbers were more reliable afterwards."

That answer is vague on the problem, invisible on your role, and unmeasured on the result. An interviewer cannot tell what you actually did.

Strong: "Our daily revenue dashboard was silently dropping about three percent of orders because a nightly batch job timed out before it finished, and finance was making decisions on numbers that were quietly low. I picked it up after a finance lead flagged a mismatch. I added row-count checks at each stage of the pipeline, found the job was loading the whole day in one transaction and hitting a lock timeout, and split it into hourly chunks with a checkpoint so a failure resumed instead of restarting. I shipped it behind a feature flag, reconciled a week of historical numbers, then cut over. The dashboard has matched the source ledger to the row every day since, and I added an alert so a future gap pages us instead of surfacing in a finance meeting."

The difference is not a more impressive project. It is the same project told with a clear problem, a first-person role, a specific action, and a measured result. That is what STAR is for.

Aim to capture each story in a compact form so you can rehearse it without rereading a wall of text:

Title: Revenue dashboard undercount
Situation: Daily dashboard silently ~3% low; finance deciding on bad numbers
Task: I owned the investigation after a finance lead flagged a mismatch
Action: Added per-stage row-count checks, found a batch lock timeout, split the load into resumable hourly chunks behind a flag, reconciled history
Result: Dashboard matches the ledger to the row daily since; added a paging alert
Themes: data correctness, ownership, cross-functional trust

On the technical side, move from refreshing fundamentals to applied practice:

• Work through problems in your weak areas deliberately, not just the ones you find easy.
• For system design, practise sketching a handful of common systems end to end and talking through the tradeoffs out loud.
• Start narrating your thinking as you solve problems, because explaining your reasoning is a separate skill from getting the answer.

By the end of week two you should have your story library drafted and a clear sense of which technical topics still need the most work.

Week three: heavy, realistic practice

Week three is the core of the plan and the most demanding. The goal is to practise under conditions as close to a real interview as you can manage, because performing a skill under pressure is different from knowing it calmly at your desk. The nervous system treats a silent room and a watching interviewer as two different environments, and only one of them is the one you will be assessed in.

Make the practice realistic:

• Do timed problems rather than open-ended ones, so you get used to the clock.
• Practise out loud, explaining every step as if an interviewer were listening, even when you are alone.
• Arrange at least one or two mock interviews with another person, a friend, a peer, or a more formal mock partner. A live mock surfaces weaknesses no solo practice will. The mock interview practice plan covers how to run these well.
• Rehearse your behavioural stories by speaking them, not just reading them, so they come out naturally and within a reasonable length.

A concrete worked example of how to run a single timed coding problem, the way you should in week three:

0:00  Read the prompt twice. Restate it in your own words.
0:02  Ask clarifying questions. Confirm input ranges and edge cases.
0:05  State a brute-force approach and its complexity, out loud.
0:08  Propose a better approach. Name the data structure and why.
0:12  Write the code, narrating each block as you go.
0:30  Walk a small example through the code by hand.
0:35  Call out edge cases: empty input, duplicates, overflow.
0:38  State final time and space complexity.

The detail that matters is the narration at every step, not just the code at minute twelve. Interviewers score the path, not only the destination, and a candidate who silently produces a correct answer often scores below one who reasons clearly towards a slightly worse one.

This is also the week to start company-specific research if you have interviews lined up. Read about the company, use the product, and begin drafting the questions you will ask. Tie your preparation to the actual roles rather than preparing in the abstract; mapping your practice to a concrete role, such as the topics in backend engineer interview questions, is far more efficient than generic grinding.

Expect this week to feel hard, and expect to find things you are worse at than you hoped. That is the point. Far better to discover a weak spot in a mock than in the real thing.

Week four: polish, taper, and logistics

The final week is for consolidation, not cramming new material. Trying to learn an entirely new topic days before an interview usually just raises your anxiety without raising your ability. The marginal value of one more unfamiliar algorithm is low; the marginal value of arriving rested and composed is high.

Focus this week on:

• Reviewing your notes and the patterns from your practice rather than starting fresh problems.
• Doing a lighter volume of practice to stay sharp while letting yourself arrive rested, much as you would taper before a physical event.
• A final pass over your behavioural stories and your list of questions to ask.
• Company-specific final prep: re-reading your research and mapping your experience to each role's main requirements.

Crucially, sort the logistics in this week so they are not a last-minute scramble. For an onsite, confirm the route, timing, and what to bring. For a remote interview, test your camera, audio, and the platform on the device you will actually use. Sleep and basic self-care matter more than one extra hour of practice the night before, so protect them.

A short pre-interview checklist worth running the day before each round:

• Platform tested on the actual device, camera and microphone confirmed.
• Quiet space booked, phone silenced, water within reach.
• Copies of your stories and questions open in a single tab or page.
• Recruiter email re-read for format, names, and timings.
• A two-line summary of why this company, ready for the inevitable question.

A realistic weekly shape

Week 1: Map the format, assess weaknesses, refresh fundamentals
Week 2: Build 6-8 behavioural stories, applied technical practice
Week 3: Timed practice, mock interviews, start company research
Week 4: Review and taper, finalise stories and questions, sort logistics

Reallocating the four weeks for your level and role

The four-week shape holds across the board, but where the hours land inside it should not. The same calendar can be a coding-heavy month for one candidate and a system-design-and-stories month for another. Use this to redraw the percentage table at the top of the guide before week one rather than treating it as fixed.

If you are junior, pour weeks one to three into coding fundamentals and clean problem-solving, and keep the system-design slice small. If you are senior or above, move those same hours toward system design and behavioural depth, because at that level the conversation is less "can you code" and more "can you make good calls at scale and bring people with you." A senior candidate who aces a sorting problem but cannot articulate a single hard tradeoff they navigated will struggle, and no amount of week-three coding drills fixes that.

Role redraws the table as much as level does. A frontend engineer should push week-two and week-three practice toward UI architecture, state management, and accessibility; a backend engineer toward data modelling, concurrency, and the topics in your role-specific interview questions; a candidate doing pure algorithm rounds should lean on the data structures and algorithms study plan inside week three rather than improvising. Rebuild the weekly split around the loop you actually face.

Common mistakes that quietly cost offers

Most failed preparation looks productive from the inside. These are the patterns that waste a month:

• Practising only the comfortable topics. The dopamine of solving easy problems is real, and it is the enemy of progress. Track which topics you avoid, then start there.
• Leaving behavioural prep to the final days. It is the most reliably underdone area and the easiest to fix early. A drafted story library by end of week two removes a whole category of last-minute panic.
• Silent practice. If you have never said your reasoning out loud, the first time you do it will be in front of the person scoring you. Narrate from week two.
• Solving without clarifying. Jumping straight into code on an ambiguous prompt is a frequent, avoidable failure. The first two minutes of questions are part of the assessment.
• No mocks. Solo practice cannot reveal how you handle a hint, a follow-up, or visible time pressure. At least one live mock in week three is non-negotiable.
• Cramming in week four. New material days out raises anxiety without raising ability. Taper instead.

Frequently asked questions

Is four weeks enough? For most engineers with a working baseline, yes. If you are returning after a long gap or changing specialism, treat this as the minimum and stretch week three. If you are already interviewing regularly, two weeks of the same structure often suffices.

How many problems should I solve? Volume is the wrong target. A smaller set solved deliberately, narrated out loud, with edge cases and complexity stated, beats a large number rushed. Quality of reflection after each problem matters more than the count.

What if I get an interview in one week, not four? Compress. Spend two days on a fast self-assessment and your three weakest topics, two days on stories and one mock, and the final days on company research and logistics. Drop breadth, keep the order.

Should I prepare salary expectations too? Yes, before the first conversation, not after. Knowing your number and its justification keeps you calm in the screen and stronger later; see the guidance on negotiating tech compensation.

How do I handle a topic I simply cannot crack in time? Aim for competent, not expert. Learn the standard approach, be able to talk through it, and be honest in the room if pressed. A candidate who reasons sensibly about an unfamiliar area usually outscores one who pretends fluency and gets exposed.

Adapt it honestly

No plan survives contact with a real schedule, and that is fine. The two most common adjustments are compressing it when an interview lands sooner than expected, and rebalancing it when your self-assessment was wrong. If week three reveals that system design is far weaker than you thought, spend more of week four there and less on the things you have already got. Treat the timeline as a frame that keeps you moving in the right order, foundations, stories, practice, polish, rather than a rigid contract. The engineers who interview well are rarely the ones who did the most preparation in total. They are the ones who prepared the right things, in the right order, with enough practice under pressure that the real thing felt familiar.

Sources

• Spacing effect, Wikipedia, summarising Cepeda and colleagues' review of distributed practice. The evidence base for why four spread weeks beat one crammed one.

Put the plan into action

Each week of the plan leans on a more focused guide; reach for these as you hit that phase:

• STAR framework for behavioural interviews, for building the week-two story library.
• Data structures and algorithms study plan, if your week-three coding practice needs a structured order.
• Mock interview practice plan, for running the live week-three rehearsals well.
• Onsite interview day logistics, for the week-four logistics pass.