277 JavaScript Frontend Developer Interview Questions & Answers

I would first validate that the input is a non-empty array. Then I make one pass through it while keeping a running sum and count. For each number, I verify that it is finite before adding it to the sum and increasing the count. At the end, I return sum divided by count. This works because every valid number contributes exactly once. The time complexity is O(n), and the auxiliary space complexity is O(1).

The function receives an array containing one or more finite numbers and returns their arithmetic mean. The mean is the total of all numbers divided by how many numbers there are. Duplicate and negative values are allowed. The function must not change the array. It must reject a non-array or any non-finite member with TypeError and reject an empty array with RangeError. A single pass with a running sum and count satisfies these requirements.

1. Should a non-array input throw TypeError?
2. Should an empty array throw RangeError?
3. Should NaN, Infinity, -Infinity, or other non-finite members throw TypeError?
4. Must the original array remain unchanged?

First, I check Array.isArray(values). If values is not an array, I throw TypeError. Next, I check values.length === 0. If the array is empty, I throw RangeError. These checks happen before calculating the mean.

I set sum = 0 and count = 0. The variable sum stores the total of all valid numbers processed so far. The variable count stores how many numbers have been processed. Before the loop starts, no numbers have been processed, so both values are 0.

I process the array from left to right with one for...of loop. For each number n, I check typeof n !== 'number' or !Number.isFinite(n). If either condition is true, I throw TypeError. Otherwise, I add n to sum and increase count by 1. The array itself is never changed.

For mean([2, -1, 5, 2]), the starting state is sum = 0 and count = 0.

Step 1: n = 2. It is finite. I add 2, so sum becomes 2 and count becomes 1. At this point, sum / count is 2 / 1 = 2.

Step 2: n = -1. It is finite. I add -1, so sum becomes 1 and count becomes 2. At this point, sum / count is 1 / 2 = 0.5.

Step 3: n = 5. It is finite. I add 5, so sum becomes 6 and count becomes 3. At this point, sum / count is 6 / 3 = 2.

Step 4: n = 2. It is finite. I add 2, so sum becomes 8 and count becomes 4. At this point, sum / count is 8 / 4 = 2.

After the loop, the function returns sum / count, which is 8 / 4 = 2.

After every completed iteration, sum equals the total of all array members processed so far, and count equals the number of members processed so far. Each valid number is added exactly once. Therefore, when the loop finishes, sum is the total of the whole array and count is its length. Dividing sum by count gives the arithmetic mean.

The implementation performs the array and empty-array checks first. It then initializes sum and count. The for...of loop processes each member once. Each member is checked with typeof and Number.isFinite before it affects the running state. Valid values update sum and count. Finally, the function returns sum / count.

The loop processes n array elements once, so the time complexity is O(n). Only a fixed number of variables are used, so the auxiliary space complexity is O(1). Non-array input causes TypeError. An empty array causes RangeError. NaN, Infinity, -Infinity, and any other non-finite member cause TypeError. Duplicates, negative values, zero, and a one-element array work correctly. The function does not mutate the input array.

Use a single-pass running-sum algorithm. First validate that values is an array and that it is not empty. Initialize sum = 0 and count = 0. Then process each number n in order. Before using n, verify that it is a number and that Number.isFinite(n) is true. Add each valid n to sum and increment count. Finally, return sum / count. The central invariant is that after each completed iteration, sum is the total of exactly the values processed so far and count is exactly how many values have been processed.

Let n be the array length. The function visits each member once, so the time complexity is O(n). It does not create another array or any collection that grows with the input. It only keeps sum, count, and the current loop value, so the auxiliary space complexity is O(1). The original input array is only read and is not modified.

A common mistake is checking only typeof n === 'number'. NaN and Infinity also have the JavaScript type number, so Number.isFinite is needed. Another mistake is forgetting the empty-array check, which would make the calculation invalid. Candidates may also divide by the wrong count, mutate the input unnecessarily, or make an extra copy of the array. Another mistake is giving the wrong complexity. This solution is O(n) time and O(1) auxiliary space.

Explain the invariant while you code: after every iteration, sum is the total of all values processed so far and count is the number of values processed so far. Then the final return sum / count follows directly.

I would keep pending tasks in a FIFO queue and track the number of running tasks. I start work only while activeCount is below the concurrency limit. Each running task gets its own AbortController. A pending abort removes and rejects that task before it starts. A running abort only forwards cancellation through its signal. When any task settles, I free its slot and schedule the next queued task. Queue operations are O(1) amortized, with O(n) auxiliary space.

This class controls how many asynchronous tasks may run at the same time. Each call to add returns a promise for that task. Extra tasks wait in the order they were added. When a running task finishes or fails, the oldest waiting task starts. A waiting task may be cancelled before it starts. A running task receives an abort signal, but the runner cannot force it to stop. close stops new additions and either lets waiting work drain or rejects it.

1. Should close() return a promise that resolves after all already accepted work has finished?
2. With cancelPending = true, should already running tasks continue? The approved design keeps them running and rejects only pending work.
3. For a running task, is cooperative cancellation through AbortSignal sufficient? The approved design assumes yes because the runner cannot forcibly stop arbitrary asynchronous JavaScript.

The constructor receives limit, which is the maximum number of tasks allowed to run together. add(task, { signal }) accepts a function. The runner calls that function with an internal AbortSignal. The function may return a normal value or a promise. add returns a promise for that result. activeCount is the number of running tasks. pendingCount is the number waiting in the FIFO queue. close rejects future additions. It either drains pending work or rejects pending work depending on cancelPending.

