Explain Kotlin's `reified` type parameters and their use case

What's really being asked

This question tests your understanding of a core Kotlin language feature that directly addresses a fundamental limitation of the JVM: type erasure. The interviewer is checking if you know not just the syntax, but the underlying mechanism. A senior-level answer connects reified to inline functions, explains how inlining enables this feature, and articulates the practical benefit of creating cleaner, more type-safe APIs.

The full answer

First, state the problem: On the JVM, generic type information is erased at runtime. A List<String> is just a List to the runtime, so you can't check myVar is T where T is a generic type parameter.

Second, introduce reified as the solution. Marking a type parameter as reified makes its type information accessible within the function at runtime. This allows you to perform operations that would normally require a Class object, like type checks (is T) or creating instances.

Third, explain the critical dependency on inline functions. reified only works with inline functions because the compiler doesn't generate a standard function call. Instead, it copies the body of the inline function directly to the call site. During this process, it substitutes the generic type parameter T with the actual type used in the call (e.g., MyClass). The type is now baked into the bytecode, not erased.

Fourth, provide a clear example. Contrast the verbose Java-style approach of passing a class reference, fun <T> findAncestor(clazz: Class<T>), called with findAncestor(MyView::class.java), with the clean Kotlin reified version, inline fun <reified T> findAncestor(), called with findAncestor<MyView>().

The mistakes people make

A candidate isn't ready if they forget the inline requirement. reified is meaningless without inline, and missing this link shows a superficial understanding. Another red flag is a vague definition like "it's for generics" without explaining the problem of type erasure. Finally, some candidates mistakenly believe reified can be used on classes or non-inline functions, which is incorrect.

What usually comes next

Expect questions about the trade-offs. For example, "What is the performance cost of inline?" The answer is that it increases the size of the generated bytecode, so it should be avoided for large functions. Another follow-up could be, "What are noinline and crossinline?" These are modifiers for lambda parameters within an inline function to control which parts are inlined and to manage non-local returns.

A concrete example

The classic example is finding a view of a specific type in a hierarchy. Without reified, you need to pass the class type explicitly: fun <T> View.findParentOfType(clazz: Class<T>): T?

myView.findParentOfType(Button::class.java)

With reified, the API becomes much cleaner because the type is accessed directly from the generic parameter: inline fun <reified T> View.findParentOfType(): T? { var p = parent

while (p != null && p !is T) { p = p.parent }

return p as T? } myView.findParentOfType<Button>()