Job Interview Preparation Plan: A 14-Day Schedule That Works
CareerLesson 2 of 45 min read
What you'll learn
- Split limited prep time across technical, behavioural and company research tracks
- Follow a day-by-day 14-day plan and adapt it to your role
- Compress the plan to 7 days or stretch it to 30 without losing the structure
- Track progress with a simple log so you can see what is working
On this page
The night before an interview, most people open ten tabs, skim twenty topics and go to bed more anxious than before. The problem is not a lack of effort. It is the absence of a plan: nobody decided in advance how much time each kind of preparation deserved, so the loudest worry got all of it. A written schedule turns "I should prepare more" into "today is Tuesday, so I do two array problems and one story".
Three tracks, one calendar
Interview preparation breaks into three tracks that need different kinds of effort.
- Technical or role skills. For software roles this means coding or system-design practice; for analysts, SQL and case exercises; for other roles, the core craft questions. This track rewards repetition and spacing.
- Behavioural. Stories, your introduction and your reasons for the move. This track rewards speaking aloud, because a story that feels fine in your head often rambles when spoken.
- Company and role research. The prep sheet from the previous lesson. It needs concentrated effort early, then only a light refresh.
A sensible starting split for a role with a technical round is roughly half of your time on the technical track, a third on behavioural and the remainder on research. For roles without a technical test, shift some of the technical share to behavioural and mock practice. These ratios are a starting point, not a rule; adjust them to where your gaps are.
The 14-day plan
The plan assumes about 90 minutes on weekdays and two to three hours on weekend days. If you can only manage 45 minutes, keep the structure and cut the volume rather than skipping a track. The example below uses software topics for the technical column; replace them with whatever the role actually tests, which your requirement-to-evidence map will tell you.
| Day | Technical track | Behavioural track | Company track |
|---|---|---|---|
| 1 | List the topics the role tests and rate each 1-5 | Draft your 60-second intro | Decode the job post, build the evidence map |
| 2 | Weakest topic: learn the idea, 1 easy problem | Pick 3 story topics, write bullets | Company research checklist (1 hour) |
| 3 | Second weakest topic: 2 problems | Say story A aloud, time it | Find interviewers' roles and backgrounds |
| 4 | Revisit day-2 topic with a harder problem | Say story B aloud | Write why this company and why now |
| 5 | Mixed set: 2 problems, no notes | Say story C aloud | Draft 3 questions to ask |
| 6 | Weekend: 1 timed set, review mistakes | Record the intro and one story, listen back | Try the product or read recent news |
| 7 | Light review only; rest | Rest | Rest |
| 8 | Third topic: learn and 2 problems | Practise 'tell me about a failure' | Check what peers are asked (forums, contacts) |
| 9 | Revisit day-3 topic, no notes | Practise 'why should we hire you' | Refine the three questions |
| 10 | Mock round 1 (technical), see next lesson | Review mock feedback, fix one thing | Light refresh of facts |
| 11 | Fix top mistakes from the mock | Mock round 2 (behavioural) | Prepare logistics: tools, route, setup |
| 12 | Weekend: full mock, timed, recorded | Review recording, update stories | Update the prep sheet |
| 13 | Light: skim notes, 1 easy problem | Say intro once, then stop | Final read of the prep sheet; set out clothes and bag |
| 14 | Interview day: no new material | Warm up with intro only | Read the sheet once, then go |
Choosing technical topics and where to go deeper
Do not try to cover everything. Take the topics your target role actually tests, rate yourself honestly, and spend the first week on the weakest ones. Use stronger topics only for maintenance. For software roles, our guide to coding interview prep for self-taught developers explains how to pick problems, and the data structures course gives a structured way to rebuild fundamentals. If the role includes design questions, see the system design interview guide. For larger companies with long loops, how to crack FAANG interviews describes the format.
Shorter and longer versions
| Time available | What changes |
|---|---|
| 7 days | Merge days 1-2 and 3-5. Do the evidence map and research on day 1. Do one mock technical round and one behavioural round, no more. Keep one fully light day. |
| 14 days | The plan above. |
| 30 days | Spend week 1 on fundamentals, weeks 2 and 3 on practice by topic, week 4 on mock rounds and the prep sheet. Repeat the weakest topic once a week. |
A progress log
A plan is only useful if you notice what is working. Keep a log with three lines per session. It takes two minutes and shows you whether your weakest topic is improving, which is hard to judge from memory.
DATE / DAY: Day 3, Wednesday
TRACK: Technical (second weakest topic: hash maps)
DONE: 2 problems, one with a hint after 15 minutes
STUCK ON: Forgot to handle an empty input in problem 2
NEXT TIME: Write the edge cases before the code, every time
CONFIDENCE: 3/5 (was 2/5 on day 2)
DATE / DAY: Day 4, Thursday
TRACK: Behavioural (story B, disagreement)
DONE: Said it aloud twice; first version ran 4 minutes
STUCK ON: Too much background before the point
NEXT TIME: Cut to 2 minutes; start with the result
CONFIDENCE: 3/5Common mistakes
- Spending all the time on the technical track. Symptom: you solve the problems and then stumble on "walk me through your background". Reserve time for speaking aloud.
- Reading solutions instead of attempting problems. Symptom: everything looks familiar on the page and you freeze when a blank editor opens. Attempt first, then compare.
- Cramming in the last 24 hours. Symptom: you arrive tired and blank. Keep the final two days light and free of new material.
- Never practising out loud. Symptom: your answers run past three minutes and you lose the thread mid-sentence. Speak every story and every explanation aloud.
- Ignoring the log. Symptom: two weeks later you cannot say which topics improved. Write the two-minute notes.
How this shows up in real projects and interviews
Real schedules are messier than a table. An interview moves, a second round appears or work gets in the way. What carries over is the principle: decide the split in advance, spend the first half learning and the second half rehearsing, and protect the last two days. If your interview is announced with only a few days' notice, use the 7-day version and be explicit with yourself about what you are not covering. Candidates who choose what to skip usually perform better than candidates who try to do everything.
Practising out loud also trains skills the interviewer cares about beyond content. The lesson on thinking out loud in interviews shows how to narrate your reasoning during a technical question.
Try it yourself
Write your own 14-day plan for a real or imagined interview. List the topics the role tests, rate each 1 to 5, then fill a three-column table (technical, behavioural, company) for each day, including two light days. Add a two-line daily log template and fill in the first entry after your first session.
Show a hint
If a day in your plan needs more than two hours, move something. Plans that are too heavy get abandoned by day four.
Key takeaways
- Split time into technical, behavioural and company tracks, with a first guess of about half, a third and the remainder.
- Spend the first week on your weakest topics and the second on mock rounds and refinement.
- Keep days 13 and 14 light; no new material right before the interview.
- Practise every story and explanation aloud, not only in your head.
- Use a two-minute daily log so you can see which topics are actually improving.
Test yourself
A trick from this lesson's ride: Slice the calendar by the round you'll face: heaviest round, biggest slice. Four more tricks like it wait along the route, each followed by a question.
Frequently asked questions
How long should I prepare for a job interview?
Two weeks of steady, short sessions is a good target for most roles, with a seven-day version if time is tight and a thirty-day version for large companies with several rounds. What matters is covering all three tracks, not the exact number of days.
How should I split interview preparation time?
For a role with a technical round, start with about half on technical practice, a third on behavioural stories and the rest on company research. For roles without a technical test, move some technical time to behavioural practice and mock interviews.
What should I do the day before an interview?
Keep it light. Read your one-page prep sheet, say your introduction once, prepare your logistics (links, route, documents, setup) and sleep. Avoid learning new topics, which tends to increase anxiety more than it improves performance.