Explain val, var, and null safety in Kotlin
This tests your grasp of immutability and Kotlin's compile-time null safety. Define val (immutable reference) vs. var (mutable), explain nullable types using ?, and state the risk is NullPointerException. A red flag is confusing val with a constant.
What's really being asked
This question seems basic, but for a senior role, it's a probe into your understanding of Kotlin's core design philosophy. The interviewer is checking if you grasp the importance of immutability for writing safe, predictable code and if you understand how Kotlin's type system is explicitly designed to prevent NullPointerExceptions (NPEs) at compile time, a major departure from Java.
The full answer
First, define the difference in mutability. val declares a read-only property or local variable. Its reference is immutable; it can be assigned only once. var declares a mutable property or variable whose reference can be reassigned.
Second, state the best practice. You should always prefer val over var to promote immutability, which reduces side effects and makes code easier to reason about, especially in multi-threaded environments.
Third, explain nullability. To declare a variable that can hold null, you must explicitly mark its type with a question mark, like String?. By default, types are non-nullable.
Fourth, identify the risk. The main risk of using a nullable type is a NullPointerException at runtime if you attempt to access a member on a null reference. The Kotlin compiler prevents this by forcing you to handle the null case, unless you explicitly bypass the check with the not-null assertion operator (!!).
The mistakes people make
Saying "a val is a constant." This is a major red flag. A val is a read-only reference. If it points to a mutable object (like a MutableList), the internal state of that object can still change. A compile-time constant is declared with const val.
Being vague about the risk. Instead of just saying "the app might crash," a strong answer specifically names the NullPointerException and explains that Kotlin's type system is designed to catch this error at compile time, not runtime.
Forgetting the ? syntax. Failing to mention the explicit ? syntax for declaring nullable types shows a weak grasp of Kotlin's core null-safety feature.
What usually comes next
How do you safely access a property on a nullable type? (Expected answer: safe call operator ?., the Elvis operator ?:, or an if (x != null) check).
When is it appropriate to use the not-null assertion operator (!!)? (Expected answer: Sparingly. Only when you are 100% certain a value is not null, for example after an external library check or during Java interop).
A concrete example
val name: String = "App" // Immutable reference. var userCount: Int = 1000 // Mutable reference. userCount = 1001 // This is valid.
var apiKey: String? = "xyz-123" // Nullable type. apiKey = null // This is valid.
val keyLength = apiKey.length // COMPILE ERROR: Only safe calls allowed. val safeLength = apiKey?.length ?: 0 // Safe access: returns length or 0 if null.
Interview question
What is the main advantage of Kotlin's approach to null safety with default non-nullable types?
- a.It allows the !! operator to be used safely in all situations.
- b.It guarantees that all val variables are compile-time constants.
- c.It simplifies code by eliminating the need for any null checks.
- d.It shifts the detection of potential NullPointerExceptions from runtime to compile time.Correct
Why? this is the answer
Kotlin's type system is explicitly designed to prevent NullPointerExceptions (NPEs) at compile time, a major benefit over languages that only catch them at runtime. Option B is a common misconception; val declares a read-only reference, not necessarily a compile-time constant.
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