Coding interview: How would you build lazy pipelines with JavaScript Iterator Helpers?

1. Question and context

You must process a synchronous iterator that may contain millions of records: filter invalid rows, map them to view models, take the first 100, and calculate a total amount. The original code spread the source into an array before calling map, filter, and reduce, causing a high memory peak. Rewrite it with JavaScript Iterator Helpers and explain laziness, iterator protocols, early termination, cleanup, and older-runtime fallback.

2. What the interviewer evaluates

• Whether you understand the difference between Iterator and Iterable, and that Iterator Helpers return iterators that can continue being consumed.
• Whether you can compose map, filter, take, find, reduce, and toArray into a lazy pipeline.
• Whether you know an iterator is stateful and usually moves forward once, and that early termination gives the underlying return method a chance to clean up.
• Whether you handle infinite or expensive sources, exceptions, compatibility, and the boundary where array materialization is appropriate.

3. Clarifications to ask before answering

1. Is the source a synchronous Iterator, an Iterable, or an asynchronous paged API?
2. Must the result be returned as one array, or can the caller keep consuming it as a stream?
3. After taking N results, must a network, file, or database cursor be closed?
4. Do target Node and browser versions provide native Iterator Helpers, and is a polyfill allowed?

4. A 30-second answer framework

I would normalize the Iterable into an Iterator, then chain filter, map, and take, calling toArray only at a boundary that truly needs an array. map and filter do not traverse immediately; reduce and toArray start consumption. Once take reaches its limit, the pipeline should stop pulling and use iterator closing so resources can be released. Iterators are stateful and should not be casually shared between consumers. Older runtimes can use a controlled polyfill or generator implementation with the same semantics, tested for exceptions, early termination, and memory use on large sources.

5. Step-by-step deep answer

Step 1: Distinguish Iterator and Iterable

An Iterable provides a Symbol.iterator method that can produce an Iterator; an Iterator provides next and returns done and value. Iterator.from normalizes an input that follows the iteration protocol. Iterator Helpers operate on iterators and create lazy helpers; they do not automatically copy the entire source into an array.

Step 2: Build a lazy map, filter, and take pipeline

The function below reads the source only while the result is consumed. filter checks a row, map transforms it, and take stops after the requested count so unrelated records are not pulled.

function topAmounts(source, limit) {
  return Iterator.from(source)
    .filter((row) => row.status === "paid")
    .map((row) => ({ id: row.id, amount: row.cents / 100 }))
    .take(limit);
}

const firstHundred = topAmounts(records(), 100).toArray();

Step 3: Understand consumption timing and one-pass state

Creating a helper does not call callbacks. Pulling next, or calling forEach, find, reduce, or toArray, consumes source values. An iterator stores a current position; the first consumer changes its state and the second may see an exhausted iterator. Create a new source iterator for independent results instead of sharing a consumed instance.

Step 4: Handle early termination, return, and exceptions

Operations such as take and find can stop after a result. If the underlying iterator provides return, a helper should give it a chance to close resources on completion or failure, such as a file handle or page cursor. Business code should still release resources it owns in finally, and verify cleanup when a callback throws or a consumer stops early.

Step 5: Choose a materialization boundary and fallback

toArray materializes the remaining results, so place it only where random access, serialization, or batch rendering needs an array. Infinite iterators, large pages, and expensive computations should remain lazy. If the runtime lacks native Iterator Helpers, use a controlled polyfill or generator wrapper for map, filter, and take. Preserve one-pass consumption, early termination, and exception propagation; do not secretly convert every source to an array.

6. High-quality sample answer

I would normalize the input with Iterator.from, then chain filter, map, and take, calling toArray only at an output boundary that needs an array. Helper callbacks run during consumption, so a large source is not expanded early; take or find should stop pulling and use return to let the underlying cursor close. An iterator is stateful and normally single-use, so independent results need new source iterators. For older Node or browsers, I would use a polyfill or generator implementation with the same lazy and closing semantics, and test exceptions, early stopping, resource release, and memory peaks.

7. Common mistakes

• Spreading the source first → the whole source is materialized → keep toArray at the boundary that truly needs an array.
• Assuming creating map executes callbacks → side effects do not appear during setup → explain that consumption triggers pulling.
• Reusing one iterator → the second result is empty or partial → create a new source for each consumer.
• Continuing to request pages after take → network and resources are wasted → verify early termination calls the underlying return.
• A polyfill that only copies array results → infinite-source and exception semantics change → preserve laziness, one-pass state, and exception propagation.

8. Follow-up questions and responses

Follow-up 1: What is the key difference between Iterator Helpers and array methods?

Array methods operate on an already materialized array and usually traverse immediately. Iterator Helpers take an iterator and make lazy transformations such as map, filter, and take, pulling only the elements the consumer requests.

Follow-up 2: When should you still call toArray?

Call it when a boundary needs random indexing, serialization, a batch API that accepts only arrays, or a small one-time render. Avoid materialization for huge or infinite sources and keep consuming lazily.

Follow-up 3: Why should an iterator not be reused casually?

It stores a cursor, and next changes its internal state. After one consumer reads it, a second consumer receives the remaining position. Replaying requires a new iterator produced from the Iterable.

Follow-up 4: How do you verify that early termination releases resources?

Use a test iterator that counts pulls and records return calls. After take or find, assert that pulling stopped and return ran, then cover callback exceptions and consumer interruption.