29 Google JavaScript Frontend Developer Interview Questions & Answers

I would use iterative pre-order depth-first traversal with an explicit stack of traversal frames. I start the result with the root. Each frame stores a parent element and the index of its next child. I process children from left to right, append each child before visiting its descendants, and pop a frame when all of its children are finished. This preserves DOM sibling order without recursion. The time complexity is O(n), and the auxiliary stack space is O(depth).

The function receives one HTML element. It must return a normal array containing that element and every light-DOM descendant element below it. The order is parent first, then children from left to right. Text and comment nodes do not count. Shadow-root content and iframe documents are not entered. The page must not be changed. A very deeply nested DOM must also work safely, so recursion is avoided. An explicit stack lets us remember where we are while using extra memory based on nesting depth.

1. Should the returned array include the root element itself? The stated contract says yes.
2. Should only light-DOM element children be visited, while shadow roots and iframe documents stay excluded? The stated contract says yes.
3. Is O(depth) auxiliary stack space required even when an element has many siblings? The stated contract says yes.

The input is root, and it must be an Element. If it is not an Element, the function throws TypeError.

The output is a static JavaScript array of Element references. It starts with root. After that, it contains every light-DOM descendant element in pre-order depth-first order.

For the example <main><section><b></b></section><p></p></main>, the tag-name order is MAIN, SECTION, B, P.

We use children, so text nodes and comment nodes are ignored. We do not enter shadow roots or iframe documents. We also do not mutate the document.

I use iterative depth-first search with an explicit stack of traversal frames.

Each frame stores two values. parent is the element whose children we are scanning. nextIndex tells us which element child should be processed next.

The key invariant is simple. Every frame points to one active parent and the next unvisited child of that parent. Because nextIndex moves from left to right through parent.children, DOM sibling order is preserved.

This frame design also keeps the auxiliary stack bounded by the active nesting depth.

First, I validate the input.

Then I create result = [root]. The root is already visited because pre-order traversal visits a node before its descendants.

I also create stack = [{ parent: root, nextIndex: 0 }]. This means the root is the active parent, and its first element child is the next child to inspect.

The example tree is MAIN with children SECTION and P. SECTION has child B.

Initial state: result is [MAIN]. The stack is [MAIN:0].

The top frame is MAIN:0. Its first child is SECTION. We advance MAIN's index to 1, append SECTION, and push SECTION:0. Result becomes [MAIN, SECTION].

The top frame is now SECTION:0. Its first child is B. We advance SECTION's index to 1, append B, and push B:0. Result becomes [MAIN, SECTION, B].

B has no element children, so its frame is exhausted and popped. SECTION:1 is also exhausted, so it is popped.

We return to MAIN:1. Its next child is P. We advance MAIN's index to 2, append P, and push P:0. Result becomes [MAIN, SECTION, B, P].

P has no element children, so it is popped. MAIN:2 is now exhausted and is also popped. The stack becomes empty, so traversal stops.

Each frame scans parent.children in increasing index order. Therefore siblings are visited from left to right.

A child is appended to the result before a frame for that child is processed. Therefore every element appears before its descendants. That is exactly pre-order depth-first traversal.

When a frame has no unvisited children left, it is popped. This returns processing to the parent frame. Each element is therefore visited exactly once in the required light-DOM order.

The code first checks root instanceof Element. It then puts root in the result and creates one frame for it.

Inside the loop, the code reads the top frame and its parent.children collection. If nextIndex has reached the number of children, that frame is finished and is popped.

Otherwise, the code reads the next child and increments nextIndex. It appends that child to the result and pushes a new frame for the child. The loop ends when no frames remain.

If there are n element nodes in the light-DOM subtree, each one is visited once. The time complexity is O(n).

The explicit frame stack contains at most one frame for each active nesting level. Its auxiliary space is O(depth). The returned array itself contains n element references, but that is required output storage rather than auxiliary stack storage.

A root with no element children returns [root]. Very deep nesting, including a depth of 50,000, does not use the JavaScript recursive call stack. A non-Element input throws TypeError. Shadow roots and iframe documents are not entered.

The key idea is to simulate recursive pre-order DFS with explicit traversal frames. Each frame stores a parent element and nextIndex, the index of the next element child to visit. The top frame represents the current active nesting level. We read parent.children in normal DOM order. Before descending into a child, we advance the parent's index, append that child to the result, and push a new frame for it. When a frame has no children left, we pop it. The central invariant is that every frame points to an active parent and its next unvisited child. This preserves pre-order and sibling order while keeping the stack proportional to DOM depth.

Let n be the number of element nodes in the light-DOM subtree. Each element is visited once, so the total time is O(n). Let depth be the maximum element nesting depth. The explicit stack keeps at most one active frame for each nesting level, so auxiliary space is O(depth). The returned array contains all n elements and therefore uses O(n) output space, but that required output array is not counted as auxiliary stack space.

1. Using recursion even though a depth of 50,000 can overflow the JavaScript call stack.
2. Using childNodes instead of children, which would include text and comment nodes that the problem says not to count.
3. Appending the root again inside the loop even though result already starts with [root].
4. Forgetting to advance nextIndex before descending, which can cause the same child to be visited repeatedly.
5. Traversing into shadowRoot or an iframe's document even though the required traversal is light DOM only.
6. Claiming O(depth) auxiliary space while using a different pending-node stack that can hold many siblings at the same time.

Explain what one stack frame means before writing the loop: parent is the active element, and nextIndex is its next unvisited element child. Then trace MAIN:0, SECTION:0, and B:0 on the example. This makes the O(depth) space bound and the left-to-right pre-order behavior easy to justify.

I would first validate the selection and every node. Then I would keep only non-empty node intervals that truly overlap the selection using the strict half-open interval rule. I store each matching node with its original index, sort the matches by increasing start time and then original input order, and return their IDs. For the example, the result is ['C','B']. The worst-case time is O(n log n), and the auxiliary space is O(n).

We have a list of timeline items. Each item has an ID, a start time, and an end time. We also have a selected time range. We need to return the IDs of items that share some real time with that range. Simply touching the range at one endpoint does not count. An empty item or empty selection also has no overlap. The input may be in any order. After finding the matching items, we order them by start time. Equal start times keep their original input order.