The main data structure is a FIFO queue. New pending tasks go to the back. The scheduler takes tasks from the front. The central invariant is that activeCount never becomes greater than limit. FIFO order is preserved because an older pending task is always selected before a newer pending task. Tasks may be added while other tasks are running.

Whenever capacity is available, the scheduler removes the oldest pending task and starts it. Starting a task increments activeCount and creates an AbortController for that task. The task call is placed inside a promise chain. This converts a synchronous throw into a rejected promise. When the task resolves or rejects, its add promise receives the same result. Cleanup then decreases activeCount and immediately runs the scheduler again. A failure therefore does not block later tasks.

The diagram uses limit = 2. Task A takes 300 ms. Task B takes 500 ms. Task C takes 400 ms. A, B, and C are added at time 0.

At t = 0 ms, A starts and activeCount becomes

1. B then starts and activeCount becomes
2. C cannot start because both slots are occupied, so C waits in the FIFO queue. pendingCount is 1.

At t = 300 ms, A finishes. Its slot becomes free. C is the oldest pending task, so C starts immediately. B and C are now running. activeCount stays 2 and pendingCount becomes 0.

At t = 500 ms, B finishes. C continues running. activeCount becomes 1.

At t = 700 ms, C finishes. activeCount becomes 0. The queue is empty and all three tasks are complete.

This gives the exact execution order shown in the diagram: A and B start first, then C starts as soon as A frees a slot.

If an external signal aborts while a task is still pending, the runner removes that task from the queue and rejects its add promise. The task is never called. If the signal aborts after the task has started, the runner aborts the task's internal AbortController. The task receives signal.aborted and may stop cooperatively. The runner cannot force it to stop.

close({ cancelPending: false }) marks the runner closed, so later add calls reject. Already accepted work continues and the queue drains normally. close({ cancelPending: true }) instead rejects all tasks that are still pending. Running tasks are not forcibly stopped. The close promise resolves after no running or pending work remains.

The scheduler checks capacity before every start, so activeCount cannot exceed limit. The queue always removes the oldest pending entry, so pending tasks start in FIFO order. Every running task releases exactly one slot when it settles. Cleanup schedules more work even after rejection, so failures cannot stall the runner. Pending aborts remove work before execution. Running aborts only forward the signal. These rules match every transition in the diagram.

Adding a task, taking the oldest task, removing a known pending task, starting a task, and handling one task settlement use O(1) queue bookkeeping in the implementation below. Rejecting all pending work during close({ cancelPending: true }) takes O(p), where p is the number of pending tasks. The runner stores pending entries and cancellation bookkeeping, so auxiliary space is O(n). Important cases are synchronous throws, rejected promises, abort before start, abort while running, adding after close, and repeated close calls.

Use a bounded FIFO scheduler. Each pending task is a queue entry containing the task, its promise callbacks, its external AbortSignal, and queue links. The scheduler repeatedly starts the oldest pending entry while activeCount is less than limit. The central invariant is activeCount <= limit. FIFO is preserved because entries are added at the tail and removed from the head. Each settlement releases one slot and triggers scheduling again, so failures cannot stop the queue. A pending abort removes the entry before execution. A running abort is forwarded through that task's internal AbortController.

The queue implementation keeps direct previous and next links, so enqueue, dequeue, and removal of a known pending entry take O(1) time. Starting a task and handling one task settlement also use O(1) runner bookkeeping. close({ cancelPending: true }) must visit every pending task that it rejects, so that call takes O(p), where p is the number of pending tasks. The actual tasks may take any amount of time because their work is outside the scheduler. Auxiliary space is O(n) for queued entries, signals, listeners, and bookkeeping.

One mistake is starting every task immediately instead of checking activeCount against limit. Another is breaking FIFO order by taking a newer pending task first. A candidate may treat aborting a running task as forced termination, even though the runner can only forward an AbortSignal. It is also easy to forget that a synchronous throw must reject the promise returned by add. Another common bug is scheduling the next task only after success, which makes one rejection stall the queue. Finally, abort listeners should be removed when they are no longer needed.

State the two invariants before coding: activeCount never exceeds limit, and pending tasks start in FIFO order. Then show that every success, rejection, or synchronous throw reaches the same cleanup path, which releases one slot and schedules the next task.

I would render the vnode tree with an explicit depth-first stack instead of recursion. Strings become text nodes with createTextNode. Element vnodes are validated, created with createElement, and their allowed props are applied safely. I keep an active-ancestor Set to detect only real cycles, then process each parent’s children from left to right. This preserves order and supports depth 10,000. The expected time is O(n + p), and auxiliary space is O(h).

This problem asks us to turn a small tree-shaped description into real browser nodes. A string becomes text. An object describes an HTML element, its settings, and its children. We must build one new node and return it without placing it on the page. We must reject unsafe or invalid input, keep children in the same order, and support very deep trees. The main idea is to build the tree with our own explicit stack, so depth 10,000 does not depend on JavaScript recursion.

1. Should props and children always be present on every element vnode?
2. Should Boolean attributes be accepted only from the supported HTML Boolean-attribute set shown in the solution?
3. If the same vnode object is reused in two separate branches without forming a cycle, should that be allowed?

