Explain `inline` and `reified` in Kotlin
Tests your grasp of JVM performance costs and type erasure. A great answer explains how inline avoids object allocation for lambdas, and how this enables reified to bypass type erasure for runtime checks. A red flag is just saying 'it's for performance'.
What's really being asked
Your depth of knowledge on Kotlin's compiler features and how they address underlying JVM limitations. It separates senior candidates who understand why a feature exists (the performance cost of lambda objects, type erasure) from junior candidates who only know what it does. The interviewer is listening for precision on object allocation, virtual calls, and type erasure.
The full answer
Three key points in order. First, inline addresses the performance overhead of higher-order functions. Each lambda passed is an object, which requires memory allocation and a virtual call. inline eliminates this by copying the function's bytecode and the lambda's bytecode directly into the call site. Second, this inlining is a prerequisite for reified type parameters. Because the code is moved to the call site, the compiler knows the concrete type being used. Third, reified makes a generic type parameter T accessible at runtime, effectively bypassing JVM type erasure for that specific call. This allows for operations that are normally impossible, like checking myObject is T.
The mistakes people make
A major red flag is a vague answer like "inline makes code faster." This is true but misses the core mechanism. A senior answer must mention the elimination of function objects and virtual calls. Another mistake is failing to connect inline as a prerequisite for reified. Candidates might explain reified in isolation, not understanding that the type information is only available because the function is inlined. Finally, providing a code example that doesn't actually need reified shows a lack of practical understanding.
What usually comes next
"When should you not use inline?" (Answer: For large functions, as it increases code size and can hurt performance by bloating the instruction cache). "What do noinline and crossinline do?" (Answer: noinline opts a specific lambda parameter out of inlining so it can be stored or passed; crossinline prevents non-local returns from a lambda that's called in a different execution context).
A concrete example
A common Android use case is finding a parent View of a specific type. Without reified, you'd have to pass the class reference explicitly (myView.findParentOfType(CardView::class.java)), which is clumsy. With inline and reified, the call site becomes much cleaner.
inline fun <reified T : View> View.findParentOfType(): T? {
var p = parent
while (p != null) {if (p is T) return p p = p.parent } return null }
// Usage at the call site:
val parentCardView = myButton.findParentOfType<CardView>()Here, the compiler replaces T with CardView in the generated bytecode, making the p is T check possible at runtime.
Interview question
Why must a Kotlin function be declared `inline` to use a `reified` type parameter?
- a.To ensure the function call avoids creating a lambda object, which would otherwise interfere with runtime type checks.
- b.Because `reified` checks are computationally expensive and require the performance optimizations that `inline` provides.
- c.To prevent the JVM's type erasure from removing the generic type information from the function's signature in the compiled class file.
- d.Because inlining moves the function's bytecode to the call site, where the compiler can access the concrete type argument.Correct
Why? this is the answer
The `reified` keyword needs to know the actual type at runtime, which is normally erased by the JVM. The `inline` keyword enables this by copying the function's code to the call site, where the compiler knows the concrete type (e.g., `String`) and can substitute it directly into the bytecode. Option C is incorrect because `inline` doesn't prevent type erasure in general; it provides a clever workaround for a specific call.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
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