A study plan built back from your interview date

Six weeks of eight hours is 48 hours, and that number is fixed the day you learn your interview date: the plan has to fit it. A study plan built back from the date starts at the end. It protects the last week for light review, logistics and rest, fills the weeks before it with one weekly cycle of new material, timed practice, re-solves at growing gaps and a mock, and lets a diagnostic in week 1 decide how the hours are shared between coding, design and behavioural preparation.

The plan then changes whenever its checkpoints show that it is not working. By the end you can build such a plan, read two worked plans whose every total a program recomputes, and run a checker on your own plan against five rules.

Tests and spacing beat rereading, so the plan is built from them

Henry Roediger and Jeffrey Karpicke gave students short passages to learn, then either a second reading or a test in which they wrote down what they remembered, with no feedback. On a test five minutes later the second reading looked better. On tests two days and one week later, the students who had been tested remembered more. Two larger reviews point the same way:

• Ten study habits, weighed. John Dunlosky and four co-authors weighed the evidence on ten common study habits. Two earned their top rating: practice testingpractice testing: Recalling or solving without the answer in view, such as working a problem from a blank page or writing down what you remember. A review of ten study techniques rated it one of the two most useful., meaning any attempt to recall or solve without the answer in view, and distributed practicedistributed practice: Spreading the study of one topic over sessions on different days instead of one long session. The best gap between the sessions grows with how long you need to remember., meaning sessions spread out over days. Interleavinginterleaving: Mixing different kinds of problem in one practice session, so that each problem has to be recognised before it can be solved, as in a real round., mixing different kinds of problem in one session, landed in the middle. Rereading and highlighting landed near the bottom.
• Spacing wins, and the best gap grows. Nicholas Cepeda and colleagues pooled 317 experiments on spacing. Spread-out study beat the same amount crammed together, and the longer something had to be remembered, the longer the gap between sessions that served it best.

For interview preparation, MySmartCoPilot reads the techniques as sessions you can plan:

Employers say much the same: Meta’s full loop guide advises practising fewer problems of many types rather than many problems of one type. None of the studies used coding or design interviews, so the exact gaps in this lesson are a sensible default rather than a research result.

Count back from the date: the budget, then a protected last week

Multiply the weeks to your interview by the hours you can give each week: that is the budget. An engineer with an SDE-2 loop six weeks away and eight spare hours a week has 48 hours, and every later choice spends them. If you have several interviews, plan for the first one that matters and treat the rest as later checkpoints. Then protect the end. These are MySmartCoPilot’s planning rules, so change them where your situation differs:

1. The last week is light. Every area gets half its usual time, except one timed mock early in the week.
2. Nothing new in the last 48 hours. A topic started two days before the interview cannot be practised at the spacing that makes it stick, and it takes time from reviewing what you can already do.
3. The final four weeks hold at least one timed mock each. A mockmock interview: A full rehearsal of one interview round under its real conditions: a problem you have not seen, the round's length and tool, and a person or a recording to explain your thinking to. More in “Mock interviews and deliberate practice” is a full round under real conditions: the round’s length, its editor or whiteboard, and someone, or a recording, to talk to.

The diagram shows the order in which you plan, from the date down to week 1; reading it upwards gives the order in which you live the plan:

Step through the same count for the SDE-2 candidate, with the hours each rule leaves:

The light week keeps 4 hours 24 minutes of its 8, and the 3 hours 36 minutes it frees are rest. Those hours would buy little: material learnt in the last days has no time left to come back at a gap, and rest leaves you fresh for the round.

A week-1 diagnostic decides where the hours go

In the first week, spend two or three hours on a diagnosticdiagnostic: A short timed test of each area a round covers, taken and scored at the start of a study plan, so that the hours go to the weakest areas rather than the favourite ones., to measure where you stand. Use original practice problems of medium difficulty that you have not seen recently, and the conditions of your round:

• Coding: two problems against the clock at the pace of your round, in the editor you will use. A round of about two problems in about 40 minutes, as Meta’s guide describes its coding interviews, means 20 minutes a problem.
• Low-level design, if your round has one: 30 minutes on the classes and interfaces of a small system.
• System design, for experienced roles: one 45-minute design, talked through aloud and recorded on your own device.
• Behavioural: two stories told aloud, three minutes each. Amazon’s SDE II prep page, for example, says each interviewer typically asks two or three behavioural questions, across a loop of four 55-minute interviews.