1. Should an empty selection such as [2,2) return an empty result after all input records are validated?
2. If two matching nodes have the same start time, should their original input order be preserved?
3. Should malformed node records cause an error instead of being skipped?

I first check that nodes is an array. I also check that selectionStart and selectionEnd are finite numbers and that selectionStart <= selectionEnd.

Then I validate every node before returning any result. Each node must be an object with a string id, finite numeric start and end values, and start <= end.

This order matters. Even when the selection is empty, malformed node records must still be rejected.

After every node is valid, I check whether selectionStart === selectionEnd.

A half-open range such as [2,2) contains no time at all, so no node can overlap it. I return [] immediately.

A node can overlap the selection only when the node itself is non-empty and both strict comparisons are true:

node.start < node.end

node.start < selectionEnd

node.end > selectionStart

The strict comparisons are important. A node ending exactly where the selection starts does not overlap. A node starting exactly where the selection ends also does not overlap.

The input order is B:[4,7), A:[0,4), C:[2,5). The selection is [4,6).

For B, 4 < 7, 4 < 6, and 7 > 4, so B overlaps.

For A, its end is exactly 4. The test 4 > 4 is false, so A only touches the selection and is not kept.

For C, 2 < 5, 2 < 6, and 5 > 4, so C overlaps.

The matching nodes are B and C. We then sort them by start time. C starts at 2 and B starts at 4, so the final order is C, B. The returned result is ['C','B'].

For every matching node, I store its ID, start time, and original input index.

I sort first by increasing start. If two starts are equal, I compare the saved original indices. This gives the required tie behavior without changing the original nodes array.

The main invariant is that the match array contains only valid, non-empty nodes that have a real intersection with the selection.

The strict overlap test removes endpoint-only contact. Saving the original index gives the required tie-breaker. Sorting the matches by (start, original index) therefore produces the required output order.

Validation takes O(n) time. Filtering also takes O(n) time. If m nodes overlap, sorting the matches takes O(m log m). Since m can equal n, the worst-case total time is O(n log n).

The algorithm stores up to O(n) matching records, so auxiliary space is O(n).

Important edge cases are an empty selection, a zero-length node, endpoint-only contact, negative times, unsorted input, no matching nodes, and matching nodes with the same start time.

The key idea is to separate validation, overlap testing, and ordering. First validate the selection and every node. After validation, an empty selection can immediately return an empty array. For a non-empty selection, keep a node only when the node is non-empty and satisfies node.start < selectionEnd && node.end > selectionStart. This is the strict overlap rule for half-open intervals. Each match keeps its original input index. The invariant is that every stored match is valid, non-empty, and truly overlaps the selection. Sorting by start and then original index gives the required order.

Let n be the number of input nodes and m be the number of nodes that overlap the selection. Validating all nodes takes O(n) time. Finding the overlaps also takes O(n) time. Sorting the m matching records takes O(m log m) time. In the worst case, every node matches, so m = n and the total time is O(n log n). The matching-record array can grow to size n, so the auxiliary space is O(n).

A common mistake is using non-strict comparisons, which incorrectly counts endpoint-only contact as overlap. Another is forgetting that a zero-length node such as [3,3) is empty. Returning [] for an empty selection before validating all node records is also wrong. Sorting the original nodes array violates the no-mutation requirement. Finally, sorting only by start time without keeping the original index can break the required order when two matching nodes have the same start.

State the overlap rule before writing the filtering loop: a node must be non-empty, its start must be before the selection end, and its end must be after the selection start. Then explain that the saved original index is used only as the tie-breaker for equal start times.

I would validate the toolbar, label, and callback before changing the document. Then I create one native button, render the label with textContent, and keep its toggle state in a private boolean mirrored by aria-pressed. Click, Enter, or Space goes through one activation function that flips the state before calling onActivate. Each instance keeps separate state and listeners. setPressed updates the state without firing the callback, and destroy removes the listeners and button. Each operation is O(1) time and O(1) auxiliary space per instance.

The function adds one accessible toggle button to an editor toolbar that already exists. The button displays the supplied label and exposes whether it is pressed. Each created button keeps its own state. A click, Enter, or Space activation changes that state first and then calls the supplied callback with the new value. The function also returns one method for changing the state from code and one method for removing the button. Invalid required arguments are rejected before the existing toolbar is changed.

1. Should setPressed call onActivate? The shown design does not. It only changes the stored state and aria-pressed.
2. Should destroy be safe when called more than once? The shown implementation makes repeated calls harmless.
3. Should values passed to setPressed be converted to booleans? The shown implementation uses Boolean conversion.

First, check that toolbar is an Element. Then check that config contains a non-empty string label and that onActivate is a function. These checks happen before the button is appended, so an invalid call does not leave a partial control in the existing toolbar.

Create a native button and set type to button. Set textContent to label, so the label is rendered as text rather than HTML. The visible text also gives the button its accessible name. Store the current pressed state in a private isPressed boolean. Set aria-pressed to "true" or "false" so assistive technology can read the toggle state.

The activate function flips isPressed. It then updates aria-pressed. Only after the state is updated does it call onActivate(isPressed). This order is important because the callback receives the new state and the DOM already exposes that same state.

A click listener calls activate. The keydown listener handles Enter and Space. It calls preventDefault and then calls the same activate function. Using the same activation function keeps the state-change logic in one place. In the diagram example, pressed starts as false. One activation changes aria-pressed to "true" and calls onActivate(true) exactly once.

setPressed(value) converts value to a boolean, stores it in isPressed, and updates aria-pressed. It does not call onActivate because it is a programmatic state change. destroy removes both listeners and removes the button when it is still attached. The parent check makes repeated destroy calls harmless.

Every createEditorButton call creates a new isPressed variable, button element, and pair of listeners. Therefore, multiple instances do not share state. The main invariant is that isPressed and aria-pressed always represent the same boolean state. Creation, activation, setPressed, and destroy each perform a fixed amount of work. They are O(1) time, with O(1) auxiliary space per button instance.

