Share your 3 key kotlin interview question


Hi Kotliner,
Was looking for some similar post, but couldn’t find one, so created this.

I know 3 is very less number, feel free to add 5, 10 or more.

Lets stick to kotlin jvm for this post and avoid android specific questions.

Feel free to ask trick questions, code snippet or ideomatic design related questions but also share your answer in some link or attachments for such questions.

In the next post i would share my 3 favorite key questions, which i would like to ask any kotlin developer.


Will add more tomorrow, but this is one I read wrong often and every time I find it annoying…

What is wrong about the statement “val means immutable”?

val does not mean immutable, val means read-only.

class Test{
    private val _rand = Random()
    val rand get() = _rand.nextInt()

Immutable hopefully will be added soon…

What does cross-inline mean and when do you use it?

inline fun foo(crossinline lamb: () -> Unit){

When you add crossinline, you can only return from the lambda (local return).
When you don’t add crossinline, you can return out of the place that calls the lambda as well (non-local return):


in my own words
inline fun foo(lamb: ()->Unit) = lamb()
fun bar() {
    foo{ return }

is replaced with:

fun bar() {

So you return not only out of foo, but out of bar as well. this is called non-local return.

When the lambda can be inlined, but is called inside another lambda/object, the context changes.
This means that you can’t return out of the original context anymore.
In other words, the return should not be allowed anymore.

a clear example:

inline fun createReturner(crossinline lamb: () -> Int) = object: Returner{
override fun returning() = lamb()

fun test() : Int{
    Main.returner = createReturner{
        return 4.

This is obviously not allowed: calling returner.returning() in Main, will not make test return 4.
And it would be a complete maddness when you take in account that returner.returning can be called twice :stuck_out_tongue_winking_eye: .


The term ‘read-only’ doesn’t help me much. (After all, if an object was really read-only, then it’d be immutable!)

Instead, I think of val as meaning that the reference is immutable — not the object it points to.

(Probably harking back to my days of coding in C, where const is part of the type and can apply to pointers or to the values they point to…)

One of the puzzlers that’s ensnared me before is illustrated by:

fun displayNumber(i: Int) = {

That compiles, but does it do what’s expected?

No! It’s intended to take a number and print it; but what it actually does is take a number and return a function which prints it.
The mistake is the extraneous equals sign.
This sort of problem can be very hard to spot. A good way is to specify the function’s return type: if you give Unit but the compiler finds () -> Unit, it’ll complain.


Nop. I understand what you mean, but a property is not pointing to an object. A property is just a combination of a getter and optionally also a setter and backing variable. There is nothing immutable about a property.

This idea leads to a lot of problems. For example some people think of List to be immutable because it just has val-properties, it is read-only though.