Score each area from 1 to 4 against this table, and write down the measurements behind the score:

The measurements matter more than the scores: minutes to a working solution, hints taken, bugs that your own tests caught before you said “done”, and how long each story took. They are what the checkpoints later in the plan compare against, so a score of 3 in week 1 and a score of 3 in week 4 can still show progress.

Split the hours by target, then move them towards the gap

Start from the split for your target, then adjust it with the diagnostic. These starting splits are MySmartCoPilot’s recommendations, not any employer’s:

Read the table by column: the more experienced the target, the more of the week moves from coding to design and to stories. The adjustment rule: when an area scored two or more points below your best area, move 5 percentage points of the split from the best area to it, and look again at the next checkpoint. One step at a time keeps the strong areas from going stale. If your target role has no design round, its share goes to coding and behavioural preparation. The material itself lives in other tracks of MySmartCoPilot Learn: this plan schedules lessons from coding patterns, data structures and algorithms, low-level design, system design and behavioural interviews, and from aptitude when your process starts with an aptitude test.

Every week repeats four sessions, and misses come back at growing gaps

Every week of the plan holds four kinds of session:

1. Learn: a new pattern or topic, from its lesson, with one problem solved slowly.
2. Timed practice: problems against the clock, with no hints in the first two thirds of the time.
3. Spaced review: re-solves of problem families from your error log, and stories retold.
4. One mock: a full round, followed by a written debrief.

In the first half of the plan, take one pattern at a time, so that each one becomes familiar. In the second half, practise in mixed sets in which nothing announces the pattern, because a real round does not announce it either.

Every problem you miss or solve slowly goes into an error logerror log: A list of every problem you missed or solved slowly, with the day, the family of problem, what went wrong, the minutes it took and the hints you needed, from which the re-solves are scheduled.: the day, the family of problem, what went wrong, the minutes it took and the hints you needed. The entry starts a ladder of re-solvesre-solve: Solving a fresh problem from a family you missed earlier, a day or more after the miss, to check that what went wrong is fixed. Repeating the same problem tests memory instead., here after gaps of 1, 3, 7, 14 and 30 days, each counted from the last attempt. A miss at any re-solve starts the gaps again at 1 day, and any day on or after the interview is dropped. Walk through one entry of a plan whose interview is on day 42:

The program below computes the same calendar from the entry and the re-solves done so far. Change done to the results of your own re-solves and run it again:

// A spaced re-solve calendar for one problem family, started by an entry in the error log. The family comes back
// after gaps of 1, 3, 7, 14 and 30 days, each counted from the last attempt (a MySmartCoPilot schedule). A miss at
// any re-solve starts the gaps again at 1 day, and a day on or after the interview is dropped. Days count from the
// start of the plan. Change `done` and press Run.

const GAPS = [1, 3, 7, 14, 30];
const interviewDay = 42;
const entry = { day: 9, family: 'merging intervals', what: 'sorted by end instead of start; needed a hint; 38 minutes' };
// The re-solves done so far, in order: [day, solved inside the time limit without a hint?]
const done = [
  [10, true],
  [13, true],
  [20, false],
];

const days = (n) => `${n} day${n === 1 ? '' : 's'}`;

console.log(`Error log, day ${entry.day}: ${entry.family}: ${entry.what}`);
let last = entry.day;
let step = 0;
for (const [day, solved] of done) {
  const result = solved ? 'solved' : 'missed, so the gaps start again at 1 day';
  console.log(`  day ${day}, ${days(day - last)} after day ${last}: ${result}`);
  step = solved ? step + 1 : 0;
  last = day;
}
const upcoming = [];
for (; step < GAPS.length; step++) {
  const day = last + GAPS[step];
  if (day >= interviewDay) {
    console.log(`  day ${day}, ${days(GAPS[step])} after day ${last}: dropped, on or after the interview on day ${interviewDay}`);
    break;
  }
  console.log(`  day ${day}, ${days(GAPS[step])} after day ${last}: due${upcoming.length ? ', if the re-solves before it are solved' : ''}`);
  upcoming.push(day);
  last = day;
}
if (step === GAPS.length) {
  console.log(upcoming.length ? '  then retired, once the re-solve at the 30-day gap is solved' : '  retired: solved at the 30-day gap');
}
console.log(upcoming.length ? `Re-solves still to come: days ${upcoming.join(', ')}` : 'No re-solves left before the interview');

