Haskell Interview Questions

Analogy categoryAnalogies

What Interviewers Look For

Haskell interviews typically probe three layers: whether you understand core language mechanics, type classes, monads, laziness, whether you can write idiomatic code under pressure, pattern matching, recursion, list processing, and whether you can reason about tradeoffs, when laziness helps vs. hurts, when to use a specific monad transformer. Strong answers explain the 'why' behind a choice, not just that Maybe exists, but why you'd choose it over throwing an exception in a specific scenario, since interviewers are usually evaluating judgment as much as syntax recall.

🏏

Cricket analogy: A Haskell interview probing both mechanics and judgment is like a BCCI selector trial that tests not just whether a bowler can bowl a yorker technically, but whether they know when to use it, at the death against a set batsman like Hardik Pandya, since technique without game sense doesn't win selection.

Core Concepts: Type Classes and Monads

Expect questions like 'what is a type class', answer: an interface defining a set of functions a type must implement, like Eq, Ord, or a custom class, resolved at compile time via dictionary passing, and 'what is a monad', answer: a type with bind and return/pure satisfying the monad laws, used to sequence computations with an added context, Maybe for optional failure, lists for nondeterminism, IO for effects. A common follow-up is 'why do we need do notation', it's syntactic sugar for chained bind calls, letting a do-block desugar directly into a chain of bind calls with a lambda, which interviewers use to check you understand the desugaring, not just the surface syntax.

🏏

Cricket analogy: A type class like Eq is like the BCCI's fitness-test standard, the Yo-Yo test, that any player must pass, implement, to be eligible for selection, regardless of whether they're a batter or bowler; different players satisfy the same interface in their own way, just as different types implement equality differently.

Lazy Evaluation and Performance Questions

Interviewers often ask 'what's the difference between foldl and foldl-prime', foldl builds up a chain of unevaluated thunks that can cause a stack overflow or space leak on large lists, while foldl-prime, from Data.List, strict, forces each intermediate accumulator as it goes, so it's almost always the right choice for large numeric folds. A related question is 'explain WHNF, weak head normal form', an expression is in WHNF once its outermost constructor is known, even if its arguments aren't yet evaluated, which is the depth to which functions like seq force evaluation, versus full normal form where every subexpression is fully evaluated.

🏏

Cricket analogy: The difference between foldl and foldl-prime is like the difference between a scorer who defers every arithmetic update, I'll add up all these partnership totals at the end of the innings, versus one who updates the running total after every over, deferring too long, like lazy foldl, risks a mental overload, space leak, when the whole innings' arithmetic hits at once.

haskell

data OrderState = Placed | Paid | Shipped | Cancelled | Delivered
  deriving (Eq, Show)

data OrderEvent = ConfirmPayment | Ship | Cancel | ConfirmDelivery

data TransitionError = InvalidTransition OrderState OrderEvent
  deriving Show

-- Illegal transitions are caught by pattern match, not scattered runtime checks.
transition :: OrderEvent -> OrderState -> Either TransitionError OrderState
transition ConfirmPayment Placed = Right Paid
transition Ship           Paid   = Right Shipped
transition ConfirmDelivery Shipped = Right Delivered
transition Cancel state
  | state `elem` [Placed, Paid] = Right Cancelled
transition event state = Left (InvalidTransition state event)

System-Design Style Questions

At a senior level, expect open-ended questions like 'how would you model a state machine for an order-processing system in Haskell', a strong answer reaches for a sum type like data OrderState = Placed | Paid | Shipped | Cancelled with a pure transition function that returns an Either, making illegal transitions, shipping a cancelled order, a compile-time-checked pattern match rather than a runtime check scattered across the codebase. Interviewers are listening for whether you reach for the type system to make invalid states unrepresentable, rather than defending them with runtime if checks the way you might in a dynamically typed language.

🏏

Cricket analogy: Modeling OrderState as a sum type is like the ICC defining a fixed, exhaustive set of valid match states, In Progress, Rain Delayed, Abandoned, Completed, so that a broadcast graphics system can never display an impossible combination like Abandoned but still bowling, the way Haskell's type system rules out an illegal OrderState transition at compile time.

Watch out for the classic interview trap question: 'is Haskell always lazy?' The correct nuanced answer is no, data constructors can be made strict with a bang pattern or the StrictData language extension, seq and dollar-bang force evaluation to WHNF explicitly, and GHC's strictness analysis can optimize away laziness where it proves no observable difference. Answering 'yes, always' is a common way candidates lose points on an otherwise strong interview.

Haskell interviews test mechanics (type classes, monads, laziness), idiomatic coding under pressure, and judgment about tradeoffs.
A type class is an interface a type implements (Eq, Ord, Show, or custom classes) resolved via compile-time dictionary passing.
A monad provides bind and pure/return satisfying the monad laws, used to sequence computations with context (Maybe, lists, IO, State).
do notation is syntactic sugar for chained bind calls; be ready to manually desugar a do-block in an interview.
foldl' (strict) is almost always preferred over foldl (lazy) for large folds to avoid space leaks from thunk buildup.
WHNF means the outermost constructor is evaluated even if arguments aren't yet forced; seq forces evaluation to WHNF, not full normal form.
Strong system-design answers reach for sum types and pure transition functions to make illegal states unrepresentable at compile time.