The solution uses one private boolean for each button instance. aria-pressed always mirrors that boolean. After validation, the function creates a native button, writes the label with textContent, initializes the toggle state, and appends the button to the supplied toolbar. Click, Enter, and Space all reach the same activate function. activate flips the private state, updates aria-pressed, and then calls onActivate with the new value. setPressed changes the same state without invoking the callback. destroy removes both event listeners and the element. The central invariant is that the internal state and aria-pressed always stay synchronized.

Button creation takes O(1) time because it performs a fixed number of checks, assignments, and DOM operations. Each activation is also O(1) because it flips one boolean, updates one attribute, and calls one callback. setPressed and destroy are O(1) as well. Auxiliary space is O(1) per button instance because each instance stores only a fixed number of variables, functions, and one button reference. If many independent buttons are created, total memory grows with the number of instances.

One mistake is calling onActivate before aria-pressed is updated. The required order is state change first and callback second. Another mistake is using innerHTML instead of textContent, which treats the supplied label as markup. Candidates may also forget preventDefault in the custom Enter and Space key handler, which can allow the browser's native activation behavior to run as well. Other common mistakes are sharing state between instances, calling onActivate inside setPressed, changing the toolbar before validating required inputs, or removing the button without removing its event listeners.

Explain the activation order clearly: change the private boolean, update aria-pressed, and only then call onActivate. Also point out that click, Enter, and Space all reuse the same activate function, so the behavior stays consistent.

I would validate the function and delay first. Then I return a normal wrapper function. Every wrapper call captures its own call-time this value and arguments, schedules exactly one setTimeout, and returns that timeout identifier. When the timer fires, it calls the original function with fn.apply(context, args). Calls stay independent, so nothing is debounced or cancelled. Under the diagram's per-call model, each wrapper call takes O(1) time and O(1) auxiliary space.

This problem asks us to create a function that delays another function call. The caller gives us a function and a delay from 0 through 60,000 milliseconds. We return a new normal function. Every time that returned function is called, it creates one timer. Later, the original function runs with the same this value and arguments from that call. Different calls must not replace or cancel each other. Each wrapper call must also return its timer identifier.

1. Should every wrapper call create a separate timeout even when another timeout is already waiting? Yes. The stated contract requires independent calls.
2. Should the wrapper preserve the this value from the moment the wrapper is called? Yes. That call-time value must be forwarded to fn.

First, check fn. If it is not a function, throw TypeError. Next, check delayMs. It must be a number and it must be finite. Values such as NaN, Infinity, and -Infinity are invalid and cause TypeError. After that, check the range. A delay below 0 or above 60,000 causes RangeError.

delayCall does not run fn immediately. It returns wrapper(...args). It must be a normal function instead of an arrow function because a normal function receives its own call-time this value. The wrapper can therefore capture both this and the arguments from each individual call.

Inside each wrapper call, save this in context. The rest parameter ...args collects the arguments for that specific call. This state belongs to that invocation. A later wrapper call gets its own context and arguments, so the calls do not overwrite one another.

The wrapper calls setTimeout exactly once. The timeout callback later runs fn.apply(context, args). apply is important because it calls fn with the captured this value and passes the captured arguments in the same order. The wrapper immediately returns the timeout identifier returned by setTimeout.

The diagram uses log(x) to push values into logs, then creates later = delayCall(log, 10). Calling later('A'), later('B'), and later('C') schedules three independent timers and returns three timeout identifiers. After about 10 milliseconds, each timer callback invokes log with the argument captured by that wrapper call. The diagram shows the resulting log values as A, B, and C, while noting that relative timer execution order should not be treated as guaranteed.

The central invariant is that every wrapper invocation owns its own captured this value, captured arguments, and timeout. The implementation never stores one shared pending timer and never calls a cancellation API. Therefore each wrapper call independently schedules one later invocation of fn with the correct call-time state and returns the required timeout identifier.

Each wrapper call performs a fixed sequence of operations in the diagram: capture the call state, call setTimeout once, and return the timeout identifier. Under that per-call model, this is O(1) time and O(1) auxiliary space. A delay of 0 is valid and still runs asynchronously. A delay of 60,000 is also valid. A non-function fn or non-finite/non-number delay causes TypeError. A delay outside [0, 60000] causes RangeError.

The key idea is one independent timer per wrapper invocation. delayCall validates its inputs once and returns a normal function. Each call to that wrapper captures its own call-time this value and argument list, then schedules one setTimeout. When the timeout callback runs, fn.apply(context, args) restores the captured receiver and arguments. The central invariant is: one wrapper call owns one captured call state and one timeout. Because there is no shared pending timer and no cancellation, calls remain independent.

The diagram treats each wrapper call as constant work. It captures the call-time state, calls setTimeout once, and returns the timeout identifier. That is O(1) time per wrapper call. The diagram also gives O(1) auxiliary space per call under its per-call model because the wrapper keeps only a fixed set of references for that scheduled callback. The browser manages the timer itself.

A common mistake is returning an arrow function as the wrapper. An arrow function would not receive its own call-time this value. Another mistake is calling fn(...args) and losing the required receiver instead of using fn.apply(context, args). Some candidates accidentally implement debounce by storing one timer and cancelling the previous one, but this problem requires all calls to stay independent. It is also easy to accept NaN or Infinity by checking only typeof delayMs === 'number'. Finally, the wrapper must return the timeout identifier from every call.

State the key invariant before coding: "Every wrapper call keeps its own this, arguments, and timeout." That makes the normal wrapper function, fn.apply(context, args), and the no-debounce requirement easy to justify.

I would first validate that the root is a Document or Element. Then I would use querySelectorAll to collect descendant h1 through h6 elements in document order. For each heading, I trim its text, skip it if the text is empty, get the numeric level from the tag name, and keep the original element reference. I never change the DOM or enter shadow roots. The time is O(n) over visited descendants, and the additional storage, including matched references and the result, is O(h).

The goal is to create a simple outline from the headings inside a document or one element. We read headings from top to bottom in the same order they appear. For every heading, we keep its heading number, its cleaned text, and the original heading itself. A heading containing only spaces is ignored. We do not create missing heading levels or change anything on the page. The browser can collect the needed headings in their existing order, so one DOM query followed by one simple loop fits the problem well.

