Declaration Forms
The shapes a function declaration can take — top level, nested, expression-bodied — and the parameter features that go with them: defaults, named arguments, and varargs. Interviewers grade whether you use these instead of overload piles.
part ofKotlinoverview, primer and where to startread it →on this pageshowhide
explore
- Top-Level Functions5 questions
- Default Arguments5 questions
- Named Arguments5 questions
- Vararg & Spread Operator5 questions
- Single-Expression Functions5 questions
- Local & Nested Functions5 questions
- Function & Bound References5 questions
- Unit & Nothing Return Types5 questions
questions
page 2 of 2How do @JvmName and @JvmMultifileClass change the file facade, and when would you use them?
basics
~10 s@JvmName renames the generated facade class so Java callers see a nicer name. @JvmMultifileClass lets several files share one facade class, so functions split across files appear under a single name to Java.
When should you choose a top-level function over a companion-object method or member function, and what are the design trade-offs?
basics
~20 sUse a top-level function when the behavior doesn't belong to any specific object's state. Use a member or companion method when the function is conceptually part of a type, needs its private internals, or should be namespaced under that type.
When should you explicitly declare a function's return type as Nothing, and what concrete benefits does that give callers versus declaring it Unit or omitting the type?
basics
~20 sDeclare Nothing when a function never returns — it only throws or loops. This lets callers use it after Elvis, in when-branches, and as any value, and tells the compiler the code after it is dead.
Does spreading an array into a vararg parameter copy it or pass the same array? Explain the aliasing/mutation implications, including when the vararg parameter type is `Array<T>` of objects.
basics
~20 sSpreading copies the array's elements into a new array that the function receives, so the function's array is a different array. But for object elements both arrays point at the same objects, so mutating an object is visible to both.
What is the `KFunction` type that a `::` reference produces, and what additional capabilities does it give you beyond plain invocation?
basics
~10 sA :: reference is a KFunction object. Besides being callable, it carries reflection info — you can read its name, parameters, return type, and modifiers like whether it's suspend or inline.
As a senior, when would you mandate explicit return types on single-expression functions across a codebase, and how does this interact with overrides and binary compatibility?
basics
~20 sFor public or library code, require explicit return types so the type is a deliberate promise that won't change by accident. For small private helpers, inference is fine. Explicit types also make overrides and shared APIs safer and more stable.
How do Unit and Nothing interact with type inference and generics — for example, the inferred type of `val x = null`, the result of `emptyList()`, and lambdas like `{ throw E() }`?
basics
~20 sNothing is the type the compiler picks when an expression has no real value, like a lambda that only throws. null alone is Nothing?. The compiler then specializes these from context, and Unit is what value-less lambdas infer to.
From an API-design and binary-compatibility standpoint, when would you prefer default arguments over explicit overloads, and what are the pitfalls of adding a new defaulted parameter to a published function?
basics
~20 sDefaults give cleaner, smaller APIs and are great for optional configuration. But adding a defaulted parameter to an already-published function changes its bytecode signature, which can break Java callers and previously compiled binaries even though Kotlin source still compiles.
How should named arguments influence the design and evolution of a public Kotlin API?
basics
~10 sBecause callers can pass arguments by name, parameter names become part of your public contract. Pick names carefully and avoid renaming or reordering them, since that can break callers who used names.
Explain how Kotlin `vararg` maps to JVM varargs for interop, how spread interacts with calling Java varargs methods, and one subtlety of overload resolution between a vararg overload and a fixed-arity overload.
basics
~20 sKotlin vararg compiles to a normal JVM varargs array, so Java code can call it and Kotlin can call Java varargs the same way. To pass an existing array to either, use the * spread. When both a vararg and an exact fixed overload match, Kotlin prefers the more specific fixed-arity one.
showing 31–40 of 40