JavaScript Interview Questions for 5+ Years of Experience

If you have 5+ years of JavaScript under your belt, the bar in interviews shifts. You're expected to know the language well, but what gets you hired is judgment — knowing which tradeoffs matter in production, where the language gets weird, and how the framework you use is built on top of it.

This article covers 20 questions that come up in senior and lead engineer loops at large tech companies, plus three open-ended scenarios that test depth rather than recall.

If you're looking for additional JavaScript interview preparation materials, also check out these resources:

• Front End Interview Playbook
• Practice JavaScript coding interview questions
• Practice JavaScript quiz interview questions

Production scenario questions

Three open-ended scenarios that come up in senior loops. Unlike recall questions, there's no single right answer — what's being evaluated is how you decompose the problem.

Scenario A: A long-lived React app is leaking memory

"Your team's dashboard runs in a browser tab for 6+ hours per day. Users report it grows to ~1 GB of memory usage. Walk me through your debugging approach."

A solid answer walks through the layers:

1. Reproduce and quantify — Chrome DevTools → Memory → take a heap snapshot at startup, use the app for 30 minutes, take another snapshot. Use the comparison view to find which constructor counts grew.
2. Form a hypothesis from the deltas. A growing count of Detached HTMLDivElement points to DOM nodes still referenced from JavaScript after they were removed from the tree (typical cause: an event listener on window/document that captured the node in a closure and was never removed). A growing count of plain Objects often points to an unbounded cache or Map that nothing evicts.
3. Use the Performance panel to record over a longer window and look at the JS heap line — sawtooth means GC is keeping up; monotonically rising means a true leak.
4. Check the usual culprits — setInterval not cleared on unmount, addEventListener on window/document without cleanup, observers (IntersectionObserver, MutationObserver, ResizeObserver) not disconnected, subscriptions to external stores not unsubscribed.
5. Fix and verify by re-snapshotting until the leaked constructor count no longer grows over time.

What separates a strong answer is naming specific tools and constructor names, rather than just listing "common causes of memory leaks".

Scenario B: Three API calls — two can run in parallel, one depends on the result of the first

"Write the minimum-latency code for this dependency graph. Why might Promise.all be the wrong tool?"

async function loadCheckout(userId) {
  // Step 1 must complete before Step 3 because Step 3 needs the cart id.
  const cart = await getCart(userId);
  // Steps 2 and 3 are independent and can run concurrently.
  const [user, lineItems] = await Promise.all([
    getUser(userId),
    getCartItems(cart.id),
  ]);
  return { cart, user, lineItems };
}

Wrapping all three in Promise.all doesn't work — getCartItems needs cart.id, which isn't known until getCart resolves. Promise.all only parallelizes inputs that are already independent. When there's a dependency chain, await the dependency first, then Promise.all the leaves. (For a deeper comparison, see Promise.all vs Promise.allSettled.)

Scenario C: A junior wrote setInterval(updateUI, 16) for an animation — what's wrong with this?

Three issues:

1. It misses frames. The browser paints roughly every 16.67 ms (on a 60 Hz display), but setInterval doesn't synchronize with paint. You'll drift in and out of phase with the refresh cycle, getting visible stutter. requestAnimationFrame schedules work to run right before the next paint.
2. It keeps running in inactive tabs. setInterval is throttled in background tabs (Chrome drops to ~1 Hz, then to ~1/min under "intensive throttling" after 5 minutes hidden), but it still fires. requestAnimationFrame simply pauses while the tab is hidden — saving CPU and battery.
3. It doesn't degrade gracefully. If a callback occasionally takes longer than the interval, setInterval will fire as soon as the previous one finishes, with no breathing room. rAF naturally skips a frame and resumes on the next paint.

For animations driven from JS, requestAnimationFrame is the default. For purely declarative timing (e.g. fading in an element from 0 to 1 opacity over 300 ms), the Web Animations API or CSS transitions are usually a better fit since they run off the main thread.

How the same question gets graded differently at junior vs senior level

For the questions below, what separates a passing answer from a strong one is rarely correctness — it's the depth of the connection drawn between the language feature and its real-world consequence:

The deeper answer in each case ties the language feature to a specific failure mode and, where it applies, to where the consequence shows up in a framework like React.

1. What's a typical use case for anonymous functions in JavaScript?

Anonymous functions provide a concise way to define functions, especially useful for simple operations or callbacks. They are commonly used in:

