Need help preparing for upcoming JavaScript interview

General
1

I have a JavaScript developer interview coming up and I’m not sure which topics and questions I should focus on to get ready. I know the basics, but I’m worried I’ll miss modern concepts like async/await, closures, prototypes, and common coding challenges. Can someone share key JavaScript interview questions, must-know concepts, and any practical tips or resources to help me prepare effectively and feel more confident?

2

Focus on what interviewers actually ask about, not everything you ever saw in a JS book.

Core language

  1. Types and coercion
  • typeof quirks: typeof null == ‘object’, arrays are objects.
  • == vs ===, truthy / falsy.
  • Example: == 0, ‘’ == 0, == ‘’ all true.
    Be ready to explain why, not only the result.
  1. Scope, closures, this
  • var vs let vs const, function scope vs block scope.
  • Classic closure example: a loop with var that logs 5,5,5,5,5 and how to fix with let or IIFE.
  • this in:
    • function foo() {}
    • obj.method()
    • constructor with new
    • arrow functions capturing outer this.
      Have 1 or 2 real examples ready, like a click handler using this vs an arrow.
  1. Prototypes and classes
  • How prototype chain works: obj.proto, Object.getPrototypeOf, Function.prototype.
  • How class is syntax sugar over constructor + prototype.
  • Explain how method lookup works when you access obj.someMethod.

Async stuff
4) Call stack, event loop, tasks

  • Macrotask vs microtask: setTimeout vs Promise.then.
  • Example question:
    console.log(1)
    setTimeout(()=>console.log(2))
    Promise.resolve().then(()=>console.log(3))
    console.log(4)
    Answer: 1,4,3,2 and explain why.
  1. Callbacks, Promises, async/await
  • Know how to create a Promise manually: new Promise((resolve, reject) => { … }).
  • .then, .catch, .finally chaining.
  • Convert callback style to Promise, then to async/await.
  • Try/catch with async/await, plus error bubbling.
  • Example: write a function fetchUser then fetchPosts and handle errors.

Browser and DOM
6) DOM basics

  • querySelector, addEventListener, event delegation.
  • Event bubbling vs capturing.
    They love to ask: how to handle click on list items with one listener on parent.
  1. Fetch and API handling
  • fetch, handling JSON, HTTP errors.
  • Example pattern:
    const res = await fetch(url)
    if (!res.ok) throw new Error(‘…’)
    const data = await res.json()

Modern language features
8) ES6+ syntax

  • Destructuring arrays and objects.
  • Spread and rest.
  • Arrow functions and when not to use them, like as methods that need their own this.
  • Template literals.
  • Default parameters.
  1. Modules
  • import / export default / named exports.
  • How bundlers or modern browsers load modules.
    You do not need webpack internals, but you must know syntax and basic behavior.

Data structures and algorithms lite
10) Array and object ops

  • map, filter, reduce, find, some, every.
  • Mutating vs non mutating methods.
    Be ready to solve a small task like “group users by role” or “sum prices” with reduce.
  1. Common coding tasks
  • Reverse string or array.
  • Remove duplicates from array using Set or filter + indexOf.
  • Debounce and throttle concepts, at least be able to talk through them.

Async patterns and pitfalls
12) Common async bugs

  • Forgetting await inside async function.
  • Using forEach with async and expecting order, use for..of or Promise.all instead.
    Know how to explain Promise.all and Promise.race in plain language.

Tooling and runtime
13) Browser vs Node

  • Global object window vs global.
  • require/module.exports vs import/export in modern Node.
    They might ask how you run code, test snippets, use devtools.

Behavioral but JS flavored
14) Testing and debugging

  • Console debugging patterns.
  • Basic unit test style: describe, it, expect. Even if you do not know Jest deeply, know the idea.

Prep plan for a few days
Day 1

  • Revisit scope, closures, this, prototypes.
  • Implement a few closure examples from memory.

Day 2

  • Event loop, Promises, async/await.
  • Do 5 small tasks with fetch or mock async functions.

Day 3

  • Array methods practice on random problems.
  • DOM event delegation example.

Day 4

  • Do timed mock questions, write on paper or in a simple editor, no autocomplete.
  • Explain each answer out loud like you talk to an interviewer.

