Scala Interview Questions

Case classes automatically generate a value-based equals method. Since p1 and p2 have the same x and y values, p1 == p2 evaluates to true. Reference identity is not used; the comparison is structural.

The auto-generated equals for a case class first checks that.isInstanceOf[Person]. Since Employee("Alice") is not an instance of Person, the equality check short-circuits to false. Field names and values matching is irrelevant when the runtime types differ.

Case class equality compares ALL fields in declaration order. u1 and u2 have the same name ("Bob") but different age values (30 vs 31), so equals returns false and the output is false.

The Scala Language Specification requires a companion object to have the same name as the class and to be defined in the same compilation unit (typically a single source file). When both conditions are met, the class and the companion object can access each other's private members.

Scala allows a class to mix in multiple traits. The first trait (or class) is referenced with extends, and every subsequent trait is added with with. This is the standard syntax for trait composition in Scala.

Scala's linearization formula for C extends B1 with B2 with ... with Bn is L(C) = C, L(Bn) ⊕ ... ⊕ L(B1), where ⊕ merges sequences giving priority to the right operand (elements that appear in both are kept from the right operand). For Cat extends Animal with Furry with FourLegged, the parents are B1=Animal, B2=Furry, B3=FourLegged, so we compute L(FourLegged) ⊕ L(Furry) ⊕ L(Animal). Each trait's linearization is: L(Animal)=[Animal], L(Furry)=[Furry, Animal], L(FourLegged)=[FourLegged, Animal]. Merging L(FourLegged) ⊕ L(Furry): FourLegged is unique to the left, Animal is shared so it comes from the right operand, yielding [FourLegged, Furry, Animal]. Merging that with L(Animal) changes nothing since Animal is already present. The full linearization is therefore: Cat → FourLegged → Furry → Animal. FourLegged appears before Furry because it is the rightmost mixin in the with clause, so its linearization is processed first in the merge chain.

LazyList is the standard lazy (non-strict) immutable sequence introduced in Scala 2.13 to replace the deprecated Stream. Its elements are computed only when accessed, which is why LazyList.from(1) can represent an infinite sequence without evaluating every element.

Calling .view on a strict collection produces a SeqView (a lazy view). Transformations applied to the view — such as map and filter — are not executed immediately; they are composed and deferred until a forcing operation like .toList is called, which traverses the view and produces a new strict collection.

In Akka Typed the primary communication primitive is the tell operator (!), which places a message in the recipient's mailbox without waiting for a reply. The ask pattern (ask via AskPattern) is a separate, higher-level abstraction that returns a Future and is built on top of tell, not a built-in operator on ActorRef. The key concurrency-safety guarantee is actor isolation: the framework ensures each actor handles exactly one message at a time, eliminating the need for explicit synchronization. While immutability of messages is a strongly recommended best practice, it is not enforced by the framework — the real safety property is the serialized message processing within each actor.

A companion object and its companion class can see each other's private members. This is the defining benefit of the companion relationship in Scala and is why companion objects are commonly used to hold factory methods that invoke private constructors, or to hold shared private state that the class instances can read.

Scala resolves trait super calls through linearization — a deterministic right-to-left ordering of all mixed-in traits. When a trait calls super.someMethod(), the call is dispatched to the next trait in the linearization chain, not to the JVM parent class directly. This is what enables stackable modifications and traits to work as composable layers.

The case class companion object receives a synthesized apply method that acts as a factory (allowing MyCase(1, 2) instead of new MyCase(1, 2)) and a synthesized unapply method that deconstructs an instance back into its fields for pattern matching. These two methods are the core of why case classes work seamlessly with match expressions and constructor-call syntax.

Scala computes the linearization of D extends B with C as: start with D, then prepend the linearization of the rightmost mixin C (giving C, A), then prepend B's linearization (giving B, with A already present so it is removed). The result is D, C, B, A (followed by AnyRef, Any). When greet() is called, D.greet invokes super which resolves to C, which resolves to B, which resolves to A. So the invocation order from most-derived to least-derived is D → C → B → A.

In Scala, the superclass constructor (Base) runs first, then the trait initializers execute in the order they are declared left-to-right (T1, T2, T3), and finally the body of the class itself (Derived) runs last. This mirrors the linearization order with the most-derived element (Derived) initialized last. The output is: Base, T1, T2, T3, Derived.

LazyList.from(1) produces an infinite lazy sequence starting at 1. The .map call is lazy — it returns a new LazyList without evaluating anything yet. The first lzy.head forces evaluation of the first element: the map function runs once (count becomes 1) and the result (2) is memoized in the LazyList cell. The second lzy.head returns the already-computed, cached head without re-invoking the map function, so count stays at 1. This memoization behavior is the key distinction between LazyList and a non-caching lazy view that recomputes on each traversal.

For every case class the Scala compiler generates: equals (structural, based on constructor parameters), hashCode (consistent with equals), canEqual (invoked by the generated equals so subclasses can opt out of cross-type equality), and copy (creates a new instance with named-parameter overrides for any subset of fields). A compareTo method is NOT generated — natural ordering requires mixing in Ordered or supplying an Ordering instance.

