Scala interview questions

What a strong answer covers

• Define `val` as an immutable reference/value, meaning it cannot be reassigned after initialization.
• Define `var` as a mutable variable, meaning its value can be reassigned.
• Discuss the preference for `val` in idiomatic Scala due to benefits like thread safety, predictability, and easier reasoning.
• Provide scenarios where `var` might be acceptable or necessary (e.g., performance-critical loops, integration with mutable Java APIs, specific state management patterns).

Where people lose the point

• ×Confusing `val` with a constant; `val` refers to the reference being immutable, not necessarily the object it points to (if the object itself is mutable).
• ×Overusing `var` when `val` would suffice, indicating a lack of understanding of Scala's immutability principles.
• ×Failing to mention the benefits of immutability (e.g., concurrency, easier debugging).

What a strong answer covers

• Explain that `case class` is a special kind of class primarily used for modeling immutable data.
• List the automatic features provided by `case class` (e.g., `equals`, `hashCode`, `toString`, `copy` method, companion object with `apply` and `unapply`).
• Contrast with a regular `class`, which requires manual implementation of these methods and is typically used for more complex objects with behavior or mutable state.
• Provide use cases: `case class` for DTOs, messages, algebraic data types; `class` for services, actors, objects with side effects.

Where people lose the point

• ×Not mentioning the `unapply` method, which is crucial for pattern matching.
• ×Failing to emphasize the immutability aspect of `case class` instances.
• ×Suggesting `case class` for objects with complex mutable state or side effects.

What a strong answer covers

• Explain that `Option` is a container that can hold either a value (`Some(value)`) or no value (`None`), providing a type-safe way to handle optionality.
• Contrast with `null`, which is a runtime concept that can lead to `NullPointerException`s if not explicitly checked.
• Describe how `Option` forces the developer to explicitly handle both the `Some` and `None` cases, typically through pattern matching or methods like `map`, `flatMap`, `getOrElse`.
• Provide a simple code example demonstrating `Option` usage and how it avoids `NullPointerException`.

Where people lose the point

• ×Suggesting `Option.get` as a primary way to access the value, which defeats the purpose of `Option`'s safety.
• ×Not explaining how `Option` shifts error detection from runtime to compile time.
• ×Failing to mention `map` and `flatMap` as idiomatic ways to work with `Option`.

What a strong answer covers

• **Destructuring Case Classes:** Explain how pattern matching can extract components from case class instances, making code cleaner than direct field access.
• **Handling `Option`/`Either`:** Demonstrate how to use pattern matching to safely extract values from `Option` or `Either` types, handling both success and failure/absence cases.
• **Type Matching/Exhaustive Checks:** Illustrate how to match against different types (e.g., in a `List[Any]`) or ensure all cases of a `sealed trait` hierarchy are covered, leading to compile-time safety.
• Optional: **List Decomposition:** Show how to match against the head and tail of a list.

Where people lose the point

• ×Providing examples that are overly complex or not clearly illustrating the specific use case.
• ×Not emphasizing the compile-time safety benefits, especially with `sealed trait` hierarchies.
• ×Confusing pattern matching with simple `if-else` statements without highlighting its destructuring or type-safety advantages.

What a strong answer covers

• Define higher-order functions as functions that either take other functions as arguments or return functions as results.
• Explain `map`: It transforms each element of a collection into a new element, returning a new collection of the same size.
• Explain `filter`: It selects elements from a collection that satisfy a given predicate, returning a new collection containing only the matching elements.
• Provide clear code examples for both `map` and `filter` on a `List` or `Vector`, demonstrating their usage with anonymous functions.

Where people lose the point

• ×Confusing `map` with `foreach` (which performs side effects and returns `Unit`).
• ×Not emphasizing that `map` and `filter` return *new* collections, adhering to immutability.
• ×Failing to explain the general concept of higher-order functions beyond just `map` and `filter`.

What a strong answer covers

