Top 60 Scala Interview Questions (2026)

Scala is a statically typed language on the JVM that blends object-oriented and functional programming in one syntax. It compiles to Java bytecode and calls Java libraries directly, so it fits into any JVM stack.

What sets it apart is the combination: everything is an object, functions are values, immutability is the default, and a strong type system catches errors at compile time. That mix is why Scala powers tools like Apache Spark.

A val is an immutable binding: once assigned, the name can't be reassigned. A var is a mutable binding you can reassign. Scala style prefers val everywhere, reaching for var only when reassignment is genuinely needed.

Immutability by default makes code easier to reason about and safer under concurrency, which is why the first thing reviewers look for in Scala is whether you overuse var.

Immutable data can't change after creation, so it's safe to share across threads without locks, easy to reason about, and free of a whole class of aliasing bugs. Scala's default collections are immutable, and val makes bindings immutable.

The trade-off is that updates create new objects rather than mutating in place, but structural sharing keeps that cheap for persistent collections. Reaching for immutable structures first is the idiomatic Scala instinct.

Scala infers types where it safely can, so you often skip annotations on local vals and let the compiler deduce the type from the right-hand side. The code stays concise while remaining fully statically typed.

You still annotate public method return types and parameters, both because inference doesn't cross those boundaries and because explicit types document intent. Over-inferring on public APIs is a common review note.

Scala has no primitives in the Java sense at the language level: Int, Boolean, and even functions are objects with methods. 1.toString and (1).+(2) are valid because Int is a real type with methods.

This uniform object model is why operators are just methods and functions are values you can pass around. The compiler still maps Int to the JVM primitive for performance, so you get the clean model without the cost.

A case class is a class the compiler enriches for holding immutable data. You get a factory apply (no new needed), structural equals and hashCode, a readable toString, a copy method for making modified duplicates, and an unapply so it works in pattern matching.

Case classes are the default for modeling data and message types. Reaching for one instead of a plain class is the idiomatic move whenever you're carrying values around.

Option[T] represents a value that's either present, Some(x), or absent, None. It encodes possible absence in the type system, so the compiler forces you to handle the empty case instead of risking a NullPointerException.

You unwrap it with pattern matching, getOrElse, map, or a for-comprehension. Using Option over null is one of Scala's clearest safety wins, and the question expects you to reach for it.

Pattern matching tests a value against a set of patterns and binds parts of it in one expression. Beyond matching constants like a switch, it destructures case classes, tuples, and lists, matches by type, and guards with conditions.

It returns a value, so a match is an expression you can assign. Combined with sealed types, the compiler checks that you've covered every case.

Scala's default List is an immutable singly linked list. Prepending with :: is O(1) and cheap; appending is O(n) because it walks to the end. Operations like map and filter return new lists, leaving the original intact.

Because it's immutable, a List is safe to share. When you need fast indexed access or appends, Vector is the better default general-purpose collection.

map applies a function to every element and returns a new collection of results. filter keeps only elements that satisfy a predicate. reduce combines all elements into one value with a binary function, like summing.

These higher-order functions replace explicit loops and read as a transformation pipeline. Chaining them is the idiomatic way to process collections in Scala.

The underscore is Scala's wildcard, and it means different things by context: a placeholder in a function literal (_ + 1), a match-all pattern in a match, an import wildcard (import scala.util._), an ignored value, and a partially applied function.

Interviewers ask this to see whether you read the underscore in context. Naming two or three uses cleanly signals real fluency.

Prefix a string with s to embed expressions with a dollar sign: s"Hi $name, total ${a + b}". The f interpolator adds printf-style formatting (f"$price%.2f"), and raw skips escape processing.

It's more readable and less error-prone than concatenation with plus signs, and it's the expected way to build strings from values.

In Scala, if returns a value, so you can assign its result directly: val label = if (n > 0) "pos" else "neg". There's no separate ternary operator because if already does the job.

