Interview replay
Full round replay — stream laziness
Timed verbal replay with pass/fail criteria per follow-up.
How to run this
The opener
“Why does a stream with no terminal operation do nothing?”
Budget: 45 seconds. Going long here is itself a fail signal.
Follow-ups
1. “What is the difference between an intermediate and a terminal operation?”
Testing: Can they give the rule rather than a memorised list?
Scoring
Pass: An intermediate operation returns a Stream and is lazy; a terminal operation returns something else and triggers execution. The return type is the rule, and there is exactly one terminal operation per pipeline.
Fail: Recites two lists with no distinguishing principle.
2. “Does a five-operation chain read the source five times?”
Testing: The most common misconception in the topic.
Scoring
Pass: No — one pass. Each element goes through every stage before the next element starts, which is why an early filter genuinely saves the later map calls.
Fail: Believes each stage completes over the whole collection before the next begins.
3. “Which operations break that one-at-a-time flow?”
Testing: Stateful operations.
Scoring
Pass: sorted and distinct. Neither can emit its first element until it has seen the input, so they buffer — which is why sorted on an infinite stream never returns.
Fail: Cannot name one, or thinks filter buffers.
4. “How does findFirst avoid scanning a million elements?”
Testing: Do they connect laziness to short-circuiting?
Scoring
Pass: The terminal operation pulls elements, so it can stop pulling. Looking for the first multiple of 77 in a million integers examines 77 of them.
Fail: Thinks the whole stream is filtered and the head taken.
5. “sorted().findFirst() — how much work is that?”
Testing: Whether they over-apply laziness.
Scoring
Pass: All of it. sorted must buffer and sort everything before it can emit one element, so findFirst cannot short-circuit through it. min with a comparator is one pass.
Fail: Says it stops at the first element.
6. “Can you reuse a stream?”
Testing: Single-use, and what to do instead.
Scoring
Pass: No — IllegalStateException, stream has already been operated upon or closed. Stream the source again, or hold a Supplier<Stream<T>> when several passes are intended.
Fail: Thinks it works as long as the first operation was intermediate.
7. “Is peek a reasonable place for logging or an audit?”
Testing: The Java 9 change, and the principle behind it.
Scoring
Pass: No. Since Java 9 count() can compute the size from the source and skip the pipeline, so peek runs zero times. The runtime may skip any lambda whose result it does not need.
Fail: Treats peek as a guaranteed hook.
8. “A stream is built, the list is then modified, then the terminal operation runs. What is seen?”
Testing: That the stream holds the source, not a snapshot.
Scoring
Pass: The modified data — the source is not read until the terminal operation. A structural change during traversal gives ConcurrentModificationException instead.
Fail: Assumes the stream copied the list when it was created.
9. “Are streams faster than loops?”
Testing: Whether they will say no.
Scoring
Pass: Not inherently. For small collections the pipeline setup costs more than the loop. They win on clarity, on large data, and where parallelism genuinely applies.
Fail: Claims streams are optimised and always faster.
Score yourself
← Back to Why does a stream with no terminal operation do nothing?