Explain val vs. var and null safety in Kotlin
Tests your grasp of Kotlin's core principles: immutability and compile-time null safety. Define val (read-only) vs. var (mutable), declare nullables with ?, and identify the risk as runtime NullPointerExceptions.
What's really being asked
This question checks your understanding of Kotlin's foundational principles: immutability preference (val over var) and compile-time null safety. Interviewers want to see that you not only know the syntax but also grasp why these features exist—to write safer, more predictable code and avoid the "Billion-Dollar Mistake" of null pointer exceptions common in languages like Java. It's a test of fundamental language design philosophy.
The full answer
A strong answer addresses three points in order. First, explain val vs. var: val declares a read-only property or local variable, meaning the reference cannot be reassigned after initialization. var declares a mutable property or variable that can be reassigned. Emphasize the preference for val to promote immutability. Second, explain how to declare a nullable type by appending a question mark to the type name, for example, String?. This explicitly tells the compiler the variable can hold a null value. Third, identify the main risk: a NullPointerException (NPE) at runtime if you attempt to access a member of a null reference. Explain that Kotlin's type system is designed to prevent this by forcing developers to handle nullability at compile time, using constructs like safe calls (?.) or the Elvis operator (?:).
The mistakes people make
A major red flag is confusing reference immutability with object immutability. Saying "a val object cannot be changed" is incorrect. For example, if you have a val list = mutableListOf(1, 2), you cannot reassign list, but you can absolutely call list.add(3). The reference is immutable, not the object it points to. Another weak answer simply states the risk is an "NPE" without explaining that Kotlin's key innovation is moving this check from a runtime surprise to a compile-time error, which is the entire point of its null safety system. Finally, forgetting to mention the ? syntax for declaring nullables is a basic omission.
What usually comes next
Expect questions about specific null-handling mechanisms. "When would you use the non-null assertion operator (!!)?" (Answer: Almost never; it's a code smell, used only when you are 100% certain a value is not null, often during Java interop). "What is the difference between a safe call (?.) and the Elvis operator (?:)?" (Answer: ?. executes the call if the receiver is not null and returns null otherwise. ?: provides a default value if the expression on its left is null). "What is lateinit and how does it relate to nullability?" (Answer: It's a promise to the compiler that a non-null var will be initialized before its first use, avoiding null checks but risking an UninitializedPropertyAccessException if you break the promise).
A concrete example
"In our user profile screen, we might have val userId: String which is passed on creation and never changes. However, we could have var userBio: String? = null. It's a var because the user can edit their bio, and it's nullable (String?) because a new user might not have a bio yet. Trying to access userBio.length directly would be a compile-time error. We must use userBio?.length ?: 0 to safely get the length or default to 0 if it's null, preventing a runtime NPE that would crash the app."
Interview question
Given the Kotlin declaration `val userNames = mutableListOf("Alice")`, which statement accurately describes the `userNames` variable?
- a.The code fails to compile because a `val` cannot reference a mutable object.
- b.The list is completely immutable; no new users can be added or removed.
- c.The variable `userNames` can be reassigned to a new list, as long as the new list is not null.
- d.The variable `userNames` cannot be reassigned, but the list it points to can be modified.Correct
Why? this is the answer
The `val` keyword creates a read-only reference, meaning the `userNames` variable cannot be reassigned. However, the `mutableListOf` object it points to is still mutable, allowing its contents to be changed. A common misconception is that `val` makes the object itself immutable.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kotlin — each one lists the topics its interview covers.
See open roles