Step 1: Pick your core resources

When I prepared for a new client project, I noticed I was opening fifteen tabs and finishing none of them. The internet has too much. Pick one resource per technology and stay with it long enough to actually finish.

Here's what I keep going back to:

• web.dev HTML
• web.dev Accessibility
• web.dev CSS
• web.dev Responsive Design
• web.dev JavaScript
• web.dev Performance
• Patterns.dev
• React Official Docs (or Vue/Angular official docs if you work with those)

These aren't the only options out there. They're the ones maintained by the people who built the platform, which means the explanations don't drift. They won't teach you every advanced trick. They'll confirm your foundation is sound, and that's the part that matters.

Don't shop for the perfect course. Pick one and finish it.

Step 2: Deepen when you find weak spots

You're reading about JavaScript promises and you notice you can't actually explain what Promise.all does when one of the inputs rejects. That's the moment. Stop scrolling. Go deeper on that one thing before moving on.

You don't need to cover every corner case in HTML or CSS. You do need to refuse to walk past the gaps you noticed. Walked-past gaps are the ones that show up in interviews.

AI is good for this if you stop using it as a search engine. Last week I caught myself hand-waving about React's useEffect cleanup in a code review. Here's the prompt I pasted into ChatGPT right after:

"I'm reviewing junior code. Show me three realistic useEffect mistakes a mid-level React dev makes around cleanup. For each one, write the broken hook, the bug it produces in the UI, and the corrected version. No theory, just the three diffs."

The answer surprised me on the second one (a subscription that re-subscribed on every render because the dependency was a freshly-created function). I'd seen that bug in PRs. I hadn't framed it that cleanly. That's the kind of prompt worth keeping in a notes file.

Step 3: Make it interactive

Reading the docs is the easy part. Reading and then assuming you've learned it is where most prep falls apart.

Last winter I sat down to refresh CSS Grid before a client interview. I'd used Grid for years. I "knew" Grid. Then I tried to rebuild the homepage of a news site I read every morning using nothing but grid-template-areas, and twenty minutes in I was Googling the difference between auto-fill and auto-fit like a junior. The mini-demo did in twenty minutes what a week of re-reading the spec hadn't done.

That's the move. Pick one concept you just read. Build the smallest possible thing that uses it. If you can't, that's your weak spot, named and located.

A few formats that work, depending on the day:

• A short YouTube explainer from someone whose taste you trust (Kevin Powell for CSS, Theo or Lee Robinson for React, Wes Bos for plain JS).
• A quick quiz: ask AI for "10 interview-style questions on the JavaScript event loop, with the answer hidden after each one so I can self-test".
• The mini-demo above. Twenty minutes, one file, one concept.

If I had to do this again

I'd pick one resource per technology, finish it, and only let myself search for a second source when I hit a concept I couldn't explain to a junior in two sentences. That's the whole rule.

Here's the one I keep coming back to: the JavaScript event loop. I "understood" it for years in the textbook sense (call stack, microtasks, macrotasks, all the right words) and still couldn't explain why a Promise.resolve().then(...) ran before a setTimeout(..., 0) in a junior's PR. I had to sit down with one of Jake Archibald's talks, draw the queues on paper, and only then did the words match the picture in my head.

That's what fluency looks like. Not "I read about it." It's "I can draw it, and the drawing matches what the engine actually does." Aim for that on three or four core concepts before the next interview. You'll feel a different kind of calm walking in.