• Immediate execution: Encapsulate code within a local scope using Immediately Invoked Function Expressions (IIFEs).
• Callbacks: Define handlers directly where they are called without having to search elsewhere.
• Higher-order functions: Use as arguments to functions like map(), filter(), and reduce().
• Event Handling: Common in React for inline event handling.

Some examples:

// Encapsulating Code using IIFE
(function () {
  // Some code here.
})();

// Callbacks
setTimeout(function () {
  console.log('Hello world!');
}, 1000);

// Functional programming constructs
const arr = [1, 2, 3];
const double = arr.map(function (el) {
  return el * 2;
});
console.log(double); // [2, 4, 6]

Explore a typical use case for anonymous functions in JavaScript on GreatFrontEnd

2. What is a closure in JavaScript, and why would you use one?

A closure is a function that retains access to variables from its enclosing scope even after the outer function has finished executing. The function effectively carries its original environment with it.

function outerFunction() {
  const outerVar = 'I am outside of innerFunction';

  function innerFunction() {
    console.log(outerVar); // `innerFunction` can still access `outerVar`.
  }

  return innerFunction;
}

const inner = outerFunction(); // `inner` now holds a reference to `innerFunction`.

inner(); // "I am outside of innerFunction"
// Even though `outerFunction` has completed execution, `inner` still has access to variables defined inside `outerFunction`.

Closures are useful for:

• Data encapsulation: Create private variables and functions that can't be accessed from outside the closure.
• Maintaining state: Particularly in functional programming and React hooks.
• Event handlers and callbacks: Retain access to variables when handlers are defined.

Explore what a closure is in JavaScript, and why you would use one on GreatFrontEnd

3. What are the pros and cons of using Promises instead of callbacks in JavaScript?

Pros:

• Avoid callback hell: Promises simplify nested callbacks.

  // Callback hell
  getData1((data) => {
    getData2(data, (data) => {
      getData3(data, (result) => {
        console.log(result);
      });
    });
  });

• Sequential code: Easier to write and read using .then().

• Parallel code: Simplifies managing multiple promises with Promise.all().

  Promise.all([getData1(), getData2(), getData3()])
    .then((results) => {
      console.log(results);
    })
    .catch((error) => {
      console.error('Error:', error);
    });

Cons:

• Can be slightly more complex to understand initially.

Explore the pros and cons of using Promises instead of callbacks in JavaScript on GreatFrontEnd

4. How do you abort a web request using AbortController in JavaScript?

AbortController allows you to cancel ongoing asynchronous operations like fetch requests. To use it:

1. Create an instance: const controller = new AbortController(); 2.Pass the signal: Add the signal to the fetch request options.
2. Abort the request: Call controller.abort() to cancel the request.

Here is an example of how to use AbortControllers with the fetch() API:

const controller = new AbortController();
const signal = controller.signal;

fetch('YOUR API', { signal })
  .then((response) => {
    // Handle response
  })
  .catch((error) => {
    if (error.name === 'AbortError') {
      console.log('Request aborted');
    } else {
      console.error('Error:', error);
    }
  });

// Call abort() to abort the request
controller.abort();

Some of its use cases can be:

• Cancel a fetch() request on a user action
• Prioritize latest requests in a race condition
• Cancel requests that are no longer needed

Explore how to abort a web request using AbortController in JavaScript on GreatFrontEnd

5. Why is extending built-in JavaScript objects not a good idea?

In JavaScript it's very easy to extend a built-in/native object. You can simply extend a built-in object by adding properties and functions to its prototype.

String.prototype.reverseString = function () {
  return this.split('').reverse().join('');
};

console.log('hello world'.reverseString()); // Outputs 'dlrow olleh'

// Instead of extending the built-in object, write a pure utility function to do it.

function reverseString(str) {
  return str.split('').reverse().join('');
}

console.log(reverseString('hello world')); // Outputs 'dlrow olleh'

While this may seem like a good idea at first, it is dangerous in practice. Imagine your code uses a few libraries that both extend the Array.prototype by adding the same contains method, the implementations will overwrite each other and your code will have unpredictable behavior if these two methods do not work the same way.

Extending built-in objects can lead to issues such as:

• Future-proofing: Risk of conflicts with future implementations.
• Collisions: Potential clashes with other libraries.
• Maintenance: Difficult for other developers to understand.
• Performance: Potential negative impact.
• Security: Risk of introducing vulnerabilities.
• Compatibility: Issues across different environments.

