They ask: "Walk through the phases of the Node event loop."
Interviewers ask this to check you understand Node isn't "just JS" — it's a loop libuv drives through fixed phases, each with its own callback queue, and knowing the order explains ordering bugs that pure JS knowledge can't. The phases, in order, per tick: timers (expired setTimeout/setInterval callbacks), pending callbacks (some OS-level callbacks deferred from the previous loop), idle/prepare (internal use), poll (retrieve new I/O events and run their callbacks — this phase can block here waiting for I/O if nothing else is scheduled), check (setImmediate callbacks specifically), close callbacks (socket.on('close', ...) and similar cleanup).
┌───────────────────────┐
│ timers │ setTimeout, setInterval
├───────────────────────┤
│ pending callbacks │
├───────────────────────┤
│ idle, prepare │ (internal)
├───────────────────────┤
│ poll │ I/O callbacks; can block here
├───────────────────────┤
│ check │ setImmediate
├───────────────────────┤
│ close callbacks │ socket.on('close', ...)
└───────────────────────┘
Say it: "The loop cycles through timers, pending callbacks, poll, check, and close-callback phases each tick — the poll phase is where it can actually block waiting for I/O, which is why 'the event loop' isn't one queue, it's several, processed in a fixed order."
Red flag: Describing the event loop as "a single callback queue processed in order." That's the older mental model and misses why setImmediate and setTimeout(fn, 0) can fire in different orders depending on context.