Skip to content
tezvyn:

Compare and contrast `apply` and `let` scope functions

Source: kotlinlang.orgHardHow cards are made

Compare and contrast `apply` and `let` scope functions

Tests Kotlin scope function knowledge: context (this/it) & return value. apply uses this, returns the object (for config). let uses it, returns lambda result (for null-checks/transforms). Red flag: mixing up return values or use cases.

What's really being asked

This question tests your deep understanding of idiomatic Kotlin, specifically the nuances of scope functions. The interviewer wants to see if you can articulate the two critical differences between apply and let: 1) the context object reference (this vs. it) and 2) the return value (context object vs. lambda result). A senior answer goes beyond a simple definition to explain why these differences lead to distinct, canonical use cases for configuration versus null-safe transformation.

The full answer

First, define the context object. apply executes the lambda as an extension function, so the context object is an implicit receiver, available as this. let passes the context object as a lambda argument, available as it. Second, define the return value. This is the key differentiator. apply returns the context object itself, allowing for fluent chaining of object initializations. let returns the result of the last expression inside the lambda, which is used for transforming the object into a new value or type. Third, provide the canonical use case for apply: object configuration. It's perfect for setting multiple properties on a new instance, like a Dialog or Intent. Fourth, provide the canonical use case for let: executing a block of code on a non-nullable object (often with the safe-call ?.let) or mapping the object to a new result.

The mistakes people make

A major red flag is confusing the return values. For example, trying to assign the result of an apply block to a variable expecting a computed value, or trying to chain calls on the original object after a let block that returned a Unit or String. Another weak answer is describing them as interchangeable without acknowledging their distinct purposes. Forgetting to mention the ?.let pattern for null safety is a missed opportunity to demonstrate practical knowledge. Finally, simply stating the difference is this vs it without explaining the implication for readability and usage is a junior-level answer.

What usually comes next

Expect questions about the other scope functions: "When would you use run over apply?" (Answer: When you need to configure an object AND return a result). Or, "How does also differ from let?" (Answer: also returns the context object, making it useful for side-effects like logging without altering the chain). You might also be asked about the dangers of overusing or nesting scope functions, which can harm readability.

A concrete example

For apply, object configuration is key. For example, creating an Android Intent:

val intent = Intent(this, MainActivity::class.java).apply { putExtra("USER_ID", 123); action = "ACTION_VIEW" }

The intent variable holds the configured Intent object, ready to be used.

For let, null-safe transformation is the classic use case:

val user: User? = findUserById(id)
val userEmail: String? = user?.let { "Contact: ${it.email}" }

Here, the lambda only executes if user is not null, and userEmail becomes a String? containing the computed result, not the User object.

Interview question

Which Kotlin scope function is most idiomatic for configuring an object's properties and then returning the configured object itself?

  • a.applyCorrect
  • b.also
  • c.run
  • d.let
Why?

apply is specifically designed for object configuration; it executes a block of code on the receiver (available as 'this') and returns the receiver object itself. In contrast, let returns the result of its lambda, making it unsuitable for directly returning the configured object.

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.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on kotlin — each one lists the topics its interview covers.

See open roles