Explore why extending built-in JavaScript objects is not a good idea on GreatFrontEnd

6. Why is it, in general, a good idea to leave the global JavaScript scope of a website as-is and never touch it?

In the browser, the global scope refers to the top-level context where variables, functions, and objects are accessible throughout the code. This scope is represented by the window object. Variables and functions declared outside of any function or block (excluding modules) are added to the window object, making them globally accessible.

For example:

// This runs in the global scope, not within a module.
let globalVar = 'Hello, world!';
function greet() {
  console.log('Greetings from the global scope!');
}

console.log(window.globalVar); // 'Hello, world!'
window.greet(); // 'Greetings from the global scope!'

In this example, globalVar and greet are attached to the window object and can be accessed from anywhere in the global scope.

Generally, it's advisable to avoid polluting the global namespace unless necessary. Key reasons include:

• Naming conflicts: Multiple scripts sharing the global scope can lead to conflicts and bugs when new global variables or changes are introduced.
• Cluttered global namespace: Minimizing the global namespace helps keep the codebase manageable and maintainable.
• Scope leaks: Accidental references to global variables in closures or event handlers can result in memory leaks and performance issues.
• Modularity and encapsulation: Good design practices involve keeping variables and functions within specific scopes, improving organization, reusability, and maintainability.
• Security concerns: Global variables are accessible by all scripts, including potentially malicious ones, posing security risks, especially if they contain sensitive data.
• Compatibility and portability: Relying heavily on global variables reduces code portability and complicates integration with other libraries or frameworks.

Explore why it is, in general, a good idea to leave the global JavaScript scope of a website as-is and never touch it on GreatFrontEnd

7. Explain the differences between CommonJS modules and ES modules in JavaScript?

In JavaScript, modules are reusable pieces of code that encapsulate functionality, making it easier to manage, maintain, and structure your applications. Modules allow you to break down your code into smaller, manageable parts, each with its own scope.

CommonJS is an older module system that was initially designed for server-side JavaScript development with Node.js. It uses the require() function to load modules and the module.exports or exports object to define the exports of a module.

// my-module.js
const value = 42;
module.exports = { value };

// main.js
const myModule = require('./my-module.js');
console.log(myModule.value); // 42

ES Modules (ECMAScript Modules) are the standardized module system introduced in ES6 (ECMAScript 2015). They use the import and export statements to handle module dependencies.

// my-module.js
export const value = 42;

// main.js
import { value } from './my-module.js';
console.log(value); // 42

Explore the differences between CommonJS modules and ES modules in JavaScript on GreatFrontEnd

8. Explain the difference between mutable and immutable objects in JavaScript

Immutability is a core principle in functional programming but it has lots to offer to object-oriented programs as well.

Mutable objects

Mutable objects in JavaScript allow for modifications to their properties and values after creation. This behavior is default for most objects.

let mutableObject = {
  name: 'John',
  age: 30,
};

// Modify the object
mutableObject.name = 'Jane';

console.log(mutableObject); // Output: { name: 'Jane', age: 30 }

Mutable objects like mutableObject above can have their properties changed directly, making them flexible for dynamic updates.

Immutable objects

In contrast, immutable objects cannot be modified once created. Any attempt to change their content results in the creation of a new object with the updated values.

const immutableObject = Object.freeze({
  name: 'John',
  age: 30,
});

// Attempting to modify the object
immutableObject.name = 'Jane'; // This change won't affect the object

console.log(immutableObject); // Output: { name: 'John', age: 30 }

Here, immutableObject remains unchanged after creation due to Object.freeze(), which prevents modifications to its properties.

The primary difference lies in modifiability. Mutable objects allow changes to their properties directly, while immutable objects ensure the integrity of their initial state by disallowing direct modifications.

const vs immutable objects

A common confusion is that declaring a variable using const makes the value immutable, which is not true at all.

Using const prevents the reassignment of variables but doesn't make non-primitive values immutable.

// Using const
const person = { name: 'John' };
person = { name: 'Jane' }; // Error: Assignment to constant variable
person.name = 'Jane'; // Allowed, person.name is now 'Jane'

// Using Object.freeze() to create an immutable object
const frozenPerson = Object.freeze({ name: 'John' });
frozenPerson.name = 'Jane'; // Silently ignored in sloppy mode; throws TypeError in strict mode
frozenPerson = { name: 'Jane' }; // Error: Assignment to constant variable