This expression-oriented design runs throughout Scala: match, blocks, and try all yield values. It nudges you toward assigning results rather than mutating variables inside branches.

Unit is Scala's type for expressions evaluated only for side effects, similar to void in Java but a real type with a single value written (). Methods that return nothing meaningful, like println, return Unit.

Because Unit is a real type, functions returning Unit are still first-class. A common bug is accidentally returning Unit when you meant to return a value, which the compiler often catches with a type mismatch.

Any is the root of Scala's type hierarchy. Under it, AnyVal is the parent of value types (Int, Double, Boolean, Unit), and AnyRef is the parent of reference types, mapping to Java's Object. Nothing sits at the bottom, a subtype of everything.

Nothing has no values and types expressions that never return normally, like a thrown exception, which lets both branches of an if unify to a sensible type.

A tuple groups a fixed number of values of possibly different types: ("Asha", 31, true). You access elements with _1, _2, and so on, or destructure them in a val or a pattern.

Tuples are handy for returning a couple of values from a method or pairing keys and values, but once a group gains meaning, a case class with named fields reads far better.

A higher-order function takes another function as a parameter, returns a function, or both. map, filter, and foldLeft are all higher-order because they accept a function argument.

This is the backbone of functional style in Scala: you pass behavior as data. Writing a method that accepts a function parameter shows you understand functions are first-class values.

A trait bundles abstract and concrete methods plus fields, and classes mix it in with extends and with. Unlike a classic Java interface, a trait can carry state and full method implementations, and a class can mix in several.

Traits give Scala flexible composition of behavior. Recent Java interfaces gained default methods, but traits go further with fields and stackable modification.

A companion object is an object with the same name as a class, declared in the same file. It shares private access with the class and typically holds factory methods (apply), constants, and other members that would be static in Java.

The apply in a companion object is what lets you write MyClass(args) without new. Case classes generate their companion for you.

A for-comprehension is Scala's syntax for sequencing operations over collections and other container types. It reads like a loop but produces a value with yield, and it desugars to map, flatMap, and withFilter calls.

Because it desugars to those methods, the same syntax works over List, Option, Either, and Future, which is why it feels like a loop for collections and like sequencing for effects.

A pure function returns the same output for the same input and has no side effects: no mutation, no I/O, no reliance on external state. Given the same arguments, it always produces the same result.

Purity makes code easy to test, reason about, and run concurrently, since nothing hidden changes. Scala doesn't force purity, but idiomatic Scala pushes side effects to the edges and keeps the core pure.

map applies a function to each element and wraps each result, so a function returning a collection gives you nested results. flatMap does the same then flattens one level, so functions returning List, Option, or Future don't leave you with List[List[T]].

The rule of thumb: use flatMap when your transformation itself produces a wrapped value. Chaining flatMap is exactly what a for-comprehension does under the hood.

Chain with map, flatMap, getOrElse, or a for-comprehension. A for-comprehension over several Options yields Some only when every step is Some, and None the moment any step is None, so you never manually unwrap.

Calling .get on an Option throws on None and defeats the purpose. Composing instead keeps the possible-absence handling in the type system.

Option says a value is present or absent but carries no reason for the absence. Either[L, R] carries two possibilities, conventionally Left for an error and Right for success, so it explains why something failed.

Reach for Either (or a validation type) when the caller needs the failure reason, and Option when absence alone is enough. Both compose in for-comprehensions.

A sealed trait can only be extended within the same file, so the compiler knows the full set of subtypes. That enables exhaustiveness checking: a pattern match that misses a case gets a compile-time warning.

Sealed traits with case classes model algebraic data types, a closed set of shapes a value can take. This pairing is the backbone of type-safe domain modeling in Scala.

Immutable collections live in scala.collection.immutable and are the default: operations return new collections and never change the original. Mutable ones live in scala.collection.mutable and you update in place.

