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, improve with spaced practice rather than a single long session. 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.
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.
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.
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.
- 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.
End the week with a plan that points your limited time at your actual gaps rather than at whatever you happen to enjoy practising.
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.
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.
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.
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.
- Rehearse your behavioural stories by speaking them, not just reading them, so they come out naturally and within a reasonable length.
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.
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.
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 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
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.
Continue your prep
Put the plan into action with these: