Your 90-Day Plan

Mental model: Skill comes from finishing small things repeatedly, not from studying more. The plan exists so that on any given evening you already know what to do and never negotiate with yourself.

Level: beginner · about 14 minutes

This plan assumes about seven hours a week: an hour on five weekdays plus a longer weekend session. Less than that still works, it just stretches the calendar. What does not work is an eight-hour Sunday every three weeks, because retention comes from the number of separate days you touched the material, not the total hours.

Mon to Thu, 45 min

build the current project. One commit minimum, however small

Any day, 10 min

spaced review of flagged concepts, before you write code

Friday, 45 min

read someone else's code and write three sentences about what you learned

Weekend, 2 to 3 h

the week's milestone: finish, deploy, write it up

Never

a new tutorial while the current project is unfinished

Weeks 1 to 6: from working to trustworthy

Weeks 7 to 12: from trustworthy to hireable

The project ladder

1. Rung 1: copy with the tutorial closed Build something you have already been shown, from memory, looking things up as you go. This converts recognition into recall, which is the gap most people mistake for talent.
2. Rung 2: change the requirements Take that project and add a feature nobody showed you: filtering, undo, keyboard shortcuts, an empty state. Now you are designing, not transcribing.
3. Rung 3: introduce someone else's data Consume a real API you do not control. Rate limits, missing fields, slow responses and inconsistent shapes are the difference between a demo and software.
4. Rung 4: solve a problem you actually have The best portfolio project is boring and personal: a tracker for a habit you keep, a tool for a hobby. You are the domain expert, so requirements come from you and motivation lasts past week two.
5. Rung 5: work inside code you did not write Fix a typo in documentation, then a small bug, in an open source project. Reading, matching an existing style and surviving review is most of a real job.

The spaced review habit

const INTERVALS = [1, 2, 4, 8, 16];      // days until the next sighting

function review(card, correct, today) {
  const box = correct ? Math.min(card.box + 1, INTERVALS.length - 1) : 0;
  return { ...card, box, dueDay: today + INTERVALS[box] };
}

let card = { id: 'closures', box: 0, dueDay: 0 };

card = review(card, true, 0);    console.log(card.box, card.dueDay);  // -> 1 2
card = review(card, true, 2);    console.log(card.box, card.dueDay);  // -> 2 6
card = review(card, false, 6);   console.log(card.box, card.dueDay);  // -> 0 7
card = review(card, true, 7);    console.log(card.box, card.dueDay);  // -> 1 9

A five-box scheduler. This is the same logic behind this course's review view, in ten lines.

const INTERVALS = [1, 2, 4, 8, 16];
const promote = (box) => Math.min(box + 1, INTERVALS.length - 1);

let box = 0;
let day = 0;

for (const correct of [true, true, false, true]) {
  box = correct ? promote(box) : 0;
  day += INTERVALS[box];
}

console.log(box, day);

Two correct answers promote the card to box 2 (day 2, then day 6). One lapse sends it back to box 0 and schedules it for tomorrow (day 7). The final correct answer moves it to box 1, due on day 9. Resetting on a lapse is deliberate: a concept you just failed needs to be seen tomorrow, not in two weeks, and this is why the review queue is a better use of ten minutes than rereading notes.

The code reading habit

1. Pick one small, well-written library (not a framework). Look for one under 2,000 lines.
2. Read package.json, then the entry file, then one exported function all the way down.
3. Write three sentences: what problem it solves, one technique you would reuse, one thing you did not understand.
4. Look up only that one thing you did not understand. Leave the rest for next Friday.
5. Once a month, read a source file for something you already use. You will find a bug you have hit.

Interview preparation, in the last three weeks

Self-assessment: tick these off

• I can explain the difference between a primitive and a reference, and predict what a function does to an object I pass it.
• I can predict what == will do with a mixed pair, and I know why I still use ===.
• I can write a closure that keeps private state, and explain what it captured.
• I can transform any array shape into any other with map, filter and reduce, without a for loop.
• I can say which of this, arrow functions and bind applies at a given call site, and why.
• I can order the output of a snippet mixing setTimeout, a resolved promise and synchronous logs.
• I can write an async function with error handling that reports a failed request usefully to a user.
• I can throw a custom error with a cause, and read a stack trace back to the line that caused it.
• I can build a small UI without a framework: build nodes, delegate events, keep state in one place.
• I can write a test for a pure function and one for an async function, and make them fail on purpose first.
• I can open an unfamiliar repository and find where a feature is implemented within ten minutes.
• I can explain what TypeScript checks and what it never checks.
• I can name what my framework does for me, and do the same thing by hand for a small case.
• I can run JavaScript on a server, read configuration from the environment, and say why a client-side secret is not a secret.
• I have deployed something to a public URL that a stranger has used.
• I have written up one bug: symptom, cause, fix, and how I know it is fixed.