1. Should a heading with only whitespace be ignored after trimming its text?
2. Should the element field keep the exact original DOM element reference?
3. Should any root that is not a Document or Element throw TypeError?

The function accepts a Document or an Element. If the root is neither one, I throw TypeError. This stops invalid values before the code tries to call DOM methods on them.

I call root.querySelectorAll('h1, h2, h3, h4, h5, h6'). This returns a static NodeList containing matching descendant headings in document order. It does not include normal non-heading elements, and this query does not cross shadow-root boundaries.

I iterate through the heading-only NodeList. For each heading, I read textContent and trim it. If the trimmed text is empty, I skip that heading. Otherwise, I read the heading level from its tag name. For example, H3 gives level 3. I then push { level, text, element }, where element is the original heading object.

The example is <h2>Intro</h2><h3>Setup</h3><h2>API</h2>. First, Intro is an H2, so its level is 2. Next, Setup is an H3, so its level is 3. Finally, API is an H2, so its level is 2. The result stays in that same order: Intro, Setup, API. Each record also keeps the corresponding original heading reference.

The main invariant is that after each loop iteration, the result contains exactly the earlier non-empty matching headings in their original document order. Every stored level comes from that heading's tag name. Every stored text value comes from that heading's trimmed textContent. Every stored element is the same DOM element that was visited. We never infer missing levels, mutate the DOM, or enter shadow roots.

The code validates the root, creates the heading NodeList, creates an empty result array, processes every matched heading, and returns the result. The time is O(n) over visited descendants. If h headings match, the static NodeList can hold up to h element references and the result can contain up to h records, so the additional/result storage is O(h). Invalid roots throw TypeError. Empty headings are skipped. Deeply nested headings still follow document order.

The key idea is to ask the browser for exactly the descendant heading elements that matter. querySelectorAll('h1, h2, h3, h4, h5, h6') already returns those headings in document order, so no sorting or outline-tree reconstruction is needed. The central invariant is: after processing any heading, the result contains exactly the non-empty headings processed so far, in the same order, with the correct numeric level, trimmed text, and original element reference. This directly satisfies the required output contract.

Let n be the number of descendants the selector may need to visit, and let h be the number of matching h1 through h6 elements. The time is O(n) over visited descendants. querySelectorAll creates a static NodeList with up to h heading references, and the returned outline can contain up to h records. Therefore the additional/result storage is O(h). No copied DOM tree, sorting structure, recursion stack, map, or set is needed.

A common mistake is iterating every descendant even though the selected querySelectorAll already returns only headings. Another is forgetting to trim textContent, which incorrectly keeps whitespace-only headings. Candidates may return only level and text and lose the required original element reference. They may also try to infer missing heading levels, even though the problem forbids that. Manually entering shadow roots or mutating the DOM also breaks the contract. Finally, the memory explanation should account for the static NodeList and returned records.

Explain that querySelectorAll already gives exactly the matching h1 through h6 descendants in document order. Then show that the loop only trims text, skips empty headings, reads the level, and stores the original element reference. That makes both the implementation and correctness argument easy to follow.

I would try every valid expression while keeping the four numbers in their original order. There are five binary parenthesizations and 64 operator triples, so at most 320 expression forms are possible. I represent every intermediate value as a reduced fraction, which avoids floating-point equality errors and lets me reject division by zero safely. I return true as soon as an exact result is 24. Because the input always contains exactly four numbers, both time and auxiliary space are O(1).

We have exactly four numbers. We must keep them in the given order. We can put +, -, *, or / between them and add parentheses in any valid way. We need to decide whether one expression gives exactly 24. Division can create values that are difficult to compare safely with normal decimal arithmetic, so we keep every value as an exact fraction. There are only five parenthesizations and 64 operator choices for each one, so checking every possibility is small and complete.

1. Must the four numbers stay in exactly their original order? Yes. The problem does not allow reordering.
2. Should intermediate division use exact arithmetic instead of floating-point comparison? Yes. The problem requires exact rational values.

The input is an array of exactly four integers from 1 through 9. We do not mutate this array. We place one binary operator between each neighboring value and may choose any valid binary parenthesization. The output is a Boolean. We return true when at least one valid order-preserving expression equals exactly 24. Otherwise, we return false.

Four ordered values have exactly five binary parenthesizations. There are three operator positions, and each position has four choices: +, -, *, or /. That gives 4^3 = 64 operator triples for each parenthesization. Therefore, there are at most 5 × 64 = 320 expression forms to test.

Each value is represented as a numerator and denominator. For example, 6 is stored as 6/1. After an operation, the fraction is reduced with the greatest common divisor, and the denominator is kept positive. If a division would use a zero-valued right operand, that expression is invalid and is skipped. This avoids floating-point equality errors.

The input is [6, 1, 3, 4]. One successful parenthesization is a / (b - (c / d)), with operators /, -, /. First, 3 / 4 = 3/4. Next, 1 - 3/4 = 1/4. Then, 6 / (1/4) = 24/1. Since 24/1 is exactly the target 24/1, the function returns true immediately. No later expression forms need to be checked after this match.

Every valid expression that preserves the order of the four values uses one of the five binary parenthesizations. Every choice of the three operators is one of the 64 operator triples. The algorithm covers both complete sets. Exact fraction arithmetic preserves the true mathematical value of every intermediate expression. Therefore, the search returns true exactly when a valid order-preserving expression evaluates to 24.

The code defines helpers for greatest common divisor, normalized fractions, and applying one operator to two fractions. It converts the four inputs to exact BigInt fractions without changing the original array. Three nested loops enumerate all operator triples. For each triple, the five valid parenthesizations are evaluated in order. After each one, the code checks for exactly 24 and returns true immediately when a match is found. If every valid combination fails, it returns false.

At most 320 expression forms are possible. Each one needs only a fixed number of arithmetic operations, so this problem takes O(1) time because the input always has exactly four numbers. The algorithm also uses only a fixed number of fraction objects and temporary values, so auxiliary space is O(1). Important cases are division by zero, negative or fractional intermediate values, exact fraction comparison, and the case where no expression reaches 24.

