277 JavaScript Frontend Developer Interview Questions & Answers

Big O notation describes how an algorithm’s running time or extra-space use grows as the input size n grows. It describes growth, not exact milliseconds. Common rates are O(1), O(log n), O(n), O(n log n), and O(n²). In JavaScript, examples include direct array access, binary search, one full loop, efficient comparison-style sorting, and nested pair comparisons. I use the expected input size to decide which growth rate is practical for the problem.

Big O helps us understand what happens when an input becomes larger. We can use it for running time or for extra memory. It does not tell us exactly how many milliseconds a program will take. Different computers and browsers can have different measured times. Big O focuses on how the amount of work grows as n grows. The diagram compares five common growth rates using small JavaScript examples. This helps us choose a solution that will still be practical for the expected input size.

1. Are we analyzing running time, extra-space use, or both?
2. What input size should the solution handle?
3. Do you want the worst-case growth rate, the typical growth rate, or both?

Let n mean the input size. Big O describes how running time or extra-space use grows as n grows. It focuses on the growth pattern rather than exact elapsed time. Constant factors and smaller-order terms normally do not change the Big O class.

The diagram uses direct array access. The function first(arr) returns arr[0]. This performs one direct lookup regardless of how many items are in the array. That is why this example represents O(1) time. For a normal dense JavaScript array, indexed element access is constant-time in the usual case. The function also uses O(1) auxiliary space.

The diagram uses binary search on a sorted array. The search starts with low at the first index and high at the last index. It calculates the middle position. If the middle value is the target, it returns that index. If the target is larger, low moves to mid + 1. Otherwise, high moves to mid - 1. Each step removes about half of the remaining search range. That gives O(log n) time and O(1) auxiliary space for this iterative version.

The diagram uses a sum function. It starts total at 0 and visits every array element once. Each value is added to total. If n roughly doubles, the amount of loop work also roughly doubles. That is O(n) time. The function stores only total and the loop index, so its auxiliary space is O(1).

The diagram connects O(n log n) with efficient comparison sorting and shows arr.slice().sort((a, b) => a - b) as its JavaScript example. O(n log n) grows faster than O(n) but much slower than O(n²). Merge sort and heap sort are standard examples of algorithms with O(n log n) running time. JavaScript Array.prototype.sort() itself does not have one universal Big O guarantee in ECMAScript because the specification does not require one particular sorting algorithm. Also, arr.slice() creates a copy that uses O(n) additional space.

The diagram uses hasDuplicate(arr) with two nested loops. For each index i, the inner loop checks the later indices starting at i + 1. It returns true as soon as two equal values are found. If no duplicate is found, many pairs are compared. In the worst case, the number of comparisons grows proportionally to n². That gives O(n²) worst-case time and O(1) auxiliary space.

For a small input, an O(n²) solution may still be fast enough. For larger inputs, O(n) or O(n log n) is usually more practical when the problem allows it. O(log n) and O(1) scale even better. The goal is not to choose the smallest Big O symbol without context. The goal is to choose the lowest-growth correct solution that fits the real input size, time limit, and memory limit.

The key idea is to compare how different kinds of work grow as n becomes larger. O(1) stays constant. O(log n) grows slowly because each step removes a constant fraction of the remaining problem. O(n) grows directly with the number of items. O(n log n) commonly appears in efficient comparison-based sorting. O(n²) often appears when each item can be compared with many other items. The central rule is that Big O describes the growth rate of time or space, not an exact elapsed time. This makes it useful for choosing an approach that fits the expected input limits.

This question compares several complexity classes rather than giving one complexity for one algorithm. O(1) means the work stays constant as n grows. O(log n) means the work grows slowly because the remaining problem is repeatedly reduced, as in binary search. O(n) means the work grows roughly in direct proportion to n. O(n log n) grows more than linear but much less than quadratic. O(n²) grows quickly because the work can be proportional to n times n. The diagram's direct-access, iterative binary-search, sum-loop, and nested-loop examples use O(1) auxiliary space. The arr.slice() operation in the sorting example creates an O(n) copy, and the sorting implementation may use additional memory depending on the JavaScript engine.

