JavaScript interview questions

The event loop, which is near-guaranteed

You will be shown code mixing `setTimeout`, promises and synchronous logging and asked for the output order. The model to hold: all synchronous code runs first, then the microtask queue drains completely (promise callbacks), then one macrotask runs (timers), and the cycle repeats.

• `setTimeout(fn, 0)` does not run immediately - it queues a macrotask.
• `Promise.then` callbacks are microtasks and jump ahead of any pending timer.
• `async`/`await` is promise machinery - everything after an `await` is effectively a `.then` callback.
• A long synchronous loop blocks everything, including rendering. Saying so shows you understand why this matters.

Closures and scope

• Define a closure and give a practical use - a counter, a module pattern, or memoisation.
• The `var` in a loop problem, why `let` fixes it, and what block scoping actually changed.
• Hoisting - what is hoisted, what the temporal dead zone is, and why `let` throws where `var` gives `undefined`.
• Write `debounce` and `throttle`, and explain which you would use for a search box against a scroll handler.

this, prototypes and objects

• What `this` refers to in a normal function, an arrow function, a method, and a detached method passed as a callback.
• `call`, `apply` and `bind` - and why `bind` is used in older class components.
• Prototypal inheritance, and what `class` syntax is doing underneath.
• Shallow versus deep copy, and why spreading a nested object shares the inner references.
• Equality - `==` coercion rules, and why most codebases standardise on `===`.

Practical questions

Expect at least one small implementation: flatten a nested array, implement `Array.prototype.map`, write a function that retries a promise, or build a simple event emitter. These are closer to the job than trivia and are increasingly how front-end loops are run - the component-building round is covered in frontend interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and honesty about what you have not done reads better than bluffing.
• Mid-level: the same ground, plus a feature you shipped to real users. Expect follow-ups asking why you made a particular choice rather than whether you know the syntax.
• Senior: bundle size, module systems, and why a dependency choice mattered. At this level the language questions get shorter and the judgement questions get longer.

Whatever the level, the reliable way to prepare is to say your answers out loud rather than reading them. Most of what candidates lose in a JavaScript interview is lost in the gap between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common JavaScript interview questions?

Closures, the event loop and output ordering with setTimeout and promises, `this` binding across function types, prototypal inheritance, and implementing debounce or throttle from scratch. An output-order question is close to guaranteed.

How do you explain the event loop in an interview?

Synchronous code runs first, then the microtask queue drains completely - promise callbacks - then a single macrotask such as a timer runs, and the cycle repeats. That model answers almost every output-ordering question you will be given.

What is the difference between a normal function and an arrow function?

Arrow functions do not have their own `this`; they inherit it from the enclosing lexical scope. That is why arrow functions are convenient in callbacks and wrong as object methods when you need `this` to refer to the object.

Do JavaScript interviews still ask about prototypes?

Yes, though usually framed through `class` syntax - what it desugars to, and how inheritance resolves through the prototype chain. You rarely need to write prototype manipulation by hand any more.