Error log, day 9: merging intervals: sorted by end instead of start; needed a hint; 38 minutes
  day 10, 1 day after day 9: solved
  day 13, 3 days after day 10: solved
  day 20, 7 days after day 13: missed, so the gaps start again at 1 day
  day 21, 1 day after day 20: due
  day 24, 3 days after day 21: due, if the re-solves before it are solved
  day 31, 7 days after day 24: due, if the re-solves before it are solved
  day 45, 14 days after day 31: dropped, on or after the interview on day 42
Re-solves still to come: days 21, 24, 31

The family was missed on day 9 and solved on days 10 and 13, so its next gap was 7 days. On day 20 it was missed again, and the gaps started over: days 21, 24 and 31 are due, and day 45 falls after the interview and is dropped. A re-solve takes one fresh problem of the same family, not the same problem again: a problem you remember tests your memory of it, not the pattern.

Two worked plans show where the hours go

Here are the rules applied to two invented candidates: a final-year student with 12 weeks of 10 hours for new-graduate roles, and an engineer with three years of experience and 6 weeks of 8 hours for an SDE-2 loop. The program works in minutes, so every total adds up exactly:

// Two worked study plans, with every total recomputed. Each plan splits its weekly minutes across areas by its
// target role (the splits are MySmartCoPilot's starting points, adjusted at each checkpoint). Every week has one timed
// mock, and the last week is light: half time for every area except the mock, and nothing new in the last 48 hours.
// Change a plan's weeks, hours or split and press Run.

const plans = [
  {
    who: 'Final-year student, new-graduate SDE roles',
    weeks: 12,
    hoursPerWeek: 10,
    split: [['coding', 60], ['CS fundamentals', 15], ['behavioural', 15], ['mocks', 10]],
  },
  {
    who: 'SDE-2 candidate, three years of experience',
    weeks: 6,
    hoursPerWeek: 8,
    split: [['coding', 40], ['system design', 25], ['low-level design', 10], ['behavioural', 15], ['mocks', 10]],
  },
];

/** "1 h 30 min", "45 min" or "6 h" from a number of minutes. */
function hm(minutes) {
  const h = Math.floor(minutes / 60);
  const m = Math.round(minutes - h * 60);
  if (!h) return `${m} min`;
  return m ? `${h} h ${m} min` : `${h} h`;
}

const line = (pairs) => pairs.map(([area, minutes]) => `${area} ${hm(minutes)}`).join(' · ');

for (const p of plans) {
  const percent = p.split.reduce((sum, [, pct]) => sum + pct, 0);
  if (percent !== 100) throw new Error(`${p.who}: the split adds up to ${percent} %, not 100 %`);
  const weekly = p.hoursPerWeek * 60;
  const normal = p.split.map(([area, pct]) => [area, (weekly * pct) / 100]);
  const last = normal.map(([area, minutes]) => [area, area === 'mocks' ? minutes : minutes / 2]);
  const totals = normal.map(([area, minutes], i) => [area, minutes * (p.weeks - 1) + last[i][1]]);
  const planned = totals.reduce((sum, [, minutes]) => sum + minutes, 0);
  const budget = p.weeks * weekly;

  console.log(`${p.who}: ${p.weeks} weeks × ${p.hoursPerWeek} h = ${hm(budget)}`);
  console.log(`  weeks 1 to ${p.weeks - 1}, each: ${line(normal)}`);
  console.log(`  week ${p.weeks}, light: ${line(last)}`);
  console.log(`  totals: ${line(totals)}`);
  console.log(`  planned ${hm(planned)} of ${hm(budget)}; ${hm(budget - planned)} left unused on purpose in the light week`);
  console.log('');
}

Final-year student, new-graduate SDE roles: 12 weeks × 10 h = 120 h
  weeks 1 to 11, each: coding 6 h · CS fundamentals 1 h 30 min · behavioural 1 h 30 min · mocks 1 h
  week 12, light: coding 3 h · CS fundamentals 45 min · behavioural 45 min · mocks 1 h
  totals: coding 69 h · CS fundamentals 17 h 15 min · behavioural 17 h 15 min · mocks 12 h
  planned 115 h 30 min of 120 h; 4 h 30 min left unused on purpose in the light week

