Erlang Interview Questions

Erlang interviews rarely stay at the syntax level for long, because the language's real value shows up in how it handles concurrency and failure at scale. Interviewers use questions about processes, OTP behaviours, pattern matching, and distribution as proxies for whether a candidate has actually built and operated a concurrent, fault-tolerant system rather than just read about one. A strong candidate doesn't just recite that 'processes are cheap' or that Erlang 'lets it crash' — they can explain the mechanism behind each claim and connect it to a concrete production scenario, which is exactly what the sections below walk through.

Erlang's concurrency model is built on the actor model: every process is a lightweight, independently scheduled unit managed entirely by the BEAM virtual machine, not by the operating system. Process creation is cheap — a new process starts with a small heap of only a few hundred words — and each process owns a private, isolated heap, so there is no shared mutable memory and no need for locks or mutexes between processes. Garbage collection happens per-process and never stops the rest of the system, and all communication happens exclusively through asynchronous message passing into a process's mailbox, read via selective receive. The BEAM scheduler (typically one OS thread per core) preemptively switches between processes based on a reduction count — roughly 2000 function calls per process before it must yield — rather than a fixed time slice, which guarantees fairness even under heavy load. Interviewers ask about this because it explains why Erlang systems can run millions of concurrent processes where a thread-per-connection model in most languages runs out of memory or context-switching overhead in the low thousands.

"Let it crash" is Erlang's philosophy of not defensively coding against every conceivable failure inside a process, and instead letting a process terminate when it hits an unexpected state, while a supervisor detects that exit and restarts the process into a known-good state. Interviewers ask about this to check whether a candidate understands that supervision trees turn error handling into a structural, declarative concern rather than scattered try/catch blocks: a supervisor is configured with a restart strategy — one_for_one restarts only the failed child, one_for_all restarts every sibling, rest_for_one restarts the failed child plus every child started after it, and simple_one_for_one is used for dynamically spawned children of the same type — along with a restart intensity such as allowing at most 3 restarts within 5 seconds before the supervisor itself gives up and escalates. A strong answer also explains that process links propagate exit signals, and a supervisor traps those exits via process_flag(trap_exit, true) so it can react instead of dying itself, which is the actual mechanism that makes Erlang systems self-healing in production.

Interviewers frequently ask candidates to distinguish OTP's core behaviours. gen_server implements the generic client/server pattern — call for synchronous request/reply (with a default 5-second timeout), cast for asynchronous fire-and-forget, and handle_info for out-of-band messages — and is the workhorse behind most stateful services. gen_statem, which replaced the older gen_fsm, models a process as an explicit state machine using either state_functions or handle_event_function callback mode, letting each state pattern-match incoming events and transition explicitly, which suits protocols, connection handshakes, or anything with well-defined states. gen_event manages a set of pluggable handler modules that can be added or removed independently at runtime and that all react to events broadcast through one manager process, which is why it's the classic choice for logging or alerting fan-out. Hot code reloading builds on the code server keeping at most two versions of a module resident at once — current and old — and a long-running loop process only picks up the new version when it makes a fully qualified call (Module:Function); OTP behaviours implement the code_change/3 callback specifically to transform their internal State term across an upgrade so in-flight processes don't need to restart, which is what makes zero-downtime releases possible via appup and relup instructions.

Pattern matching in Erlang is not just destructuring — it's a control-flow mechanism, since function clauses, case, and receive all select a branch by matching a value's shape, including matching against already-bound variables, which is a classic interview trap for candidates coming from imperative languages. Guards (a when clause restricted to guard-safe built-ins like is_integer/1, length/1, or comparison operators) add conditions that can never raise an exception, which distinguishes them from if, which requires one of its own guard-sequence clauses to evaluate true or it errors with no matching clause, and from case, which is the general-purpose form for matching arbitrary patterns and typically includes a catch-all fallback clause. On the data-structure side, interviewers commonly probe the difference between ETS (Erlang Term Storage), an in-memory table that lives outside any single process's heap and can be read from or written to directly by any process without message passing, supporting set, ordered_set, bag, and duplicate_bag semantics; the process dictionary, a mutable key-value store scoped to a single process that is generally discouraged because it breaks referential transparency; and Mnesia, a distributed, transactional database built on top of ETS and DETS that adds replication, disk persistence, and transactions across cluster nodes.

Erlang nodes form a cluster through distributed Erlang: each node registers with epmd (the Erlang Port Mapper Daemon) on startup, nodes authenticate one another using a shared magic cookie, and once connected, process communication — message sends, spawn, links, and monitors — works transparently across node boundaries using the same primitives as local processes. Interviewers like asking candidates to reason about network partitions here, and why relying purely on net_kernel or global-based registration doesn't substitute for a real consensus layer when split-brain-sensitive state is involved. On raw performance, candidates should be able to explain that the BEAM runs one scheduler thread per core with per-process reduction counting for fairness, that NIFs (natively implemented functions) offer C-level speed but can block an entire scheduler if they don't yield or run on a dirty scheduler, and that tools like observer, recon, and process_info are the standard way to diagnose message queue backlogs or memory bloat in a live production system.