Explain Kotlin's declaration-site variance with `in` and `out`
This tests your grasp of type systems and API design. Explain how out (covariance/producer) and in (contravariance/consumer) provide type safety at the declaration site, simplifying usage. A red flag is confusing variance with immutability.
What's really being asked
Your ability to connect abstract type system concepts (covariance, contravariance) to practical API design. Interviewers want to see if you understand why Kotlin chose declaration-site variance over Java's use-site wildcards, focusing on the producer/consumer pattern for type safety.
The full answer
Four key points in order. First, define variance: covariance (out) preserves subtyping (a List<String> is a List<Any>), while contravariance (in) reverses it (a Consumer<Any> is a Consumer<String>). Second, explain out T for covariant types, where T is only produced (return types), like in interface Source<out T>. This allows a Source<String> to be used where a Source<Any> is expected. Third, explain in T for contravariant types, where T is only consumed (function arguments), like in interface Comparable<in T>. This allows a Comparable<Any> to be used where a Comparable<String> is expected. Fourth, emphasize that this is declaration-site variance, which makes APIs cleaner by baking in these producer/consumer rules at the class level, avoiding repetitive use-site annotations like in Java.
The mistakes people make
The most common red flag is confusing variance with immutability. A type marked with out is not immutable; for example, you can still call clear() on a list since the method takes no parameters. Variance guarantees type safety, not immutability. Another mistake is mixing up in and out or failing to connect them to the producer/consumer pattern (PECS: Producer-Extends, Consumer-Super). Simply describing the syntax without explaining the design benefit is a junior-level answer.
What usually comes next
"When would you still need use-site variance in Kotlin?" (For types that are both producers and consumers, like MutableList, to restrict a specific usage). "What is the term for use-site variance in Kotlin?" (Type projection). "Can you give an example of a standard library class that uses in or out?" (List<out E> is a producer, Comparable<in T> is a consumer).
A concrete example
Consider a generic Box. If it's a producer, it's covariant: class ProducerBox<out T>(val item: T). Now you can safely assign a ProducerBox<Int> to a variable of type ProducerBox<Number>. If it's a consumer, it's contravariant: interface ConsumerBox<in T> { fun pack(item: T) }. You can safely assign a ConsumerBox<Number> to a variable of type ConsumerBox<Int> because if it can pack any Number, it can certainly pack an Int.
Interview question
What is the primary implication of declaring a generic type parameter with the `out` modifier, as in `interface Source<out T>`?
- a.It restricts the type `T` to only be used as a parameter in the class's methods.
- b.It allows an instance of `Source<String>` to be used where `Source<Any>` is expected.Correct
- c.It allows an instance of `Source<Any>` to be used where `Source<String>` is expected.
- d.It ensures that instances of the `Source` class are immutable.
Why? this is the answer
The `out` modifier indicates covariance (a producer), which preserves the subtyping relationship. This allows a `Source<subtype>` (like `String`) to be used as a `Source<supertype>` (like `Any`). A common misconception is that `out` implies immutability, but it only enforces type safety.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
- #kotlin
- #generics
- #api design
- #type system
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kotlin — each one lists the topics its interview covers.
See open roles