The key idea is exhaustive search over a very small fixed search space. The four input values always stay in their original order. We enumerate all five binary parenthesizations and all 64 operator triples. Every intermediate result is stored as a normalized exact fraction. The central invariant is that each stored fraction equals the exact mathematical value of the expression subtree that produced it. Because every valid ordered expression belongs to one of the five parenthesizations and one of the 64 operator triples, checking all of them is complete. The search stops as soon as one exact result is 24.

There are exactly five binary parenthesizations and 64 operator triples. That means at most 5 × 64 = 320 expression forms are checked. Every expression needs only a constant number of exact-fraction operations. Since the problem always gives exactly four numbers, this fixed amount of work is O(1) time. The code also keeps only a fixed number of fractions and temporary values, so auxiliary space is O(1).

One common mistake is using normal floating-point arithmetic and comparing a result directly with 24. Rational intermediate values can have rounding errors. Another mistake is forgetting one of the five binary parenthesizations. Reordering the four input numbers also breaks the problem rules. Candidates may forget to reject division by a zero-valued intermediate result. Another mistake is continuing to process expressions after a valid result has already been found. Finally, the complexity should be O(1) for this exact fixed-size problem.

Before writing code, explain that four ordered values have only five binary parenthesizations and 64 operator triples. Then show why exact fractions are needed. This makes both the completeness argument and the code structure easy for the interviewer to follow.

I would use iterative breadth-first search. If the clicked cell is a bomb, I return that coordinate immediately with gameOver true. Otherwise, I put the starting cell in a queue and mark it visited. When I remove a cell, I reveal it. Only a 0 cell adds its eight unvisited neighbors. Marking cells when they enter the queue prevents duplicates. This preserves breadth-first discovery order. The worst-case time is O(R × C), and the auxiliary space is O(R × C).

The board contains bombs and numbers. A click can end the game or reveal part of the board. If the clicked cell is a bomb, we return only that cell and say the game is over. Otherwise, we reveal the clicked cell. A 0 means the safe empty area continues, so we also reveal its eight-direction neighbors. Connected 0 cells continue this process. Numbered cells around that region are revealed but do not expand. We must return each revealed coordinate once, in breadth-first discovery order, without changing the board.

1. Should diagonal cells count as neighbors? Yes. The problem says to use all eight directions.
2. Does the returned order matter? Yes. Coordinates must be returned in breadth-first discovery order.
3. May I modify the board to mark visited cells? No. The board must remain unchanged.

The input is a rectangular board plus a valid zero-based row and column. Each board cell is either "*" or an integer from 0 through 8. The output is {gameOver:boolean, revealed:Array<[row,column]>}. If the clicked cell is a bomb, we return only that coordinate with gameOver:true. Otherwise, gameOver is false and revealed contains every discovered coordinate exactly once.

I use breadth-first search with a FIFO queue. FIFO means first in, first out. This gives the required breadth-first discovery order. I also use a visited matrix with the same dimensions as the board. A coordinate is marked visited when it enters the queue. The main invariant is that every coordinate in the queue has already been marked visited, so the same coordinate cannot be enqueued twice.

For the safe click shown in the diagram, the starting coordinate is (4,0). The queue begins as [(4,0)]. The revealed array begins empty, and visited[4][0] is set to true. The eight directions are checked in this exact order: (-1,-1), (-1,0), (-1,1), (0,-1), (0,1), (1,-1), (1,0), (1,1).

The board is [[0,0,1,"*",1],[0,0,2,2,2],[0,0,1,"*",1],[0,0,1,1,1],[0,0,0,0,0]], and we click (4,0). The clicked value is 0. We dequeue (4,0), append it to revealed, and examine its eight neighbors. Each valid unseen neighbor is marked visited immediately and added to the queue. BFS continues in FIFO order. When a dequeued cell is a number from 1 through 8, it is revealed but does not add neighbors. When a dequeued cell is 0, it expands. The exact discovery order is [[4,0],[3,0],[3,1],[4,1],[2,0],[2,1],[2,2],[3,2],[4,2],[1,0],[1,1],[1,2],[3,3],[4,3],[0,0],[0,1],[0,2],[3,4],[4,4]]. The queue eventually becomes empty, so 19 coordinates have been revealed.

Only revealed 0 cells expand. Every valid neighbor discovered from a 0 is marked visited before it is enqueued. Therefore, no coordinate can be added to the queue more than once. Numbered boundary cells are still revealed because they are discovered as neighbors, but they never expand. Since the queue is FIFO, coordinates are appended to revealed in breadth-first discovery order.

The code first handles the bomb case with an immediate return. For a safe cell, it creates the queue, a head index, the visited matrix, the direction array, and the revealed array. The head index gives FIFO queue behavior without repeatedly calling Array.shift(). Each dequeued coordinate is appended to revealed. A nonzero value does not expand. A 0 checks all eight neighbors. Out-of-bounds or already visited neighbors are skipped. Every new valid neighbor is marked visited before being enqueued.

Let R be the number of rows and C be the number of columns. Each coordinate can enter the queue at most once. Each 0 cell checks at most eight neighbors. Therefore, the worst-case time is O(R × C). The visited matrix and queue require O(R × C) auxiliary space. Important cases are a bomb click, a nonzero numbered click, a zero on an edge or corner, a connected zero region with numbered boundary cells, and a board as large as 500 × 500 where iterative BFS avoids recursive stack overflow.

Use iterative breadth-first search starting from the clicked cell. The important rule is that only cells whose value is 0 expand to neighbors. Numbered cells can be discovered and revealed, but they stop expansion. Mark each coordinate visited when it is enqueued. This maintains the invariant that every queued coordinate is unique. A FIFO queue then preserves the required breadth-first discovery order. This approach also avoids recursion, which is important because a connected region on a board as large as 500 × 500 could overflow the JavaScript call stack.

Let R be the number of rows and C be the number of columns. A coordinate is marked visited before it enters the queue, so it can be enqueued at most once. A 0 cell checks at most eight neighbors, which is a constant amount of work. Therefore, the worst-case time is O(R × C). The visited matrix and queue can both grow with the size of the board, so auxiliary space is O(R × C). The returned revealed array is output space.

