Kotlin engineer technical fundamentals interview questions

As asked

Explain structured concurrency in Kotlin coroutines. How does it change the way you launch background work in an Android or JVM service?

Sample answer outline

Structured concurrency means child coroutines are tied to an explicit parent scope, so cancellation, failure and lifetime are visible in the call structure. In Android this usually means using lifecycle-aware scopes such as viewModelScope rather than GlobalScope. In backend services it means request-scoped or application-scoped CoroutineScope objects with clear shutdown behaviour. A failed child should either cancel siblings or be isolated with SupervisorJob when that is intentional. Candidates trip up by launching fire-and-forget work that outlives the user action, leaks resources, or silently drops exceptions.

Expect these follow-ups

• When would you use supervisorScope instead of coroutineScope?
• How do Dispatchers.IO and Dispatchers.Default differ?
• What happens to child coroutines when a ViewModel is cleared?

As asked

A Kotlin service calls a legacy Java library with weak nullability annotations. How do you keep nulls from leaking into the rest of the codebase?

Sample answer outline

The safest pattern is to isolate the Java dependency behind a Kotlin adapter that translates platform types into explicit nullable or non-null types. Validate inputs and outputs at the boundary, and fail early if the Java contract is violated. Avoid spreading !! through business logic because it turns type safety into runtime surprise. Strong candidates mention JSpecify, Checker Framework or JetBrains annotations where the Java side can be improved. The interviewer wants a boundary design, not just a list of Kotlin null operators.

Reference implementation (kotlin)

class LegacyUserAdapter(private val client: LegacyUserClient) {
    fun findUser(id: String): User? {
        val raw = client.lookup(id) ?: return null
        val email = requireNotNull(raw.email) { "legacy user email missing for id=$id" }
        return User(id = raw.id, email = email.lowercase())
    }
}

Expect these follow-ups

• When is requireNotNull better than returning null?
• How do platform types differ from String? and String?
• What would you enforce in code review around !!?

As asked

An iOS screen is dismissed but its view model and network task never deallocate. How would you find and fix the retain cycle?

Sample answer outline

Start with the memory graph debugger or Instruments to identify the ownership chain keeping the object alive. Common causes are closures capturing self strongly, delegates not marked weak, Combine subscriptions retained by the same object they capture, and tasks that outlive the view lifecycle. The fix is not blindly adding weak self everywhere, but deciding which object owns the work and when cancellation should happen. A view model should usually cancel outstanding tasks in deinit or when the lifecycle ends. Strong candidates explain ARC as deterministic reference counting with cycles that need explicit weak or unowned links.

Expect these follow-ups

• When is unowned safe and when is it dangerous?
• How do async Task closures capture self?
• How would you test that a screen deallocates?

As asked

Explain how Swift structured concurrency handles cancellation, actor isolation and UI updates in an iOS app.

Sample answer outline

Structured concurrency ties async child tasks to a parent task so cancellation and errors can propagate through the task tree. Cancellation is cooperative, so long-running work must check Task.isCancelled or call throwing APIs that observe cancellation. UI state should be updated on the MainActor, either by marking the view model or specific methods. Actors protect mutable state through isolation, but they do not make blocking or slow code free. Candidates often overstate cancellation as preemptive or forget that detached tasks leave the structured tree.

Reference implementation (swift)

@MainActor
final class ProfileViewModel: ObservableObject {
    @Published private(set) var state: State = .idle

    func load(id: String) async {
        state = .loading
        do {
            let profile = try await api.fetchProfile(id: id)
            try Task.checkCancellation()
            state = .loaded(profile)
        } catch is CancellationError {
            state = .idle
        } catch {
            state = .failed(error)
        }
    }
}

Expect these follow-ups

• When would you use Task.detached?
• What does @MainActor guarantee and what does it not guarantee?
• How do actors avoid data races without locks?

As asked

In Scala, when would you use Future directly, and when would you reach for an effect system such as cats-effect or ZIO?

Sample answer outline

Future starts running eagerly and is tied to an ExecutionContext, which is fine for simple service calls but makes cancellation, resource safety and deterministic tests harder. Effect systems represent work as values, so execution, retries, cancellation, timeouts and resource scopes can be composed before the program is run. The tradeoff is complexity and team learning cost. A strong answer names the operational benefits: bounded concurrency, structured resource handling and better testing with controlled runtimes. Candidates often describe effect systems as only functional style rather than as production control over side effects.

Expect these follow-ups

• Why does eager execution make Future awkward in tests?
• How does Resource prevent leaks?
• When would an effect system be overkill?