Prefer immutable for safety and easier reasoning; reach for mutable inside a tight, local hot loop where the allocation cost matters and the collection never escapes. Returning a mutable collection from a public method is a smell.

List is a singly linked list: O(1) prepend and head access, but O(n) indexing and append. Vector is a tree-backed indexed sequence with effectively constant-time random access, updates, and appends across the whole structure.

Use List when you mostly prepend and process head-to-tail; use Vector as the default when you need indexed access or balanced performance. Both are immutable.

Both collapse a collection into a single value using a start value and a binary function. foldLeft processes left to right and is tail-recursive, so it's safe for large collections. foldRight processes right to left and can overflow the stack on long lists.

Prefer foldLeft unless the operation genuinely needs right-associativity. It's the general tool behind sum, building maps, and many aggregations.

A call-by-value parameter is evaluated once before the method runs. A call-by-name parameter, written with an arrow (=> T), is evaluated each time it's used inside the method, so the argument is passed as a thunk and may run zero or many times.

Call-by-name powers custom control structures and lazy logging, where you don't want to compute an argument unless it's actually needed.

A lazy val defers its initialization until the first time it's accessed, then caches the result for every later read. A plain val runs its right-hand side immediately at definition.

Use lazy val for expensive values that might not be needed, or to break initialization-order cycles. Be aware the first access carries the cost and, in older Scala, involves a synchronization check.

A PartialFunction is a function defined only on some inputs. It adds isDefinedAt to check whether an input is handled, so callers like collect can skip inputs the function doesn't cover.

A block of case clauses without a match is a PartialFunction literal. collect is the classic use: filter and map in one pass, keeping only elements a pattern matches.

Currying writes a function as a chain of single-argument (or grouped) parameter lists, so applying some arguments returns a function waiting for the rest. In Scala you declare multiple parameter lists to get this.

It enables partial application, cleaner higher-order APIs, and better type inference across parameter lists, which is why so many library methods split their arguments into groups.

Variance says how subtyping of a type parameter relates to subtyping of the container. Covariant (+T) means List[Dog] is a subtype of List[Animal]. Contravariant (-T) flips it, used for consumers like function inputs. Invariant (plain T) allows neither.

Immutable producers are usually covariant; function argument positions are contravariant. Getting a variance annotation wrong shows up as a compile error about positions, which is the whole point of the check.

An implicit class (Scala 2) or an extension (Scala 3) adds methods to a type you don't own. The compiler wraps the value when you call the new method, so it indicates if the type always had it.

This is the enrichment pattern behind much of Scala's expressive syntax. Keep the extensions focused, because surprising implicit conversions make code hard to follow.

A type class defines behavior a type can support without the type inheriting from anything. You define a trait parameterized by a type, provide instances for concrete types, and pass those instances implicitly (given/using in Scala 3).

It's how Scala achieves ad-hoc polymorphism: adding JSON encoding or ordering to existing types, including ones you can't modify. Libraries like Cats are built on this pattern.

map transforms the value inside a Some and leaves None untouched. getOrElse returns the inner value or a default when None. fold handles both cases at once: one function for None, one for Some.

These let you work with the possibly-missing value without ever unwrapping unsafely. fold is the most complete because it forces you to handle both branches.

apply lets an object be called like a function: Circle(2.0) invokes Circle.apply(2.0), which is why factory methods and case classes construct without new. unapply is the reverse: it extracts values, enabling a type to appear in pattern matches.

Case classes generate both. Writing a custom unapply lets your own types destructure in match expressions, which is how extractors work.

You can use try/catch, but idiomatic Scala often wraps failures in a value: Try captures success or exception, Either carries a typed error, and Option signals absence. These compose in for-comprehensions instead of unwinding the stack.

Try is handy at boundaries with code that throws (parsing, I/O). Converting a thrown exception into a value keeps error handling explicit and composable.

