WebSockets Interview Questions

Analogy categoryAnalogies

WebSocket interview questions typically probe three areas: whether you understand the protocol mechanics (handshake, framing, close codes), whether you can reason about scaling a real-time system (multiple servers, backpressure, reconnection), and whether you know when WebSockets are the wrong tool compared to alternatives like Server-Sent Events, long polling, or WebRTC. Strong answers ground abstract protocol knowledge in a concrete example, such as describing exactly what happens on the wire during a handshake rather than just naming the header.

🏏

Cricket analogy: A good interview answer is like a commentator not just saying 'good shot' but explaining the exact footwork and bat angle that produced the cover drive — specificity is what separates a real understanding of WebSockets from a memorized definition.

Protocol Mechanics Questions

A frequently asked question is 'what happens during a WebSocket handshake, at the byte level?' The strong answer: the client sends a regular HTTP GET request with Upgrade: websocket, Connection: Upgrade, and a random Sec-WebSocket-Key; the server responds with HTTP 101 Switching Protocols and a Sec-WebSocket-Accept header computed by concatenating the key with a fixed GUID (258EAFA5-E914-47DA-95CA-C5AB0DC85B11), SHA-1 hashing it, and base64-encoding the result — this proves the server actually understood the WebSocket protocol rather than being, say, a misconfigured proxy blindly echoing headers back.

🏏

Cricket analogy: The Sec-WebSocket-Accept computation is like a bowler's action being validated by a biomechanics report before an ICC clearance — it's not enough to claim you can bowl, you must produce cryptographic-grade proof the action is legitimate.

System Design Questions

'How would you scale a WebSocket service to millions of concurrent connections?' is a classic system design question. A strong answer covers: horizontal scaling behind a load balancer that supports long-lived TCP connections (not one that assumes short request/response cycles), a shared pub/sub layer (Redis, Kafka, NATS) so messages fan out across server instances, connection-aware routing or sticky sessions so a client's reconnect lands on a server that can resolve its state, and monitoring per-connection memory usage since each open socket consumes kernel and application memory, meaning connection count — not just message throughput — becomes the bottleneck at scale.

🏏

Cricket analogy: Scaling WebSockets is like scaling a franchise cricket league from one stadium to ten simultaneous venues: you need a central results feed (pub/sub) syncing scores across all grounds, and each venue needs enough staff (memory/connections) regardless of how many balls are actually bowled that hour.

Sample Answer Snippet: Explaining Backpressure

javascript

// A commonly asked follow-up: 'how do you handle a slow client?'
ws.on('message', (data) => {
  // Check bufferedAmount before sending more data to a client
  if (ws.bufferedAmount > MAX_BUFFER_BYTES) {
    // Client can't keep up — drop, throttle, or disconnect
    console.warn('slow client detected, bufferedAmount=', ws.bufferedAmount);
    ws.close(1008, 'client too slow');
    return;
  }
  ws.send(data);
});

Interviewers often ask 'WebSockets vs Server-Sent Events (SSE) — when would you use SSE instead?' Good answer: SSE is simpler (plain HTTP, auto-reconnect built in, works over HTTP/2 multiplexing) and is enough when data only flows server-to-client, like live notifications or a stock ticker; WebSockets are needed when the client also needs to send frequent messages back, like chat or collaborative editing.

A common interview trap: candidates say WebSockets are 'always better' than long polling or SSE. Push back on absolutes — mention that SSE has simpler infrastructure requirements and native reconnection, and long polling can still be the pragmatic choice behind restrictive corporate proxies that block WebSocket upgrades entirely.

Be ready to explain the handshake at the byte level, including the Sec-WebSocket-Accept computation, not just name the headers involved.
Know the meaning of common close codes (1000, 1001, 1006, 1008, 1011) and be able to explain what each implies for debugging.
For system design questions, cover horizontal scaling, pub/sub fan-out across instances, and connection count as the binding resource constraint.
Understand backpressure: check bufferedAmount and have a strategy (throttle, drop, disconnect) for slow clients.
Be able to compare WebSockets against SSE, long polling, and WebRTC, and justify a choice based on directionality and infrastructure constraints, not just 'newer is better'.
Discuss reconnection strategy: exponential backoff, and how the client resyncs state (e.g. via a last-seen message ID) after a dropped connection.
Mention security considerations: validating the Origin header, authenticating the handshake (token in query string or subprotocol), and rate-limiting messages per connection.