Records are transparent immutable carriers: you declare the components and get a canonical constructor, accessors, equals, hashCode and toString. Sealed interfaces restrict which types can implement them, so a switch over those types can be checked for exhaustiveness at compile time with no default branch. Record patterns then let you destructure in the switch, which turns a chain of instanceof casts into one readable statement.
Why interviewers ask this
This dates your Java knowledge instantly and shows whether you model data deliberately. The interviewer wants to hear that sealed plus records gives you algebraic data types, that exhaustive switches turn a new subtype into a compile error rather than a runtime surprise, and that a record is not just a shorter class: it is a statement that the value is a transparent aggregate.
How to structure your answer
- Define each feature in one line and how they combine.
- Explain exhaustiveness and why a missing default is the point.
- Give a real modeling example such as a result or event type.
- Note the limits: records are shallowly immutable and not for entities.
Example answer
I use them together. A sealed interface declares the closed set of cases, each case is a record with its own components, and then a switch with record patterns handles them. So a payment result becomes a sealed interface with Approved, Declined and Pending records, and the switch destructures each one straight into its fields. The compiler enforces exhaustiveness, which is the real benefit: when someone adds a fourth case, every switch that handles the type fails to compile instead of silently falling into a default branch and doing the wrong thing. Records also gave me correct equals and hashCode for free, and a compact constructor is a natural place to validate, so an amount cannot be negative on any instance that exists. The caveats I mention are that a record is only shallowly immutable, so a record holding a list can still be mutated through that list unless I copy it in the constructor, and that they are a poor fit for JPA entities, which want a no argument constructor and mutable state.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you validate inside a record without a full constructor?
- When would you still write a regular class instead of a record?
- What does a sealed hierarchy give you that an enum does not?
Related java developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions