Question 1

Should I learn Elixir before Phoenix?

Accepted Answer

Yes, but only the basics — pattern matching, pipes (`|>`), the `case`/`with` flow control, and how modules/functions work. Two days of `Exercism` Elixir track is enough to start a Phoenix tutorial. OTP concepts (GenServers, supervisors) you can pick up as you encounter them; you don't need them for typical CRUD work, but they're indispensable once you write Channels, LiveView, or background jobs.

Question 2

How much does a Phoenix / Elixir developer earn in India?

Accepted Answer

₹10-28 LPA in 2026, skewing higher than equivalent Python or Node.js roles because the talent pool is smaller. Companies hiring in India: Glific (nonprofit messaging), parts of Razorpay's realtime ops, ShareChat (some services), and a long tail of remote-friendly companies (Discord, Brex, Pinterest, Lemonade) that hire from India. Specialised areas (high-concurrency systems, fintech, edtech with real-time features) pay at the upper end.

Question 3

Is LiveView ready for production in 2026?

Accepted Answer

Yes — LiveView has been production-grade since around the 0.18 release (2022) and 1.0 shipped in 2024. Major deployments at Brex, Cars.commerce, Heroku Dashboard, and the Fly.io dashboard itself all run on LiveView. It's the right default for internal admin tools, dashboards, and CRUD apps; for marketing pages and content-heavy sites where SEO and CDN cache are critical, you can still pre-render to static HTML via `Phoenix.HTML` and skip LiveView entirely.

Question 4

How does Phoenix compare to Node.js for real-time apps?

Accepted Answer

Phoenix wins on connection scale (BEAM scheduler vs Node's single event loop), fault tolerance (supervisors restart crashed processes; a Node process crashing usually means everything dies), and observability (`:observer.start()`, `:recon`, distributed tracing built in). Node wins on ecosystem size and how fast you can spin up the first version. For chat, notifications, multiplayer, or any system where 'how many concurrent connections' is the dominant question, Phoenix is the technically superior choice — that's why Discord uses it.

Question 5

Do I need to know OTP to be productive in Phoenix?

Accepted Answer

For basic CRUD and LiveView, no — you can ship a usable app understanding only the controller / context / changeset / Repo flow. For Channels, background jobs (Oban), or anything that holds long-running state, yes — at least GenServer and supervisor basics. The good news: OTP concepts are small in number (maybe 5 building blocks) and the official Elixir docs explain them well. Most Elixir developers in India learn OTP on the job once they hit a real concurrency problem.

Question 6

What's the difference between Phoenix Channels and LiveView?

Accepted Answer

Channels are a low-level pub/sub protocol over WebSockets — you control the wire format, you write the JS client, you build the UI yourself. Use Channels when you have a separate frontend (React, mobile app) that needs server push. LiveView is a higher-level abstraction built on top of Channels: it manages the WebSocket, the wire format, and the UI for you, and you write only Elixir. Use LiveView when you want a reactive web UI without a separate frontend codebase. Many production apps use both — LiveView for the dashboard, Channels for the mobile app talking to the same backend.

Question 7

What is Phoenix and how does it differ from Rails or Django?

Accepted Answer

Phoenix is a web framework written in Elixir, designed for high-concurrency, low-latency applications. It looks superficially like Rails — same MVC layout, similar generators, comparable router DSL — but the runtime story is completely different. Phoenix sits on top of the BEAM (Erlang VM), which gives it preemptive scheduling, lightweight processes (a single node handles 2M+ idle connections), and supervision trees. A Rails request handler that blocks on a slow DB call ties up a thread; a Phoenix handler runs in its own process and the scheduler simply picks another. The other big differentiator is real-time: Channels (WebSockets) and LiveView (server-rendered reactive UIs) are first-class, not bolted on. The trade-off is the language — Elixir is functional, immutable, and message-passing, which is unfamiliar if you come from Ruby or Python.

Question 8

What does a Phoenix 1.7 route look like with verified routes (`~p`)?

Accepted Answer

Phoenix 1.7 introduced verified routes — the `~p` sigil — which checks at compile time that every URL you generate in your templates and controllers actually exists in the router. If you misspell a route or delete it, the compiler tells you immediately instead of failing at runtime. The router itself uses a pipeline-and-scope DSL: pipelines apply middleware (Plugs) to groups of routes, and scopes group routes under a common path/module prefix.

Question 9

What is a 'context' in Phoenix and why does it exist?

Accepted Answer

A context is a Phoenix-recommended pattern for grouping related business logic into a single module that becomes the public API for that domain. Instead of controllers calling Ecto schemas directly, they call functions like `Accounts.create_user/1` or `Billing.charge_subscription/2`. The point is to keep the web layer (controllers, LiveViews) thin and decoupled from the data layer. Generated by `mix phx.gen.context Accounts User users email:string`, a context bundles the schema, the changeset, and CRUD functions in one place. Critically, contexts let two teams share the same database without one stomping on the other — `Accounts.User` and `Billing.User` can be different views of the same underlying table.

Question 10

What is Ecto and how do schema, changeset, and Repo fit together?

Accepted Answer

Ecto is Elixir's database wrapper — closer to a query builder than a traditional ORM. Three pieces: (1) **Schema** maps a database table to an Elixir struct with typed fields. (2) **Changeset** is a struct that wraps changes about to be applied — it tracks the original data, the new params, validation errors, and required fields. Every insert / update goes through a changeset. (3) **Repo** is the module that actually talks to the database — `Repo.insert/1`, `Repo.update/1`, `Repo.get/2`, `Repo.all/1`. Keeping these separate is intentional: a schema with no changeset never reaches the DB, so you can never accidentally write invalid data.

Question 11

What is a Plug and how does it work?

Accepted Answer

Plug is the Elixir equivalent of Rack (Ruby) or WSGI/ASGI (Python) — a specification for composable HTTP middleware. A Plug is either a function `plug(conn, opts) -> conn` or a module with `init/1` and `call/2`. The router, controllers, and even individual actions are all built as Plugs. The Conn (`%Plug.Conn{}`) struct flows through every Plug and accumulates state — headers, params, assigns, response body. Each Plug returns a possibly-modified Conn, which becomes input to the next Plug. If a Plug calls `halt(conn)`, the chain stops (used for auth failures, redirects).

Question 12

How do you query data with Ecto?

Accepted Answer

Two styles. (1) **Keyword syntax** — concise, declarative, recommended for most queries. (2) **Composable pipeline** with `from`, `where`, `order_by`, `select` — useful when you build queries from runtime conditions. Either compiles to parameterized SQL with placeholders, so you're protected from injection automatically. Use `Repo.all/1` for lists, `Repo.one/1` for a single result, `Repo.get/2` for a primary-key lookup.

Question 13

What is a controller in Phoenix and how does it return responses?

Accepted Answer

A controller is a module whose functions (`action/2`) take a Conn plus params and return a Conn. Phoenix's `Phoenix.Controller` provides helpers like `render/3`, `redirect/2`, `json/2`, `put_status/2`, `put_flash/3`. For JSON APIs, you typically render via a separate `JSON` module that defines `render("index.json", %{posts: posts})`. For HTML, you render HEEx templates via a `HTML` module. The split keeps view logic out of controllers.

Question 14

What is HEEx and how does it differ from EEx?

Accepted Answer

HEEx (HTML+EEx) is Phoenix's HTML template engine, introduced in 1.6 and now the default. It validates HTML at compile time — unclosed tags, mismatched attributes, and bad interpolation become compile errors. EEx (Embedded Elixir) is the older, plain-text template engine still used for non-HTML output (emails, text files). HEEx also enables function components: reusable HTML snippets declared like Elixir functions, callable as `<.button>Save`. This is the foundation for LiveView's UI composition.

Question 15

How do you handle params and validate them in a controller?

Accepted Answer

Controllers don't validate params themselves — that's the context/changeset's job. The controller pattern-matches on params, hands them to a context function like `Blog.create_post(params)`, and branches on the `{:ok, ...} | {:error, changeset}` result. The changeset returned on error contains all field-level error messages, which the template renders next to each input. This separation means validation rules live in one place (the schema's `changeset/2`) and are reused across HTML and JSON endpoints. For JSON APIs, you also typically use `action_fallback` (set once at the top of the controller) so any `{:error, changeset}` automatically renders as a 422 response with the error map — keeping your action functions to a single happy-path line each.

