Elixir interview questions

What a strong answer covers

• = is the match operator, not assignment. It asserts that the right side fits the shape on the left and binds any variables on the left; if it does not fit, it raises a MatchError.
• Multiple function clauses with different patterns replace most if/else branching. The first clause that matches runs, so order matters and the catch-all goes last.
• Guards (when is_integer(x) and x > 0) add conditions a pattern alone cannot express.
• A strong answer shows a real use, such as matching {:ok, value} and {:error, reason} from a function that can fail.

Where people lose the point

• ×Calling = assignment and missing that a failed match raises.
• ×Forgetting the pin operator (^) when matching against an existing value instead of rebinding it.

What a strong answer covers

• A value never changes after it is created. Functions return new values; a variable can be rebound to a new value, but the old value is untouched.
• Because nothing is shared and mutated, processes can run concurrently without locks, and a function's behaviour depends only on its inputs.
• Persistent data structures share unchanged parts, so updating a large map does not copy all of it.
• State that has to change over time lives in a process (a GenServer, for example), which holds the current value and replaces it on each message.

Where people lose the point

• ×Saying rebinding a variable mutates the data.
• ×Assuming immutability means every update copies the whole structure.

What a strong answer covers

• They are lightweight processes managed by the BEAM virtual machine, not the OS. Creating one is cheap, so systems routinely run very large numbers of them.
• Each process has its own heap and mailbox and shares no memory with others. They communicate only by sending messages, which are copied.
• The BEAM scheduler runs one scheduler per CPU core and preempts processes after a budget of work, so one busy process cannot starve the rest.
• Garbage collection is per process, so there is no global stop-the-world pause.

Where people lose the point

• ×Treating processes like threads that share memory.
• ×Ignoring that large messages are copied between process heaps (large binaries are the exception, they are reference-counted).

What a strong answer covers

• A GenServer is a process that holds state and handles messages through callbacks: init/1 sets the starting state, handle_call/3 answers synchronous requests, handle_cast/2 handles asynchronous ones, and handle_info/2 handles any other message.
• call waits for a reply and has a timeout (5 seconds by default), so the caller gets back-pressure and knows the work happened.
• cast returns immediately with no confirmation. It is fine for fire-and-forget work, but nothing slows a fast sender down, so the mailbox can grow without bound.
• Every request is handled one at a time by that single process, so a popular GenServer can become a bottleneck.

Where people lose the point

• ×Defaulting to cast everywhere and losing back-pressure.
• ×Putting slow work (HTTP calls, heavy computation) inside handle_call and blocking every other caller.

What a strong answer covers

• A supervisor starts child processes and restarts them when they crash. Supervisors can supervise other supervisors, which forms a tree.
• :one_for_one restarts only the child that died. :one_for_all restarts every child, for processes that cannot work without each other. :rest_for_one restarts the failed child and those started after it, for ordered dependencies.
• max_restarts and max_seconds stop a crash loop: if children die too often, the supervisor itself exits and its parent decides what to do.
• Child restart values (:permanent, :transient, :temporary) say whether a child should come back at all.

Where people lose the point

• ×Picking :one_for_all by default and restarting healthy processes for no reason.
• ×Not explaining what happens to the state of a process when it is restarted (it starts fresh from init).

What a strong answer covers

• Instead of defensive code for every unexpected state, a process fails fast and its supervisor restarts it in a known good state.
• It keeps the happy path simple and isolates failure: one crashed process does not corrupt others, because they share no memory.
• It still means handling expected errors. Invalid user input or a missing record should return {:error, reason}, not crash.
• It is the wrong fit when a restart loses state that cannot be rebuilt, or when the failure is permanent and restarting only produces a crash loop.

Where people lose the point

• ×Using it as a reason to skip error handling altogether.
• ×Not mentioning that supervisors and restart limits are what make it safe.

What a strong answer covers

• ETS is an in-memory key-value table owned by a process. Many processes can read it directly, without sending a message to the owner.
• It suits read-heavy shared data such as caches or lookup tables, where routing every read through one GenServer would make that process a bottleneck.
• Options like read_concurrency and write_concurrency tune it for the access pattern. Data is copied in and out of the table.
• The table disappears when its owner dies, so ownership and recovery need a plan, and ETS gives no transactions across multiple keys.

Where people lose the point

• ×Reaching for ETS before measuring that the GenServer is actually the bottleneck.
• ×Forgetting that the table dies with its owning process.

What a strong answer covers

• Task.async_stream over the list, with max_concurrency to cap how many run at once and a timeout for slow requests.
• Or Task.async for each request followed by Task.await_many, when the list is small and fixed.
• Under a Task.Supervisor, use async_nolink if one failure should not crash the caller.
• A strong answer covers what happens when one request times out or fails, and how the results are matched back to the inputs.

Where people lose the point

• ×Spawning an unbounded number of tasks against an external API.
• ×Not handling timeouts, so one slow request holds up everything.

What a strong answer covers

• Check the message queue length with Process.info(pid, :message_queue_len) or a tool like :observer. A growing queue means messages arrive faster than they are handled.
• Look for slow work inside callbacks, casts with no back-pressure, or messages the process never matches, which sit in the mailbox forever.
• Fixes include moving slow work into tasks, switching hot paths to call for back-pressure, splitting state across several processes, or moving reads to ETS.
• Add telemetry or metrics so the queue length is visible before it becomes an incident.

Where people lose the point

• ×Restarting the process and calling it fixed.
• ×Not checking for unmatched messages accumulating in the mailbox.

What a strong answer covers

• Each connected user gets a server-side process that holds the page state. Events go over a WebSocket, the server updates the state and re-renders, and only the changed parts are sent to the browser.
• It lets a team build interactive pages without a separate JavaScript front end and its API layer.
• Trade-offs: every interaction needs a round trip to the server, so latency matters, and there is a process and some memory per connected user.
• Purely client-side interactions, such as toggling a menu, are better handled with JS hooks or small client-side commands.

Where people lose the point

• ×Describing it as server-side rendering with page reloads.
• ×Ignoring connection loss and what state survives a reconnect.