Null Safety Interview Questions
KOTLIN › Language Idioms
When reviewing a PR, you spot heavy use of !! to silence the compiler. How do you push back and what would you suggest instead?
What a strong answer covers: A strong answer treats every !! as a deliberate 'crash here if I'm wrong' assertion and asks whether that's actually the intended behavior; if the value truly can never be null, they'd make that guarantee explicit (a non-null type, requireNotNull with a message, or restructuring so the nullable is resolved earlier), and if null is a legitimate case, they'd replace it with ?.let, elvis (?:), or an early return. They'd also flag that !! throws a bare NullPointerException with no context, so at minimum it deserves a message explaining the invariant.
Walk me through the risk of Java interop platform types (Type!) in a real Android codebase: where do they tend to bite, and how do you defend against them?
What a strong answer covers: Platform types come from Java APIs without nullability annotations, older Android SDK methods and some third-party Java libraries, and Kotlin lets you treat them as either nullable or non-null with zero compiler enforcement either way, so the danger spot is exactly where a team assumes an SDK method never returns null and skips a check. A strong answer describes wrapping such APIs in a thin Kotlin adapter layer that pins down real nullability once, and leaning on @Nullable/@NonNull annotations upstream so Kotlin can infer a proper nullable or non-null type instead of a platform type.
Some teams ban !! entirely via lint rules; others allow it in tests or startup code. Where do you draw the line, and how do you decide when a nullable is genuinely a bug versus a real business case to handle gracefully?
What a strong answer covers: A strong answer frames this around blast radius and recoverability: in test code or app-startup/DI wiring where a null genuinely means a broken build, an immediate crash via !! or requireNotNull is useful fail-fast behavior; on user-facing runtime paths, like parsing a server response or reading a nullable form field, a null is often an expected business state that should be handled with elvis, early-return, or a sealed error state rather than crashing the app. They'd also mention codifying the decision as a team convention or lint suppression policy rather than leaving it to individual judgment call by call.