Question 16

What is `mix` and how do you start the Phoenix dev server?

Accepted Answer

Mix is Elixir's build tool — equivalent of Cargo, Maven, or npm scripts. Phoenix ships dozens of Mix tasks. The ones you'll run daily: `mix phx.new my_app` (new project), `mix phx.gen.html` / `phx.gen.json` / `phx.gen.live` (generators for HTML, JSON API, and LiveView resources), `mix phx.gen.auth` (full auth scaffolding with verification, password reset, sessions), `mix ecto.create` / `ecto.migrate` / `ecto.rollback`, `mix test`, `mix deps.get`. To start the server, `mix phx.server` compiles and listens on port 4000. The pro move is `iex -S mix phx.server`, which attaches an interactive Elixir REPL — you can call `Repo.all(User)` directly, inspect running GenServers with `:observer.start()`, hot-reload code with `recompile()`, and connect to a running production node over SSH for live debugging. There's no Phoenix equivalent of `rails console` because IEx is the console.

Phoenix Interview Questions

What is Phoenix and how does it differ from Rails or Django?

What does a Phoenix 1.7 route look like with verified routes (`~p`)?

What is a 'context' in Phoenix and why does it exist?

What is Ecto and how do schema, changeset, and Repo fit together?

What is a Plug and how does it work?

How do you query data with Ecto?

What is a controller in Phoenix and how does it return responses?

What is HEEx and how does it differ from EEx?

How do you handle params and validate them in a controller?

What is `mix` and how do you start the Phoenix dev server?

What is `assigns` and `@conn` in a Phoenix template?

How do you write Ecto migrations and what is `Ecto.Migration`?

What are Phoenix Channels and how do they work?

How do you authenticate WebSocket / Channel connections?

What is Phoenix.PubSub and when do you use it directly?

What is LiveView and what is its lifecycle?

How do you avoid N+1 queries in Ecto?

What is Ecto.Multi and when should you reach for it?

How do you handle file uploads in LiveView?

What are LiveView Hooks and when do you need them?

What is Phoenix Presence and how does it work?

How do you test a LiveView?

What is `mix phx.gen.auth` and what does it scaffold?

How do you broadcast a message from a controller to all LiveViews?

What's the difference between `push_patch`, `push_navigate`, and JS commands in LiveView?

What's new in Phoenix 1.8 and how is scope-based auth different?

How do you cluster Phoenix nodes and what are the gotchas?

How would you architect a Phoenix system for 100k+ concurrent WebSocket connections?

What are the most common LiveView performance pitfalls in production?

How do you deploy a Phoenix app to Fly.io or Gigalixir, and what changes for a clustered setup?

Companies Hiring Phoenix

Salary Insights

Frequently Asked Questions