How Do You Prepare for a JS Interview?

Prepare in three layers, because interviews test three different things.

The language. Be able to explain, not just recall. Why the plus operator behaves differently from the minus operator. What the temporal dead zone is. How the prototype chain resolves a property. Why an arrow function has no this. If you can explain the reason behind a rule, you will not forget it, and you will be able to reason about the rules you have not met yet.

Problem solving. The array and string manipulation drills, done out loud, on paper or a whiteboard, without a reference. The goal is not memorising a solution but practising the loop of reading a requirement, checking the edge cases, and choosing a data structure. Doing twenty small problems in that loop is worth more than reading three long tutorials.

Your own code. Be ready to talk about two projects in depth. What the problem was, what the constraints were, what you built, what went wrong, and what you would change. Interviewers ask follow-up questions precisely to see how deeply you know your own work, and a project you cannot explain in detail is worse than no project at all.

On the day, ask what the interviewers care about and follow their lead. Write code out loud as you think, because the interviewer is usually grading your reasoning rather than your typing. And when you are stuck, say what you know and what you would check, because that is exactly how you would debug it at work.

A self-test is more useful than rereading notes, because it forces you to produce an answer rather than recognise one. This one is small enough to build in an afternoon and use every week.

// A tiny self-test harness: a list of questions and a checker.
const questions = [
  { q: "What does the triple equals compare?", answer: "type and value" },
  { q: "What is the temporal dead zone?", answer: "before a let or const is initialised" },
  { q: "What runs first, a promise callback or a timer?", answer: "promise" },
];

const quiz = (list) => {
  let score = 0;
  const details = [];

  for (const item of list) {
    const expected = item.answer.toLowerCase();
    const given = (item.given ?? "").toLowerCase();
    const ok = given.includes(expected);

    if (ok) score += 1;
    details.push(`${ok ? "PASS" : "FAIL"}: ${item.q}`);
  }

  return { score, total: list.length, details };
};

// Run it against your own answers.
const myAnswers = questions.map((item) => ({ ...item, given: "type and value" }));

const result = quiz(myAnswers);
console.log(result.score, "of", result.total);   // 1 of 3
console.log(result.details);
// ["PASS: What does the triple equals compare?", "FAIL: ...", "FAIL: ..."]

The design is deliberately simple. Each entry has a question and the answer you expect, and the checker is deliberately forgiving, because a self-test should tell you that you did not remember something, not grade your phrasing. The details array gives you a list of what to go and revise.

Two ways to make it more useful. Put the questions in a file you can add to every week, so the set grows and you can see the same topic come back until it sticks. And keep a second set for the questions you got wrong, because those are the ones worth repeating.

The pairing that makes it stick is to write the answer down from memory before you check it. Reading the answer teaches you nothing, and the whole point is that you produce it yourself. If you cannot remember it, that is the question to revise, and it will come back again next week.

The point of a revision helper is that it picks something you have not looked at recently, so you do not keep reviewing what you already know.

// A revision list you can shuffle and quiz yourself on.
const topics = [
  "closures",
  "the event loop",
  "prototype chain",
  "promise microtasks",
  "optional chaining",
];

const nextTopic = (list, seen = []) => {
  const fresh = list.filter((topic) => !seen.includes(topic));
  if (fresh.length === 0) return null;
  return fresh[Math.floor(Math.random() * fresh.length)];
};

console.log(nextTopic(topics));                  // one of the topics
console.log(nextTopic(topics, ["closures"]));    // never "closures"

// Work through the whole list once, then start again.
const seen = [];
let topic = nextTopic(topics, seen);
while (topic) {
  console.log("revise:", topic);
  seen.push(topic);
  topic = nextTopic(topics, seen);
}
console.log("round complete:", seen.length, "topics");

The seen list is what makes it a spaced-repetition tool rather than a random picker. Once you have revised a topic in a round it is excluded, so a full pass covers everything before anything comes round again. When the list is exhausted the helper returns nothing, which is your signal to start the next round.

To make it genuinely spaced, keep two lists. One for topics you keep getting wrong, which comes up every round, and one for topics you are comfortable with, which comes up less often. The simplest version of that is to move a topic to the front of the list after you get it wrong.

One practical tip that pairs well with this. Write the answer out in full, in your own words, and include one example. The act of writing it is what makes it stick, and the example is what tells you whether you actually understood it or only recognised the words.