1. Saying Big O gives an exact runtime in milliseconds. It describes a growth rate instead.
2. Looking only at the Big O label and ignoring the expected input size. O(n²) can still be acceptable when n is small.
3. Saying binary search is O(log n) without mentioning that its input must be sorted.
4. Assuming every pair of nested loops is automatically O(n²). The actual number of iterations determines the complexity.
5. Saying JavaScript Array.prototype.sort() has a guaranteed O(n log n) complexity. ECMAScript does not require one specific sorting algorithm or one universal complexity bound.
6. Ignoring extra memory. For example, arr.slice() creates a new array whose size grows with n.

Explain the growth rates in order from O(1) through O(n²), connect each one to the matching JavaScript example, and then finish by explaining how the expected input size affects which complexity is practical.

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 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 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.

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.

I would use one browser timer and keep the latest call state inside a closure. Each call saves the newest this and arguments, clears the previous timer, and starts a fresh timer for wait milliseconds. When the timer finally fires, I call fn with that latest state and save its result. cancel() removes pending work. flush() runs pending work immediately or returns the last completed result. Each operation is O(1) time with O(1) auxiliary space.

The goal is to delay a function until calls have stopped for the requested amount of time. Every new call replaces the earlier pending call. We remember only the newest this value and arguments, plus the result from the most recent completed invocation. One browser timeout tracks the pending work. The returned function also has cancel() to discard pending work and release references, and flush() to run pending work immediately. This design matches the required trailing-edge debounce behavior with a small, fixed amount of state.

1. Should flush() return the most recent completed result when there is no pending call? Yes, that is required here.
2. Should cancel() keep the most recent completed result? Yes. It clears pending state but leaves the completed result available to flush().

debounce(fn, wait) receives a function and a delay. It returns a normal function. That returned function must forward the latest call-time this and arguments. The original fn runs only after there have been no new calls for wait milliseconds.

The returned function also exposes cancel() and flush(). cancel() prevents pending work from running and releases retained references. flush() immediately runs pending work and returns its result. If nothing is pending, flush() returns the most recent completed result.

The input is validated first. fn must be a function. wait must be a finite number and cannot be negative.

The closure stores timerId, lastArgs, lastThis, lastResult, and hasPending. timerId identifies the active browser timeout. lastArgs and lastThis belong to the newest call. lastResult stores the most recent completed result. hasPending tells us whether a call is waiting to run.

The main invariant is that while work is pending, lastArgs and lastThis always belong to the newest call.

When the returned function is called, it saves the current this and arguments. It marks the call as pending. If an earlier timeout exists, that timeout is cleared. A new timeout is then created for wait milliseconds.

This reset is the key debounce behavior. Every new call starts the quiet period again.

At 0 ms, the wrapper is called with A. It saves A and starts a timer that would fire at 50 ms.

At 20 ms, the wrapper is called with B. The first timer is cleared. B becomes the newest saved call, and a new timer is scheduled for 70 ms.

At 40 ms, the wrapper is called with C. The second timer is cleared. C becomes the newest saved call, and a new timer is scheduled for 90 ms.

There are no more calls. At 90 ms, 50 ms have passed since the call at 40 ms. fn runs exactly once with the third call's this and arguments. Its return value becomes lastResult. The pending references are then released.

cancel() clears the active timeout when one exists. It also clears the saved this and arguments and marks the operation as not pending. It does not call fn. The previously completed lastResult is kept.

flush() first checks whether work is pending. If nothing is pending, it returns lastResult. If work is pending, it prevents the scheduled timeout from firing later, invokes fn immediately with the newest saved context and arguments, stores that result, clears the pending references, and returns the result.

Only the newest call's context and arguments are retained. Every new call resets the timeout, so fn can run only after a full wait interval with no later call. cancel() removes pending work before it can run. flush() executes exactly the newest pending call immediately and prevents the timer from executing that call again.