groupBy takes a function that computes a key for each element and returns a Map from each key to the list of elements that produced it. It's the one-liner for bucketing data by some property.

It's common for turning a flat list into grouped structures: users by team, orders by status. Pairing it with mapValues or a fold aggregates each group.

A recursive call is in tail position when it's the last thing the function does, so no work waits on its return. Scala compiles tail-recursive calls into a loop, avoiding stack growth. Annotate with @tailrec and the compiler errors if the method isn't actually tail-recursive.

This matters because deep non-tail recursion overflows the stack. Restructuring with an accumulator parameter is the usual way to reach tail position.

Scala 2 overloaded one keyword, implicit, for defining instances, accepting them, and converting types, which made intent hard to read. Scala 3 splits it: given defines an instance, using accepts one as a parameter, and implicit conversions require an explicit Conversion instance and an import.

The mechanics are the same resolution, but the syntax now signals what each use does. Being able to translate an implicit val into a given and an implicit parameter into using shows you've worked across both versions.

A Future represents a value that will be available later, running on a thread from an ExecutionContext. You never block on it in production; you compose with map, flatMap, and for-comprehensions, and handle failure with recover.

Futures are eager: they start as soon as they're created. For referentially transparent, controllable async, teams often reach for an effect type like Cats Effect IO or ZIO, which is worth naming as the modern alternative.

Future is eager and memoized: constructing one starts the work, so it isn't referentially transparent, and you can't safely retry or reason about it as a value. Effect types like Cats Effect IO and ZIO are lazy descriptions of effects that only run when you execute them.

That laziness buys you retries, resource safety, cancellation, and controlled concurrency, plus typed errors in ZIO. For simple async glue, Future is fine; for effect-heavy systems, the effect types earn their weight.

