HardDSAAsked in 20247 min read

Find the Intersection of N Arrays (Not Just Two)

Q: Find the Intersection of N Arrays (Not Just Two)

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Hard > **How to read this doc:** the correctness is checked against brute force on 20,000 random inputs (including `NaN`), and the performance claims were measured with median-of-9 runs after a warm-up, because a first single-run measurement was noisy and misleading. The result: scanning each array against a small "candidates" set, starting from the smallest array, is roughly 2.5x faster than building a set per array, and an empty candidate set stops the work immediately. ## 1. The problem, restated Keep only the values present in every input array, each reported once, in the order they appear in the first array. Two arrays is a one-liner; the interview is about extending it cleanly to N, avoiding an O(N · n²) blow-up, and being explicit about duplicates. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Duplicates? | Set semantics (

716 views

147 of 154

The problem

Problem, as an interviewer would state it: "Return the values that appear in ALL of N arrays, not just two. Discuss edge cases, runtime, and how the arrays' sizes and order affect performance."

Examples:

Code

intersectAll([1, 2, 3, 4], [2, 4, 6], [4, 2, 9]); // [2, 4]
intersectAll([4, 2, 1], [1, 2, 4]);               // [4, 2, 1]  (order of the first array)

Clarifying questions expected:

Should the result contain each value once (set semantics), or respect counts (multiset)?
Which array's order should the result follow?
What should zero arguments, one array, or an empty array among the inputs return?

Code / implementation expected: Yes — real, direct proof against a brute-force reference, plus a measurement of how ordering and early exit change the cost.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Hard

How to read this doc: the correctness is checked against brute force on 20,000 random inputs (including NaN), and the performance claims were measured with median-of-9 runs after a warm-up, because a first single-run measurement was noisy and misleading. The result: scanning each array against a small "candidates" set, starting from the smallest array, is roughly 2.5x faster than building a set per array, and an empty candidate set stops the work immediately.

1. The problem, restated

Keep only the values present in every input array, each reported once, in the order they appear in the first array. Two arrays is a one-liner; the interview is about extending it cleanly to N, avoiding an O(N · n²) blow-up, and being explicit about duplicates.

2. Clarifying questions a

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: N-array intersection matches brute force, respects the first array's order, never double counts duplicates, and exits early

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 147 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextHard→

Implement an LFU (Least Frequently Used) Cache

Continue