A common mistake is marking a coordinate visited only when it is dequeued. Two different 0 cells could then enqueue the same neighbor before it is processed. Another mistake is expanding from numbered cells. Only 0 cells expand. Candidates may also forget diagonal neighbors even though this problem requires all eight directions. Mutating the board to record visited state breaks the contract. Recursive flood fill can overflow on a large board. Repeatedly using Array.shift() is also unnecessary because a head index gives FIFO behavior without removing elements from the front.

State the two key rules before coding: mark a coordinate visited when it enters the queue, and expand neighbors only when the current cell is 0. Those rules explain the duplicate prevention, the boundary behavior, and most of the correctness of the BFS.

I would protect login with a short-lived, single-use server-bound anti-forgery token and origin checks. After verifying credentials, I would invalidate the pre-login session and issue a fresh session ID. Secure, HttpOnly, appropriate SameSite cookies, validated identity-provider state, server-side authorization, and replay tests provide defense in depth.

This question asks how to stop another website from making a person's browser sign in to an account chosen by an attacker. The sign-in can appear successful, but the browser may now be connected to the attacker's account. The person could then unknowingly place private information into that account. It also asks how to stop an old browser identifier from becoming the identifier for a newly signed-in account. A safe design makes each sign-in belong to the browser flow that started it, gives the browser a fresh identity after success, accepts only expected sign-in returns, and rejects unexpected or repeated attempts safely.

1. Is sign-in performed directly with username and password, through an external identity provider, or both?
2. Do we control the trusted server that creates and validates the session cookie?
3. Must two or more sign-in tabs be able to remain active at the same time?
4. Are legitimate cross-site top-level redirects from an identity provider part of the required flow?

I would treat login as a security-sensitive state change even though the user is not authenticated yet.

The first threat is login CSRF. CSRF, or cross-site request forgery, means another site causes the victim's browser to send a request to our application. In login CSRF, the attacker can try to submit the attacker's own credentials through the victim's browser. If the application accepts that request without proving it belongs to a legitimate login flow, the victim may receive a session for the attacker's account. The victim can then unknowingly enter private data into an account the attacker can access.

This differs from ordinary authenticated CSRF. In ordinary CSRF, the victim is already signed in, and the attacker tries to make that existing identity perform a sensitive action, such as changing an email address. In login CSRF, the attacker's goal is instead to control which identity the victim becomes signed in as.

For a direct credential form, I would create a cryptographically unpredictable anti-forgery token on the trusted server when the login page or login attempt is created. I would bind it to that browser's pre-login context, give it a short lifetime, and require it on the credential submission. The server verifies the token before authenticating the request. A missing, mismatched, expired, or already-consumed token fails. The token becomes unusable after successful use so replaying an old login token does not work.

I would also validate request origin for the direct login endpoint. When the browser supplies an Origin header, the server compares the parsed origin exactly with the application's expected HTTPS origin. It should not use substring or suffix matching. If Origin can legitimately be absent for a supported client or browser path, a carefully defined HTTPS Referer check can be used as a fallback. If the origin cannot be established according to the application's policy, the login should fail safely rather than silently weakening the check.

These checks must be enforced by the trusted server. Frontend JavaScript cannot be the security boundary because the attacker controls the attacker's own page and can choose what requests that page attempts to send.

Credential verification also belongs on the trusted server. Passwords should travel only over HTTPS. They should never be placed in URLs, stored in localStorage or sessionStorage, embedded in frontend code, written to analytics, or logged. The frontend should contain no server secret or long-lived credential.

After credentials are successfully verified, I would rotate the session identifier. More precisely, I would invalidate the pre-login or anonymous session identifier and create a fresh, cryptographically unpredictable authenticated session identifier. The authenticated user is associated only with the new server-side session. This prevents session fixation, where an attacker tries to make the victim authenticate while continuing to use a session identifier that the attacker already knows or influenced.

The server must not accept an arbitrary session ID from a URL, form field, or other attacker-controlled input as the authenticated session identifier. If the browser arrives with a valid anonymous session cookie, that session can hold temporary state such as a CSRF token, but successful authentication must still replace its identifier. A test that begins with a known preexisting session ID should therefore observe a different session ID after login, and the old ID must no longer provide authenticated access.

For the session cookie, I would normally use Secure so the browser sends it only over HTTPS and HttpOnly so frontend JavaScript cannot read it. I would keep Domain and Path as narrow as practical. When deployment allows it, a host-only cookie such as one using the __Host- prefix is a useful additional hardening measure because it requires Secure, Path=/, and no Domain attribute.

I would choose SameSite based on the actual authentication architecture. SameSite=Lax is commonly appropriate for a first-party web session because it prevents the cookie from being sent with many cross-site requests while permitting cookies on ordinary top-level safe navigations. SameSite=Strict can be stronger but may break legitimate navigation and authentication flows. SameSite=None requires Secure and should be used only when cross-site cookie delivery is truly required. SameSite is defense in depth; it is not the sole proof that a login request is legitimate.

CORS and the same-origin policy are also not replacements for login-CSRF protection. The same-origin policy limits what an attacker's script can read from another origin, and CORS controls selected cross-origin script access. Neither means a cross-site HTML form is unable to send a request. The trusted server must therefore validate the login request even if the attacker cannot read its response.

For a redirect-based identity-provider login, I would not blindly apply the direct-form Origin rule to the callback because a legitimate top-level navigation returns from another origin. Instead, before redirecting the browser, the application creates an unpredictable correlation value, commonly the OAuth or OpenID Connect state value, and binds it to the login attempt. On callback, the trusted server validates state and all required protocol checks. Depending on the flow, that can also include PKCE and an OpenID Connect nonce. Only a callback tied to a login attempt that our application actually initiated is accepted.

The state value should not contain a raw secret merely because it travels through the browser. It should be random and associated with server-side state, or otherwise integrity-protected according to the chosen design. Authorization codes and protocol credentials must not be logged or exposed to unrelated frontend code.

For two sign-in tabs, I would not rely on one mutable global CSRF value if opening tab B would unexpectedly invalidate tab A. The server can maintain multiple outstanding, short-lived login attempts for the same browser, each with its own unpredictable, single-use identifier. Tab A must submit tab A's token, and tab B must submit tab B's token. A token used successfully cannot be replayed in the other tab.