A text vnode is a string. An element vnode is an object with type, props, and children. The function returns one newly created DOM Node. It does not insert that node into the document. Text must use createTextNode. Elements must use createElement. The function rejects invalid tags, cyclic children, unsafe HTML props, unknown event keys, and invalid attribute values.

The solution uses iterative depth-first traversal. A stack frame stores { vnode, node, childIndex }. This tells us which virtual node we are processing, which real DOM node belongs to it, and which child comes next. An active Set stores only element vnodes on the current ancestor path. That catches a real cycle but still allows the same vnode object to be reused later in a different non-cyclic branch. The explicit stack replaces recursion and avoids recursive stack overflow.

className, style, and dataset use the specified DOM properties. Boolean attributes use presence or absence: true calls setAttribute(key, ''), while false leaves the attribute out. Ordinary attributes must contain strings and use setAttribute. Only onClick, onInput, and onChange are allowed event keys, and their values must be functions. innerHTML, dangerouslySetInnerHTML, and every other on... key are rejected. No string is evaluated as code.

The example vnode has type button, className save, disabled set to true, and one child string, Save. First, the tag name is validated. Then the code creates a <button> element. It sets className to save. Because disabled is true, it adds the disabled attribute. The next child is the string Save, so the code creates a text node and appends it. The button frame then finishes, leaves the active Set, and is popped.

A frame is finished when childIndex reaches children.length. At that point, its vnode is removed from active and the frame is popped. Processing continues until the stack is empty. The final returned node is the newly created <button class="save" disabled>Save</button> node. It has not been inserted into the document.

Children are read from index 0 upward, so each parent’s DOM children are appended in the same order as the vnode children. Every string uses createTextNode, and every element uses createElement. The active Set contains exactly the element vnodes on the current path, so an object found there would create a cycle. Removing a vnode when its frame finishes allows safe reuse in a different branch.

Let n be the number of vnodes and p be the total number of property entries processed, including entries inside style and dataset. With average O(1) Set and Map operations, the expected time is O(n + p). Let h be the maximum element-tree depth. The explicit stack and active-ancestor Set both grow with the current path, so auxiliary space is O(h), excluding the returned DOM tree. Important cases are empty children, mixed text and element children, depth up to 10,000, invalid props or tag names, unknown event keys, and cyclic child references.

The key idea is to simulate recursive depth-first rendering with an explicit stack. Each frame stores the current vnode, its real DOM node, and the next child index. The central invariant is that active contains exactly the element vnodes on the current ancestor path. Children are processed from index 0 upward and appended immediately, so DOM child order matches vnode child order. When a frame finishes, its vnode leaves active, so repeated vnode objects in separate non-cyclic branches are allowed. This explicit stack avoids recursive call-stack overflow.

Let n be the number of vnodes and p be the total number of property entries processed, including entries inside style and dataset. With average O(1) Set and Map operations, the expected time is O(n + p). Let h be the maximum element-tree depth. The explicit stack and the active-ancestor Set contain only the current path, so auxiliary space is O(h), excluding the returned DOM tree. This avoids using the JavaScript call stack, which is why depth 10,000 can be supported.

1. Using recursion, which can overflow the JavaScript call stack at depth 10,000.
2. Using one global visited Set, which wrongly rejects a vnode reused in a different non-cyclic branch.
3. Processing children in the wrong order or forgetting to remove a finished vnode from the active-ancestor Set.
4. Using innerHTML, accepting unknown on... event keys, or evaluating strings instead of requiring event-handler functions.
5. Treating ordinary attributes as arbitrary values instead of requiring strings, or handling false Boolean attributes as present instead of omitted.

Explain the active Set carefully. Say that it tracks only the current ancestor path, not every vnode ever seen. That one detail shows why real cycles are rejected while safe reuse in another branch still works.

An algorithm is a finite and clear sequence of steps that transforms valid input into the required output. In this example, I use linear search on [3, 7, 1, 9, 7, 4] to find 7. I check values from left to right and stop at the first match, which is index 1. The same steps work with a JavaScript Array or TypedArray. The search takes O(n) time and O(1) auxiliary space.

An algorithm is a clear set of steps for solving a problem. The steps must have one clear meaning and must eventually finish. Here, the input is [3, 7, 1, 9, 7, 4], and the target is 7. We want the index of the first matching value. Linear search fits because it checks each value from left to right and can stop when it finds the target. The same search steps can work with either a JavaScript Array or a TypedArray.

1. Should I return the index of the first matching value?
2. What should I return when the target is not present?
3. Can the input be empty or contain duplicate values?

The input is a sequence of values and a target value. In the diagram, the input is [3, 7, 1, 9, 7, 4], and the target is 7. The required output is the index of the first matching value. The answer is index 1 because the value at index 1 is 7. If no match exists, the function returns -1.

Linear search checks the input from the beginning, one item at a time. It fits because the values are not shown as sorted. At each index, compare the current value with the target. If they are equal, return the current index immediately. Otherwise, move to the next item.

Start at index 0. The current value is 3. Check whether 3 === 7. It is false, so move to the next index.

Now check index 1. The current value is 7. Check whether 7 === 7. It is true, so return index 1 and stop. Indices 2 through 5 are not processed because the answer has already been found.

Before checking index i, every earlier index has already been checked and did not contain the target. Therefore, the first successful comparison gives the first matching index. If the loop reaches the end without a match, then every valid index has been checked, so returning -1 is correct. The loop also always terminates because the index increases by one each time and cannot continue past the input length.