Try it yourself

Build your review queue

const INTERVALS = [1, 2, 4, 8, 16];

const cards = [
  { id: 'closures', box: 3, dueDay: 12 },
  { id: 'this-binding', box: 0, dueDay: 5 },
  { id: 'event-loop', box: 1, dueDay: 6 },
  { id: 'coercion', box: 4, dueDay: 30 },
];

const due = (list, today) => list.filter((c) => c.dueDay <= today).map((c) => c.id);

function review(card, correct, today) {
  const box = correct ? Math.min(card.box + 1, INTERVALS.length - 1) : 0;
  return { ...card, box, dueDay: today + INTERVALS[box] };
}

console.log(due(cards, 6));   // -> [ 'this-binding', 'event-loop' ]
console.log(due(cards, 12));  // -> [ 'closures', 'this-binding', 'event-loop' ]
console.log(review(cards[3], false, 30)); // a lapse drops box 4 straight back to 0

Add a lapses count and make a card with three or more lapses come back every day regardless of box. Then sort the queue so the most overdue card is first.

Score your own checklist

const checklist = [
  { skill: 'primitives vs references', done: true },
  { skill: 'closures with private state', done: true },
  { skill: 'reduce without a for loop', done: false },
  { skill: 'event loop ordering', done: false },
  { skill: 'async error handling', done: true },
  { skill: 'reading an unfamiliar repo', done: false },
  { skill: 'deployed to a public URL', done: true },
];

const done = checklist.filter((c) => c.done).length;
const pct = Math.round((done / checklist.length) * 100);

console.log(`${done}/${checklist.length} (${pct}%)`);
console.log('next up:', checklist.filter((c) => !c.done).map((c) => c.skill));

Replace the booleans with your honest answers, then print only the unticked items. That list is your next two weeks, in priority order.

Exercises

Schedule your own reviews

Write review(card, correct, today) returning a new card. A correct answer moves it up one box, capped at the last of [1, 2, 4, 8, 16]; a wrong answer drops it straight to box 0. Either way dueDay becomes today plus the interval for the new box. Then write dueCards(cards, today) returning the ids of every card due on or before today, in the order given.

Check yourself

You have seven hours this week. Which schedule teaches you more?

Five sessions of about an hour across the week — Retrieving something after you have partly forgotten it is what strengthens the memory, and that only happens across separate days. A single long session also spends most of its later hours tired. The same total time, split up, produces noticeably better recall, which is the entire basis of the review queue in this course.

A concept you failed today should come back when?

Tomorrow, and often until it holds — A lapse means the memory is weak, so the next attempt must come soon: the scheduler resets the card to box 0, due tomorrow. Repeating it five times in the same session mostly trains short-term memory. Waiting two weeks guarantees another failure, and waiting for a project means the gap bites you under pressure.

What does this print?

4 48 — The first promotion takes box 3 to 4 and adds 16. The next two are capped at 4 by Math.min, adding 16 each time, so the total is 48 days and the box stays at 4. Capping matters: without it you would index past the end of the array and get undefined, then NaN for every future due date.

Which portfolio project is most likely to get you hired?

A small deployed tool that solves a problem you personally have, with a README — Reviewers check three things: does it run, did you make decisions, and can you explain them. A personal tool wins on all three, because you owned the requirements and you can talk about trade-offs. Tutorial clones show you can follow instructions, which is not the skill being bought, and anything local cannot be evaluated at all.

Common mistakes

• Starting a new tutorial while the current project is unfinished. Finishing is the skill being trained.
• Batching all your practice into one long weekend session, which is the least efficient way to remember anything.
• Rereading notes instead of retrieving from memory. Recognition feels like learning and is not.
• Choosing a portfolio project so large it can never be deployed. Ship the smallest version, then extend it.
• Skipping the write-up. The ability to explain a bug and a trade-off is what gets tested in interviews.
• Treating an unticked checklist box as a verdict on your ability instead of a to-do item for next week.

Takeaways

• Seven hours spread across five days beats seven hours in one. Separate days are what build recall.
• Every week ends with something that exists: a deploy, a feature, a test suite, a write-up.
• Climb the ladder: copy from memory, change the requirements, use real data, solve your own problem, work in someone else's repo.
• Ten minutes of spaced review before you code is worth more than an hour of rereading.
• Read code every Friday and write three sentences about it. Reading is the skill with no ceiling.
• Prepare interviews by narrating out loud, not by memorising answers.
• An unticked checklist box is a small exercise to do, not a judgement to carry.