Asynchronous JavaScript and Event Loop Questions

Comprehensive understanding of asynchronous programming in JavaScript including callback functions and the pitfalls of callback nesting, Promises including their lifecycle and state transitions, promise chaining, and common utility methods such as Promise.all, Promise.race, and Promise.allSettled. Knowledge of async and await as syntactic sugar over Promises, proper error handling patterns using try catch and promise catch, and avoiding unhandled rejections. Practical skills for working with multiple concurrent operations such as coordinating parallel requests, implementing retry logic, rate limiting, throttling and debouncing of async calls, and handling race conditions. Deep understanding of the JavaScript event loop model including the call stack, task queue, microtask queue, the ordering of macrotasks versus microtasks, how timers and promise callbacks are scheduled, and how this affects concurrency and ordering. Familiarity with implementing a simplified Promise from first principles to demonstrate internal behavior, diagnosing timing and ordering bugs, and designing solutions for real world asynchronous flows and performance considerations.

HardTechnical

65 practiced

In a large frontend codebase you see intermittent 'Unhandled Promise Rejection' warnings. Propose a systematic architecture and team-level patterns to reduce unhandled rejections and improve error observability. Include code examples: a centralized request wrapper that always handles errors, global handlers for unexpected rejections, and how to enforce these patterns during code review and testing.

Sample Answer

**Overview — goal**Reduce intermittent "Unhandled Promise Rejection" by: centralizing async error handling, adding global guards/observability, and enforcing patterns via code review, linting and tests.

**Architecture & team patterns**- Single responsibility: HTTP + async helpers always return a normalized Result/Error object or throw documented, handled errors.- Observability: capture all rejections to monitoring (Sentry/Datadog), include context (userId, route, component).- Team rules: PR checklist requires no raw Promise usage without await/try-catch or .catch; reviewers verify instrumentation; add unit/integration tests for failure paths.

**Centralized request wrapper (example)**

javascript

// apiClient.js
export async function request(url, opts = {}) {
  try {
    const res = await fetch(url, opts);
    const body = await res.json().catch(() => null);
    if (!res.ok) throw { status: res.status, body };
    return { ok: true, data: body };
  } catch (err) {
    // normalize
    const normalized = { message: err.message || 'Network error', original: err };
    // send to observability
    window.__MONITOR__?.captureError(normalized, { url, opts });
    return { ok: false, error: normalized };
  }
}

**Global handlers**

javascript

window.addEventListener('unhandledrejection', event => {
  const reason = event.reason;
  window.__MONITOR__?.captureError(reason, { source: 'unhandledrejection' });
  // optionally surface friendly UI
  event.preventDefault();
});

window.addEventListener('error', e => {
  window.__MONITOR__?.captureError(e.error || e.message, { source: 'globalError' });
});

**Enforcement during review & testing**- Lint rules: custom ESLint rule to flag promise expressions not awaited or lacking .catch.- PR template: checklist entries for error handling and observability calls.- Tests: unit tests that assert request() returns { ok: false } on failures; e2e tests simulate network errors and assert no unhandled rejections (CI fails on console errors).- CI: run a headless browser test that listens for unhandledrejection events; fail build if any occur.

**Outcome & trade-offs**- Predictable error shapes, full telemetry, fewer runtime warnings. Trade-off: minimal wrapper overhead and discipline; mitigated by clear docs, examples, and automated checks.

HardTechnical

65 practiced

Implement a simplified Promise from first principles in JavaScript named `SimplePromise`. The implementation must support: creating with `new SimplePromise((resolve, reject) => {})`, `.then(onFulfilled, onRejected)` chaining, proper state transitions (pending -> fulfilled/rejected), asynchronous invocation of handlers (via queueMicrotask or equivalent), and basic thenable assimilation. It does not need to implement every edge of the full spec, but should handle chained Thens and errors correctly.

Sample Answer

**Approach**Implement a Promise-like class with states, queues for fulfil/reject handlers, asynchronous handler invocation via queueMicrotask, and basic thenable assimilation (if resolved value has a then method call it).

**Code**

javascript

class SimplePromise {
  constructor(executor) {
    this.state = 'pending';
    this.value = undefined;
    this.handlers = []; // {onFulfilled,onRejected,resolve,reject}

    const fulfill = val => this._resolve(val);
    const reject = err => this._settle('rejected', err);

    try { executor(fulfill, reject); }
    catch (e) { reject(e); }
  }