The same linearSearch function works with a normal JavaScript Array and an Int32Array. Both provide indexed access and a length property, so the search steps do not change. For [3, 7, 1, 9, 7, 4] with target 7, both versions return index 1. Only the structure that stores the values changes.

Let n be the number of input items. Linear search checks at most n items, so its time complexity is O(n). It uses only a fixed amount of extra state, so its auxiliary space complexity is O(1). Important boundary cases are an empty input, a single item, the target at the first or last position, duplicate target values, and a target that is not present.

The key idea is to scan the input from left to right and return as soon as the target is found. The invariant is: before checking index i, every earlier index has already been checked and does not contain the target. This means the first successful comparison gives the first matching index. If no comparison succeeds, returning -1 is correct because every valid position was checked. The same algorithm works with both Array and Int32Array because both support indexed access and a length property.

Let n be the number of items in the input. The algorithm checks at most n items, so the time complexity is O(n). It can stop earlier when it finds the target. The algorithm uses only a small fixed amount of extra state, mainly the loop index, so the auxiliary space complexity is O(1). The Array and TypedArray versions shown in the diagram use the same search steps and have the same complexity.

A common mistake is returning the value 7 instead of its index 1. Another mistake is continuing after the first match even though the diagram returns the first matching index. Candidates may also forget to return -1 when the target is absent. With duplicate values, they should return the first match because the search moves from left to right. Another mistake is claiming O(1) time because one indexed access is constant time. The full search may still inspect up to n items, so the time complexity is O(n).

Walk through the first two positions aloud: index 0 contains 3, so continue; index 1 contains 7, so return 1 and stop. This makes the processing order, early return, correctness, and complexity easy to explain.

I would keep the counter value inside the factory so each returned function has its own private state. First, I validate that initial is a number and a safe integer. Then I store it in current. On each call, I save the current value, increment current by one, and return the saved value. This makes separate counters independent and prevents direct state mutation. Each call takes O(1) time, and each counter keeps O(1) retained space.

The task is to create a function that makes an independent counter. The caller gives a starting whole number, or 0 is used by default. The returned function takes no arguments. Each time it is called, it gives back its current number and then moves to the next number. Different counters must remember different values. Outside code must not be able to directly change the remembered number. Invalid input must throw the required error. For the given example, starting at 3 makes three calls return 3, 4, and 5.

1. If the counter eventually moves beyond JavaScript's safe-integer range, should it continue using normal number behavior, or should that later state be rejected?
2. Are only the required error types important, or do you also want specific error messages?

makeCounter(initial = 0) receives one starting value. The starting value must be a JavaScript number and must pass Number.isSafeInteger. The function returns another function that takes no arguments. Each time that returned function runs, it returns the current stored value and then increases the stored value by one.

The solution uses a closure. A closure means the returned function keeps access to variables created inside makeCounter even after makeCounter has finished. We store the private counter value in current. Outside code cannot directly access that local variable. Every call to makeCounter creates a different current, so separate counters do not share state.

First, check typeof initial !== 'number'. If that condition is true, throw TypeError. Next, check Number.isSafeInteger(initial). If that condition is false, throw RangeError. After validation, set current = initial. In the diagram example, current starts at 3.

Create const c = makeCounter(3). The private state is now current = 3. On the first call, save 3, change current to 4, and return 3. On the second call, save 4, change current to 5, and return 4. On the third call, save 5, change current to 6, and return 5. Therefore [c(), c(), c()] produces [3, 4, 5]. If we called it again, it would return 6 and then change current to 7.

The main invariant is that before each call, current is exactly the value that the next call must return. The function saves that value before changing the state. It then increments current by one. This means every call returns the correct current value, and the following call sees the next integer. Each factory call creates its own closure, so different counters stay independent.

The outer function validates the starting value and creates the private current variable. The returned zero-argument function reads current into value, increments current, and returns value. The code uses no globals, class fields, timers, or external libraries. Because current is local to the factory and only the returned function closes over it, callers cannot directly mutate it.

Each counter call performs a fixed amount of work: read one value, increment once, and return one value. That is O(1) time per call. Each counter keeps one private numeric state value, so retained space is O(1). A non-number input throws TypeError. A numeric value that is not a safe integer, such as 1.5, NaN, or Infinity, throws RangeError. Negative safe integers and zero are valid starting values.

Use a closure to store one private variable named current. Validate the starting value before creating the counter. The central invariant is: before every invocation, current is the exact value that the next call must return. The returned function first copies current into a local variable, then increments current, then returns the saved value. Saving before incrementing is required because the contract says to return the current value first. Every call to makeCounter creates a new closure, so separate counters keep separate state.

Each call to the returned counter does a fixed amount of work. It reads the current number, saves it, adds one to the private state, and returns the saved number. Therefore each call takes O(1) time. Each counter keeps only one private current value between calls. The amount of retained memory does not grow as the counter is used, so retained space per counter is O(1).

A common mistake is incrementing current before saving it. That would make a counter starting at 3 return 4 first. Another mistake is storing the counter value in a global variable, which would make different counters share state. Candidates may also throw the wrong error type by treating every invalid value the same. Another mistake is exposing current through an object or property, which would let callers mutate it directly. It is also incorrect to claim that retained space grows with the number of calls.

State the invariant before writing the returned function: current is always the value that the next call should return. Then implement the operation in the same order as the diagram: save current, increment the private state, and return the saved value.