If one tab authenticates while another login attempt is still open, the application needs an explicit policy. It may invalidate all outstanding login attempts, which is simpler and safer, or allow independent attempts if the product requires that behavior. If a later attempt is allowed to complete, it must verify its own credentials and anti-forgery state and rotate the session again. It must never inherit authentication merely because another tab completed login.

Authentication and authorization remain separate. Authentication establishes which user owns the session. Authorization decides whether that user may access a particular resource or perform an operation. Every protected request must be authorized by the trusted server. The frontend may hide or show controls for usability, but frontend state is not an authorization boundary.

Failure behavior should be safe and predictable. Invalid origin, bad anti-forgery state, token replay, invalid credentials, or invalid identity-provider correlation must not create or upgrade an authenticated session. Responses should avoid unnecessary account-enumeration detail. Security logs can record a failure category, time, request or correlation identifier, and useful diagnostic metadata, but should never record passwords, complete session cookies, anti-forgery tokens, OAuth authorization codes, or other credentials.

I would verify the design with the exact threat cases in the question. First, host a form on another origin and try to submit attacker credentials to the login endpoint; it must fail the anti-forgery or origin checks. Second, submit a valid login token once and replay it; the replay must fail. Third, start with a known pre-login session ID; successful authentication must produce a different session ID, and the old ID must not be authenticated. Fourth, perform a legitimate top-level redirect from the identity provider; a callback with valid correlation state must succeed while an uncorrelated callback must fail. Fifth, open two login tabs and verify that each has independent state, that tokens cannot be swapped or replayed, and that completion follows the application's documented concurrent-login policy.

1. Create a short-lived login attempt on the trusted server before processing credentials.
2. Generate a cryptographically unpredictable, single-use anti-forgery value and bind it to the browser's pre-login context.
3. Require the value on a direct credential submission and validate it before credential processing.
4. Validate the direct login request's expected HTTPS Origin, using only a deliberately defined fallback when Origin can legitimately be absent.
5. Reject missing, mismatched, expired, replayed, or wrong-origin requests without creating an authenticated session.
6. Verify credentials only on the trusted server and never expose passwords or server secrets through URLs, storage, logs, or frontend code.
7. On successful authentication, invalidate the pre-login session identifier and issue a fresh unpredictable authenticated session identifier.
8. Set the session cookie with Secure, HttpOnly, narrow scope, and SameSite behavior chosen for the real login architecture.
9. For identity-provider redirects, validate protocol correlation state and applicable nonce or PKCE checks rather than requiring the callback to look like a normal same-origin form submission.
10. For multiple tabs, use independent short-lived single-use login attempts or deliberately invalidate outstanding attempts after one succeeds.
11. Enforce authorization independently on every protected server request.
12. Fail safely, log without secrets, and verify cross-site submission, token replay, preexisting-session rotation, identity-provider redirects, and two-tab behavior.

The extra browser work is small: each login carries a small anti-forgery value and receives a new session cookie after successful authentication. Token and origin checks are normally constant-time operations compared with password verification, which is intentionally more expensive. The server needs a small amount of short-lived state for outstanding login attempts unless it uses an equivalent integrity-protected design. Supporting two tabs can require several temporary login-attempt records for one browser. The main operational and maintenance cost is getting expiration, replay prevention, cookie policy, concurrent-login behavior, and identity-provider exceptions correct and testing them whenever domains or authentication flows change.

Common mistakes include protecting only actions performed after login while leaving the login endpoint vulnerable; assuming SameSite alone prevents login CSRF; treating CORS or the same-origin policy as CSRF defenses; checking Origin with unsafe substring matching; accepting an attacker-supplied or pre-login session identifier after authentication instead of rotating it; failing to invalidate the old session ID; using reusable anti-forgery tokens; putting passwords or authentication secrets in URLs, browser storage, analytics, or logs; trusting frontend JavaScript as the enforcement point; rejecting every cross-site identity-provider callback instead of validating protocol correlation state; accepting an identity-provider callback without state validation; using one mutable login token that causes unsafe or unpredictable two-tab behavior; confusing authentication with authorization; revealing unnecessary account information in failures; and logging passwords, session cookies, anti-forgery tokens, or authorization codes.

Explain two independent protections first: prove that the login request belongs to a legitimate login flow, then replace the pre-login session identifier after successful authentication. Contrast login CSRF with transaction CSRF, explain the identity-provider exception, and finish by walking through the five required tests.

JSONP turns a remote response into JavaScript that runs in the including page. That creates code-supply and sensitive-data risks if the callback, endpoint, or response is attacker-influenced. Use normal JSON with fetch, server-side authorization, and narrowly configured CORS instead.

This question asks why an old method for getting information from another website can be unsafe when that information is private. The key point is that the browser does not simply receive and read the returned information. It runs what comes back as instructions inside the requesting page. That changes who the page must trust. If the remote service, the requested function name, or the returned content can be changed, harmful actions may run. It also asks whether private account information can be exposed to another website and what safer design should replace this method.

1. Does the JSONP endpoint return user-specific or sensitive account data when the user is authenticated?
2. Is the callback value fixed by the server, restricted to known values, or directly reflected from request input?
3. Can the endpoint or its hosting infrastructure be controlled by a third party or become independently compromised?

The practical decision is to avoid JSONP for sensitive browser-facing data. Return ordinary JSON and use fetch. Keep authorization on the trusted server, and use explicit CORS only when a different browser origin genuinely needs permission to read the response.

A legacy JSONP request might use <script src='https://api.example/account?callback=show'>. The server could return show({"name":"Alice"});. Because the response was loaded through a script element, the browser treats those returned bytes as JavaScript source code. It does not treat them as inert JSON.

The returned JavaScript executes in the context of the page that included the script. That means the remote endpoint is being trusted as a supplier of executable code to that page. This is the central trust boundary: the page chooses the script URL, but the remote server controls the bytes that the browser executes.