SDE-2 candidate, three years of experience: 6 weeks × 8 h = 48 h
  weeks 1 to 5, each: coding 3 h 12 min · system design 2 h · low-level design 48 min · behavioural 1 h 12 min · mocks 48 min
  week 6, light: coding 1 h 36 min · system design 1 h · low-level design 24 min · behavioural 36 min · mocks 48 min
  totals: coding 17 h 36 min · system design 11 h · low-level design 4 h 24 min · behavioural 6 h 36 min · mocks 4 h 48 min
  planned 44 h 24 min of 48 h; 3 h 36 min left unused on purpose in the light week

What the numbers say:

• The student gets 6 hours of coding every week, 1 hour 30 minutes each of CS fundamentals and behavioural preparation, and a 1-hour mock. Over twelve weeks that is 69 hours of coding and 12 of mocks, and the light last week leaves 4 hours 30 minutes of the budget unused on purpose.
• The SDE-2 candidate has 48 minutes a week for low-level design. That is enough for one timed design a week, which keeps a skill sharp, but not enough to learn the subject from the start. If the diagnostic scored low-level design at 1, the split has to move, or the target has to.
• Mocks at 10 % give the SDE-2 candidate 4 hours 48 minutes over six weeks, which is six mocks of 48 minutes: a 45-minute round and a short debrief each week.

Change the plan when a checkpoint misses twice in a row

Hours studied measure effort, not readiness, so the checkpoints measure what the rounds measure. Look at them every two weeks, and every week in the final month:

The rule for changing the plan, a MySmartCoPilot rule: change it when a checkpoint misses its target twice in a row, not after one bad day. Move hours towards the measure that missed, put a topic on a list of what you will not cover, or, if the gap is too large for the weeks that are left, ask the recruiter early whether the date can move.

Practise: check your own plan against five rules

The program below checks a plan against five rules: the hours fit the budget, every area of the target role appears, the gaps between sessions on one topic never shrink, each of the last four weeks has a timed mock, and nothing new starts in the last 48 hours. The sample plan breaks three of them. Press Run to see why, then replace the sessions with your own plan, fix every line it reports, and run it again.

// Checks a study plan against five rules and explains each failure. Days count from the start of the plan (day 1);
// the interview is on `interviewDay`. Replace the sample with your own plan and press Run.
//   kind: learn (new material) · timed (practice against the clock) · review (a re-solve or a story retold) · mock

const plan = {
  hoursPerWeek: 6,
  interviewDay: 29,
  areas: ['coding', 'design', 'behavioural'],
  sessions: [
    // [day, area, kind, minutes, topic]
    [1, 'coding', 'learn', 60, 'hash maps'],
    [2, 'coding', 'learn', 60, 'two pointers'],
    [3, 'coding', 'timed', 60, 'hash maps'],
    [4, 'behavioural', 'learn', 60, 'stories'],
    [5, 'design', 'learn', 60, 'caching'],
    [6, 'coding', 'mock', 60, 'mixed'],
    [8, 'behavioural', 'review', 30, 'stories'],
    [9, 'coding', 'review', 45, 'two pointers'],
    [10, 'coding', 'review', 45, 'hash maps'],
    [11, 'coding', 'timed', 60, 'two pointers'],
    [12, 'design', 'timed', 60, 'caching'],
    [13, 'behavioural', 'timed', 45, 'stories'],
    [15, 'coding', 'learn', 60, 'intervals'],
    [16, 'coding', 'timed', 60, 'intervals'],
    [17, 'coding', 'review', 45, 'hash maps'],
    [19, 'design', 'review', 45, 'caching'],
    [20, 'coding', 'mock', 60, 'mixed'],
    [22, 'coding', 'review', 45, 'intervals'],
    [23, 'coding', 'timed', 60, 'mixed'],
    [26, 'design', 'mock', 60, 'caching'],
    [26, 'behavioural', 'timed', 45, 'stories'],
    [27, 'coding', 'learn', 60, 'tries'],
    [28, 'coding', 'review', 30, 'intervals'],
  ],
};

const week = (day) => Math.ceil(day / 7);
const hm = (m) => (m % 60 ? `${Math.floor(m / 60)} h ${m % 60} min` : `${m / 60} h`);