I would use a rest parameter so the function receives every supplied argument in one array called args. JavaScript keeps explicit undefined values in that array, so the exact number of supplied arguments is args.length. I do not need to inspect the values, parameter names, function .length, or the caller. I simply return args.length. Reading the count takes O(1) time with respect to argument inspection and O(1) additional space beyond the required rest-parameter array.

The function needs to report how many values were actually supplied when it was called. A value still counts when that value is undefined or null. Extra arguments also count. The simple idea is to collect every supplied argument into one array and return that array's length. JavaScript rest parameters do exactly this. For numberOfArguments(undefined, null, 3), the collected array is [undefined, null, 3], so its length and the returned result are both 3.

1. Should an explicit undefined value count as an argument? Yes, the question says it should.
2. Should the function accept any number and type of JavaScript values? Yes, including extra arguments.

The input is any number of JavaScript values supplied at the call site. The output is one number: the exact count of those supplied arguments. Calling the function with no arguments returns 0. Passing undefined still adds one argument because that value was explicitly supplied.

Use a rest parameter written as ...args. JavaScript collects all supplied arguments into the args array. This keeps the important difference between an omitted argument and an explicit undefined argument. The central rule is simple: every supplied argument becomes one element in args.

Call numberOfArguments(undefined, null, 3). Three arguments are supplied at the call site. Inside the function, ...args creates [undefined, null, 3]. The array has length 3. The function reads args.length and returns 3. No argument value is inspected or changed.

The rest parameter creates one array element for every argument supplied at the call site. Therefore, args.length is exactly the number of supplied arguments. Explicit undefined is still one array element. A completely omitted argument creates no element. Any extra arguments are also collected and counted.

The function declaration uses ...args to collect all supplied values. There is no loop and no condition because the actual values do not matter. The function reads the length property of the collected array and immediately returns it. It does not inspect parameter names, function .length, the caller, or the contents of the arguments.

Reading args.length is O(1) with respect to argument inspection because the function does not scan the argument values. The diagram describes O(1) additional space beyond the rest-parameter array created by JavaScript. Important cases are zero arguments, explicit undefined, arbitrary JavaScript values, extra arguments, and not mutating any supplied argument.

The key insight is that a JavaScript rest parameter already records exactly which arguments were supplied. The function declares ...args, so each supplied argument becomes one element of the args array. The invariant is that args.length equals the number of arguments supplied at the call site. Because the answer is already available as the array length, there is no need to inspect values or loop through them. Returning args.length directly gives the required count.

Time is O(1) with respect to argument inspection. The function only reads the array's length property and does not loop through the argument values. The diagram describes O(1) additional space beyond the args array created by the required rest parameter. The function itself creates no other data structure that grows with the number of arguments.

A common mistake is using the function's .length property. That reports the number of declared parameters, not the number supplied at a particular call site. Another mistake is treating explicit undefined as if the argument were omitted. It must still count. Candidates may also loop through args even though only args.length is needed. Another mistake is inspecting the caller or parameter names, which the question forbids. The function also must not mutate any supplied argument.

State the key distinction early: omitted and explicit undefined are different at the call site. Then show that ...args preserves this distinction automatically, so returning args.length is enough.

I would validate the delay first, then check whether the optional signal is already aborted. If it is valid, I return a Promise, start a browser setTimeout, and attach one abort listener. If the timer fires first, I remove the listener and resolve with undefined. If abort happens first, I clear the timer, remove the listener, and reject with the abort reason. The computational work is O(1), and the auxiliary space is O(1).

The goal is to create a small sleep function for browser JavaScript. It waits for a requested delay and then finishes with undefined. The delay must be a finite number from 0 through 60,000. The caller may also provide a cancellation signal. If cancellation has already happened, or happens before the wait finishes, the function rejects instead. This approach fits because a browser timer handles the delay, while one cancellation listener handles the optional early stop.

1. Should values such as strings, NaN, Infinity, negative numbers, and values above 60,000 be rejected? Yes. The contract requires that behavior.
2. If the AbortSignal has a reason, should that exact reason be used for rejection? Yes. Otherwise, the diagram uses new DOMException("Aborted", "AbortError").

First, I check ms. It must be a JavaScript number and it must be finite. If either check fails, I throw TypeError. Then I check the allowed range. A value below 0 or above 60,000 throws RangeError. A delay of 0 is valid.

Before creating the timer, I check signal?.aborted. If it is already true, I return a rejected Promise immediately. I reject with signal.reason when it is available. Otherwise, I use new DOMException("Aborted", "AbortError").

The diagram uses await sleep(100, { signal: controller.signal }), where controller.signal is not aborted. I create a new Promise and start setTimeout for 100 milliseconds. The Promise remains pending while the timer is waiting.

After starting the timer, I define onAbort and attach it with { once: true }. If abort happens before the timer fires, onAbort clears the timer, removes the abort listener, and rejects with signal.reason or the AbortError fallback.

In the diagram example, no abort happens. After at least 100 milliseconds, the timer callback runs. It removes the abort listener and resolves the Promise with undefined. Therefore, the exact result is undefined after at least 100 milliseconds.

While the Promise is pending, this call has one timer and at most one abort listener. The timer path resolves the Promise only after the requested delay. The abort path cancels the pending timer and rejects instead. Each path removes the listener as part of cleanup. A Promise can settle only once, so only one final result is observed.