Each normal call, cancel(), and flush() performs a constant amount of state and timer work. Each operation is O(1) time. The closure stores a fixed number of variables, so auxiliary space is O(1).

Use a trailing-edge debounce with one browser timeout and a fixed set of closure variables. On every wrapper call, replace the saved this and arguments with the newest values, clear the previous timeout, and create a fresh timeout for wait milliseconds. The central invariant is that pending state always represents the most recent call. When that timeout finally completes, invoke fn with the saved context and arguments, store its returned value, and release the pending references. cancel() discards pending work, while flush() executes pending work immediately or returns the latest completed result.

Each call to the debounced function does a fixed amount of work. It saves a few values, may clear one timeout, and creates one timeout. cancel() and flush() also do a fixed amount of work. Therefore each operation is O(1) time. The closure stores only one timer identifier, the latest arguments, the latest this, the latest completed result, and one pending flag. That storage does not grow as more calls arrive, so auxiliary space is O(1).

One common mistake is starting a new timeout without clearing the previous one, which can invoke fn several times. Another is returning an arrow function and accidentally losing the caller's dynamic this. Candidates may also forget to replace the saved arguments on every call, fail to release pending references in cancel(), or let flush() invoke the pending call without cancelling its scheduled timeout. Another mistake is returning undefined from flush() when nothing is pending instead of returning the most recent completed result. Invalid waits such as negative numbers, NaN, and Infinity must also be rejected.

State the invariant before writing the methods: while work is pending, the saved this and arguments always belong to the newest call. Then show that every new call resets the single timer. This makes the behavior of cancel() and flush() easy to reason about.

I keep one throttle-window start time, one timer, and the latest pending this and arguments. A leading call can run immediately at the start of a window. Calls inside that window only replace the pending values. If trailing is enabled, one timer runs the latest pending call at the window end. cancel() clears all state, and flush() runs a pending trailing call immediately. The throttle bookkeeping uses O(1) time per call and O(1) auxiliary space.

The goal is to control how often a function can run. During each wait-millisecond window, the wrapped function can run at most once. Leading mode can run it at the window start. Trailing mode can run the newest pending call later. If more calls arrive while waiting, we keep only their latest this and arguments. We also need cancel() and flush(), safe elapsed-time measurement, and cleanup of timers and saved references.

1. When leading is false, should the first call wait one full wait interval before a trailing invocation?
2. Should flush() return the latest function result when there is no pending trailing call?
3. Should cancel() fully reset the throttle so the next call behaves like a new first call?

The inputs are fn, wait, and the leading and trailing options. The returned function controls when fn is allowed to run. It also exposes cancel() and flush().

If both options are false, fn is never invoked.

For the verified example, wait = 50, leading = true, and trailing = true. Calls happen at 0, 20, 40, and 80 ms. Invocations happen at 0, 50, and 100 ms. The invocation at 50 uses the arguments from the 40-ms call. The invocation at 100 uses the arguments from the 80-ms call.

The implementation stores windowStart, timerId, lastArgs, lastThis, and result.

windowStart anchors the current throttle window. timerId tells us whether one trailing timer already exists. lastArgs and lastThis contain only the newest pending call. result keeps the latest return value from fn.

The central invariant is that at most one timer is active, and a trailing invocation uses only the newest pending this and arguments.

Every accepted call saves its latest arguments and this.

If windowStart is undefined, the call starts a new window. We set windowStart to the current time. If leading is true, we invoke immediately. Otherwise, if trailing is true, we schedule one timer for the full wait interval.

For a later call, we calculate elapsed = time - windowStart. Inside the active window, the call does not invoke immediately. It replaces lastArgs and lastThis. If trailing is enabled and no timer exists, we schedule one timer for wait - elapsed.

At 0 ms, there is no active window. We set windowStart = 0. Leading is enabled, so fn runs immediately with args@0.

At 20 ms, elapsed = 20. The call is inside the 50-ms window. We save args@20. Because trailing is enabled and no timer exists, we schedule one for 30 ms later, at 50 ms.

