Kotlin Null Safety: Catch Nulls at Compile Time
Kotlin's type system catches null pointer errors at compile time. Variables are non-nullable by default; you must opt-in to nulls with a ? (e.g., String?). The compiler then forces you to handle the null case. The main footgun is the !! operator.
Why it exists
In many languages like Java, any object reference can be null, leading to unexpected runtime crashes called NullPointerExceptions (NPEs). This is so common it's been called "The Billion-Dollar Mistake." Kotlin was designed to solve this by catching null-related errors at compile time, not runtime.
The mental model
Think of variables as non-nullable by default. You must explicitly ask for permission to store a null value. The compiler acts as a strict partner, forcing you to prove you've handled the possibility of null before you can use the variable. It's an opt-in system for nulls, not a free-for-all.
How it works
Kotlin's type system distinguishes between two kinds of types. A non-nullable type, like String, can never hold a null value; the compiler will throw an error if you try. A nullable type, marked with a question mark like String?, can hold a string or null. When you have a nullable type, the compiler forbids you from accessing its properties directly (e.g., myString.length). You must use a safe mechanism. Three common ways are: first, an explicit if (myString != null) check; second, the safe call operator ?. (e.g., myString?.length), which returns null if the variable is null; third, the Elvis operator ?: to provide a default value if the result is null (e.g., myString?.length ?: 0).
When to use it
Null safety is a fundamental feature you use constantly in Kotlin. Use a nullable type (Type?) whenever a value can legitimately be absent. This is common when dealing with optional data from an API, database queries that might return no result, or properties that are initialized later.
When not to use it
The main thing to avoid is the not-null assertion operator (!!). This operator tells the compiler, "I promise this value is not null," turning a compile-time safety guarantee back into a potential runtime crash. Use it only when you are absolutely certain a value cannot be null. While rare, other causes of NPEs in Kotlin include Java interoperability and complex initialization logic.
One canonical example
A function to get a user's name from a map, providing a default if the user doesn't exist. fun findUserName(id: Int, users: Map<Int, String?>): String { return users[id] ?: "Unknown User" }. Here, the map lookup users[id] returns a nullable String?. The Elvis operator ?: cleanly provides the default value "Unknown User" if the result is null, all in one line.
Interview question
What is the main consequence of using the not-null assertion operator (!!) in Kotlin?
- a.It automatically converts a nullable type into its non-nullable equivalent without any risk.
- b.It tells the compiler to trust that a value is not null, potentially leading to a runtime NullPointerException if it is.Correct
- c.It safely calls a method or accesses a property on a nullable object, returning null if the object itself is null.
- d.It provides a default value if the expression on its left side evaluates to null.
Why? this is the answer
The not-null assertion operator (!!) bypasses Kotlin's compile-time null safety, forcing the compiler to assume a value is non-null. If the value turns out to be null at runtime, it will result in a NullPointerException, defeating the purpose of Kotlin's null safety. Option A is incorrect because it introduces risk, and options C and D describe the Elvis operator (?:) and safe call operator (?.), respectively.
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