What problem does `inline` solve, and how does `reified` relate?

What's really being asked

This question probes your understanding of the performance implications of higher-order functions in Kotlin and the mechanisms the language provides to mitigate them. It specifically tests if you know that lambdas are objects that create runtime overhead. It then checks if you understand JVM type erasure and how the combination of inline and reified provides a type-safe, ergonomic workaround. It separates senior candidates who understand the "why" from junior developers who only know the "what".

The full answer

A strong answer addresses three points in order. First, it explains the problem inline solves: higher-order functions create function objects and capture closures, which leads to memory allocations and virtual call overhead. inline eliminates this by copying the function body and the passed lambda's body directly into the call site, avoiding object creation. Second, it defines reified as a keyword that makes a generic type parameter's information available at runtime, overcoming standard JVM type erasure. Third, it connects the two by explaining that reified is only possible on inline functions because inlining allows the compiler to substitute the concrete type (e.g., String) for the generic placeholder (T) directly in the bytecode at the call site. Without inlining, the type would be erased.

The mistakes people make

A frequent red flag is describing inline as just "making code faster" without specifying the mechanism related to lambdas and object allocation. Some candidates forget to mention the overhead of function objects entirely. Another mistake is explaining reified correctly but being unable to articulate why it depends on inline. A candidate might say "you just have to use them together" without explaining that the code substitution from inlining is what preserves the type information that would otherwise be erased. Finally, providing a poor code example, like one that doesn't actually use the reified type for a check (e.g., is T), shows a theoretical but not practical understanding.

What usually comes next

Be prepared for questions about the downsides of inline, such as increased code size, and when not to use it (e.g., for large functions). An interviewer might also ask about noinline and crossinline to test the depth of your knowledge. For example, "What if you have two lambda parameters but only want to inline one? How would you do that and why?" (Answer: noinline). Or, "What if your lambda needs to be called from a different execution context, like a Runnable? What problem would that cause for an inline function and how do you solve it?" (Answer: non-local returns are disallowed, use crossinline).

A concrete example

Here is a utility function that filters a list for items of a specific type, which is only possible with reified.

inline fun <reified T> List<Any>.filterIsInstance(): List<T> {

val destination = mutableListOf<T>()
for (element in this) {
if (element is T) {
destination.add(element)
}
}

return destination }

// Usage:

val mixedList: List<Any> = listOf("hello", 1, 2.0, "world")
val strings: List<String> = mixedList.filterIsInstance<String>()

// strings will contain ["hello", "world"]

This demonstrates how reified T allows the runtime check element is T, which would be impossible with a regular generic function due to type erasure.