  _settle(state, value) {
    if (this.state !== 'pending') return;
    this.state = state;
    this.value = value;
    queueMicrotask(() => {
      this.handlers.forEach(h => this._runHandler(h));
      this.handlers = [];
    });
  }

  _resolve(val) {
    // thenable assimilation (avoid self-resolution)
    if (val === this) return this._settle('rejected', new TypeError('Cannot resolve with itself'));
    if (val && (typeof val === 'object' || typeof val === 'function')) {
      let then;
      try { then = val.then; }
      catch (e) { return this._settle('rejected', e); }
      if (typeof then === 'function') {
        // call then once
        let called = false;
        try {
          then.call(val, y => { if (!called) { called = true; this._resolve(y); } },
                         r => { if (!called) { called = true; this._settle('rejected', r); } });
          return;
        } catch (e) { if (!called) return this._settle('rejected', e); }
      }
    }
    this._settle('fulfilled', val);
  }

  _runHandler({onFulfilled,onRejected,resolve,reject}) {
    try {
      if (this.state === 'fulfilled') {
        if (!onFulfilled) return resolve(this.value);
        resolve(onFulfilled(this.value));
      } else {
        if (!onRejected) return reject(this.value);
        resolve(onRejected(this.value));
      }
    } catch (e) { reject(e); }
  }

  then(onFulfilled, onRejected) {
    return new SimplePromise((resolve, reject) => {
      const handler = { onFulfilled, onRejected, resolve, reject };
      if (this.state === 'pending') this.handlers.push(handler);
      else queueMicrotask(() => this._runHandler(handler));
    });
  }

  catch(fn) { return this.then(null, fn); }
  static resolve(v) { return new SimplePromise(r => r(v)); }
  static reject(r) { return new SimplePromise((_, rej) => rej(r)); }
}

**Explanation & Complexity**- Uses microtasks via queueMicrotask so handlers run asynchronously like native Promises.- Supports chaining by returning new SimplePromise in then; fulfills with returned value or rejects on thrown errors.- Thenable assimilation implemented to adopt external promise-like objects.- Time/space: operations are O(1) per then; chaining creates new promise objects O(n) overall.

**Edge cases**- Self-resolution guarded, exceptions from executor and then handled, multiple calls to thenable.then guarded by `called`.

MediumTechnical

58 practiced

Implement a polyfill for Promise.allSettled named `allSettled(promises)` that accepts an iterable of Promises or values and returns a Promise that resolves to an array of result objects of the form `{status: 'fulfilled', value}` or `{status: 'rejected', reason}` in the input order. The implementation should work in environments that lack Promise.allSettled.

Sample Answer

**Approach**Use Promise.resolve to normalize inputs, map each to a promise that always fulfills with a result object, and return a Promise that resolves when all mapped promises settle using Promise.all.

**Implementation**

javascript

function allSettled(iterable) {
  // Convert iterable to an array to preserve order and allow multiple iterations
  const items = Array.from(iterable);
  const wrapped = items.map((p) =>
    // Normalize value to a Promise
    Promise.resolve(p)
      .then((value) => ({ status: 'fulfilled', value }))
      .catch((reason) => ({ status: 'rejected', reason }))
  );
  // Wait for all wrapped promises to resolve to their result objects
  return Promise.all(wrapped);
}

**Explanation & reasoning**- Promise.resolve makes non-promises behave like promises.- Each item is transformed to a promise that never rejects — it instead resolves to an object describing outcome.- Promise.all on those wrapped promises resolves only when every item has produced a result object, preserving input order.

**Complexity**- Time: O(n) extra scheduling; overall depends on input promises.- Space: O(n) for arrays of items and wrapped promises.

**Edge cases**- Empty iterable -> resolves to [].- Iterable that throws when iterated -> will throw synchronously (same as native behavior).- Non-iterable input -> Array.from will throw; callers should pass iterables.

HardTechnical

82 practiced

Implement a TokenBucket rate limiter in JavaScript with the following characteristics: a maximum capacity (burst), refill rate (tokens per second), and methods `tryRemove(count)` which returns true/false immediately and `remove(count)` which returns a Promise that resolves when tokens become available. Ensure the implementation scales to many concurrent callers efficiently without creating many timers.

Sample Answer

**Approach**- Track current tokens via lastRefill timestamp and calculate tokens on demand (no continuous timers).- For blocking removes, queue requests and schedule a single timer to resolve the earliest satisfiable request. This scales: only one timer when there's backlog.

