Testing scope functions and lambdas in Kotlin - Time & Space Complexity

Time Complexity: Testing collection functions and lambdas

O(n)

Understanding Time Complexity

We want to understand how the time it takes to run Kotlin collection functions and lambdas changes as the input grows.

How does the number of operations increase when using these functions with larger data?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

val numbers = listOf(1, 2, 3, 4, 5)
numbers.map { it * 2 }
       .filter { it > 5 }
       .forEach { println(it) }
    

This code doubles each number, keeps those greater than 5, and prints them.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: The map, filter, and forEach each loop over the list.
• How many times: Each function goes through all items once, so three times total over the list.

How Execution Grows With Input

Explain the growth pattern intuitively.

Input Size (n)	Approx. Operations
10	About 30 (3 times 10)
100	About 300 (3 times 100)
1000	About 3000 (3 times 1000)

Pattern observation: The total work grows directly with the size of the list, multiplied by the number of functions called.

Final Time Complexity

Time Complexity: O(n)

This means the time to run grows in a straight line as the input list gets bigger.

Common Mistake

[X] Wrong: "Using multiple collection functions like map and filter makes the code run in constant time because they are built-in."

[OK] Correct: Each collection function processes the whole list once, so the total time grows with the input size, not fixed.

Interview Connect

Understanding how collection functions and lambdas affect performance helps you write clear and efficient Kotlin code, a skill valued in many coding challenges and real projects.

Self-Check

"What if we combined map and filter into a single loop using sequence? How would the time complexity change?"

Practice

1. Which Kotlin scope function returns the object it was called on after executing the given lambda?

easy

A. run

B. also

C. let

D. apply

Solution

1. Step 1: Understand scope function behavior

   The also function executes the lambda with the object as it and returns the original object.

2. Step 2: Compare with other functions

   let returns the lambda result, run returns lambda result, apply returns the object but uses this inside lambda.

3. Final Answer:

   also -> Option B

4. Quick Check:

   Returns original object after lambda = also [OK]

Hint: Remember: also returns object, let returns lambda result [OK]

Common Mistakes:

• Confusing 'also' with 'let' return values
• Mixing 'apply' and 'also' usage
• Assuming 'run' returns the object

2. Which of the following is the correct syntax to use the let scope function on a nullable variable name?

easy

A. name?.let { println(it) }

B. name.let { println(it) }

C. let(name) { println(it) }

D. name?.let println(it)

Solution

1. Step 1: Check nullable safe call usage

   To safely call let on a nullable variable, use the safe call operator ?..

2. Step 2: Validate lambda syntax

   The lambda must be enclosed in braces {} and use it as the implicit parameter.

3. Final Answer:

   name?.let { println(it) } -> Option A

4. Quick Check:

   Safe call with lambda braces = name?.let { println(it) } [OK]

Hint: Use ?.let { } for nullable variables to avoid errors [OK]

Common Mistakes:

• Omitting safe call operator on nullable
• Incorrect lambda syntax without braces
• Trying to call let as a standalone function

3. What is the output of this Kotlin code?

val result = "hello".run {
    println(this.uppercase())
    this.length
}
println(result)

medium

A. 5
HELLO

B. hello
5

C. HELLO
hello

D. HELLO
5

Solution

1. Step 1: Understand run behavior

   The run function executes the lambda with this as the receiver and returns the lambda's last expression.

2. Step 2: Trace the code execution

   Inside lambda, println(this.uppercase()) prints "HELLO". Then this.length returns 5, assigned to result. Finally, println(result) prints 5.

3. Final Answer:

   HELLO 5 -> Option D

4. Quick Check:

   run prints uppercase then returns length = HELLO and 5 [OK]

Hint: run returns last lambda value; println outputs immediately [OK]

Common Mistakes:

• Assuming run returns the printed string
• Confusing this with it inside lambda
• Mixing order of printed lines

4. Identify the error in this Kotlin code snippet:

val numbers = listOf(1, 2, 3)
numbers.also {
    it.add(4)
}
println(numbers)

medium

A. Missing lambda parameter name

B. also does not return the list

C. Cannot call add on immutable list

D. Syntax error in lambda

Solution

1. Step 1: Check list mutability

   listOf creates an immutable list; calling add is not allowed.

2. Step 2: Understand scope function effect

   also runs the lambda but does not change immutability; trying to add causes a runtime error.

3. Final Answer:

   Cannot call add on immutable list -> Option C

4. Quick Check:

   Immutable list blocks add() method = Cannot call add on immutable list [OK]

Hint: listOf creates immutable list; use mutableListOf to add [OK]

Common Mistakes:

• Assuming also changes list mutability
• Ignoring immutable list restrictions
• Thinking lambda syntax is wrong

5. Given a list of nullable integers val nums = listOf(1, null, 3, null, 5), which code snippet correctly uses scope functions and lambdas to create a list of doubled non-null values?

hard

A. nums.filterNotNull().map { it * 2 }

B. nums.map { it * 2 }.filterNotNull()

C. nums.also { it.map { it * 2 } }

D. nums.run { map { it!! * 2 } }

Solution

1. Step 1: Remove nulls before mapping

   Use filterNotNull() to exclude null values safely.

2. Step 2: Map remaining values to double

   Apply map { it * 2 } on non-null list to double each integer.

3. Final Answer:

   nums.filterNotNull().map { it * 2 } -> Option A

4. Quick Check:

   Filter nulls then map doubling = nums.filterNotNull().map { it * 2 } [OK]

Hint: Filter nulls first, then map to avoid null errors [OK]

Common Mistakes:

• Mapping before filtering nulls causes null results
• Using unsafe !! operator risking exceptions
• Misusing also or run without returning correct list