Elixir Interview Questions

Analogy categoryAnalogies

What Interviewers Actually Probe For

Elixir interviews generally probe four areas in roughly this order of frequency: core language fundamentals (pattern matching, immutability, recursion), concurrency and OTP (processes, GenServer, Supervisors), practical framework knowledge (Phoenix routing, Ecto changesets), and a live coding or system-design exercise that forces you to combine several of the above. Interviewers are less interested in memorized syntax and more interested in whether you can explain why Elixir makes a particular design choice -- for example, why immutability is a prerequisite for safe concurrency, not just a stylistic preference.

🏏

Cricket analogy: It's like a talent scout evaluating a young player across four dimensions -- technique, temperament, fitness, and match-awareness -- rather than just clocking their bowling speed in one net session; Elixir interviews similarly probe fundamentals, concurrency, framework knowledge, and applied problem-solving together.

Core Language: Pattern Matching, Immutability, and Recursion

A very common opening question is 'explain the difference between pattern matching and assignment in Elixir' -- the answer is that = is the match operator, not assignment: {a, b} = {1, 2} binds a and b because the shapes match, but {a, b} = {1, 2, 3} raises a MatchError because the shapes don't line up, and a strong candidate mentions the ^ pin operator, which forces matching against an existing variable's value instead of rebinding it (^a = 5 fails if a isn't already bound to 5). On recursion, interviewers often ask why tail-call optimization matters: a function is tail-recursive when the recursive call is the very last operation with no pending work afterward (like accumulating into a parameter), which lets the BEAM reuse the same stack frame instead of growing the call stack, so a tail-recursive sum([1, 2, 3], 0) handles a million-element list with constant stack space, unlike a naive non-tail-recursive version.

🏏

Cricket analogy: The = match operator is like an umpire checking whether the ball's trajectory matches the stumps' exact position before signaling out -- it's a verification, not an assignment of a new rule; the pin operator ^ is like insisting on checking against the original pitch marking rather than remeasuring a new one.

Concurrency and OTP Fundamentals

A near-universal question is 'what's the difference between GenServer.call/3 and GenServer.cast/2' -- call is synchronous: the caller blocks until the server processes the message in its handle_call/3 callback and sends a reply back, making it appropriate when the caller needs a result or needs backpressure (a slow server naturally makes callers wait). cast is fire-and-forget: the caller sends the message via handle_cast/2 and continues immediately without waiting for a reply, which is faster but means the caller has no way to know if the operation actually succeeded, so it's inappropriate for anything where the caller needs confirmation. Interviewers also expect you to know the core GenServer callbacks (init/1 for startup state, handle_call/3, handle_cast/2, handle_info/2 for out-of-band messages like :DOWN monitors or timers) and to be able to explain that a GenServer is just a regular BEAM process running a receive loop, with OTP providing the standardized structure around it.

🏏

Cricket analogy: GenServer.call is like a batsman waiting at the crease for the third umpire's review decision before play resumes -- everything pauses until the reply comes back; GenServer.cast is like signaling a boundary and moving on immediately without waiting for the scorer to confirm it.

Practical Coding Questions

A common live-coding warm-up is implementing FizzBuzz idiomatically, which is really testing whether you reach for pattern matching and guards instead of a chain of if/else. A clean Elixir answer defines a private helper with multiple clauses matched by rem(n, 15) == 0, rem(n, 3) == 0, rem(n, 5) == 0, and a catch-all, called via Enum.each(1..100, &fizzbuzz/1) -- the interviewer is checking that you know guard clauses can call built-in functions like rem/2, that clause order matters (the most specific case, divisible by 15, must come before the divisible-by-3 and divisible-by-5 clauses), and that you default to Enum/Range idioms over manually managing a loop counter.

🏏

Cricket analogy: Clause ordering in FizzBuzz is like a bowling change-of-pace plan where you must check for the most specific match-winning condition, a set play for a specific batsman, before falling back to your general-purpose delivery, or you'll never get to use the specialized plan.

elixir

defmodule FizzBuzz do
  def run(n), do: Enum.each(1..n, &fizzbuzz/1)

  defp fizzbuzz(n) when rem(n, 15) == 0, do: IO.puts("FizzBuzz")
  defp fizzbuzz(n) when rem(n, 3) == 0, do: IO.puts("Fizz")
  defp fizzbuzz(n) when rem(n, 5) == 0, do: IO.puts("Buzz")
  defp fizzbuzz(n), do: IO.puts(n)
end

# Tail-recursive sum with an accumulator
defmodule Summer do
  def sum(list), do: sum(list, 0)
  defp sum([], acc), do: acc
  defp sum([head | tail], acc), do: sum(tail, acc + head)
end

When answering out loud, narrate trade-offs explicitly -- e.g. 'I'm using [head | tail] recursion here, which is O(n); if I needed random access I'd reach for a different structure since Elixir lists don't support O(1) indexing.' Interviewers weight this reasoning as highly as the working code.

A frequent stumble under pressure: candidates use GenServer.cast for an operation where the caller actually needs a guaranteed result (like a balance transfer), silently introducing a race condition or lost-update bug. If the caller needs to know the outcome, it must be call, not cast -- flag this trade-off explicitly rather than picking one out of habit.

System Design Style Questions

A common system-design prompt is 'design a real-time chat server in Elixir' -- the expected answer sketches one lightweight GenServer process per chat room (not per user, to avoid message-ordering headaches), registered by name via Registry so any node can look up 'room:42' without a global process dictionary, with a DynamicSupervisor starting rooms on demand so a crashed room only affects the users in that specific room, and Phoenix.PubSub broadcasting messages to every subscribed connection so the room process itself never has to track individual socket PIDs directly. A strong candidate also discusses back-pressure: if a room process's mailbox grows unbounded because messages arrive faster than it can broadcast them, you need either rate limiting per user or a bounded mailbox strategy, since an unbounded BEAM process mailbox is a classic way to leak memory under load.

🏏

Cricket analogy: One process per chat room, not per user, is like assigning one scorer per match rather than one scorer per player -- the scorer tracks the shared match state that all eleven players affect, avoiding conflicting records if each player kept their own scorebook.

Elixir interviews typically cover four areas: core language fundamentals, concurrency/OTP, practical framework knowledge, and applied coding/system-design problems.
= in Elixir is the match operator, not assignment; the ^ pin operator forces matching against an already-bound variable instead of rebinding it.
Tail-recursive functions (where the recursive call is the last operation) let the BEAM reuse the same stack frame, enabling constant stack space for long lists.
GenServer.call/3 is synchronous and blocks for a reply; GenServer.cast/2 is fire-and-forget with no confirmation of success.
In pattern-matched function clauses, order matters -- the most specific guard (like divisible by 15) must come before more general ones.
A solid chat-server design uses one process per room (not per user), Registry for name lookup, DynamicSupervisor for on-demand room creation, and Phoenix.PubSub for broadcast.
Always narrate complexity and design trade-offs out loud during live coding -- interviewers weight reasoning as much as the final code.