• Describe `for-comprehension` as syntactic sugar for chaining operations on monadic types (like `Option`, `List`, `Future`).
• Explain that it desugars into a series of `map`, `flatMap`, and `filter` calls, making sequential operations more readable.
• Illustrate how `for-comprehension` with `<-` generators corresponds to `flatMap` (for the first generator) and `map` (for the last `yield`).
• Show how `if` guards within a `for-comprehension` desugar to `filter` calls.
• Provide a simple example using `Option` or `List` to demonstrate its usage and desugaring concept.

Where people lose the point

• ×Treating `for-comprehension` as a loop construct rather than a transformation mechanism.
• ×Not correctly explaining the desugaring process, especially the role of `flatMap` and `map`.
• ×Failing to mention that it works with any type that implements `map`, `flatMap`, and `filter` (or `withFilter`).

What a strong answer covers

• Define `sealed trait` as a trait that can only be extended within the same source file (or compilation unit) where it is defined.
• Explain its primary benefit: enabling exhaustive pattern matching. The compiler can warn you if you haven't covered all possible subtypes in a `match` expression.
• Discuss its use in defining Algebraic Data Types (ADTs), where a type can be one of a fixed set of known alternatives (e.g., `sealed trait Shape`, with `case class Circle` and `case class Rectangle`).
• Provide a clear example demonstrating a `sealed trait` and how pattern matching against it provides compile-time safety.

Where people lose the point

• ×Incorrectly stating that `sealed trait` can be extended anywhere, not just the same file.
• ×Not emphasizing the compile-time safety aspect of exhaustive pattern matching.
• ×Failing to connect `sealed trait` to the concept of Algebraic Data Types.

What a strong answer covers

• Define `lazy val` as a value that is initialized only upon its first access, rather than at the point of declaration.
• Discuss use cases: deferring expensive computations until they are actually needed, breaking circular dependencies, or initializing resources that might not always be used.
• Explain its implications: it's thread-safe (initialized once, even with concurrent access), but introduces a slight overhead for the first access.
• Contrast with `val` (eager evaluation) and `def` (re-evaluated on each access).

Where people lose the point

• ×Confusing `lazy val` with `def` (which re-evaluates every time).
• ×Not mentioning the thread-safety aspect of `lazy val` initialization.
• ×Failing to identify scenarios where `lazy val` provides a clear benefit.

What a strong answer covers

• **`recover` / `recoverWith`:** Explain `recover` for transforming a failed `Future` into a successful one with a default value, and `recoverWith` for transforming a failed `Future` into another `Future` (allowing for asynchronous recovery).
• **`onComplete`:** Describe `onComplete` as a callback that executes when the `Future` completes, regardless of success or failure, receiving a `Try[T]` (either `Success(value)` or `Failure(exception)`).
• **`fallbackTo`:** Mention `fallbackTo` for providing an alternative `Future` to execute if the original one fails.
• Discuss the importance of handling exceptions in asynchronous contexts to prevent unhandled `Future` exceptions.

Where people lose the point

• ×Suggesting `try-catch` blocks directly around `Future` creation without understanding that the computation runs on a different thread.
• ×Not distinguishing between `recover` (returns a value) and `recoverWith` (returns a `Future`).
• ×Failing to mention `Try` when discussing `onComplete`.

What a strong answer covers

• **Currying:** Define currying as the transformation of a function that takes multiple arguments into a sequence of functions, each taking a single argument.
• **Partial Application:** Define partial application as the process of fixing a number of arguments to a function, producing another function of smaller arity.
• Highlight the difference: Currying is a function transformation (design choice), while partial application is an application of a function (runtime action). A curried function is inherently designed for partial application.
• Discuss usefulness: creating specialized functions, improving readability, enabling function composition, and working with higher-order functions.
• Provide code examples for both currying (e.g., `def add(x: Int)(y: Int)`) and partial application (e.g., `add(5)_`).

Where people lose the point

