What do the safe call and Elvis operators do in Kotlin?
Kotlin null-safety and default-value fallback.
?. yields null if receiver is null; ?: provides the right operand when left is null; chain as val len = str?.length ?: 0.
Using !!, verbose if checks, or stating ?.
What's really being asked
Your understanding of Kotlin's compile-time null-safety and your ability to handle nullable types idiomatically. The interviewer wants to see that you know how to access members on a nullable receiver without triggering a NullPointerException and how to supply a default value in a single expression rather than resorting to verbose control flow or unsafe assertions.
The full answer
Four things in order. First, define the safe call operator ?. as an operator that evaluates the property or function call only when the receiver is non-null, otherwise producing null. Second, define the Elvis operator ?: as a binary operator that returns its left operand if that operand is non-null, otherwise returning its right operand. Third, explain that these operators are designed to work together so that ?. can produce a nullable intermediate result and ?: can immediately provide a fallback. Fourth, provide a concise code example such as val length = text?.length ?: 0 where text is a String?, demonstrating that if text is null the expression evaluates to 0 without an NPE.
The mistakes people make
Three red flags stand out. One is using the not-null assertion !! to force unwrap the nullable, which defeats Kotlin's null-safety and can crash at runtime. Another is writing a multi-line if-else null check when the operators already express the intent more cleanly. A third is incorrectly stating that ?. changes the type from nullable to non-null; in reality ?. still returns a nullable type unless combined with ?: or another null-handling mechanism.
What usually comes next
The interviewer may ask what happens when you chain multiple safe calls together, such as user?.address?.city ?: "Unknown". They might also ask how ?. differs from let, or when you would prefer an explicit if (x != null) block over these operators. Another common follow-up is how these operators interact with platform types coming from Java interop.
A concrete example
Imagine a function that formats a user label from a nullable User object. You can write val label = user?.name?.capitalize() ?: "Guest". Here, user?.name returns null if user is null, name?.capitalize() returns null if name is null, and ?: "Guest" substitutes the default string whenever any part of the chain yields null. The result is a non-null String without any branching.
Interview question
If user is null, what happens when evaluating user?.name ?: "Guest"?
- a.It throws a NullPointerException because safe calls crash on null receivers
- b.It returns Guest without throwing an exceptionCorrect
- c.It returns null because the safe call preserves the nullable type
- d.It requires an explicit null check to compile safely
Why? this is the answer
The safe call operator ?. returns null when user is null, and the Elvis operator ?: then substitutes Guest as the fallback. Option C is tempting because ?. does preserve nullability, but it ignores that ?: immediately provides the default value.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
- #kotlin
- #null-safety
- #operators
- #android
- #interview
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