JavaScript Questions — User Guide

A self-paced quiz catalogue of 155 advanced JavaScript multiple-choice questions, each followed by a worked-out answer explanation. The canonical English edition is maintained by Lydia Hallie, and 22 community-led translations mirror it into Arabic (Modern Standard and Egyptian colloquial), Bosnian, Chinese (Simplified and Traditional), Dutch, French, German, Indonesian, Italian, Japanese, Korean, Polish, Portuguese (Brazilian), Romanian, Russian, Albanian, Spanish, Thai, Turkish, Ukrainian, and Vietnamese.

This is not a software package. There is nothing to install, build, or run. The product is the content: 155 carefully crafted "what's the output?"-style puzzles that probe the corners of the language — hoisting, scope, coercion, prototypes, async, generators, iterators, modules, getters/setters, tagged templates, and a long tail of one-off curiosities.

Note

The repository was created in 2019. The questions reflect JavaScript syntax and behaviour at that time. Modern features added since (top-level await, private class fields with #, logical-assignment ??=/||=/&&=, the at() array method, and so on) are not represented. This is intentional — the question numbering is stable so individual items can be referenced by number across all 22 translations without churn.

Table of Contents

1. Quick Start
2. What This Repository Is (and Isn't)
3. Reading a Question End-to-End
4. The Question Formats You'll Encounter
5. Topic Coverage Across the 155 Questions
6. Choosing a Translation
7. Recommended Study Workflows
8. Reading Offline or on the Go
9. Working Through the Code Examples
10. Known Content Issues and Errata
11. Contributing an Improvement
12. License and Reuse
13. Frequently Asked Questions
14. Reference

1. Quick Start

The fastest path from "I just heard about this" to "I've answered my first question":

On GitHub

1. Open github.com/lydiahallie/javascript-questions.
2. Click README.md in the file list, or just scroll down on the repository landing page.
3. The first question loads inline. Read the code block.
4. Pick A, B, C, or D in your head — don't peek.
5. Click the Answer disclosure triangle to expand the explanation.
6. Scroll to question 2 and repeat.

On a Local Clone

git clone https://github.com/lydiahallie/javascript-questions.git
cd javascript-questions

Cloning into 'javascript-questions'...
remote: Enumerating objects: ...
Resolving deltas: 100%

Then open README.md (or one of the locale READMEs) in any GFM-aware viewer — VS Code, Obsidian, glow, grip, mdcat, or your preferred markdown reader.

Tip

If you just want the questions in your native language, jump straight to Section 6 — Choosing a Translation. The English edition is the source of truth for question numbering, but several translations (Russian, Korean, Italian, Romanian, Vietnamese, Indonesian, Chinese Simplified/Traditional, Spanish, Albanian) cover all 155 items.

What you'll need

• [x] A web browser, or any markdown viewer that renders GitHub-Flavoured Markdown (collapsible <details> blocks specifically — that is how every answer hides until you click).
• [x] A working knowledge of basic JavaScript syntax (var/let/const, functions, objects, arrays, console.log).
• [x] About 8–12 hours of total reading time if you do all 155 in one pass; far longer if you actually try to predict every output before peeking.
• [ ] Optional: a JavaScript REPL (browser DevTools console, Node.js, or bun repl) for verifying surprising answers by running the snippets yourself.

A 60-second sample

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

sayHi();

The choices are:

• A: Lydia and undefined
• B: Lydia and ReferenceError
• C: ReferenceError and 21
• D: undefined and ReferenceError

The expected answer is D. The point isn't whether you got it right; the point is that the explanation walks you through var/let hoisting and the temporal dead zone in three short paragraphs — exactly enough to fix the concept in your head without a textbook detour. Every one of the 155 entries follows that same shape.

2. What This Repository Is (and Isn't)

What it IS

A single static markdown document (per language) containing 155 numbered questions about JavaScript behaviour. Each question is a small, runnable snippet of code followed by four lettered options (A–D, occasionally with a longer or shorter set when the question takes a different shape) and a hidden explanation. The questions are designed to:

• Reveal non-obvious language semantics (what does [] == ![] evaluate to, why does typeof null return "object", how does prototype lookup interact with Object.create(null)).
• Reinforce mental models for the runtime (event loop, hoisting, closure, scope chain, this binding).
• Mirror the kind of trick questions that appear in front-end coding interviews.
• Be self-contained: every snippet runs as-is in any modern browser console, with no imports, no setup, and no external state.

What it ISN'T

• Not a tutorial. It assumes you already know the basics and uses the questions as a discovery surface for edge cases. If var vs let is brand new, start with MDN's JavaScript guide first.
• Not a runnable application. There is no package.json, no build, no test runner. Questions are read, not executed (though you can copy/paste any snippet into a console).
• Not a complete reference. The 155 items are a curated set, not exhaustive coverage of the spec. Whole feature areas (regex, Intl, BigInt, top-level await, decorators, the ?. and ?? operators) are touched lightly or not at all.
• Not certified or graded. There's no scoring, no leaderboard, no completion certificate. You read until you stop.

Important

The questions are based on JavaScript circa 2019. A handful of answers depend on quirks that newer language features (e.g. private class fields, logical-assignment operators) would let you sidestep entirely. Treat the explanations as historical / interview-prep material, not as "the modern way to write JavaScript."

Numbers at a glance

3. Reading a Question End-to-End

Every question follows the same six-part structure. Recognising it lets you skim quickly when you want a refresher and slow down when you want to actually learn.

1. Heading — ###### N. Question text? where N is 1–155. The ###### (H6) heading keeps each item visually subordinate so the README reads as one long catalogue rather than 155 mini-documents.
2. Code block — a fenced ```javascript block with the snippet to evaluate. Always self-contained. No imports, no globals you didn't see.
3. Options — bulleted list of two to six lettered choices (A, B, C, D, occasionally E/F). Each option is wrapped in inline backticks so you can compare exactly what would print.
4. Disclosure trigger — <details><summary><b>Answer</b></summary> (or the localised equivalent: "Antwort", "答え", "정답", "Cevap", etc.). Click it to expand.
5. Verdict line — #### Answer: X where X is the correct letter. This is the H4 inside the disclosure.
6. Explanation — usually 1–4 short paragraphs. Sometimes contains an extra inline code block to illustrate an intermediate evaluation step or a related counter-example.

Tip

On GitHub, you can deep-link to a specific question. Hover over the ###### heading and the anchor link icon appears — copy that URL and you have a permalink like …/README.md#1-whats-the-output you can drop into a study group chat.

How long should each question take?

• Easy questions (1–10 seconds): straight var hoisting, simple console.log of a known value, one-line falsy-check questions like #35.
• Medium questions (30–60 seconds): event-loop ordering, prototype chain lookups, coercion edge cases.
• Hard questions (2–5 minutes): generators with yield*, getter/setter side effects, regex with named groups, tagged template literals where the template strings array also has expression slots.

If you find yourself spending more than five minutes on a single question, read the answer. The point of the catalogue is breadth-of-exposure, not endurance.

4. The Question Formats You'll Encounter

Although the headings make every entry look identical, there are actually six recurring question patterns. Knowing which pattern you're in front of cues you to the right reasoning strategy.

4.1 "What's the output?" (the workhorse format)

The vast majority of items — including questions 1, 2, 3, 4, 6, 7, 8, 9, 11, 12, and 100+ others — ask you to predict the exact console.log output of a snippet. You compare the result against four labelled alternatives.

Strategy: mentally execute the snippet line by line, paying attention to execution context creation (hoisting), scope resolution, and type coercion.

4.2 "What is the value of X?"

Some questions strip away console.log and ask directly for the resulting value of a binding — for example #21 What's the value of sum?, #49 What's the value of num?, and the #100–#103 cluster ("What's the value of output?").

Strategy: trace assignments. The snippet often involves a closure or accumulator; the trick is usually whether a value was captured by reference or by value.

4.3 Truthy / falsy / "which is true" predicates

Questions like #5 Which one is true? and #35 Which of these values are falsy? swap the per-option console.log strings for predicate statements. You're not predicting output — you're picking which of several claims about JavaScript is correct.

Strategy: read each option as a standalone assertion and disqualify each one by counter-example.

4.4 "Which method/operation does X?"

Items like #108 Which of these methods modifies the original array?, #115 Which method(s) will return the value 'Hello world!'?, and #117 Which of the following options will return 6? flip the polarity. The snippet is the goal, and the options are competing implementations.

Strategy: mentally apply each option and reject those whose return type, mutation behaviour, or argument count is wrong.

4.5 "What happens when…?" / behaviour-classification

Questions such as #10 What happens when we do this?, #13 What are the three phases of event propagation?, and #114 What will happen? ask you to describe the runtime's behaviour qualitatively rather than name a literal output. Options usually spell out short English sentences ("Throws an error", "Logs and continues", "Silently returns undefined").

Strategy: identify the error-throwing path vs. the silent-coercion path vs. the happy path for the snippet.

4.6 True / false statements

A small number of questions (e.g. #14 All object have prototypes, #26 The JavaScript global execution context creates two things…, #39 Everything in JavaScript is either a…, #77 Is this a pure function?) are structured as a single declarative claim followed by - A: True / - B: False alternatives, sometimes with a third "depends" option.

Strategy: look for the universal quantifier (all, every) and find the counter-example. If you can't, the statement is probably true — but check the explanation for nuance.

Note

Question phrasings drift slightly between numbers 1 and 155 — early items use "What's the output?" contractions, later items use "What is the output?" fully spelled out. The semantics are identical; the spelling difference reflects edits and re-edits over the catalogue's life. Don't read a meaning into the difference.

4.7 Distribution of correct answers (English edition)

If you find yourself reflexively picking the same letter every time you don't know, the underlying distribution will surprise you:

C is the most common right answer; D is the least. This is not a guide to gaming the quiz (there is no scoring), but it is a useful sanity check if you've been over-relying on one letter. The skew is also a quirk worth knowing if you fork the catalogue into a graded quiz app — the letter labels are not a uniformly distributed source of randomness.

5. Topic Coverage Across the 155 Questions

The questions are not explicitly grouped by topic — they are roughly chronological in the order Lydia added them. Issue #714 (closed) was a community feature request asking for a topic-wise rearrangement; the maintainer kept the original order to preserve question numbering for cross-translation references. The implicit topic distribution looks like this:

Note

These percentages are approximate — the catalogue is not formally tagged. Treat the table as a rough heat map so you can decide whether the next question you read will reinforce the topic you're working on, or take you somewhere new.

What is not covered

If you came here to drill these specific topics, you'll need a different source:

• Regex beyond a single short example (the /.+\@.+\..+/ literal in #154).
• Intl / locale APIs.
• BigInt arithmetic.
• Top-level await (added to ECMAScript modules in 2020).
• Private class fields (#name).
• Logical-assignment operators (||=, &&=, ??=).
• Optional chaining (?.) and nullish coalescing (??) — touched lightly at most.
• WeakRef, FinalizationRegistry, error cause chaining.
• Web APIs beyond the very basics of setTimeout, setInterval, and DOM event propagation. There are no questions on fetch, Service Workers, IndexedDB, or the Streams API.
• Node.js-specific APIs. Snippets are vanilla JavaScript and never require() or import anything.

This boundary is intentional. The catalogue is language-level, not platform-level, and frozen at the 2019 spec snapshot.

6. Choosing a Translation

Twenty-two community-led translations live next to the English README, each in a locale-coded directory. Coverage varies dramatically because translations are voluntary and incremental — the 155-question English edition keeps growing, and translators keep up at different rates.

6.1 Coverage matrix

Tip

If your native language has a partial translation, read it for the questions it covers and fall back to the English edition for higher-numbered items. Question numbers are aligned across translations precisely to make this fallback frictionless. Question 100 is question 100 in every translation that reached it.

6.2 Translation flavour notes

• Arabic (Modern Standard) ar-AR uses right-to-left rendering (<div dir='rtl'>) and replaces the standard ###### heading style with bold-numbered prose (1. ماهو الناتج؟). Code blocks remain LTR. Question numbering is preserved. The ar-AR edition is one of the older translations; some questions are paraphrased rather than translated word-for-word.
• Arabic (Egyptian colloquial) ar-EG is a separate translation in Egyptian dialect, not Modern Standard Arabic. Different audience, different translator. The two Arabic editions are not interchangeable.
• Chinese Simplified zh-CN vs Chinese Traditional zh-TW are separate translations; the Traditional edition has slightly higher question coverage (155 vs 150 at the documented commit).
• Romanian ro-RO uses the unique filename README.ro.md — note the .ro.md suffix. GitHub still renders it because it ends in .md, but tools that hard-code README.md discovery will miss it.
• Spanish es-ES, French fr-FR, Bosnian bs-BS and several others use locale-suffixed filenames (README-ES.md, README_fr-FR.md, README-bs_BS.md) rather than a plain README.md. The locale directory's README.md file is not present for those locales. Section 6.3 of the Admin Guide explains the convention.
• Thai th-TH uses the canonical filename README.md even though the master English README's translation index points to ./th-TH/README-th_TH.md. The link in the master index is stale — see Section 10 (Known Content Issues).

6.3 Picking your edition

Decision tree for "which edition should I read":

1. Want the most up-to-date material? → English README.md at the repo root.
2. Want full coverage in your language? → If your language is in the 100% / 99% / 98% / 97% group (Italian, Korean, Romanian, Russian, Albanian, Chinese Traditional, Indonesian, Vietnamese, Chinese Simplified), use it.
3. Your language has partial coverage? → Use the localised edition for the questions it covers; switch to English for higher-numbered ones.
4. Studying for an English-speaking interview? → Use English regardless of native language. Interview questions tend to phrase things the way the canonical edition does.
5. Studying with a friend who speaks a different language? → Question numbers are aligned. You can each read in your own language and discuss "Question 47" without ambiguity.

7. Recommended Study Workflows

7.1 The "passive read-through" workflow

Best for: refreshing your JavaScript before an interview, deciding whether to deep-dive on a topic, or just satisfying curiosity.

1. Open the README of your chosen edition.
2. Read the question; spend at most 15 seconds trying to predict the output.
3. Click Answer regardless of whether you guessed right.
4. Read the explanation once. Don't re-read.
5. Move on. Aim for ~30 questions per hour. The whole 155-question English edition fits in 5–6 sittings of an hour each.

You will not retain everything from a passive read-through, but you will surface the topics where your mental model is wrong, which is most of the point.

7.2 The "explain it back" workflow

Best for: actually learning the material rather than vibing past it.

1. Read the question.
2. Predict the output and write down your one-sentence reasoning, not just the letter.
3. Click Answer and compare your reasoning to the explanation, not just the letter.
4. If your reasoning was wrong (even when the letter was right), make a note of which concept tripped you up.
5. After every 25 questions, review your notes. Group similar mistakes.

This is roughly twice as slow as Workflow 7.1 but ~3× more retention.

7.3 The "verify-by-running" workflow

Best for: the moment you don't believe the explanation.

1. Open your browser's DevTools console (or node / bun repl).
2. Paste the snippet as-is — every snippet is self-contained and will run in isolation.
3. Confirm the output.
4. Mutate the snippet to test variations: change var to let, swap == for ===, replace setTimeout(…, 0) with Promise.resolve().then(…) and observe the order shift.
5. Re-read the explanation in light of what you observed.

Caution

A handful of questions involve non-standard ordering (event loop microtask vs macrotask interleaving) where Node.js and browser environments behave subtly differently — the setTimeout(fn, 0) ordering vs process.nextTick, for instance. If your local result disagrees with the README's stated answer, suspect the runtime environment before you suspect the question.

7.4 The "interview-prep sprint"

Best for: a coding interview is in 2–7 days.

• Day 1: Questions 1–30. Focus on hoisting, scope, closures. These dominate junior/mid interviews.
• Day 2: Questions 31–60. Event loop, this binding, prototype chain.
• Day 3: Questions 61–90. Promises, async/await, generators. Senior interviews lean here.
• Day 4: Questions 91–120. Array methods, object iteration, spread/rest.
• Day 5: Questions 121–155. Modules, getters/setters, tagged templates, miscellany.
• Day 6 (optional): Re-do the questions you got wrong. By now you've also developed a sense of which topics the catalogue itself emphasises, which loosely tracks what interviewers ask.
• Day 7: Take a break. Sleep is more useful than another 20 questions.

7.5 The "translation-pair" workflow

Best for: bilingual learners or those teaching JavaScript in a non-English-speaking class.

1. Open both your native-language edition and the English edition side by side.
2. For each question, read it first in your native language.
3. After clicking Answer, read the English explanation as well.
4. Note any terminology mismatches — the explanation might use "side effect" / "Nebeneffekt" / "side effect" for the same concept and seeing both fixes the term in your head.

This is also a great way to spot translation drift that should be reported as a PR (see Section 11).

Tip

The most efficient way to learn a new technical vocabulary is to read material you already understand in two languages simultaneously. The catalogue's question-aligned numbering makes that frictionless here.

8. Reading Offline or on the Go

Because every edition is a single markdown file, getting the catalogue onto a phone, tablet, or laptop without internet is trivial.

8.1 As markdown

git clone https://github.com/lydiahallie/javascript-questions.git

Cloning into 'javascript-questions'...
Resolving deltas: 100%

The clone is under a megabyte (the bulk is the 22 translation files). Drop the directory anywhere, point a markdown viewer at it, and you have full offline access including all collapsible answers.

8.2 As a single PDF

GitHub renders the README to HTML; save-to-PDF from any browser produces a serviceable, if long, PDF. Browser print preview is the path of least resistance:

1. Visit the README on github.com.
2. Expand all answers first — Ctrl+F / ⌘+F for the word Answer, click each disclosure. (Yes, it's tedious; there is no "expand all" button.)
3. Print → Save as PDF. On Chrome / Edge, set destination to "Save as PDF" and "Layout: Portrait".
4. Save. Expect ~120–180 pages depending on translation.

8.3 As a Kindle / e-reader file

Tools like pandoc can convert the markdown directly:

pandoc README.md -o javascript-questions.epub --toc --toc-depth=6

[INFO] No subtitle metadata found.
[INFO] EPUB written to javascript-questions.epub

The --toc-depth=6 flag is essential because the per-question headings live at H6 (######). Without it, your e-reader's TOC will be empty.

Warning

<details> collapsibility does NOT survive the PDF or EPUB conversion. All answers will be visible all the time in your offline copy. If self-testing is the goal, read on GitHub or in a markdown editor that respects <details>.

8.4 Mirrored via npm packages and quiz apps

Several community projects mirror the catalogue into runnable quiz UIs (see issue #647 about a former URL theavocoder.com going private). Lydia maintains only the canonical markdown — third-party quiz apps are unaffiliated. Verify their question counts and last-updated dates before relying on them; they may lag the source.

9. Working Through the Code Examples

The snippets are written to be runnable as-is in any modern JavaScript engine. A few conventions are worth knowing so you can paste them into a console without surprises.

9.1 What the snippets assume

• Strict mode is OFF unless explicitly turned on with 'use strict'; at the top of a snippet. Several questions hinge on the differences between sloppy and strict mode (e.g. this defaulting to undefined vs the global object, accidental globals from undeclared assignments).
• No external libraries. Every binding the snippet uses is either a JavaScript built-in (Math, JSON, Promise, Map, Set, Symbol, console, etc.) or defined inline.
• No DOM unless the question explicitly involves DOM events (a small minority — questions on bubbling/capturing, click handlers, event.target).
• No top-level await. Async snippets always use async function wrappers because the catalogue predates module-level top-level await.

9.2 Verifying a snippet locally

The cleanest way to verify is in the browser DevTools console because that closely matches the implicit "global script" environment most snippets assume:

1. Press F12 in any browser to open DevTools.
2. Click the Console tab.
3. Paste the entire snippet.
4. Press Enter.

Node.js works for most snippets too:

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

undefined
ReferenceError: Cannot access 'age' before initialization

Both browser and Node.js produce identical results for snippets that don't depend on environment-specific timer ordering.

Note

Some questions test global object identity — in a browser script the global object is window, in Node.js it's global (or globalThis everywhere). If a snippet references window, run it in a browser console; if it references global, run it in Node.

9.3 When the snippet looks broken

If a snippet appears syntactically incomplete, that is part of the question. Snippets like let x = 1; let x = 2; are intentionally a SyntaxError — and the correct answer is exactly that. Don't try to "fix" the snippet before running it; just paste it and observe what happens.

9.4 What to do with the explanation's intermediate code

Several explanations include a second, smaller code block that walks you through how the engine evaluates a sub-expression. These are illustrative, not part of the question, and you don't need to run them — but doing so reinforces the mental model.

10. Known Content Issues and Errata

The community tracks errata in GitHub Issues. At the documented commit, the open and recently-closed bug reports of note are:

Warning

Translations may lag behind errata. When an English answer is corrected via PR, the corresponding fix has to propagate to up to 22 translation files separately. If you spot an inconsistency between your translation and the English answer, the English version is canonical and the translation is the one that needs updating.

Stale link in the master translation index

The English README.md lists the Thai translation as ./th-TH/README-th_TH.md, but the actual file in the th-TH/ directory is README.md (no locale suffix). Clicking the link from the rendered English README will produce a 404 on github.com. Workaround: navigate directly to th-TH/README.md.

How to report a new issue

1. Confirm the issue is content-related, not a viewer problem (your markdown viewer doesn't support <details>, your phone is rendering RTL Arabic in a strange way, etc.).
2. Search open issues for the question number — duplicates are common.
3. If it's genuinely new, open an issue titled Q<N>: <one-line summary> so it's discoverable. Include:
   • The exact question number.
   • The translation/edition you read (e.g. ru-RU, zh-CN, or the canonical English edition).
   • What you believe the correct answer / explanation should be.
   • A reference (MDN page, ECMA-262 section, runnable counter-example).

Issues that include a runnable counter-example are the ones most likely to get reviewed quickly.

11. Contributing an Improvement

The repository accepts pull requests for content fixes, new translations, and translation updates.

11.1 What to contribute

11.2 PR workflow

1. Fork the repo on GitHub.
2. Clone your fork locally.
3. Create a branch named for the change: fix-q42-typo, add-pl-PL-q76-q90, update-ja-JA-translation.
4. Edit the appropriate README*.md file. Do not edit multiple translations in a single PR unless the change is a coordinated errata fix; one-translation-per-PR is the norm.
5. Preview your change on github.com (push the branch and view the rendered README on your fork) to confirm:
   • Headings still render at H6 (######) for question titles.
   • The <details> block still expands (the closing </details> is present).
   • Code blocks still have the ```javascript language tag — never bare ``` because GitHub's syntax highlighting needs the tag.
6. Open a PR with a title in the form Fix Q42 typo in answer or Add Q76–Q90 to pl-PL translation.
7. In the description, link to the issue you're fixing (if there is one) using Fixes #NNN so it auto-closes on merge.

11.3 Translation-specific etiquette

• Mirror the question numbering. Question 42 in ru-RU must be the same question as question 42 in README.md.
• Translate the explanation, not just the question stem. Half-translations (translated stem, English answer) are not accepted.
• Translate the option labels for the human-readable text. Letter labels (A, B, C, D) stay in Latin script even in non-Latin-script translations because they index across languages. The Egyptian Arabic edition (ar-EG) uses Arabic letters (أ, ب, ج, د) instead — that is a deliberate locale choice for that translation.
• Keep code blocks in JavaScript. Don't translate variable names, string literals, or console.log output — those are part of the question's correctness.

Important

The maintainer (Lydia Hallie) reviews PRs at her own cadence, and the PR queue can sit for weeks at a time. Don't take a delayed merge as rejection. If a PR has been open for more than 60 days with no comment, polite bumps in the PR thread are reasonable.

11.4 Code of conduct in practice

There is no formal CODE_OF_CONDUCT.md in the repository, but the de facto norm is: be specific, be kind, cite a source. Issues and PRs that do all three get attention. Issues that are vague ("This is wrong") or aggressive get ignored.

12. License and Reuse

The repository is licensed under the MIT License, copyright © 2019 Lydia Hallie. The full text is in the root-level LICENSE file.

12.1 What MIT lets you do

• Use the questions in a commercial product.
• Modify them.
• Redistribute them, including in proprietary works.
• Sublicense.

12.2 What MIT requires

• Include the copyright notice and the license text in any substantial redistribution. A LICENSE file alongside your bundled markdown satisfies this.
• No warranty or liability — the license disclaims both. If a question is wrong and your interview candidate fails because of it, that's on you.

12.3 What the maintainer asks for (not a license condition)

The README opens with the line:

Feel free to use them in a project! 😃 I would really appreciate a reference to this repo, I create the questions and explanations…

Treat that as a strong norm, not a legal requirement. If you embed the catalogue in a quiz app, training course, internal wiki, or interview-prep service, link back to github.com/lydiahallie/javascript-questions in your credits. It costs you nothing and it sustains the project.

Caution

Re-publishing the questions as your own (no attribution, no link) is technically permitted under MIT but will earn you a justified amount of community pushback. The catalogue's value is partly in its provenance — readers want to know the questions come from a working JavaScript engineer with skin in the game, not from an anonymous content farm.

13. Frequently Asked Questions

Q: I don't see a package.json, how do I run this?

You don't. There is nothing to run. The repository is a markdown document containing JavaScript snippets — the snippets are illustrative, not part of an executable project. To "run" a question, copy its code block into your browser DevTools console or a Node.js REPL.

Q: Why are questions numbered with H6 (######) and not H2/H3?

The H6 demotion keeps each question visually subordinate to the README's overall layout, so the document reads as one long list rather than 155 mini-documents stacked together. It also means the README's table of contents (the translation index at the top) is not flooded with question links.

Q: My translation only has 43 questions but the English has 155. Is my translation broken?

It is incomplete, not broken. Most translations are voluntary and lag behind the canonical edition. See Section 6.1 for current coverage. You can read the translated portion plus fall back to English for higher-numbered questions.

Q: I disagree with the answer to question N. Who do I tell?

Open a GitHub Issue. Include the question number, your reasoning, and ideally a runnable counter-example. See Section 10 for the recommended format.

Q: Can I print this and bring it to an interview?

You can, but you won't be allowed to consult it during a real interview. The catalogue's value is in drilling before the interview, so the patterns are second nature when you face an unseen question.

Q: Are the questions ordered by difficulty?

No. They're roughly chronological — the order Lydia added them. Some early questions (1, 2, 4) are quite hard; some late questions (149, 150) are quite easy. Difficulty fluctuates throughout the catalogue.

Q: Is there an answer key without the questions?

No. The answer letters are intermixed with the questions inside <details> blocks. There's no separate "all answers" file. If you wanted one for testing purposes, grep -E '^#### Answer:' README.md would extract them in question order.

Q: Is there a quiz UI?

Several community-built quiz UIs exist; they are not part of this repository. Issue #647 references one (theavocoder.com) that has since gone private. Search GitHub for "javascript-questions quiz" to find current alternatives. Check that they reference a recent commit before trusting their question count.

Q: How do I read the Arabic / Hebrew / RTL editions correctly?

Modern markdown viewers honour the <div dir='rtl'> wrapper that the ar-AR edition uses. If your viewer shows the text left-to-right anyway, switch to a viewer with proper RTL support (GitHub itself, Obsidian, recent VS Code).

Q: Can I translate this into a language not in the list?

Yes. Open an issue first to claim the locale, then submit a PR adding a new top-level directory using the two-letter language + two-letter region convention (ko-KR, pt-BR, zh-TW, etc.). The Admin Guide section on adding a new locale walks through the directory and filename conventions.

Q: Will questions for newer JavaScript features ever be added?

Probably not in the existing 1–155 sequence (that would break translation alignment). A new sequence (Q156+) covering post-2019 features could be added; whether it will be is up to the maintainer. Expressions of interest belong in a GitHub Issue, not a PR with the questions pre-written.

Q: I'm preparing for a TypeScript interview. Is this still useful?

Mostly yes — TypeScript is a superset of JavaScript, and almost every question's runtime behaviour is identical. The catalogue does not test TypeScript-specific features (types, generics, decorators, conditional types, etc.). Use it for the JavaScript fundamentals; use a separate resource for the type system.

Q: Some explanations in the Russian translation seem wrong.

This is a known concern — see issues #820 and #827. The English edition is canonical; if the Russian explanation contradicts the English answer, the English answer is the one to trust. PRs to fix the Russian text are welcome.

14. Reference

14.1 At-a-glance facts

14.2 Locale file directory

14.3 Question-finding cheat sheet

If you remember a question vaguely but can't find it, search the canonical English README for the most distinctive token in the snippet:

grep -nE '^###### |randomValue' README.md

…
3989:###### 155. What's the output?
3994:let randomValue = { name: "Lydia" }
…

The line beginning with ###### N. is the question heading; scroll up from any matching identifier to find which numbered question contains it.

14.4 External links from the catalogue

The English README front-matter links to:

• Author's Instagram: https://www.instagram.com/theavocoder
• Author's Twitter: https://www.twitter.com/lydiahallie
• Author's LinkedIn: https://www.linkedin.com/in/lydia-hallie
• Author's blog: https://www.lydiahallie.io/

These are author-personal links, not part of the question content. They can change at any time; if a link 404s, that's a bug worth reporting (issue #647 reported one such case).

14.5 Cross-references to the Admin Guide

For deeper detail on:

• The translation directory and filename conventions, the README.ro.md exception, and the locale-discovery mechanism — see Admin Guide §6 Internationalization Implementation.
• The implicit "schema" each question follows (heading level, code-block tag, options shape, disclosure structure) — see Admin Guide §5 Question Schema.
• How a maintainer reviews new-question PRs, errata PRs, and translation PRs — see Admin Guide §7 Operations Playbook.
• Quality heuristics that distinguish a good question from a weak one — see Admin Guide §11 Quality Heuristics.
• The improvement roadmap (which issues are queued, which are out of scope) — see Admin Guide §12 Improvements Roadmap.