Target questions you should answer without hesitation

  • Explain closure and give an example.
  • Explain how this works in different contexts.
  • Explain how prototype chain works.
  • Order of logs with setTimeout and Promise.then.
  • Difference between async/await and .then.
  • Difference between var, let, const.
  • How to stop event bubbling or use delegation.
  • How to handle errors with async/await.

If you can explain those cleanly and write simple code for each, you are in good shape for a JS dev interview.

3

@nachtdromer covered the “what” really well, so I’ll pile on more of the “how you’ll be tested” side and a few gaps.

  1. Don’t just study JS in isolation
    Most interviews sneak JS into 3 types of tasks:

  • Bug hunting:
    “Here’s some code, why is it logging undefined?”
    Practice reading code snippets and explaining:

    • what runs first
    • what each variable’s value is at each step
    • what this is at that specific line

  • Refactor questions:
    Take a callback-hell function and refactor it to Promises, then to async/await. Interviewers love to see if you can keep behavior the same while changing style.

  • Design-ish questions:
    “Implement a tiny event emitter,”
    “Implement a simple memoize(fn),”
    “Create a function that returns an API client with methods using closures.”
    These test if closures, this, and prototypes are more than buzzwords for you.

  1. Practice explaining, not just coding
    A lot of candidates know the answer but fail to communicate it. Pick a few key topics and rehearse short, clean explanations:

  • Closure explanation template:
    “A closure is when a function keeps access to its outer scope even after that outer function has finished. For example, makeCounter returns a function that still can see count and update it.”

  • this explanation template:
    “In JS, this is decided by how a function is called, not where it is written. For regular functions:

    • as a method: obj.method() → this is obj
    • as a plain call: func() → this is global (or undefined in strict)
    • with new: this is the new instance
      Arrow functions capture this from the surrounding scope and never rebind it.”

If you can explain like that concisely, you’ll look a lot stronger than someone who just mumbles “eh, lexical environment something”.

  1. Be opinionated about features
    Interviewers often poke your judgment, not just your knowledge:
  • When wouldn’t you use an arrow function?
  • When do you prefer for..of vs map?
  • When would you use Promise.all vs loop with await?

Have 1‑sentence opinions, even if they’re not perfect. Silence is worse than a reasonable stance.

  1. Fill in a couple of gaps I didn’t see stressed enough

  • Error handling patterns
    Everyone knows try/catch, fewer can talk about:

    • wrapping async calls into a shared helper like const [err, data] = await to(promise) style
    • what happens if you forget return in a .then chain
    • difference between rejected promise vs thrown error in async functions

  • Immutability / reference behavior
    They might hit you with:

    • why const obj = {} still lets you change properties
    • how array/object references behave when passed to functions
    • shallow vs deep copy with spread or Object.assign

  • Performance-ish questions
    Basic awareness:

    • why map over massive arrays inside repeated renders might be an issue
    • why querySelectorAll in a tight loop can be expensive
      They don’t need micro-optimizations, just that you’re not totally oblivious.
  1. How to actually prep in a short time

Instead of re-reading docs, do this:

  • Timed drills
    25 minutes each on:

    • closures / this / prototypes code-writing
    • async (Promises + async/await)
    • array methods + small transforms
      Every drill, force yourself to say out loud what the code is doing.

  • Rebuild small utilities from scratch
    Implement from memory (no copy/paste):

    • a debounce(fn, delay) function
    • a tiny pub/sub or event emitter with .on, .off, .emit
    • a function that wraps fetch and always returns parsed JSON or throws a nice error

These are like mini-interview problems in disguise.

  1. Mindset during the interview
  • Narrate your thinking: “Right now this should be the button element, but if we change this to an arrow function, it will capture this from the outer scope, which is the window, so it breaks.”
  • If you forget syntax, reconstruct it instead of panicking: “I’m blanking on exact syntax, but I know Promise.all takes an array of promises and returns a single promise that resolves to an array of results, or rejects if any fail.”
  • Admit edge cases you’re not sure about, then reason through them from first principles. That honestly looks better than guessing.

Last thing: don’t try to cram every modern feature. You’ll get more mileage from being razor sharp on:

  • closures
  • this
  • prototypes / classes
  • event loop ordering
  • Promises & async/await
  • array methods

than from half-remembered knowledge of every obscure ES proposal.

4

Skip trying to cover everything and instead prep in “layers” so you can handle both basic and sneaky questions.

Layer 1: Mental models, not trivia