At 40 ms, elapsed = 40. The timer already exists. We do not create another one. We replace the pending arguments with args@40.

At 50 ms, the timer fires. A trailing call is pending, so fn runs with args@40. windowStart becomes 50, the timer reference is cleared, and the saved this and arguments are released.

At 80 ms, elapsed = 80 - 50 = 30. The remaining delay is 50 - 30 = 20 ms. We save args@80 and schedule a timer for 100 ms.

At 100 ms, that timer fires and invokes with args@80. windowStart becomes 100. The final invocation times are exactly 0, 50, and 100 ms.

If elapsed >= wait, the previous window is expired. We clear any active timer and start a new window at the current time. A leading call can run immediately. If leading is disabled but trailing is enabled, we schedule one full wait interval instead.

The implementation prefers performance.now() because it is monotonic. This means elapsed time does not move backward when the system wall clock changes. If Date.now() is used as the fallback and elapsed < 0, we treat the previous window as expired. This prevents a backward wall-clock change from blocking execution indefinitely.

cancel() clears an active timer, resets windowStart, clears pending this and arguments, and releases the saved result. The next call behaves like a new first call.

flush() checks for a pending trailing call. If one exists, it clears the timer and invokes immediately with the newest saved this and arguments. If there is no pending trailing call, it returns the latest result.

After an invocation, pending argument and this references are cleared. Timer references are cleared after firing or cancellation.

The throttle bookkeeping takes O(1) time per incoming call. The runtime of fn itself is separate. The throttle keeps only a fixed amount of state and at most one timer, so its auxiliary space is O(1).

Important cases are leading=true, trailing=false, leading=false, trailing=true, both options false, many calls inside one window, cancel(), flush(), and a backward wall-clock change when the fallback clock is used.

The key idea is to represent the current throttle window with windowStart and allow at most one active trailing timer. Every incoming call replaces lastArgs and lastThis, so a future trailing invocation always represents the newest pending call. A new window may invoke immediately when leading is enabled. Inside an active window, calls only update the pending data, and one timer covers the remaining delay. The invariant is that at most one timer is active and any trailing invocation uses the latest pending this and arguments.

The throttle bookkeeping takes O(1) time for each incoming call because it performs a fixed number of comparisons, assignments, and timer operations. The runtime of the wrapped function fn is separate. Auxiliary space is O(1) because the throttle keeps a fixed set of state variables, one pending argument collection, one pending this reference, and at most one timer. The throttle state does not grow with the number of calls.

A common mistake is creating a new timer for every call inside one window. Only one trailing timer should exist. Another mistake is keeping the first pending arguments instead of replacing them with the newest ones. Candidates also forget to preserve this, which can change method behavior. Another error is assuming Date.now() can never move backward. Finally, cancel() and flush() are often implemented without clearing the timer or releasing saved call references.

Draw the timeline at 0, 20, 40, 50, 80, and 100 ms before writing code. Explain that the 20-ms and 40-ms calls share one timer and that the 40-ms arguments replace the 20-ms arguments. Then show that the 80-ms call has 20 ms remaining until the next trailing invocation. This makes the one-timer invariant easy to verify.

I would keep a Map inside memoize and use the single argument itself as the key. The returned normal function first checks cache.has(arg). On a hit, it returns the stored value. On a miss, it calls fn with the same call-time this, stores the result only after the call succeeds, and returns it. Map preserves the required key semantics, including object identity. The memoization overhead is O(1) on average per call, with O(k) auxiliary space for k cached keys.

The task is to wrap a function that takes exactly one argument. The wrapper remembers successful results so it does not repeat the same work for a cached key. It must also pass along the caller's this value. A Map stores each argument and its returned value. The argument itself is the key. This means two different objects with the same contents are still different keys. If the original function throws, that failed call must not be stored. The wrapper also exposes its Map through .cache and provides .clear() to empty it.

1. Should object arguments match only when they are the same object reference? Yes. The required behavior is ordinary JavaScript Map key semantics.
2. If fn returns a Promise, should I cache that Promise immediately? Yes. The returned Promise is cached as an ordinary value.

