Scala engineer interview questions

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?

As asked

How do you decide where to define interfaces in Go, and why do experienced Go teams prefer small consumer-owned interfaces?

Sample answer outline

In Go, interfaces are satisfied implicitly, so the consumer can define the behaviour it needs without forcing producers into a shared abstraction. Small interfaces such as io.Reader or a one-method Store make tests and substitutions easy while keeping production types concrete. Defining large provider-owned interfaces too early creates brittle mocks and hides useful methods behind an artificial surface. The candidate should connect this to package boundaries and dependency direction. A strong answer also says when no interface is needed because a concrete type is clearer.

Expect these follow-ups

• When is a provider-owned interface justified?
• How do generics change this decision, if at all?
• What is the smell in an interface with ten methods?

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

A consumer reads from Kafka, writes to a database and then commits offsets. Explain at-least-once, at-most-once and exactly-once behaviour in this flow.

Sample answer outline

If the consumer commits before the database write, a crash can lose the message, which is at-most-once. If it writes first and commits after, a crash between those operations can replay the message, which is at-least-once. Exactly-once for external side effects requires idempotent writes, transactions that include both offset and output, or a design where replay is harmless. Kafka transactions help when consuming and producing back to Kafka, but they do not magically make an arbitrary database update exactly once. Strong candidates discuss idempotency keys and deduplication tables.

Expect these follow-ups

• Where would you store an idempotency key?
• How do Kafka transactions work when the sink is another Kafka topic?
• What is the operational cost of exactly-once processing?

As asked

You are reviewing Scala code that processes millions of records with chained collection operations. What performance issues do you look for?

Sample answer outline

The candidate should look for accidental intermediate collections, strict versus lazy evaluation, poor choice of List for indexed access, and repeated groupBy or sortBy on large datasets. Iterator or View can avoid intermediate allocation, but they also move work later and can surprise readers if reused incorrectly. Vector is often a better general-purpose immutable sequence than List when indexed access or appends matter. For distributed data, the answer should separate local collection costs from Spark or Akka stream costs. Strong answers avoid premature optimisation but know where idiomatic code becomes expensive.

Reference implementation (scala)

val totalsByUser: Map[String, BigDecimal] =
  events.iterator
    .filter(_.status == "paid")
    .map(event => event.userId -> event.amount)
    .foldLeft(Map.empty[String, BigDecimal]) { case (acc, (userId, amount)) =>
      acc.updated(userId, acc.getOrElse(userId, BigDecimal(0)) + amount)
    }

Expect these follow-ups

• When is List the wrong default?
• How do View and Iterator differ?
• How would you prove a collection change actually helped?

As asked

A Scala service ingests events, enriches them over HTTP and writes to Kafka. How would you use Akka Streams or a similar streaming library to control backpressure?

Sample answer outline

The stream should model bounded stages explicitly rather than spawning untracked futures. mapAsync with a fixed parallelism caps HTTP concurrency, buffers should be sized intentionally, and supervision should define whether a bad record is skipped, retried or sent to a dead-letter path. Kafka commits should be tied to successful processing so replay semantics are clear. The answer should mention materialised values, kill switches and graceful shutdown. Candidates often add buffers everywhere, which hides overload until latency and memory fail together.

Expect these follow-ups

• Where would you put retries and how would you avoid retry storms?
• How do you choose mapAsync parallelism?
• What happens during shutdown with in-flight messages?