Reaching for WebSockets because it sounds the most sophisticated is a common interview misstep — the actual skill is matching the lightest mechanism that satisfies the product's real latency and directionality needs.
13 min read
Check your understanding
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
When choosing between SSE and a WebSocket for a real-time feature, what should be checked first?
Stuck? Ask the AI tutor
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Interview questions on Real-Time Updates: Polling, WebSockets, and SSE
What interviewers actually ask about this, and what a strong answer has to cover.
A feature needs to show updated data to the user without a manual refresh. Walk me through how you'd decide between polling, SSE, and WebSockets.
A strong answer covers
Checks directionality first: does the client ever need to send data back over the same channel
Weighs how much staleness the product actually tolerates before reaching for a persistent connection at all
Names polling as a legitimate, often-correct default rather than skipping straight to WebSockets
Notes the operational cost WebSockets carry beyond client code (reconnection handling, stateful server-side connections) and that it must be justified by a real bidirectional need
Likely follow-ups
If the requirement later expands so the client also needs to acknowledge or react to each update in real time, does your answer change — and why?
What would make you reconsider polling even though the current requirement tolerates some staleness?
Three real mechanisms deliver updated data to a client after the initial page load: polling, Server-Sent Events (SSE), and WebSockets. If the mechanics of any of these are fuzzy, the WebSockets & Real-Time Data lesson elsewhere in this platform covers what each one actually does under the hood — this lesson assumes that and focuses on something different: choosing between them out loud, in an interview.
Polling — the client re-requests on an interval. No persistent connection, nothing to reconnect, trivially easy to reason about and debug. The right default whenever a few seconds or minutes of staleness is genuinely fine for the product.
SSE — one-directional, server-to-client streaming over a single long-lived connection. Fits anything where the server needs to push updates but the client never needs to send data back over that same channel.
WebSockets — genuinely bidirectional, low-latency. Fits only when the client also needs to push data back in real time, not just receive it.
The decision isn't "which one is fastest" — it's "which one is the lightest mechanism that actually satisfies what this feature needs."
See it in a real thing: the same "show new data" requirement, three ways
An order-count dashboard, a live sports score feed, and a chat app all share the surface-level requirement "show the user updated data without a manual refresh." A strong interview answer treats those as three different problems, not one:
The dashboard tolerates staleness (nobody needs a sub-second order count) and never needs the client to push anything back — periodic polling is the right, boring, correct answer.
The score feed needs updates to arrive quickly and only ever flows server-to-client — SSE fits exactly, without the extra complexity of a bidirectional channel it will never use.
The chat app needs both low latency and the client sending messages back over the same real-time channel — that bidirectional requirement is what actually justifies a WebSocket.
Real-time delivery: three mechanisms, three flow shapesStep 1 of 3
Polling: the client repeatedly asks the server for updates on an interval. No persistent connection — simplest to reason about, and the right default when some staleness is fine.
What people usually miss
Watch out
Over-engineering the real-time layer is a real, common interview misstep, not a hypothetical one. Defaulting to WebSockets for a feature that would have been fine with polling reads as "knows the tool exists," not "understands when to use it."
Directionality is the first filter, not latency. If the client never needs to send data back over the same channel, that alone rules out WebSockets regardless of how fast updates need to arrive — SSE already covers fast, one-directional delivery.
SSE gets skipped entirely by candidates who only know two options. Jumping straight from "poll or WebSocket" without considering SSE is a real gap — plenty of real features (activity feeds, live scores, progress updates) are one-directional and SSE fits them better than either alternative.
WebSockets carry real operational cost beyond the client code — reconnection handling, keeping connection state on the server, and infrastructure that supports long-lived connections at scale. That cost has to be justified by an actual bidirectional need, not by "real-time" sounding like the right buzzword.
Why this matters in interviews
Almost every "design a live X" prompt in this track — notifications, chat, a collaborative editor — hinges on this exact choice, made correctly and justified out loud, before any other detail of the design matters.