The input is fn, which must be a function that accepts exactly one argument. If fn is not a function, memoize throws a TypeError. The output is a normal function named memoized. It forwards its call-time this value, caches successful return values in a Map, exposes that Map through memoized.cache, and provides memoized.clear() to empty the Map.

Create one Map named cache. Each key is the exact argument passed to memoized. Each value is the successful result returned by fn for that key. We do not stringify the argument. Primitive keys follow ordinary Map semantics. Object keys match only by reference identity. JavaScript Map uses SameValueZero key comparison, so NaN matches NaN and +0 and -0 are treated as the same key.

When memoized(arg) runs, first check cache.has(arg). If the key exists, return cache.get(arg) immediately. If the key does not exist, call fn.call(this, arg). Using call forwards the wrapper's current this value to fn. If fn returns successfully, store the result with cache.set(arg, result) and return it. If fn throws, rethrow the error and leave the Map unchanged.

The diagram wraps const double = x => x * 2. The first memoized(4) sees an empty cache, so it computes 4 * 2 = 8, stores 4 → 8, and returns 8. The second memoized(4) finds key 4 and returns the cached 8 without recomputing. The diagram then uses objA = {id: 1} and objB = {id: 1}. With the same numeric doubling function, each distinct object coerces during multiplication and produces NaN. The first objA call stores objA → NaN. A second call with that same objA reference returns the cached NaN. objB is a different reference, so it is a different Map key and causes a new computation.

The central invariant is that every entry in cache maps one argument key to the result of a previous successful call for that key. We always check the cache before computing. Therefore, a cached key returns exactly its previous successful result. We store only after fn returns successfully. Therefore, a thrown call cannot add an entry. Using the original argument directly as the key preserves the required Map identity behavior.

memoize first validates fn. It then creates one private Map. The returned normal function checks for a cached key. On a miss, it calls fn with fn.call(this, arg), stores the successful result, and returns it. A catch block simply rethrows an error so a failed call is not cached. After the wrapper is created, memoized.cache points to the same Map and memoized.clear calls cache.clear(). If fn returns a Promise, that Promise object is stored immediately just like any other returned value.

The Map lookup and insertion operations are O(1) on average. Therefore, the memoization bookkeeping adds O(1) expected time per call, excluding the time needed to execute fn on a cache miss. The cache uses O(k) auxiliary space, where k is the number of distinct successfully cached keys. Important cases are a non-function input, repeated primitive keys, the same object reference, distinct objects with the same contents, NaN, +0 and -0, thrown calls, returned Promises, and clearing the cache.

Use one Map whose key is the exact argument and whose value is the successful result returned for that argument. The key insight is that Map already provides the required key semantics, so the argument should not be stringified or transformed. The invariant is: every cache entry represents a successful earlier call for that exact Map key. Check cache.has(arg) before calling fn. On a hit, return the stored value. On a miss, call fn with the current this value, store the result only after success, and return it. If fn throws, the cache remains unchanged.

A cache lookup, read, or insertion in a JavaScript Map is O(1) on average. Therefore, the memoization work adds O(1) expected time per call. On a cache miss, the total call also includes whatever time fn itself needs. The cache uses O(k) auxiliary space, where k is the number of distinct argument keys that have completed successfully and are still stored. These Map operation costs are average-case expectations, not guaranteed worst-case bounds.

One mistake is stringifying the argument before using it as a key. That breaks the required object identity behavior. Another is returning an arrow function as the wrapper and expecting it to receive a new call-time this value. A third mistake is using cache.get(arg) alone to decide whether a key exists, because a valid cached result can be undefined. Candidates may also store a value before the wrapped call has completed successfully, which can break the thrown-call rule. Finally, two different objects with identical properties must not be treated as the same key.

Explain the order in one sentence: check the Map first, call fn only on a miss, and write to the Map only after fn returns successfully. Then mention that using the original argument as the key is what preserves JavaScript Map identity semantics.

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.