The function does a fixed amount of computational work, so its computational complexity is O(1). Its auxiliary space is O(1). sleep(0) is valid and still settles asynchronously because setTimeout runs its callback after the current synchronous stack. Other important cases are an already-aborted signal, an abort before the timer fires, a negative delay, a delay above 60,000, and a non-finite delay.

The key idea is to let one browser timer and one optional AbortSignal control the same Promise. First, validate ms and handle an already-aborted signal. Then create the Promise, start setTimeout, and attach one abort listener. The central invariant is that while the Promise is pending, the call owns at most one active timer and one abort listener. If the timer wins, remove the listener and resolve with undefined. If abort wins, clear the timer, remove the listener, and reject. Promise settlement guarantees that only one outcome becomes the result.

The computational work is O(1). The function performs a fixed number of checks, starts one timer, and optionally attaches one event listener. The real-world waiting time is at least ms milliseconds, but that waiting does not mean the JavaScript function is doing O(ms) computational work. The auxiliary space is O(1) because each call keeps only a fixed amount of extra state: one Promise, one timer handle, and at most one abort handler.

Common mistakes are checking only typeof ms === "number" and accidentally accepting NaN or Infinity, forgetting the inclusive 0 through 60,000 range, failing to check an already-aborted signal, rejecting on abort without clearing the pending timer, or forgetting to remove the abort listener during cleanup. Another mistake is resolving with some timer value instead of undefined. Candidates may also incorrectly make sleep(0) synchronous or omit the AbortError fallback used by the approved solution.

Describe the implementation as two competing settlement paths. The timer path removes the listener and resolves with undefined. The abort path clears the timer, removes the listener, and rejects. Explaining those two paths makes the cleanup and correctness easy to verify.

I would validate the callback and delay first. Then I would schedule exactly one browser timeout and keep its handle plus a done flag in the closure. When the timeout fires, I check done, mark it true, and call callback(...args). The returned cancel function also checks done. If it is still false, it clears the timeout and marks the operation finished. This makes cancellation idempotent and keeps the callback at most once. Scheduling, cancellation, and wrapper execution are O(1) time with O(1) auxiliary space.

This function schedules one callback to run later. It receives the callback, a delay, and any extra values to pass to the callback. It must also return a cancel function. If cancel is called before the scheduled callback runs, the callback must never run. Calling cancel again must be harmless. Calling cancel after the callback already ran must also be harmless. The solution stores the timeout handle and a done flag so both the timeout path and cancel path know whether the operation is already finished.

1. Should an invalid callback throw a TypeError and an invalid delay throw a RangeError?
2. Should a delay of 0 still use the normal asynchronous setTimeout behavior?

The callback must be a function. If it is not, throw a TypeError. The delay must be a finite number that is zero or greater. If it is not, throw a RangeError.

Call setTimeout exactly once and save its handle as timerId. The timeout is scheduled for the requested delay. Keep a Boolean flag named done. It starts as false. A false value means the operation has not finished or been cancelled yet.

When the timeout callback gets its turn, first check done. If done is already true, return without invoking the user's callback. Otherwise set done to true and call callback(...args). The call uses the ordinary function-call form. In strict-mode receiver semantics, that means no custom receiver is supplied.

The function returns a zero-argument cancel function. cancel first checks done. If done is already true, it returns immediately. Otherwise it calls clearTimeout(timerId) and marks done as true. This prevents the pending timeout from invoking the callback. Repeated cancellation and cancellation after execution therefore have no additional effect.

The diagram uses const cancel = setCancellableTimeout(log, 10, 'x'); cancel();. At 0 ms, timeout T1 is scheduled for 10 ms and done is false. In the execution trace, cancel is called at about 2 ms, before T1 fires. cancel clears T1 and changes done to true. At 10 ms, T1 would have fired, but it was cancelled. The callback does not run, so log('x') never executes.

The central invariant is that done tells both paths whether this timeout operation is already finished. Only a path that sees done as false can take the finishing action. The timeout path marks done before calling user code. The cancel path clears the pending timeout and marks done. Therefore the callback is invoked at most once, and cancellation is harmless when repeated or performed after execution.

Scheduling is O(1). Cancellation is O(1). The wrapper work when the timeout fires is O(1), excluding work performed inside the user's callback. The closure keeps only the timeout handle and one Boolean flag, so auxiliary space is O(1). Relevant edge cases are delay 0, repeated cancellation, cancellation after execution, a non-function callback, and a non-finite or negative delay.

The key idea is to share one closed-over state flag between the scheduled timeout and the returned cancel function. The invariant is: when done is false, the operation is still pending and the callback may run; when done is true, the operation is finished and this timeout must not start the callback. A single timerId identifies the one scheduled timeout. The timeout path checks done, marks it true, then invokes callback(...args). The cancel path checks the same flag, clears timerId, and marks done true. Because both paths use the same finished state, cancellation is idempotent and callback execution is limited to at most once.

Creating the timeout takes O(1) time. Calling cancel takes O(1) time. When the timeout fires, the wrapper itself also performs O(1) work before calling the user's callback. Work done inside the user's callback is separate. The function keeps only one timeout handle and one Boolean flag in its closure, so auxiliary space is O(1).

A common mistake is returning the timeout handle instead of the required zero-argument cancel function. Another is scheduling more than one timeout. Candidates may forget to make repeated cancel calls harmless or forget that cancel after execution must also be harmless. Input validation is another common source of errors, especially accepting Infinity, NaN, or a negative delay. It is also important to mark done before invoking user code and to call callback(...args) normally rather than supplying a custom receiver.

