Interview replay

Full round replay — sealed types

10 minintermediate2–12 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

“What do sealed classes enable that abstract classes cannot?”

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

Follow-ups

  1. 1. “Why not just use an abstract class with a package-private constructor?”

    Testing: Convention vs mechanism, and whether they connect it to exhaustiveness.

    Scoring

    Pass: That is a convention the compiler cannot reason about — so every switch still needs a default. Sealing is a class-file attribute enforced by javac and by the JVM at class load, and it is what makes the exhaustiveness check possible.

    Fail: 'Sealed is newer / cleaner' with no mechanism.

  2. 2. “What must be true of every permitted subtype, and why?”

    Testing: final / sealed / non-sealed, and the reason the rule exists.

    Scoring

    Pass: Each must be final, sealed, or non-sealed, because otherwise the set is not closed and exhaustiveness could not be proved. Notes that records are final for free.

    Fail: Does not know the three options, or thinks the modifier is optional.

  3. 3. “A record pattern looks like field access. Is it?”

    Testing: The best separator on this topic.

    Scoring

    Pass: No — it calls the accessor for each component. If an overridden accessor throws, Java 21 wraps it in MatchException, so the exception you catch is not the one thrown. Argues for keeping accessors trivial.

    Fail: 'It reads the field directly' stated with confidence.

  4. 4. “When does a switch over a sealed type still need a default?”

    Testing: Exhaustiveness depends on the selector's static type.

    Scoring

    Pass: When the selector is wider than the sealed type — switching on Object — or when a non-sealed branch makes the set unbounded. A default over a fully sealed type means the selector type is wrong.

    Fail: 'Never' — the most common wrong answer, and the reason people report that exhaustiveness 'does not work'.

  5. 5. “Your sealed interface is public API. You add a fifth permitted subtype. What breaks?”

    Testing: Source vs binary compatibility, and API judgement.

    Scoring

    Pass: Every exhaustive switch in consumer source stops compiling — a source-breaking change belonging in a major version. Already-compiled code keeps running and then fails at the match. Sealed public API is a stronger commitment than an open one.

    Fail: 'Nothing, it's additive.'

  6. 6. “Where would you NOT seal?”

    Testing: Does judgement exist, or is this cargo cult?

    Scoring

    Pass: Extension points: provider interfaces, plugin APIs, anything designed for third-party implementations. The test is whether adding a subtype SHOULD force every consumer to be revisited.

    Fail: 'Seal everything, it is safer.'

Score yourself

6/6 — you can hold this topic at senior level 4-5 — solid; reread "Interviewer's Next Move" 0-3 — reread "Understand It" and redo the Challenge tier

← Back to What do sealed classes enable that abstract classes cannot?