96 JavaScript Logic Building Questions — From Basic to Advanced (With Solutions)

Q34

var vs let inside a loop — what prints?

for (var i = 0; i < 3; i++) setTimeout(() => console.log(i));
// 3 3 3

for (let i = 0; i < 3; i++) setTimeout(() => console.log(i));
// 0 1 2

Why: var creates one binding shared by all three callbacks, and by the time they run the loop has finished. let creates a fresh binding per iteration.

Q35

Event loop ordering — what prints, and in what order?

console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
queueMicrotask(() => console.log("4"));
console.log("5");
// 1 5 3 4 2

Why: all synchronous code runs first, then the entire microtask queue (promises, queueMicrotask), and only then the macrotask queue (setTimeout). A setTimeout(fn, 0) is never actually zero.

Q36

this in a regular function vs an arrow function.

const user = {
  name: "Suhas",
  regular() { return this.name; },   // "Suhas"
  arrow: () => this?.name            // undefined
};

Why: an arrow function has no this of its own — it takes it from the scope where it was defined. Rule of thumb: never an arrow for an object method, always an arrow for a callback inside a method.

Q37

Implement Promise.all.

function promiseAll(promises) {
  return new Promise((resolve, reject) => {
    const results = [];
    let completed = 0;
    if (promises.length === 0) return resolve([]);
    promises.forEach((p, i) => {
      Promise.resolve(p).then(value => {
        results[i] = value;
        if (++completed === promises.length) resolve(results);
      }, reject);
    });
  });
}

The detail: results[i] = value, never results.push(value). Push returns results in completion order; the real Promise.all guarantees input order. Also: an empty array must resolve immediately, and one rejection rejects the whole thing.

Q38

Retry an async call with exponential backoff.

async function retry(fn, attempts = 3, delay = 500) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (err) {
      if (i === attempts - 1) throw err;
      await new Promise(r => setTimeout(r, delay * 2 ** i));
    }
  }
}

Why this closes the list: it combines loops, closures, promises and error handling in eight lines, and it is real production code — every payment gateway and third-party API integration needs it. If you can write this without help, you have finished the logic-building stage.

Q79

A UI freezes for two seconds when a button is clicked, even though the click handler looks lightweight. How do you find the cause?

The detail: JavaScript runs on a single thread, so any synchronous heavy work inside the handler — a big JSON.parse, a nested loop over a large array, a blocking regex — blocks rendering until it finishes. Profile with the Chrome DevTools Performance tab to find the long task, then move the work off the main thread with a Web Worker, or break it into chunks scheduled with setTimeout or requestIdleCallback.

Q80

Two setTimeout(fn, 0) calls fire in an unexpected order under heavy load. Is this a bug?

The detail: No. setTimeout only guarantees a minimum delay, never an exact one — if the call stack or the microtask queue is busy, queued macrotasks simply wait their turn and run whenever the event loop is actually free. Ordering under load is expected, not a defect.

Q81

A search box fires an API call on every keystroke, and users see results flicker as older responses resolve after newer ones. 'Just add debounce' fixed the request rate but not the flicker. What's still missing?

The detail: Debouncing reduces how often you call the API, but a slow older request can still resolve after a faster newer one. Cancel the previous in-flight request with an AbortController when a new one starts, or tag each request with an incrementing id and ignore any response whose id is not the latest.

Q82

A single-page app's memory grows every time a component mounts and unmounts, even though no new DOM nodes are visibly left behind. How do you investigate?

The detail: Take two heap snapshots in the browser's Memory tab, minutes apart, and diff them. Look for detached DOM nodes or growing counts of a specific object type — the usual cause is a closure formed inside the component (an event listener, an interval, a subscription) that captures the component's scope and is never torn down, so neither the closure nor what it references can be garbage-collected.

Q83

An app polls an API with setInterval, and after a user navigates away and back several times in a single-page app, you see duplicate overlapping network calls. What happened?

The detail: The interval from the previous mount was never cleared before the component mounted again, so multiple intervals are now running concurrently against the same endpoint. Always store the interval id and call clearInterval in the teardown path tied to that exact mount, not just at some later convenient point.

Q84

A class method passed directly as a callback — e.g. to setTimeout or addEventListener — throws 'Cannot read properties of undefined' in production. What are your options, and which do you prefer in a class-based codebase?

The detail: Three fixes: bind it in the constructor (this.method = this.method.bind(this)), define it as an arrow function class field so it captures the instance's this at creation, or wrap it in an inline arrow function at the call site. Arrow class fields are usually the cleanest default in a large codebase — the binding is declared once, next to the method, instead of scattered across every call site.

Q85

Extracting a method off an object — const fn = obj.method; fn() — throws or behaves differently than calling obj.method() directly. Why?

The detail: A method's this is determined by how it is called, not where it is defined. obj.method() binds this to obj at the call site; assigning the function reference to a bare variable strips that context, so calling fn() runs with this as undefined (in strict mode) or the global object. Only an arrow function or an explicitly bound function keeps working after extraction.

