Interview replay

Full round replay — collectors

10 minintermediate1–10 yrs

Timed verbal replay with pass/fail criteria per follow-up.

How to run this

Answer out loud, timed. Do not read the entry first. Then compare against "The Answer" and "Interviewer's Next Move" and mark yourself.

The opener

“How do Collectors.groupingBy and toMap differ in failure modes?”

Budget: 45 seconds. Going long here is itself a fail signal.

Follow-ups

1. “What exactly does toMap do on a duplicate key?”
Testing: Throws, or silently overwrites?
Scoring
Pass: Throws IllegalStateException, naming the key and both values. It does not keep the last — that is what the three-argument merge function asks for explicitly.
Fail: Says it overwrites with the last value.
2. “Why does toMap reject a null value when HashMap accepts one?”
Testing: Mechanism, not just the rule.
Scoring
Pass: It is implemented with Map.merge, whose contract rejects null values. The restriction comes from the collector, not the map, which is why a plain put on the same key and value succeeds.
Fail: Assumes maps in general reject nulls, or has no explanation.
3. “Why can groupingBy never have either problem?”
Testing: Whether they see it is structural.
Scoring
Pass: Its value is a collection, so a repeated key appends rather than collides, and there is no single value that could be null. The failure mode was designed out rather than handled.
Fail: Thinks groupingBy handles duplicates with special logic.
4. “What is a downstream collector, and name three.”
Testing: The half of groupingBy most people never use.
Scoring
Pass: The second argument deciding what each group becomes — counting, summingInt, mapping, collectingAndThen, or another groupingBy for a nested index.
Fail: Only knows the single-argument form.
5. “groupingBy with a boolean, or partitioningBy?”
Testing: The empty-side trap.
Scoring
Pass: partitioningBy always returns both true and false keys even when one side is empty. groupingBy omits the side it never saw, so get(true) can return null.
Fail: Calls them equivalent.
6. “How do you get the highest paid person per department?”
Testing: Do they handle the Optional?
Scoring
Pass: groupingBy with collectingAndThen(maxBy(comparing(...)), unwrap). maxBy returns an Optional, and collectingAndThen removes it as the group is finished rather than leaving Optional in the map type.
Fail: Leaves Map<String, Optional<Employee>> and calls it done.
7. “What map type does groupingBy return, and can you rely on its order?”
Testing: Implementation detail versus contract.
Scoring
Pass: A HashMap, with unspecified iteration order. If order matters, pass a map factory — TreeMap::new or LinkedHashMap::new. Relying on the default is depending on an implementation detail.
Fail: Assumes insertion order is kept.
8. “Is the list inside a groupingBy result safe to mutate?”
Testing: Guarantees versus current behaviour.
Scoring
Pass: Not guaranteed. Neither the map type nor the list type nor their mutability is specified — it happens to be an ArrayList today. Say what you want with an explicit downstream collector.
Fail: Says yes because it works.
9. “How would you compute a count and a total in one pass?”
Testing: Awareness of teeing, or a sensible alternative.
Scoring
Pass: Collectors.teeing since Java 12, which runs two collectors over the same stream and merges the results. Before that, summarizingInt or a custom collector.
Fail: Two separate streams over the same source, with no acknowledgement of the extra pass.

Score yourself

9/9 — you can design with collectors, not just use them 7-8 — solid; the null rationale and the map-type question are where points go 5-6 — you use groupingBy but not its downstream; redo the Challenge 0-4 — run the Warm-up and cause both exceptions on purpose

← Back to How do Collectors.groupingBy and toMap differ in failure modes?