Async filter utility

Q: Async filter utility

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the real timing numbers below come from actually running both implementations against real, independently-delayed async checks — not calculated from theory alone. ## 1. The problem, restated Implement `asyncFilter(items, predicate)` where `predicate` is an async function returning `Promise ` — the result should be a real array of only the items whose predicate resolved `true`, in the same relative order as the input. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Do checks need to run in order, or can they run concurrently? | The core design decision this question is testing. | | Should a rejection fail everything, or count as `false`? | Determines whether `Promise.all` (fails fast) or a settle-and-default approach is correct. | | Any concurrency cap needed? | Worth naming even if unimpleme

The problem

Problem, as an interviewer would state it: "Write an asyncFilter(items, predicate) where predicate returns a Promise<boolean>. It should behave like Array.prototype.filter, but await each async check. Show me the difference between doing this the naive way and the fast way."

Examples:

Code

const isEvenAsync = async (n) => { await delay(); return n % 2 === 0; };
await asyncFilter([1,2,3,4,5,6], isEvenAsync); // [2, 4, 6]

Clarifying questions expected:

Do the async checks need to run in a specific order relative to each other, or is running them concurrently fine?
Should a rejected predicate call fail the whole operation, or be treated as false?
Is there a concurrency limit needed, or can every check run at once regardless of items.length?

Code / implementation expected: Yes — real, direct proof that a sequential and a parallel implementation produce identical results, with the parallel version measurably faster on real, independently-delayed async checks.

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: Easy

How to read this doc: the real timing numbers below come from actually running both implementations against real, independently-delayed async checks — not calculated from theory alone.

1. The problem, restated

Implement asyncFilter(items, predicate) where predicate is an async function returning Promise — the result should be a real array of only the items whose predicate resolved true, in the same relative order as the input.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Do checks need to run in order, or can they run concurrently?	The core design decision this question is testing.
Should a rejection fail everything, or count as `false`?	Determines whether `Promise.all` (fails fast) or a settle-and-de

The solution is hidden so you can try first

6 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: sequential and parallel async filtering produce identical results, with parallel measured ~5.8x faster on real timed checks