A value class extends AnyVal and wraps a single field. At compile time it gives you a distinct type (so you can't pass a UserId where an OrderId is expected), but at runtime the compiler usually erases the wrapper to the underlying value, avoiding allocation.

It's the tool for type-safe wrappers over primitives without a memory penalty. There are cases where it still allocates (using it as a generic type argument, storing in an array), which is the nuance interviewers probe.

An upper bound, A <: Animal, restricts the type parameter A to Animal or its subtypes. A lower bound, B >: Dog, requires B to be Dog or a supertype. Bounds let generic code call methods available on the bound while staying type-safe.

Lower bounds show up when widening return types to keep covariant classes sound, for instance in an immutable list's prepend. Being able to read these signatures is expected at senior level.

A context bound, [A: Ordering], is shorthand for requiring an implicit (given) instance of a type class for A. It desugars to an extra using parameter of type Ordering[A], which the method can summon.

It keeps type-class-constrained signatures concise. You retrieve the instance with summon (Scala 3) or implicitly (Scala 2) when you need to name it directly.

A higher-kinded type abstracts over type constructors, not just concrete types. F[_] is a type parameter that itself takes a type argument, so you can write code generic over List, Option, or Future by treating them as some F.

This is what lets abstractions like Functor and Monad define map or flatMap once for any container. It's the foundation of type-class libraries and a marker of comfort with Scala's type system.

A monad is a type with flatMap (and a way to wrap a value) that lets you sequence computations while the type handles some context: absence for Option, error for Either, async for Future. It should satisfy the left identity, right identity, and associativity laws.

In day-to-day Scala you rarely say the word; you just use flatMap and for-comprehensions. The practical point is that any type with lawful flatMap and unit chains cleanly in a for-comprehension.

Beyond constants and case classes: guards (case n if n > 0), binding a matched value with @ (case list @ head :: _), nested destructuring, type patterns, and custom extractors via unapply. Sealed hierarchies add exhaustiveness checking on top.

These turn pattern matching into a tool for parsing and dispatch, not just branching. Overusing type patterns can hide design problems, which is the trade-off to acknowledge.

Spark is written in Scala, so its native API is Scala and new features land there first. Scala's immutability, functional transformations, and strong typing map cleanly onto Spark's distributed collections, where operations must be side-effect-free to run across a cluster.

The functional style also encourages the lazy, transformation-then-action model Spark uses. Data-engineering roles ask about this because Scala plus Spark is a common production stack.

The JVM erases generic type arguments at runtime, so List[Int] and List[String] are both just List. A match on x match { case l: List[Int] } can't actually check the element type, and the compiler warns.

The workaround is a TypeTag or ClassTag, which the compiler captures at the call site and passes along so the runtime can recover the type. ClassTag is also what lets you create generic arrays.

Futures with an ExecutionContext for async composition, the actor model (Akka or Pekko) for stateful message-passing systems, and effect systems (Cats Effect, ZIO) with fibers for structured concurrency and resource safety. Under all of them the JVM thread pool does the real work.

Pick Futures for simple async glue, actors when you have many independent stateful entities and want supervision, and effect fibers for large concurrent systems that need cancellation and typed errors.

A self-type declares that a trait requires another type to be mixed in alongside it, written this: Dependency =>. It expresses a dependency without inheritance, so a trait can call members it knows will be present.

The cake pattern wires dependencies by composing such traits. It works but grows awkward at scale, so many teams now prefer constructor injection or given-based wiring. Knowing the pattern and its decline is the balanced answer.

Combine by-name parameters with a curried second parameter list so the call site can use braces. The by-name parameter delays the block's evaluation until your logic decides to run it, which is how retry, using, and unless helpers are built.

This is why Scala doesn't need a keyword for many constructs: they're ordinary methods taking by-name blocks. Keep them predictable, because surprising control flow is hard to debug.

Objects that are equal must return the same hashCode, and an object's hashCode must stay stable while it's a key in a hash-based collection. Break this and lookups in maps and sets silently fail.

Case classes generate consistent structural equals and hashCode from their fields, which is one reason they're the default for value types. For a hand-written class, override both together over the same fields, or don't override either.

Calling .view makes subsequent map, filter, and other transformations lazy: they don't build intermediate collections and only compute elements when you force the result with something like toList. On a long chain over a large collection, that avoids allocating each intermediate.

It's the fix when profiling shows intermediate collections dominating a pipeline. For short chains the overhead isn't worth it, so reach for views deliberately, not by default.

An opaque type gives an existing type a new name that's distinct at compile time but erased to the underlying type at runtime, with zero wrapping cost. Inside its defining scope it's the same as the underlying type; outside, it's a separate type you can't mix up.

It's the modern successor to value classes for type-safe aliases (a Meters that isn't an Int elsewhere), without the value-class allocation edge cases.

Encoding invariants in types means the compiler rejects invalid states before the program runs. Option removes null dereferences, sealed hierarchies force exhaustive matches, distinct wrapper types stop argument mix-ups, and Either or ZIO's error channel makes failure part of the signature.

The trade-off is more upfront design and sometimes fighting the compiler. The payoff is fewer classes of runtime bug, which is the core argument for choosing Scala on a critical system.

Observe first: logs and traces around the slow path, JVM metrics (heap, GC pauses, thread states), and a profiler or async-profiler on the live process to see whether it's CPU, GC, lock contention, or blocked threads. Correlate with recent deploys and dependency bumps.

Common Scala-specific suspects: blocking calls inside Futures starving the ExecutionContext, unbounded lazy structures or views held in memory, and excessive intermediate collection allocation. Fix at the right layer, then confirm with a measurement.

Scala 3 keeps the core but adds significant-indentation syntax, replaces implicit with given/using and extension, introduces enums, opaque types, and union types, and cleans up the type system. Most Scala 2 code compiles under Scala 3 with the migration mode and a few rewrites.

Migrate incrementally: build with the Scala 3 compiler in migration mode, apply the automated rewrites, then adopt new features module by module. The two versions share bytecode compatibility for a mixed build during the transition.