Explain the done flag as the shared invariant first. Say that the timeout path and cancel path both consult the same finished state. Then walk through T1: schedule it for 10 ms, cancel it before 10 ms, clear T1, set done to true, and show that log('x') never runs.

I would wrap the callback API in a function that returns a Promise. The wrapper forwards the original this value and arguments, then appends one error-first callback. I use a called flag so only the first settlement attempt matters. A non-nullish error rejects the Promise. Otherwise, the value fulfills it. I also convert synchronous throws into rejection and clear stored argument and context references after settlement. The control logic uses O(1) extra state besides the forwarded arguments.

The goal is to turn a function that reports its result through a callback into one that returns a Promise. The new function must pass along the same this value and arguments. It adds one callback that receives an error and one value. The first settlement attempt decides the result. A real error rejects the Promise. A null or undefined error fulfills it. A synchronous throw also becomes a rejection. After settlement, the wrapper clears its stored argument and context references. In the given example, calling the promisified function with 4 must fulfill with 8.

1. Should a non-function produce a rejected Promise when the returned wrapper is called?
2. Should only the first callback invocation affect the Promise?
3. Should both null and undefined mean that no error occurred?

The input to promisify is fn, an error-first callback function. promisify returns another function. When that returned function is called, it must return a Promise. It forwards the same this value and original arguments to fn. It also appends a callback with the shape (error, value).

If error is not nullish, the Promise rejects with that error. Nullish means null or undefined. Otherwise, the Promise fulfills with value. Only the first settlement attempt is allowed to affect the Promise.

The returned wrapper receives ...args and saves its current this value in context. It then creates and returns a Promise.

Inside the Promise, the code checks whether fn is a function. If it is not, the wrapper clears args and context, rejects the Promise with TypeError, and returns.

For a valid function, called starts as false. This flag tells us whether the Promise has already been settled by the callback or by a caught synchronous throw.

The appended callback receives error and value. It first checks called. If called is already true, it returns immediately. This ignores repeated callback calls.

On the first callback call, it changes called to true. It then clears args and context so those wrapper-held references do not remain after settlement.

Next, it checks error. If error != null, it rejects with error. Otherwise, it resolves with value.

The wrapper invokes the original function with fn.apply(context, [...args, callback]). This forwards the captured this value. It forwards every original argument and places the new callback last.

The call is inside try/catch. If fn throws before anything has settled, the catch block sets called to true, clears args and context, and rejects with the thrown error. If a synchronous callback already settled first and fn then throws, the catch block sees that called is true and returns without changing the Promise result.

The example function is (x, cb) => setTimeout(() => cb(null, x * 2), 0). We create doubleAsyncP = promisify(doubleAsync), then call doubleAsyncP(4).

The wrapper captures its this value and the argument 4. It creates a Promise and calls doubleAsync with 4 and the appended callback. Later, doubleAsync calls that callback with null and 8.

called is false, so this is the first settlement. The wrapper sets called to true, clears args and context, sees that error is null, and resolves with 8. The returned Promise therefore fulfills with 8.

The central invariant is that called is false before the first settlement and true after it. Every later callback call or caught synchronous throw checks this state before trying to settle again. Therefore, only the first settlement attempt can affect the result.

The error test also matches the required contract. Null and undefined follow the success path. Any other error value follows the rejection path.

The wrapper uses a fixed amount of bookkeeping state: context, called, and the callback. The diagram describes this control overhead as O(1) extra state besides the forwarded arguments. Forwarding a arguments requires handling those a supplied values, and the spread used for invocation materializes an argument list proportional to a.

Important edge cases are a non-function fn, repeated callback calls, null or undefined errors, a synchronous throw, and a throw that happens after a synchronous callback already settled the Promise.

The key idea is to place the callback-style API behind a Promise wrapper and use one boolean, called, as the settlement invariant. Before settlement, called is false. The first callback or synchronous throw changes the state to settled. Every later settlement attempt returns without changing the result. The callback rejects when error != null and otherwise resolves with value. apply preserves the original this value, the original arguments are forwarded, and the callback is appended last. The wrapper clears its stored args and context references when the operation settles.

The diagram shows O(1) wrapper control overhead and O(1) bookkeeping state besides the forwarded arguments. The wrapper itself keeps only a fixed number of control values such as context and called. If a is the number of supplied arguments, JavaScript must also represent those a arguments, and [...args, callback] creates an invocation array proportional to a. So the fixed control work is O(1), while materializing and forwarding the argument list takes O(a) time and temporary O(a) storage. After settlement, the wrapper clears its stored args and context references.

One mistake is allowing every callback invocation to try to settle the Promise instead of guarding settlement with called. Another is checking only error === null, which incorrectly treats undefined as failure. Candidates may also lose the original this value by calling fn without the saved context. Another mistake is forgetting to catch a synchronous throw from fn. It is also easy to forget the case where the callback settles synchronously and fn throws afterward. Finally, the wrapper should clear its stored args and context references after settlement.

Explain the called flag as the single-settlement invariant before writing the callback. Then show that both the callback path and the synchronous-throw path obey that same flag. This makes the repeated-callback case and the callback-then-throw case easy to justify.

I would use depth-first search to walk through the nested object or array. Each recursive call carries the current dot-delimited path. When I reach a valid primitive, I store it in a null-prototype result object. Empty objects and arrays are stored at their own path. A WeakSet tracks containers on the active recursion path so cycles are detected. I also reject dotted keys and unsupported values. The traversal is O(N) time, with O(D) recursion depth and O(N) storage including the result.