• ×Confusing currying with partial application, or using the terms interchangeably.
• ×Not providing clear examples that differentiate the two concepts.
• ×Failing to explain the practical benefits beyond just syntax.

What a strong answer covers

• **Similarities:** Both can define abstract and concrete methods/fields, cannot be instantiated directly, and are used for polymorphism.
• **Differences:** `trait`s can be mixed into classes using `with` (multiple inheritance of behavior), while a class can only extend one `abstract class`. `trait`s cannot have constructor parameters, `abstract class`es can. `trait`s can be used for stackable modifications.
• **Use Cases:** `trait`s for defining interfaces, mixins, and reusable behaviors; `abstract class`es for defining base classes with common state and behavior, especially when constructor parameters are needed or when modeling a 'is-a' relationship.
• Mention the 'linearization' process for `trait`s when multiple are mixed in.

Where people lose the point

• ×Incorrectly stating that `trait`s can have constructor parameters.
• ×Not emphasizing the ability to mix in multiple `trait`s as a key differentiator.
• ×Failing to discuss the 'diamond problem' and how `trait` linearization addresses it.

What a strong answer covers

• Define a companion object as a singleton object that has the same name as a class and is defined in the same source file.
• Explain their relationship: they can access each other's private members, providing a way to bridge static-like methods (in the object) with instance methods (in the class).
• List typical uses: factory methods (`apply`), implicit definitions, utility methods related to the class, and implementing the `unapply` method for pattern matching.
• Provide a simple example demonstrating an `apply` method in a companion object.

Where people lose the point

• ×Confusing a companion object with a regular singleton object.
• ×Not mentioning the ability to access private members as a key feature.
• ×Failing to explain the `apply` method's role in simplifying object creation.

What a strong answer covers

• Define tail recursion as a recursive function where the recursive call is the very last operation performed in the function's body.
• Explain its importance: it prevents `StackOverflowError`s that can occur with deep recursion in non-tail-recursive functions.
• Describe how the Scala compiler (and JVM) optimizes tail-recursive calls through Tail Call Optimization (TCO), effectively transforming the recursion into an iterative loop.
• Mention the `@tailrec` annotation for compile-time verification.
• Provide a simple example of a tail-recursive function (e.g., factorial or sum) and contrast it with a non-tail-recursive version.

Where people lose the point

• ×Providing a non-tail-recursive example and claiming it's tail-recursive.
• ×Not mentioning `StackOverflowError` as the problem TCO solves.
• ×Failing to explain that TCO is a compiler optimization, not a runtime feature of the JVM for all recursion.

What a strong answer covers

• Define type inference as the Scala compiler's ability to deduce the types of expressions and variables without explicit type annotations from the programmer.
• Explain how it contributes to conciseness by reducing boilerplate code and making the code cleaner and easier to read.
• Discuss how it maintains type safety: despite fewer explicit types, the compiler still performs rigorous type checking, catching type mismatches at compile time.
• Provide examples where type inference is used (e.g., `val x = 10`, `List(1, 2, 3).map(_ * 2)`).

Where people lose the point

• ×Confusing type inference with dynamic typing; Scala is still statically typed.
• ×Suggesting that type inference means you never need to specify types.
• ×Failing to mention the compile-time safety aspect.

What a strong answer covers

• Define an implicit parameter as a parameter to a function or method that the Scala compiler can automatically supply if a suitable implicit value is available in the current scope.
• Describe the compiler's resolution rules: it searches for an implicit value in the current scope, in the companion object of the parameter's type, and in the companion object of the argument's type.
• Discuss common applications: providing context (e.g., `ExecutionContext` for `Future`s), implementing type classes, and enabling extension methods (via implicit conversions, though less common now with extension methods).
• Provide a simple example of a function taking an implicit parameter.

Where people lose the point

• ×Confusing implicit parameters with implicit conversions (though related, they are distinct concepts).
• ×Incorrectly describing the implicit resolution rules.
• ×Failing to explain the 'contextual' nature of implicit parameters.