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.
Example:
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){
lamb()
}
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):
why:
https://kotlinlang.org/docs/reference/inline-functions.html#non-local-returns
inline fun foo(lamb: ()->Unit) = lamb()
fun bar() {
println(1)
foo{ return }
println(2)
}
is replaced with:
fun bar() {
println(1)
return
}
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 
.
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) = {
println(i)
}
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.
This confusion about val, List, and immutability vs. read-only comes up so much. I wonder if it would be worth adding a section to the docs that tries to explain this with diagrams or something. Maybe this is all already there somewhere but it would be nice to have once spot we could point people to when they get it wrong.
Trying to summarize what could be explained in that section:
A val variable’s value is usually a reference to an object. The value of the variable cannot be changed to refer to a different object. However, the object to which the val variable refers can modified unless the object itself is immutable.
A variable of type List is a read-only view to a mutable object whether the variable is declared with var or val. It is possible to modify the object referenced by that variable by using another variable of type MutableList referencing the same object.
fun main(args: Array<String>) {
val c = mutableListOf("a", "b")
val d: List<*> = c as List<*>
println("d = $d")
c.removeAt(0)
println("d = $d")
}
True most of the time. But a variable of type List can also point to a immutable list. Most of the time this is just not the case, eg listOf returns an ArrayList which is mutable.
Not that I know of (at least not in the official docs, I’m sure there are many posts about this). I was thinking about writing an addition to the docs but never did it, maybe I should.
Yes, I was oversimplifying when I wrote: “A variable of type List is a read-only view to a mutable object…” An immutable List is possible, at least, in theory.
Although, I’m having a hard time thinking of an immutable collection implementation on the JVM. Are there any?
Collections.emptyList is an immutable empty list. Collections.singletonList is immutable as well. The List.of(...) overloads as of Java 9 return immutable Lists as well. And the Lists returned by Arrays.asList(...) aren’t immutable, but have a fixed size at least. So immutable Lists aren’t nearly as rare as one might think.
Unfortunately this confusion about by reference or by value has been going on a long time. Here is a snippet of something I posted to a java group 20 years ago this week:
This is the rebuttal to your statement that only primitives are passed by
value. Are objects passed-by-value or passed-by-reference? NEITHER! Java has
no syntax whatsoever for passing an object to a function since it has no
variables that can hold objects. It can only pass around object references
since those are what non-primitive types are. And it passes those references
by value.
Some Interview questions for beginners may be
A better form of the question would be:
What’s the output from this:
fun main() {
for (i: Int in 1..10) {
if (i % 2 != 0) {
displayNumber(i)
}
}
}
fun displayNumber(i: Int) = {
println(i)
}
I don’t like the question. Yes, you have to know kotlin quite well to spot that displayNumber returns a lambda instead of calling println but I don’t think I want to work for your company if you screen people by asking trick questions.
I’d argue that displayNumber should actually have an explicit return type, to make it obvious that it returns a lambda. I at least wouldn’t let that code through a code review so I don’t think it should be part of an iterview.
I have no problem with asking about this concept, but I much prefere the version @gidds posted above
Maybe ask to explain why this code is problematic and how it could be changed. That way you not only test if your applicant knows kotlin but also how they code and that they prefere clean code over something hard to spot.
Even though our company has switched to 100% Kotlin, our applicants are not required to know Kotlin at all. It is sufficient if they understand the concepts, and have good experience in some language. Also they need to show some enthusiasm about wanting to work with Kotlin.
They can learn Kotlin while working… The same way we did when we switched to Kotlin some years ago.
Of course we ask them programming questions, but they can chose the programming language themselves. I would find it quite ridiculous to ask them hard to spot Kotlin puzzler traps.
Wasabi375 and fatjoe79: You’re right. Trick questions such as that aren’t useful in a job interview.