**Implementation**

javascript

class TokenBucket {
  constructor({ capacity, refillRate }) {
    this.capacity = capacity;           // max tokens (burst)
    this.refillRate = refillRate;       // tokens per second
    this.tokens = capacity;             // current available tokens (lazy)
    this.last = Date.now();             // last refill timestamp (ms)
    this.queue = [];                    // waiting requests: {count, resolve}
    this.timer = null;
  }

  // refill tokens based on elapsed time (lazy)
  _refill() {
    const now = Date.now();
    const elapsed = (now - this.last) / 1000;
    if (elapsed <= 0) return;
    this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillRate);
    this.last = now;
  }

  // attempt immediate removal
  tryRemove(count = 1) {
    this._refill();
    if (count <= this.tokens) {
      this.tokens -= count;
      return true;
    }
    return false;
  }

  // remove with waiting; returns Promise resolving when tokens are removed
  remove(count = 1) {
    if (count > this.capacity) {
      return Promise.reject(new Error('Requested count exceeds capacity'));
    }
    this._refill();
    if (count <= this.tokens) {
      this.tokens -= count;
      return Promise.resolve();
    }
    return new Promise((resolve) => {
      this.queue.push({ count, resolve });
      // ensure single timer is scheduled to process queue when tokens become available
      if (!this.timer) this._scheduleNext();
    });
  }

  // compute ms until at least 'need' tokens available
  _msUntil(need) {
    this._refill();
    if (need <= this.tokens) return 0;
    const missing = need - this.tokens;
    return Math.ceil((missing / this.refillRate) * 1000);
  }

  // schedule timer to wake earliest waiter
  _scheduleNext() {
    if (this.queue.length === 0) { this.timer = null; return; }
    const nextNeed = this.queue[0].count;
    const ms = this._msUntil(nextNeed);
    this.timer = setTimeout(() => {
      this.timer = null;
      this._refill();
      // process as many queued requests as possible
      while (this.queue.length > 0 && this.queue[0].count <= this.tokens) {
        const req = this.queue.shift();
        this.tokens -= req.count;
        req.resolve();
      }
      // if still queued, schedule next wake
      if (this.queue.length > 0) this._scheduleNext();
    }, Math.max(0, ms));
  }
}

**Complexity & Notes**- tryRemove: O(1). remove: amortized O(1) per request; queue operations O(1).- Memory: O(waiters) for queued promises.- Edge cases: reject requests > capacity. Uses a single timer while backlog exists; no per-request timers.- Frontend use: works in browsers (setTimeout). For high-resolution rates consider using performance.now() if needed.

EasyTechnical

58 practiced

Implement a debounce utility in JavaScript:

`function debounce(fn, wait, immediate = false)`

It should return a debounced function that delays invoking `fn` until after `wait` milliseconds have elapsed since the last call. If `immediate` is true, `fn` is invoked on the leading edge. The implementation should preserve `this` and passed arguments and support canceling a pending call via a `cancel` method on the returned function.

Sample Answer

**Approach (brief)** Debounce keeps a timer; each call clears the previous timer and sets a new one. If `immediate` is true, call on the leading edge once and then ignore until wait passes. Preserve `this` and args by using closures. Expose a `cancel` method to clear pending invocation.

**Implementation**

javascript

function debounce(fn, wait, immediate = false) {
  let timer = null;
  let result;

  const debounced = function(...args) {
    const context = this;

    const later = () => {
      timer = null;
      if (!immediate) {
        result = fn.apply(context, args);
      }
    };

    const callNow = immediate && !timer;

    clearTimeout(timer);
    timer = setTimeout(later, wait);

    if (callNow) {
      result = fn.apply(context, args);
    }

    return result;
  };

  debounced.cancel = () => {
    if (timer) {
      clearTimeout(timer);
      timer = null;
    }
  };

  return debounced;
}

**Key points**- Preserves this/args via apply.- `immediate` causes leading-edge invocation; trailing invocation skipped in that call.- `cancel` clears pending trailing calls.

**Complexity**- Time: O(1) per call (clearing/setting timer). - Space: O(1).

**Edge cases**- Rapid repeated calls (works as expected). - Remember to call `cancel()` when unmounting event listeners in UI components.

Unlock Full Question Bank

Get access to hundreds of Asynchronous JavaScript and Event Loop interview questions and detailed answers.

Join thousands of developers preparing for their dream job.