The compiler-generated equals and hashCode for case classes are based on constructor parameter values, not references. After m1.value = 2, m1 has value 2 while m2 still has value 1, so m1 == m2 is false. The generated hashCode is derived from value, so it also changed. Because the hashCode changed, m1 is now stored in the wrong bucket in the HashSet, meaning set.contains(m1) is not guaranteed to find it — this breaks the hashCode/equals contract required by hash-based collections. The generated equals compares field values, not references, so the claim that the generated equals compares object references rather than field values is false.

The class class Concrete extends Base with A with B with C produces the linearization: Concrete → C → B → A → Base (traits listed right-to-left in the declaration end up left-to-right just below the class). When greet is called, dynamic dispatch resolves to the leftmost override in the linearization—C.greet. Each trait calls super.greet, which resolves to the next trait to the right. So C calls B, B calls A, and A calls Base, yielding C(B(A(Hello))).

takeWhile stops scanning as soon as it hits the first element that fails the predicate, so List(1, 2, -1, 3, 4).takeWhile(_ > 0) returns only List(1, 2) — the elements after the -1 are never examined. To keep every positive element regardless of position, the function should use filter(_ > 0) on line 2. The other lines (the function signature, the val binding, and returning positives) are all correct.

Tracing the fold for List("a", "b", "a"): the first time a word is seen it is absent from the map, so getOrElse(w, 1) returns the default 1, and + 1 makes the count 2 instead of 1. Every subsequent occurrence also adds 1 on top of the already-inflated value. The fix is getOrElse(w, 0) so the first occurrence produces a count of 1. Using foldRight instead of foldLeft is wrong because counting is order-independent. Using ++ instead of + is wrong because + is the correct Map method for adding/updating a single key-value pair; ++ merges an entire Map. Using Map(words.head -> 0) as the seed is wrong because an empty seed map is correct and words.head would fail on an empty list.

Case classes generate an equals that compares each constructor parameter via ==. For the members field this delegates to the array's equals, which is Java's reference-based Object.equals (arrays do not override equals). So t1 == t2 is false: the two Array("x","y") literals are distinct objects, and array equals is reference identity — the names match but the array references differ. t1.copy() allocates a new Team but reuses the same Array reference for members, so t1 == t3 is true: t1.name == t3.name is true and t1.members == t3.members is true because it is the same array object compared to itself. t4 = Team("A", t1.members) also passes the exact same array reference, so t1 == t4 is true for the identical reason — same name, same array object. t1 eq t3 is false because eq is reference equality on the Team instances themselves and copy creates a new Team. t1.members eq t2.members is false because each Array("x","y") call allocates a separate array object.

On a SeqView, map, filter, and take compose into a single lazy pipeline; elements are pulled through the entire chain one at a time when .toVector forces evaluation. take(2) needs two even numbers, so traversal stops as soon as the second one is produced. Element 1: track("M") fires (log=[M]), 1 is odd so it is discarded. Element 2: track("M") fires (log=[M,M]), 2 passes the filter, then track("M2") fires (log=[M,M,M2]) — that is the first element collected. Element 3: track("M") fires (log=[M,M,M2,M]), 3 is odd, discarded. Element 4: track("M") fires (log=[M,M,M2,M,M]), 4 passes the filter, then track("M2") fires (log=[M,M,M2,M,M,M2]) — second element collected, so take(2) is satisfied and traversal halts. The resulting vector is Vector(2, 4) and the log is M,M,M2,M,M,M2. The interleaving of M and M2 entries is the hallmark of lazy fusion: unlike a strict pipeline (which would run all map("M") calls first), the view pulls each element through every stage before advancing to the next source element.

Scala's private is a source-level concept: the compiler validates it during type checking but, for companions, generates synthetic accessors so the JVM allows the call. private[this] is stricter — it forbids access from any other instance, including the companion, and no accessor is emitted.

Trait super is late-bound to the linearization, not the static supertype. This lets each mixed-in trait act as a decorator around the rest of the stack, which is the foundation of the stackable modifications pattern in Scala.

The generated equals for a case class compares each field using ==. For Array[Int], Scala == delegates to the JVM array's equals, which is Object.equals (reference equality), so two distinct array instances with identical contents are not equal — Wrapper(Array(1, 2)) == Wrapper(Array(1, 2)) is false. The generated hashCode in Scala 2.13 and Scala 3 uses content-based hashing for array fields: in Scala 2.13, ScalaRunTime._hashCode special-cases arrays via productElementHashCode, which calls java.util.Arrays.hashCode; in Scala 3, Statics.anyHash likewise dispatches to java.util.Arrays.hashCode for arrays. Two arrays with the same elements therefore yield the same hash contribution, so both Wrapper instances produce the same overall hashCode. (Note: in Scala 2.12 and earlier, ScalaRunTime._hashCode did not special-case arrays, so hashCode would be identity-based and the two instances would differ — which is why the version is pinned to 2.13+.) This does not violate the equals/hashCode contract, which requires equal objects to share a hash code, not the reverse.