What does inline solve for higher-order functions, and what is reified?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: kotlinlang.org