In the first example with const, reassigning a new object to person is not allowed, but modifying the name property is permitted. In the second example, Object.freeze() makes the frozenPerson object immutable, preventing any changes to its properties.

Explore the difference between mutable and immutable objects in JavaScript on GreatFrontEnd

9. Why might you want to create static class members in JavaScript?

Static class members in JavaScript, denoted by the static keyword, are accessed directly on the class itself, not on instances. They serve multiple purposes:

1. Namespace Organization: They help organize constants or configuration values within the class, preventing naming conflicts.

class Config {
  static API_KEY = 'your-api-key';
  static FEATURE_FLAG = true;
}

console.log(Config.API_KEY); // Output: 'your-api-key'
console.log(Config.FEATURE_FLAG); // Output: true

2. Helper Functions: Static methods act as utility functions for the class or its instances, improving code readability.

class Arithmetic {
  static add(a, b) {
    return a + b;
  }
  static subtract(a, b) {
    return a - b;
  }
}

console.log(Arithmetic.add(2, 3)); // Output: 5
console.log(Arithmetic.subtract(5, 2)); // Output: 3

3. Singleton Pattern: They can facilitate the singleton pattern, ensuring only one instance of a class exists.

class Singleton {
  static instance;

  static getInstance() {
    if (!this.instance) {
      this.instance = new Singleton();
    }
    return this.instance;
  }
}

const singleton1 = Singleton.getInstance();
const singleton2 = Singleton.getInstance();

console.log(singleton1 === singleton2); // Output: true

4. No per-instance copy: Static members live on the class itself rather than each instance, so utility constants and pure helpers don't bloat individual objects.

Explore why you might want to create static class members in JavaScript on GreatFrontEnd

10. What are Symbols used for in JavaScript?