function validate(p) {
  const problems = [];
  const lastDay = p.interviewDay - 1;
  const weeks = week(lastDay);
  const budget = weeks * p.hoursPerWeek * 60;
  const used = p.sessions.reduce((sum, s) => sum + s[3], 0);

  // 1. The hours fit the budget.
  if (used > budget) problems.push(`budget: ${hm(used)} planned, but ${weeks} weeks at ${p.hoursPerWeek} h give ${hm(budget)}: cut sessions or lower their minutes.`);
  // 2. Every area of the target role appears.
  for (const area of p.areas) {
    if (!p.sessions.some((s) => s[1] === area)) problems.push(`areas: no session practises ${area}, which the target role tests.`);
  }
  // 3. Gaps between sessions on one topic never shrink (mixed sets have no single topic).
  const byTopic = new Map();
  for (const [day, , , , topic] of p.sessions) if (topic !== 'mixed') byTopic.set(topic, [...(byTopic.get(topic) ?? []), day]);
  for (const [topic, days] of byTopic) {
    const sorted = [...days].sort((a, b) => a - b);
    for (let i = 2; i < sorted.length; i++) {
      const before = sorted[i - 1] - sorted[i - 2];
      const after = sorted[i] - sorted[i - 1];
      if (after < before) {
        problems.push(`spacing: ${topic} comes back after ${before} days, then after only ${after} (day ${sorted[i]}): make each gap at least as long as the one before.`);
        break;
      }
    }
  }
  // 4. A timed mock in each of the last four weeks.
  for (let w = Math.max(1, weeks - 3); w <= weeks; w++) {
    if (!p.sessions.some((s) => s[2] === 'mock' && week(s[0]) === w)) problems.push(`mocks: week ${w} has no timed mock; each of the last four weeks needs one.`);
  }
  // 5. Nothing new in the last 48 hours.
  for (const [day, , kind, , topic] of p.sessions) {
    if (kind === 'learn' && day >= p.interviewDay - 2) problems.push(`nothing new: day ${day} starts ${topic}, in the last 48 hours before the interview: move it earlier or leave it out.`);
  }

  console.log(`Plan: ${weeks} weeks, interview on day ${p.interviewDay}, ${hm(used)} planned of ${hm(budget)}`);
  if (!problems.length) console.log('All five checks pass.');
  for (const msg of problems) console.log(`- ${msg}`);
}

validate(plan);

Plan: 4 weeks, interview on day 29, 20 h 15 min planned of 24 h
- spacing: two pointers comes back after 7 days, then after only 2 (day 11): make each gap at least as long as the one before.
- mocks: week 2 has no timed mock; each of the last four weeks needs one.
- nothing new: day 27 starts tries, in the last 48 hours before the interview: move it earlier or leave it out.

The sample comes back to two pointers after 7 days and then after only 2, has no mock in week 2, and starts tries on day 27, two days before the interview. Moving the tries session into week 3 and the day-11 two-pointer session to day 16, and adding a mock in week 2, makes all five checks pass.

Then take the self-check on the seven ideas of the plan. It starts with the idea where your answers have been weakest, gets harder as you answer correctly, and repeats any question you miss once at the end:

Interview questions

How do you learn a new technical topic so that you still remember it a month later? (warm-up)

By testing myself rather than rereading, and by coming back to it at growing gaps. When I learn a new topic, I read or watch the explanation once, then close it and work a problem or write the idea down from memory, checking what I got wrong. I keep the topics I miss in a log and return to each one a day later, then a few days later, then a week or two later, using a fresh problem each time. The research agrees: a review of ten study techniques gave its top rating only to practice testing and to spreading practice over time, while rereading, which feels productive, rated low. A good answer also gives a real example, such as a framework learnt for a project, and how you checked that it stuck.

Choose the answer you would give to each of these, and read why the other choices fall short:

Two questions from this module’s bank start from the plan of this lesson: dividing a fixed budget when one part is far weaker, and learning a skill fast with evidence that it worked:

Key takeaways

• Practice testing and spacing earned the research’s top rating and rereading one of its lowest, so every session of the plan asks you to solve or recall without the answer in view, and every topic comes back after a gap.
• The budget is the weeks times the weekly hours; the last week is light, nothing new starts in the last 48 hours, and each of the final four weeks holds a timed mock.
• A week-1 diagnostic under the conditions of your rounds gives each area a score from 1 to 4, and its measurements matter more than the scores.
• The split starts from the target role and moves 5 points at a time towards any area two or more points behind.
• Each week holds new material, timed practice, re-solves and a mock; misses come back after gaps of 1, 3, 7, 14 and 30 days from the last attempt, on fresh problems of the same family.
• The checkpoints measure minutes, hints, self-caught bugs and story length, and the plan changes when one misses its target twice in a row.