The input is one plain object or array that can contain simple values, more plain objects, and arrays. The goal is to replace the nested shape with path-value entries. Object keys become path parts. Array positions become decimal path parts. Empty containers must still appear in the result. The original input must not be changed. The solution walks through the structure with depth-first search and builds the correct path while it moves deeper.

1. Should empty objects and arrays be kept in the flattened result? Yes, the question requires this.
2. Should array indexes be written as decimal path segments such as "c.0" and "c.1"? Yes.
3. Should cycles, unsupported values, invalid container types, and object keys containing "." cause an error? Yes.

The root must be a plain object or an array. Valid leaf values are null, strings, numbers, and booleans. Plain objects and arrays can appear at any depth. Symbols, functions, bigint values, cycles, and object keys containing "." are invalid. Other object types such as Date, Map, Set, and class instances are also rejected because they are not plain objects. The function returns an object created with Object.create(null). Its keys are paths such as "a.b" and "c.1.d".

I use recursive depth-first search. Each recursive call receives the current value and the path to that value. If the value is a valid primitive, I write it to the result. If it is an array or plain object, I visit its children. The main invariant is simple: every helper call receives the exact path of its current value from the root.

A WeakSet named seen tracks only containers on the active recursion path. Before entering a container, I check whether it is already in seen. If it is, there is a cycle. After finishing that container, I remove it from seen. This backtracking means the same object may appear again through a different non-cyclic branch without being mistaken for a cycle.

The result starts as Object.create(null). This creates an object with no Object.prototype inheritance. The seen WeakSet starts empty. The first recursive call is helper(input, ""), so traversal begins at the root with an empty path.

The example input is {a:{b:1}, c:[2,{d:3}]}.

Step 1 starts at the root. The root is a non-empty plain object, so DFS visits its keys.

Step 2 visits a at path "a". Its value is {b:1}. This object is not empty, so DFS continues inside it.

Step 3 visits b with value 1 at path "a.b". The value is a primitive, so the algorithm stores result["a.b"] = 1. The result is now {"a.b":1}.

Step 4 returns to the root and visits c at path "c". Its value is [2,{d:3}]. The array is not empty, so DFS visits its indexes.

Step 5 visits index 0. The value is 2 and the path is "c.0". The algorithm stores result["c.0"] = 2. The result is now {"a.b":1,"c.0":2}.

Step 6 visits index 1. The value is {d:3} and the path is "c.1". It is a non-empty plain object, so DFS continues inside it.

Step 7 visits d with value 3 at path "c.1.d". The algorithm stores result["c.1.d"] = 3. The final result is {"a.b":1,"c.0":2,"c.1.d":3}.

Every recursive call carries the exact location of its value. Object keys add one key segment. Array positions add one decimal index segment. Therefore, every primitive is stored under the path that identifies its original position. Empty objects and arrays are written at their own path instead of disappearing. The WeakSet prevents infinite recursion because revisiting a container that is still on the active DFS path means a cycle exists.

The function first checks that the root is an array or plain object. It creates the null-prototype result and the WeakSet. The helper rejects symbol, function, and bigint values before doing anything else. It stores valid primitives immediately. Any remaining value must be an array or plain object. The helper checks for a cycle before descending. Arrays are processed from index 0 upward. Plain objects are processed with Object.keys. Every object key is checked for a dot before recursion. Empty containers are stored directly at their current path. After a container is finished, it is removed from seen.

The diagram gives O(N) time, where N is the total number of visited objects, arrays, and primitive values. The recursion depth is O(D), where D is the maximum nesting depth. The returned result and cycle-tracking state can grow with the input, so the diagram summarizes storage as O(N), plus the O(D) recursion stack. Important cases are empty objects, empty arrays, deep nesting, dotted keys, cycles, unsupported primitive types, and non-plain object containers.

Use recursive depth-first search. The helper receives the current value and its dot-delimited path. A valid primitive becomes one result entry. An empty object or array also becomes one result entry at its current path. For a non-empty array, recurse through indexes in order. For a non-empty plain object, recurse through Object.keys in order after rejecting keys containing a dot. A WeakSet tracks containers on the active recursion path. The central invariant is that every helper call receives the exact path of its value in the original input. Removing a container from the WeakSet after processing its children restores the path-local state.

The diagram gives O(N) time, where N is the total number of visited objects, arrays, and primitive values. Each reachable value is handled once by the DFS traversal. The maximum recursion depth is O(D), where D is the deepest nesting level. The flattened result grows with the input, and the cycle-detection state also uses memory. Following the diagram, total stored output and traversal bookkeeping are O(N), with an additional O(D) recursion stack.

A common mistake is to recurse into every JavaScript object. That would incorrectly accept Date, Map, Set, or class instances instead of only arrays and plain objects. Another mistake is forgetting to preserve empty objects and arrays, which makes them disappear from the output. Candidates may also forget to reject object keys containing a dot, build array paths incorrectly, or mutate the original input. Cycle detection must be path-local. If a container is never removed from seen after recursion, a shared reference can be incorrectly reported as a cycle.

Explain the invariant before writing the recursion: every helper call receives the exact flattened path of its current value. Then show how one object key or array index extends that path. This makes the primitive case, empty-container case, cycle check, and final output much easier to explain.