Symbols in JavaScript, introduced in ES6, are unique and immutable identifiers primarily used as object property keys to avoid name collisions. They can be created using the Symbol() function, ensuring each Symbol value is unique even if descriptions are identical. Symbol-keyed properties are skipped by for...in, Object.keys(), Object.getOwnPropertyNames(), and JSON.stringify(), which makes them useful as quasi-private property keys (they're still retrievable via Object.getOwnPropertySymbols() and Reflect.ownKeys()).

const sym1 = Symbol();
const sym2 = Symbol('uniqueKey');

console.log(typeof sym1); // "symbol"
console.log(sym1 === sym2); // false, each symbol is unique

const obj = {};
const sym = Symbol('uniqueKey');

obj[sym] = 'value';
console.log(obj[sym]); // "value"

Key characteristics include:

• Uniqueness: Each Symbol value is unique.
• Immutability: Symbol values cannot be changed.
• Hidden from standard enumeration: Symbol-keyed properties don't show up in for...in, Object.keys(), Object.getOwnPropertyNames(), or JSON.stringify() — but they're still accessible via Object.getOwnPropertySymbols().

Global Symbols can be created using Symbol.for('key'), allowing reuse across different parts of codebases:

const globalSym1 = Symbol.for('globalKey');
const globalSym2 = Symbol.for('globalKey');

console.log(globalSym1 === globalSym2); // true

const key = Symbol.keyFor(globalSym1);
console.log(key); // "globalKey"

There are some well known Symbol in JavaScript like:

• Symbol.iterator: Defines the default iterator for an object.
• Symbol.toStringTag: Used to create a string description for an object.
• Symbol.hasInstance: Used to determine if an object is an instance of a constructor.

Explore what Symbols are used for in JavaScript on GreatFrontEnd

11. What are JavaScript object getters and setters for?

JavaScript object getters and setters are essential for controlling access to object properties, offering customization when getting or setting values.

const user = {
  _firstName: 'John',
  _lastName: 'Doe',

  get fullName() {
    return `${this._firstName} ${this._lastName}`;
  },

  set fullName(value) {
    const parts = value.split(' ');
    this._firstName = parts[0];
    this._lastName = parts[1];
  },
};

console.log(user.fullName); // Output: 'John Doe'
user.fullName = 'Jane Smith';
console.log(user.fullName); // Output: 'Jane Smith'

Getters (fullName) compute values based on internal properties (_firstName and _lastName), while setters (fullName) update these properties based on assigned values ('Jane Smith'). These mechanisms enhance data encapsulation and allow for custom data handling in JavaScript objects.

Explore what JavaScript object getters and setters are for on GreatFrontEnd

12. What tools and techniques do you use for debugging JavaScript code?

Tools and techniques for debugging JavaScript code vary depending on the context:

• JavaScript
  • Chrome Devtools: Provides a comprehensive set of debugging tools including breakpoints, stepping through code, watching variables, profiling performance, etc. You can learn more about it here.
  • debugger statement: Inserting debugger; in code triggers breakpoints when Devtools are open, pausing execution for inspection.
  • Traditional console.log() debugging: Using console.log() statements to output variable values and debug messages.
• React and Redux
  • React Devtools: Inspect the React component tree, props, state, and hooks; profile renders.
  • Redux Devtools: Time-travel through dispatched actions, inspect state diffs, and replay history.
• Vue
  • Vue Devtools: Component inspection, reactive state visualization, Pinia/Vuex stores, and event tracking.

Explore what tools and techniques are used for debugging JavaScript code on GreatFrontEnd

13. Can you give an example of a curry function and why this syntax offers an advantage?

Currying in JavaScript is a functional programming technique where a function with multiple arguments is transformed into a sequence of nested functions, each taking a single argument. This allows for partial application of the function's arguments, meaning you can fix some arguments ahead of time and then apply the remaining arguments later.

Here's a simple example of a curry function and why this syntax offers an advantage:

// Example of a curry function
function curry(fn) {
  return function curried(...args) {
    if (args.length >= fn.length) {
      return fn(...args);
    } else {
      return function (...moreArgs) {
        return curried(...args, ...moreArgs);
      };
    }
  };
}

// Example function to be curried
function multiply(a, b, c) {
  return a * b * c;
}

// Currying the multiply function
const curriedMultiply = curry(multiply);

// Applying curried functions
const step1 = curriedMultiply(2); // partially apply 2
const step2 = step1(3); // partially apply 3
const result = step2(4); // apply the final argument

console.log(result); // Output: 24

Advantages of Curry Syntax:

• Partial Application: You can create specialized versions of functions by fixing some arguments, making it easier to reuse and compose functions.
• Modularity and Reusability: Encourages modular programming by breaking down functions into smaller, reusable parts.
• Flexibility: Allows for function chaining and incremental application of arguments, which can improve code readability and maintainability.

Currying enhances the functional programming paradigm in JavaScript by enabling concise, composable, and reusable functions, promoting cleaner and more modular code.

Explore examples of a curry function and why this syntax offers an advantage on GreatFrontEnd

14. What is the difference between the document load event and the document DOMContentLoaded event?

The DOMContentLoaded event is triggered once the initial HTML document has been fully loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading.

In contrast, the window's load event is fired only after the DOM and all dependent resources, such as stylesheets, images, and subframes, have completely loaded.

Explore the difference between the document load event and the document DOMContentLoaded event on GreatFrontEnd

15. How would you design a request-deduplication layer for a React app?

If three components in the same render tree call useUser(123), you don't want three identical network requests. A reasonable design has three parts:

1. An in-flight cache keyed by the request URL (or a stable tuple of arguments). The first caller starts the request and stores the promise; concurrent callers receive the same promise.

   const inFlight = new Map();
   
   function dedupedFetch(key, requestFn) {
     if (inFlight.has(key)) return inFlight.get(key);
     const promise = requestFn().finally(() => inFlight.delete(key));
     inFlight.set(key, promise);
     return promise;
   }

2. A short-lived response cache so quick re-renders or navigations don't re-fetch. TTL depends on data freshness requirements — longer for reference data, shorter for user state.

3. A revalidation strategy so stale data eventually refreshes. The common pattern is "stale-while-revalidate" — serve the cached value immediately, then fetch in the background and update the cache when the new data arrives.

This is what SWR, TanStack Query, and Apollo Client provide out of the box. Rolling your own makes sense for small apps with simple needs and tight bundle budgets; adopting a library is usually the right call once you need cache invalidation, retries, or devtools support.

A useful follow-up: what if two callers pass slightly different arguments that should produce the same response? The fix is to normalize the cache key (sort query params, canonicalize the URL) before lookup.

16. Explain the same-origin policy with regard to JavaScript.

The same-origin policy restricts how scripts loaded from one origin can interact with resources from another origin. An origin is the combination of URI scheme, hostname, and port — https://example.com and https://api.example.com are different origins.

A key nuance: the SOP doesn't usually block a cross-origin request from being sent; it blocks JavaScript from reading the response (and from accessing the DOM of cross-origin frames). That's why a cross-origin fetch will still hit the server, but the response body is hidden from your script unless the server opts in via CORS headers. This prevents malicious scripts from silently exfiltrating data the user is authorized to see on another site.

Explore how JSONP works (and how it's not really Ajax) on GreatFrontEnd

17. Explain what a single page app is and how to make one SEO-friendly.

Single Page Apps (SPAs) are highly interactive web applications that load a single HTML page and dynamically update content as the user interacts with the app. Unlike traditional server-side rendering, SPAs use client-side rendering, fetching new data via AJAX without full-page refreshes. This approach makes the app more responsive and reduces the number of HTTP requests.

Pros:

• Improved responsiveness with no full-page refreshes.
• Fewer HTTP requests, as assets are reused.
• Clear separation between client and server, allowing independent updates.

Cons:

• Heavier initial load due to loading all necessary assets upfront.
• Requires server configuration to route all requests to a single entry point.
• Slower time-to-content for the user's first visit, since rendering waits on JS to download, parse, and execute.

On SEO: Googlebot has run an evergreen Chromium-based renderer for years and indexes JS-rendered content, but rendering can be deferred (sometimes by days), some non-Google crawlers and AI bots don't render JS at all, and social media link previews rely on initial HTML. The standard approaches:

• Server-side rendering (e.g. Next.js, Remix, Nuxt) — generate HTML per request on the server.
• Static generation / prerendering — generate HTML at build time, or run a headless browser at request time (services like Prerender) to serve static HTML to crawlers.

Explore what a single page app is and how to make one SEO-friendly on GreatFrontEnd

18. How do you organize your code?

In the past, developers often used Backbone for models, promoting an OOP approach by creating Backbone models and attaching methods to them.

While the module pattern remains useful, modern development often favors React/Redux, which employs a single-directional data flow based on the Flux architecture. Here, app data models are typically represented using plain objects, with utility pure functions to manipulate these objects. State changes are handled using actions and reducers, following Redux principles.

Avoid classical inheritance when possible. If you must use it, adhere to best practices and guidelines.

Explore how to organize your code on GreatFrontEnd

19. How do you handle race conditions in async code?

The classic example is a search-as-you-type input that fires fetch(query) on every keystroke. A slower earlier request can resolve after a faster later one, overwriting the correct results with stale data. Three approaches, in increasing order of how well they handle it:

1. Token check — capture an id at the start of each call and only commit the result if the id is still the latest:

   let latestRequestId = 0;
   async function search(query) {
     const myRequestId = ++latestRequestId;
     const results = await fetch(`/search?q=${query}`).then((r) => r.json());
     if (myRequestId === latestRequestId) {
       setResults(results);
     }
   }

2. AbortController — cancel the previous request before starting a new one. The fetch rejects with an AbortError, which you can ignore:

   let controller;
   async function search(query) {
     controller?.abort();
     controller = new AbortController();
     try {
       const results = await fetch(`/search?q=${query}`, {
         signal: controller.signal,
       }).then((r) => r.json());
       setResults(results);
     } catch (e) {
       if (e.name === 'AbortError') return;
       throw e;
     }
   }

3. A query layer (TanStack Query, SWR) — handles deduplication, cancellation, stale-while-revalidate, and result ordering for you. Worth adopting once you have more than a handful of async data needs.

Token check is the simplest fallback and works in any environment, but the in-flight request still completes and consumes server resources. AbortController closes the connection on the client, which lets the browser stop downloading the response — though whether the server stops processing depends on whether the handler is wired to listen for the disconnect.

In React, the natural place to call controller.abort() is the cleanup function returned from useEffect, so a request started by an effect is cancelled when the component unmounts or the effect re-runs.

20. What's the difference between an "attribute" and a "property"?

Attributes: Defined in HTML tags, they provide initial info for the browser (like "Hello" in <input type="text" value="Hello">).

Properties: Belong to the DOM (JavaScript's view of the page), allowing you to access and change element info after the page loads (like updating the text field value).

Explore the difference between an "attribute" and a "property" on GreatFrontEnd

Conclusion

At the senior level, the questions don't get harder so much as the answers get deeper. You're expected to know the language, but what differentiates a strong candidate is connecting the language to its consequences — knowing where the sharp edges are, how the framework you use leans on them, and which tradeoffs you'd defend in a code review.

Prefer GitHub? You can explore all +190 JavaScript interview questions directly in our open source repo.