Q86

A function is supposed to work on a copy of a user object, but the caller's original object changes too. What's happening, and what's the general fix?

The detail: Objects and arrays are assigned and passed by reference, so const copy = user; copy.name = 'x' mutates the exact same object user points to — there was never a second object. Use a spread ({ ...user }), Object.assign({}, user), or structuredClone(user) for a deep copy, depending on how much of the object's structure needs to be independent.

Q87

In a Redux-style store, a reducer mutates state directly instead of returning a new object, and the UI silently does not re-render. Why does that specific bug produce that specific symptom?

The detail: Most state-driven UI libraries decide whether to re-render by comparing the previous state reference to the new one, not by deep-comparing their contents. Mutating the existing object in place means the reference never changes, so the comparison sees 'no change' even though the data inside genuinely changed. The fix is always to return a new object or array, never to mutate the one you were given.

Q88

An async function's try/catch does not catch an error thrown inside a .then() callback chained after an await. Why?

The detail: Mixing await with a separate, un-returned .then() chain inside the same function creates a promise that runs outside the try block's supervision — if that .then() callback throws, the outer async function has typically already moved past the try/catch by the time it happens. Keep the flow consistently on await, or explicitly return the .then() chain so its rejection stays inside the function the try/catch is guarding.

Q89

An async function silently swallows an error — nothing appears in the console or your error-tracking tool. What's the likely cause, and how do you prevent this across a whole codebase?

The detail: Almost always a fire-and-forget async call: something invoked an async function without awaiting or .catch()-ing it, so its rejection has nowhere to go and becomes an unhandled promise rejection. Add a global window.addEventListener('unhandledrejection', ...) (or process.on('unhandledRejection', ...) in Node) as a safety net, and enable an ESLint rule like no-floating-promises to catch the missing await at review time instead of in production.

Q90

A scroll handler that updates layout on every scroll event causes visible jank on mobile. You already tried throttling by time — why might that still not be smooth?

The detail: A time-based throttle can still fire mid-frame, forcing a layout read or write at a moment the browser was not about to repaint anyway, which causes layout thrashing. Batch the update inside requestAnimationFrame instead, so the DOM write happens right before the browser's own paint — aligned with the render cycle rather than an arbitrary interval.

Q91

A form's submit handler calls e.preventDefault(), but the page still reloads intermittently in production. What are the likely causes?

The detail: Three usual suspects: an error thrown earlier in the handler before preventDefault() executes, so the call never happens; a second submit listener attached elsewhere on the same form that does not call preventDefault(); or event delegation misconfigured so the handler is bound to the wrong element and never actually intercepts the real submit event.

Q92

Sorting an array of numbers with Array.prototype.sort() gives an obviously wrong order — [10, 1, 2] comes back as [1, 10, 2]. Why, and how do you fix it?

The detail: sort() converts elements to strings and compares them lexicographically by default, so '10' sorts before '2' because '1' < '2' as characters. Pass an explicit comparator — arr.sort((a, b) => a - b) — whenever you are sorting numbers, not the default.

Q93

A check like if (user.isPremium) throws 'Cannot read properties of undefined' in production, but only for some users, and it never reproduces locally.

The detail: This is almost always a timing issue: user is briefly null or undefined because the data has not finished loading yet, or the API returned a partial response for that user. Guard with optional chaining (user?.isPremium) and make sure the UI has an explicit loading or empty state instead of assuming the data is always present by the time this line runs.

Q94

JSON.stringify(obj) is missing fields when you log an object for debugging, even though the fields clearly exist when you inspect the object directly.

The detail: JSON.stringify silently drops properties whose value is a function, undefined, or a Symbol, and it will call a custom toJSON() method on any nested object that defines one (Date is the classic example) and use its return value instead of the object's own properties. Check for a toJSON() override on nested objects before assuming the data itself is missing.

Q95

A value read from process.env at the top of a module is undefined in production but works fine locally. What in the module loading order likely broke it?

The detail: Imports and requires execute top-to-bottom, eagerly, at load time — if the module that reads process.env.SOME_KEY is imported before your env-loading step (like dotenv.config()) has actually run, it captures undefined and keeps it, because the top-level read only happens once. Load environment configuration before importing anything that depends on it, or read the variable lazily inside a function instead of at module scope.

Q96

Two different files import what should be the same module, but each gets its own separate instance of a singleton 'cache' object, despite Node caching modules by default.

The detail: Node's module cache is keyed by the resolved absolute file path, not by package name — if the same package exists twice in node_modules (a version mismatch between dependencies, or a monorepo package resolved through two different symlink paths), each resolves to a different file path and therefore a different cached instance. Check the actual resolved paths with something like npm ls or node --trace-resolve rather than assuming the import statements alone guarantee one instance.