JavaScript Questions: twenty-two translations of a 2019 quiz

Every question is a snippet, four options and a lettered answer

The format is rigid, which is what makes the list quick to work through. Each item is a numbered heading reading "What's the output?" or "Which one is true?", followed by a fenced JavaScript block, then options A through C or D as inline code, then a collapsed details element holding the answer letter and an explanation. Question one offers a function that logs a `var` and a `let` before assigning them. Question two runs two nearly identical `for` loops that schedule `setTimeout` callbacks. Question three contrasts a method shorthand with an arrow-function property on the same object literal.

Nothing about the layout is decorative. Because the options are fixed, a reader either recognises the mechanism or guesses, and because the answer sits in a collapsed block, the exercise survives being read on a phone. The cost is that the list is a quiz format, not a reference, and there is no index from concept to question.

The questions are from 2019 and the repository says so

The first thing in the README is a note, and it is the most useful sentence in the file. The repository was created in 2019, the questions are based on the JavaScript syntax and behaviour at that time, and because the language keeps evolving there are newer features the questions do not cover. The framing is "from basic to advanced", for testing yourself, refreshing, or interview preparation.

The dates confirm the note rather than contradict it. The last push to the repository was 2024-08-04, and no GitHub releases have ever been published, so there is no version history to read and no way to tell from the file which question was added when. The consequence is specific rather than general: a candidate can answer all of these correctly and still be surprised by a language feature introduced after the questions were written, and neither reader nor interviewer can tell from the document which era any individual question belongs to. Treat the list as a test of fundamentals, not of currency.

Twenty-two translation directories and one document

The repository has twenty-four top-level entries. One is the LICENSE, one is the English README.md, and the other twenty-two are language directories: ar-AR, ar-EG, bs-BS, de-DE, es-ES, fr-FR, id-ID, it-IT, ja-JA, ko-KR, nl-NL, pl-PL, pt-BR, ro-RO, ru-RU, sq-KS, th-TH, tr-TR, uk-UA, vi-VI, zh-CN and zh-TW. Each holds its own README file, from README_AR.md to README_zh-TW.md.

That makes this a translation project that happens to have a quiz in it, and it is where the maintenance question lives. The summary line above the list advertises 20 available translations while the list beneath it contains 22 entries, which tells you the count is maintained by hand rather than generated. More importantly, a change to the English master has to be carried into twenty-two copies, and the repository shows no mechanism for doing that. The consequence for a team that reads the Chinese or Japanese version is that you cannot assume it matches the English text, and the two can differ in both questions and answers without anything in the repository flagging it.

The answers are prose, and nothing in the repository runs

There is no package.json, no test directory and no runner anywhere in the twenty-four entries. Every answer is a letter followed by a paragraph of explanation inside a collapsed block, and the expected output appears only as inline code in the option list.

That has two consequences. First, nothing verifies anything. If an explanation is wrong, or if a question's answer depends on an engine detail the author did not consider, the reader has no way to find out except by running the snippet in their own runtime, which means leaving the document. Second, grading is entirely self-assigned. In an interview the interviewer picks the questions and scores the reasoning, which is fine, and in solo practice the score is whatever the reader believes, which is weaker.

The upside is real and worth keeping in view. A short prose explanation of why a value is what it is teaches more than a passing test result does, and the collapsed format means you can read the whole list without spoiling it.

The visible set is built from the language's sharp edges

The questions that are visible concentrate on a small number of mechanisms, and they are the ones that generate real bugs. Variable hoisting and the temporal dead zone: a `var` is set up during the creation phase with the value `undefined`, while `let` and `const` are hoisted but not initialised, so touching them before their declaration throws a `ReferenceError`. Closure scope per loop iteration: because `setTimeout` callbacks run after the loop finishes, a `var` counter has already reached its final value while a `let` counter is block-scoped and gets a fresh binding each pass.

Then there is `this`. Question three defines a `diameter` method with shorthand syntax and a `perimeter` arrow function on the same object, and the answer turns entirely on the fact that `this` in an arrow function refers to its surrounding scope rather than the object, so the property read comes back `undefined` and the arithmetic yields `NaN`. The remaining visible questions cover unary coercion, where `+true` is `1` and negating a truthy string is `false`, and the difference between dot and bracket notation given that object keys are strings unless they are Symbols.

That is a quiz about edges, not a tour. It is a good filter for people who write JavaScript daily, and it will not tell you whether someone can build anything.

Hoisting and the temporal dead zone are the load-bearing pair

Two of the first questions are worth setting out together, because they teach the same distinction from opposite directions. The first declares a `var` and a `let` inside a function and logs both before assigning them:

function sayHi() {
  console.log(name);
  console.log(age);
  var name = 'Lydia';
  let age = 21;
}

sayHi();

The answer is `undefined` and then a `ReferenceError`, not because the two keywords behave differently by accident but because they differ in when they are initialised. The second question runs the same counter with both keywords and defers the read into a `setTimeout` callback:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 1);
}

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 1);
}

The callbacks run after both loops have finished, so the `var` version prints the same final value three times while the `let` version prints one value per iteration.

The consequence for a reader is that the mental model transfers. Once you can say when a binding is created and when it is initialised, most questions in this genre stop being tricks.

The arrow-function question is where the list earns its place

Question three is the one that catches people who otherwise know the language, and the code is short enough to sit in full:

const shape = {
  radius: 10,
  diameter() {
    return this.radius * 2;
  },
  perimeter: () => 2 * Math.PI * this.radius,
};

Both calls look symmetric and neither is. `diameter` is a regular function, so `this` is the object and the call returns `20`. `perimeter` is an arrow function, so `this` resolves to the surrounding scope, where there is no `radius`; the property read gives `undefined` and multiplying it produces `NaN`. Nothing throws, which is what makes it dangerous.

The consequence is a habit rather than a fact. A method written as an arrow-function property on an object literal is a mistake that type checkers do not always catch and that no linter reliably flags, and this is the question in the list that teaches you to look for it.

Editorial conclusion

JavaScript Questions is a good revision tool and a poor syllabus. The puzzles are well chosen, the explanations are short and accurate about the mechanism involved, and twenty-two languages mean it is readable in almost any team. Two limits should shape how you use it. The material describes itself as based on the syntax and behaviour of 2019 and says newer language features are not covered, so passing every question tells you about a JavaScript that no longer ships on its own. And there is nothing to run: the repository has no code, no test harness and no release, so a candidate's score is whatever they decide it is. Before relying on it, check three things: which features your own codebase uses that postdate the questions, whether the explanation for any question you dispute matches what your runtime actually does, and whether a translation you rely on has drifted from the English original.

Frequently asked questions

Official sources

1. Official README
2. Project repository