JavaScript Practice Test: 120 Questions with Explanations

JavaScript assessments are less about syntax than people expect. The questions that decide the outcome are about the runtime — what the event loop does next, what a closure captured, what a comparison coerces to. This is a full practice bank covering the areas those tests actually weight.

A note on what this is. These are original practice questions, not a copy of any actual exam. Real test questions are confidential, and sites that publish them get taken down. Every question here carries an explanation of why the answer is right, which is the part that transfers to the next question you have not seen.

What actually gets tested

Across freelance-platform assessments and technical screens, the same clusters come up:

• Closures and scope. The var-in-a-loop question, the Temporal Dead Zone, and whether const makes an object immutable. It does not — it prevents reassignment, not mutation.
• The event loop. Given four log statements across sync code, a timer and a promise, put them in order. Microtasks drain completely before the next macrotask, and that one rule answers most of these.
• Coercion and equality. The falsy list, == versus ===, Object.is, and why ?? exists when || was already there.
• this binding. Almost always framed as a method extracted from its object and called bare. Arrow functions have no own this, which is the fix and also the trap.
• Async correctness. Not just the syntax — whether anawait inside a loop is a bug, and what try/catch does and does not catch.

What is covered

120 questions across 13 topics, every answer explained.

Promises and the event loop together account for the largest share, which matches where assessments put their weight. If you only have time for two sections, make them those.

The eight that trip people up

Each of these appears in some form on nearly every JavaScript assessment. If you can answer all eight cold, you are in good shape.

1. 1setTimeout(fn, 0) does not run next.The whole microtask queue drains first. Promise callbacks always beat a zero-delay timer, which is why A D C B is the answer to the ordering question that appears on nearly every assessment.
2. 2A var loop with setTimeout logs 3 3 3.One function-scoped binding is shared by every callback. let creates a fresh binding per iteration and logs 0 1 2 — the single most-tested closure behaviour there is.
3. 3typeof null is "object".A bug from the first version of the language, kept for backward compatibility. Checking for null needs x === null explicitly.
4. 4[10, 9, 1].sort() gives [1, 10, 9].The default comparator stringifies before comparing, so "10" sorts before "9". Numeric sorting always needs sort((a, b) => a - b).
5. 5NaN === NaN is false.The only value in the language not equal to itself. Test with Number.isNaN, not the global isNaN, which coerces first.
6. 6A newline after return returns undefined.Automatic semicolon insertion terminates the statement, making the object literal below it unreachable. The opening brace must be on the same line.
7. 7Destructuring defaults ignore null.They apply only to undefined, so const { a = 5 } = { a: null } gives null. Same rule as default parameters, and the same rule ?? follows.
8. 8Spread is a shallow copy.{ ...user } copies the top level only; user.address is still shared by reference. This is the origin of a large share of React state bugs.

If you are really preparing for React

Most React assessment failures are JavaScript failures in disguise. The stale-closure bug in a useEffect is the var-in-a-loop question. Why React.memo fails on an inline arrow is reference equality. Why spreading state does not prevent a mutation bug is that spread is shallow. Working the JavaScript bank first tends to raise the React score more than drilling React does.

How to use this bank

Work through it in study mode first — answer, read the explanation, move on. Do not grade yourself yet. Filter to one topic at a time so you are building a model rather than sampling trivia.

Then do a timed run at roughly 30 seconds per question. That is the real test condition, and it is where the difference between recognising an answer and recalling it shows up.

Anything you miss twice, go read the MDN page for it rather than re-reading the explanation. The explanation gives you that answer; the docs give you the model that generates the next one.