A technical interview prep checklist

What to do eight weeks out, one week out and in the room, plus what to ask your recruiter first.

By Judson Dunne. Updated November 7, 2026.

No two companies run interviews the same way. Some use algorithm rounds, some have you build a small app, and some mostly talk about your past work. So the first item on this list is the one most people skip.

First: find out what you're preparing for

Recruiters generally want you to do well, and most will answer these questions. Ask them as soon as you have a contact.

  • How many rounds are there, and what happens in each?
  • Are coding rounds algorithm problems, practical exercises or both?
  • What environment do I code in? A shared editor, an IDE or a whiteboard?
  • Can I use the language I'm most comfortable with?
  • Is there a system design or behavioral round at my level?

Eight weeks out

  • Choose one language and learn its standard library for strings, maps, sets, sorting and heaps.
  • Follow a study roadmap instead of a random problem list.
  • Start a pattern log: for every problem, write down one line about what to recognize next time.
  • Solve your first few problems out loud, even if it feels silly. It's a separate skill from solving them.

Four weeks out

  • Switch to timed practice, about 25 minutes per problem.
  • Do your first mock interview, with a person if possible. Expect it to go worse than practice, because that's what it's for.
  • Prepare your stories (see below).
  • For JavaScript candidates: be solid on closures, this, promises and how map, filter and reduce work, because they often come up.
  • If the process includes building something, practice standing up a small API with one route, validation and a test.

Prepare stories, not answers

Behavioral rounds are usually about what you did and why. Pick four or five real experiences you can adapt: a hard bug, a disagreement, a mistake, a project you led and something you learned quickly. For each one, practice saying it in about two minutes:

  • The situation, in a sentence or two.
  • The decision you made, and what you considered.
  • What happened, with a concrete result if you have one.
  • What you'd do differently. This is what makes a story believable.

One week out

  • Stop learning new topics. Redo problems you've already solved, from a blank file.
  • Do one or two more mocks, focused on what the first ones exposed.
  • Read your pattern log.
  • Learn about the company's product, and prepare a few questions you actually want answered.

In the coding round

  1. Restate the problem in your own words.
  2. Ask about the input: size, empty cases, duplicates, negatives.
  3. Work through an example by hand before designing anything.
  4. Say the simple solution first, with its complexity, then look for a better one.
  5. Agree on an approach before you code. Interviewers can't help if they don't know where you're going.
  6. Keep talking while you write, especially when you're stuck.
  7. Test it yourself before saying you're done, starting with your example and then the edge cases.
  8. State the final time and space complexity.

If you get stuck, say what you know and what you're unsure about. A hint you asked for is often better than five minutes of silence.

Afterward

Write down the questions and how it went while you still remember. Whatever the outcome, it's the best study material you'll get for the next one. And don't read too much into one result, because interviews are noisy, and a single round doesn't measure your ability. If you want a structured plan, see how interview coaching works.