What does inline solve for higher-order functions, and what is reified?
It tests lambda overhead and type erasure. Answer: inline flattens lambdas into call sites to remove allocation and virtual calls; reified needs inline so the compiler knows the concrete type at the call site, enabling is T checks.
What's really being asked
The interviewer wants to see if you understand the runtime model of Kotlin higher-order functions and the interaction between inlining and JVM type erasure. Specifically they are looking for knowledge of why lambdas incur overhead, how inline mitigates it, and why reified type parameters are only possible when the compiler can perform substitution at the call site.
The full answer
First, explain that passing a lambda to a higher-order function creates a function object and captures a closure, which costs memory allocations and virtual calls. The inline keyword tells the compiler to copy the function body and the lambda bodies directly into the call site, removing that overhead. Second, mention that because the lambda is inlined, non local returns become possible; a return inside the lambda can exit the enclosing named function. Third, explain that reified type parameters solve the problem of JVM type erasure. Normally a generic type parameter T is erased at runtime, so you cannot do x is T. An inline function with a reified type parameter allows the compiler to know the exact type argument at the call site and substitute the concrete type into the generated bytecode, making runtime type checks like p is T valid. Fourth, give a concrete example.
The mistakes people make
Saying inline is just a performance hint with no semantic changes. Ignoring non local returns entirely. Claiming that reified works on ordinary functions. Confusing reified with passing a Class reference manually. Stating that inline reduces stack depth; it actually can increase code size because bodies are duplicated.
What usually comes next
When would you use noinline or crossinline and what is the difference? What are the binary compatibility risks of inline functions? How does inline affect stack traces and debugging? Can you inline functions with no lambda parameters, and why does the compiler warn you? How would you implement a type-safe generic builder without reified?
A concrete example
Consider traversing a tree. Without reified you write fun TreeNode.findParentOfType(clazz: Class<T>): T? and call it with MyNode::class.java. With reified you write inline fun <reified T> TreeNode.findParentOfType(): T? { var p = parent; while (p != null && p !is T) { p = p.parent }; return p as T? }. At the call site you write treeNode.findParentOfType<MyTreeNode>() and the compiler emits bytecode that checks against the concrete MyTreeNode type.
Interview question
Why does a reified type parameter require the enclosing function to be marked inline?
- a.Because reified parameters implicitly create a Class reference, which inline functions can pass without allocation overhead.
- b.Because the JVM preserves generic type information only for methods flagged as inline by the Kotlin compiler.
- c.Because inlining copies the body to the call site so the compiler can substitute the concrete type into bytecode despite JVM erasure.Correct
- d.Because inline functions execute faster, and reified type checks would otherwise be too slow at runtime.
Why? this is the answer
Inlining copies the function body to each call site, letting the compiler replace the type parameter with the exact type argument in the generated bytecode and bypass JVM erasure. Distractor D is wrong because reified does not merely inject a Class reference; it performs compile-time type substitution to enable runtime type checks.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
- #kotlin
- #inline-functions
- #reified
- #higher-order-functions
- #type-erasure
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