If the endpoint is compromised, it does not have to return the expected show(...) call. It can return arbitrary JavaScript. That code can do what ordinary JavaScript in the including page is allowed to do, such as inspect page-readable state, change the DOM, make requests available to that page, or steal tokens that the application has incorrectly exposed to JavaScript. Browser boundaries still apply; JSONP does not magically grant access beyond the privileges of the including page.

The callback parameter creates a second risk. A JSONP service commonly inserts a requested callback name into executable source. If it accepts unexpected syntax and reflects that text unsafely, an attacker may be able to change the structure of the generated JavaScript and inject code. A test should therefore send a callback containing characters or syntax that are not valid for the intended callback format and verify that the endpoint rejects it safely instead of reflecting it into executable output.

A fixed callback or strict callback allowlist reduces callback-injection risk, but it does not solve the fundamental problem. Even with callback=show permanently fixed, the remote endpoint still supplies executable JavaScript. If that endpoint is compromised, arbitrary returned code still executes. Callback validation therefore protects only one input path; it does not remove the script-supply trust relationship.

Sensitive account data creates a confidentiality risk as well. The same-origin policy normally prevents a page from reading arbitrary cross-origin responses, but cross-origin script inclusion has historically been allowed because websites need to load scripts from other origins. JSONP deliberately uses that script-loading behavior to bypass normal cross-origin read restrictions.

If a JSONP account endpoint returns private data based on the user's authenticated session, an attacker-controlled site may try to include that endpoint as a script. Whether authentication credentials are actually attached depends on the cookie and credential design, including modern SameSite cookie behavior. The security requirement must not depend on hoping that cross-site inclusion fails. A sensitive endpoint must not expose private account data through executable JSONP, and the trusted server must enforce authorization for the requested resource.

Authentication and authorization are different. Authentication establishes which user is making a request. Authorization decides whether that user and request are permitted to access a particular account resource. Successful authentication alone must never be treated as proof that any requesting web page is authorized to receive the data. Authorization must be enforced by the trusted server.

This is different from ordinary JSON fetched with fetch. A response such as {"name":"Alice"} is data. Merely receiving it does not execute it as JavaScript. For a cross-origin fetch, the browser's same-origin policy normally prevents the calling JavaScript from reading the response unless the remote server explicitly permits that origin through CORS. CORS therefore controls browser-readable cross-origin access; it is not authentication or authorization.

The modern browser-facing contract should use HTTPS and return application/json. A same-origin frontend can use fetch without cross-origin permission. If a trusted frontend on another origin must read the API, the server should return narrowly scoped CORS headers for approved origins. For credentialed requests, it must not use a wildcard origin. The server should authenticate when necessary and independently authorize every sensitive resource or operation.

Session cookies should use appropriate Secure, HttpOnly, and SameSite settings for the application's architecture. HttpOnly reduces exposure of session cookies to JavaScript. SameSite can reduce cross-site cookie sending. These controls are useful defense in depth, but they do not make JSONP a suitable format for sensitive data. Cookie-authenticated state-changing endpoints also need appropriate CSRF defenses because CORS is not a CSRF protection mechanism.

The safe failure behavior is to reject unsupported or malformed requests without returning sensitive information. A modern JSON endpoint should not accept a JSONP callback parameter at all. Security logs may record request identifiers, authorization failures, origin decisions, and endpoint errors, but they should not record session tokens, credentials, secrets, or sensitive account payloads.

Three tests directly verify the important boundaries. First, send a callback containing unexpected syntax. A legacy endpoint must reject it instead of reflecting it into executable source; the preferred modern endpoint accepts no callback parameter. Second, from a different site, attempt to include an authenticated account response as a script and verify that sensitive account data cannot be obtained through that mechanism. Test with the real production cookie policy because SameSite behavior matters. Third, model a compromised endpoint that returns attacker-controlled JavaScript. If the application loads that endpoint through a script element, the attacker's code executes in the including page, demonstrating why callback validation or a callback allowlist cannot solve the underlying JSONP design risk.

1. Identify whether the remote response is loaded as executable script or fetched as inert data.
2. Mark the trust boundaries among the including page, remote endpoint, callback input, authenticated session, and sensitive account resource.
3. Determine who controls the returned bytes and whether request-controlled callback text is inserted into executable source.
4. Check whether a different site can cause an authenticated JSONP response containing sensitive data to be returned, accounting for the actual cookie policy.
5. Separate authentication from authorization and require the trusted server to authorize every sensitive resource.
6. Replace JSONP with application/json over HTTPS and fetch.
7. Use same-origin access by default or a narrow CORS policy for explicitly trusted cross-origin clients.
8. Reject malformed requests safely and log failures without secrets or sensitive payloads.
9. Verify callback-syntax rejection, cross-site authenticated inclusion, and a compromised-endpoint scenario.

There is no meaningful algorithmic time or memory complexity in this security decision. The main cost is architectural and operational. Removing JSONP can require changes to the frontend request code, API response format, CORS policy, authentication behavior, authorization checks, and automated tests. Ordinary JSON is easier to maintain because data remains data instead of becoming executable source. Narrow CORS rules and server-side authorization add configuration and test work, but they create clearer trust boundaries and significantly reduce the security risk.

A common mistake is saying JSONP becomes safe when the callback name is allowlisted. An allowlist can reduce callback-injection risk, but the endpoint is still supplying executable JavaScript. Another mistake is saying the returned script executes with the API server's origin. It executes in the context of the page that included it. Candidates also confuse CORS with authentication or authorization. CORS controls whether browser JavaScript may read a cross-origin response; the trusted server must still authenticate when needed and authorize sensitive resources. Another mistake is treating ordinary JSON and JSONP as equivalent because both may contain object-shaped information. Ordinary JSON fetched through browser APIs is data, while JSONP is executable JavaScript. It is also incorrect to promise that authenticated cookies are always sent to a cross-site JSONP request in modern browsers; SameSite policy can prevent that. The correct design must remain safe regardless of that defense-in-depth behavior.

Lead with the key distinction: JSONP converts a remote response into executable JavaScript, while fetch treats JSON as data under browser read controls. Then explain callback injection, compromised-endpoint code execution, and possible authenticated-data exposure separately. Finish with the modern contract: JSON, fetch, trusted-server authorization, and narrow CORS when cross-origin reads are required.