Where I slightly disagree with @viajantedoceu / @nachtdromer: they’re right on topics, but if you just memorize their bullet lists, you’ll freeze when the interviewer twists the problem.

Build mental models:

  • Execution model:
    Think in terms of:

    • “What frame is on the call stack right now?”
    • “What variables are in scope at this line?”
    • “Is this line sync or async, and when will it actually run?”

    If you can narrate a snippet step by step, you’ll auto-handle questions on hoisting, closures, this, event loop timing, etc., without memorizing niche facts.

  • Data-flow > syntax:
    When asked something like “refactor callbacks to async/await,” focus on:

    1. What input goes in.
    2. Where control flows after each async step.
    3. Where errors should end up.

    Once you see the flow, you can rebuild the syntax you forget.

Layer 2: Connect topics into realistic tasks

A lot of interviews don’t say “Explain closures.” They say something like:

“Build a small search box that fetches suggestions as you type, but don’t spam the API.”

That actually tests:

  • Closures (the debounce or throttle logic)
  • Async (fetch / Promises / async/await)
  • DOM events (input event, listeners, maybe delegation)
  • Error handling (what if fetch fails)

So instead of random exercises, practice 2 or 3 “mini features” that chain concepts:

  1. Debounced search box

    • Input listener
    • Debounce function
    • fetch with async/await
    • Basic error handling & UI update

  2. Tiny in-memory “API client”

    • Function that takes base URL and returns an object with methods
    • Methods use closures for base URL and default options
    • Uses fetch with async/await, throws on !res.ok

  3. Simple event emitter

    • Tests your understanding of objects, arrays, closures, possibly classes

Those three cover a surprising chunk of what frontend JS interviews poke at.

Layer 3: Practice “why,” not just “what”

Interviewers love follow-ups like:

  • “Why would you use let here instead of var if they both work?”
  • “Why not an arrow function for this method?”
  • “Why Promise.all here instead of a for loop with await?”

Have short, opinionated answers ready such as:

  • “I use let or const because I want block scope and to avoid accidental re-declaration. Here the variable changes, so let fits.”
  • “For object methods where this should refer to the instance, I prefer a regular function to avoid lexical this from an arrow.”
  • “If I need all results and can run calls in parallel, Promise.all is better. I only use sequential await when there’s a real dependency.”

@viajantedoceu and @nachtdromer already gave a strong catalog of what to know. Turn that into opinions so you sound deliberate instead of guessing.

Layer 4: Know your weak spots and say it well

You will probably get one area you’re shaky on. You can still pass if you handle it cleanly:

  • Admit limits:
    “I haven’t used Proxy much in production, but from what I know it lets you intercept operations on objects like get/set and define custom behavior. I’d look up common handler traps before using it seriously.”

  • Then relate to what you do know:
    “Conceptually it reminds me of wrapping an object with getter functions instead of exposing it directly, but with more control at the language level.”

This is way better than bluffing.

About ’ (pros & cons & when it helps)

If you are using a structured prep resource like ', treat it as a drill book, not a substitute for actual coding:

  • Pros

    • Keeps topics organized so you do not forget modern pieces like async/await, closures, prototypes and modules.
    • Often comes with targeted questions that mirror what interviewers ask, which is great for quick review sessions.
    • Can surface less obvious things such as event loop order, Promise utilities, and array method edge cases.

  • Cons

    • Easy to fall into passive reading instead of writing and running code.
    • May lean into breadth over depth, which is risky if you only have a few days.
    • Some products overemphasize trick questions that you barely ever see in real interviews.

Use something like ’ for 30–45 minutes of focused review, then immediately code a small example for 2 or 3 items you just read. That pairing locks it in.

How to use what others posted without drowning

  • Take @viajantedoceu’s and @nachtdromer’s lists and create:
    • 5 “I must nail these” topics
    • 5 “I know these decently”
    • 3 “I’ll just be passable here”

For most JS dev interviews, a good “must nail” set is:

  1. Closures & scope
  2. this in different call contexts vs arrow functions
  3. Event loop / microtasks vs macrotasks
  4. Promises & async/await with error handling
  5. Array methods for data transforms

Then, instead of cramming more topics, rehearse explaining each aloud and writing 1 short code snippet per topic from scratch.

That mix of clear mental models, a handful of realistic mini features, strong “why” answers, and selective use of a resource like ’ puts you in a much better place than trying to memorize every modern keyword.