---
title: WebRTC Interview Questions and Answers (2026)
description: Real WebRTC interview questions — signaling, ICE candidates, STUN vs TURN, RTCPeerConnection, SDP offer/answer, and mesh vs SFU — with answers for each.
url: https://usegreenroom.app/blog/webrtc-interview-questions
last_updated: 2026-08-20
---
← Back to blog
Technical
# WebRTC interview questions
August 20, 2026 · 16 min read
Somewhere around the third follow-up, the interview turns into a trap. A candidate says "WebRTC connects two browsers directly, peer-to-peer, no server needed" — true, mostly — and the interviewer just asks: "then what's the server in your architecture diagram doing?" There's a long pause. The honest answer — that WebRTC needs a server for almost everything except the actual media stream — is the whole interview in one sentence, and most candidates who've only skimmed a tutorial don't have it ready. This guide covers the **WebRTC interview questions** that come up when a company is hiring for a real-time product — video calling, voice AI, live collaboration, telehealth — organized around the parts that actually get asked: signaling, `RTCPeerConnection`, offer/answer negotiation, ICE candidates, STUN vs TURN, and how group calls scale past two people.
## What WebRTC actually is (and isn't)
**WebRTC** (Web Real-Time Communication) is a set of browser APIs and an underlying set of protocols that let two browsers exchange audio, video, and arbitrary data directly — without a plugin, and, for the media itself, without routing every frame through your server. It shipped natively in Chrome in 2012 and is now standardized jointly by the W3C (the JavaScript APIs) and the IETF (the wire protocols: ICE, DTLS, SRTP).
The trap in that first paragraph — and the first thing interviewers probe — is the word "directly." WebRTC standardizes how two peers negotiate and secure a connection and stream media once connected. It deliberately does **not** standardize how those two peers find each other in the first place. That gap is called **signaling**, and it's the single most-tested WebRTC concept because it's the part a tutorial skips and a real system can't.
The core truth: WebRTC is not "a protocol for video calls." It's a toolbox — RTCPeerConnection for the connection, MediaStream for audio/video, RTCDataChannel for arbitrary data — that you wire together with a signaling layer you build yourself. Interviewers aren't testing whether you can call getUserMedia(); they're testing whether you understand what WebRTC leaves undone.
## The three core APIs
Every WebRTC interview question traces back to one of three JavaScript objects.
### `RTCPeerConnection`
The connection itself. It handles the offer/answer negotiation, ICE candidate gathering, encryption (DTLS), and the actual media/data transport once connected. You construct one per peer-to-peer link:
```js
const pc = new RTCPeerConnection({
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'turn:turn.example.com:3478', username: 'user', credential: 'pass' },
],
});
```
The `iceServers` config is the first thing a good interviewer looks at in a code sample — a config with only a STUN server and no TURN server is a call that will work on the interviewer's home WiFi and fail for a meaningful slice of real users, which is exactly the follow-up question coming next.
### `MediaStream`
Represents audio/video tracks, usually captured via `navigator.mediaDevices.getUserMedia({ video: true, audio: true })` or `getDisplayMedia()` for screen share. Tracks get attached to the connection with `pc.addTrack(track, stream)`, which is what actually puts audio/video on the wire once negotiation completes.
### `RTCDataChannel`
An arbitrary, bidirectional data pipe over the same peer connection — used for chat messages, cursor positions in a collaborative editor, game state, or file transfer, without opening a second connection. It's built on SCTP and can be configured **reliable and ordered** (TCP-like — the default) or **unreliable and unordered** (UDP-like, via `{ ordered: false, maxRetransmits: 0 }`) for latency-sensitive data like game state where a dropped, stale update is worse than a missing one.
## Signaling: the part WebRTC deliberately doesn't standardize
This is the question that separates "read the MDN page" from "shipped something real." **Signaling** is the process of exchanging connection metadata — session descriptions (SDP) and ICE candidates — between two peers before (and during) connection setup. WebRTC needs this metadata to establish a connection, but the WebRTC spec itself says nothing about how it should be transported.
Why the omission is deliberate: signaling requirements vary wildly by product. A one-to-one video call, a group call with a "raise hand" queue, and a live multiplayer game all need to route the same offer/answer/candidate messages, but through very different session and presence logic. So WebRTC leaves it to you — you build a signaling channel over WebSocket, Socket.IO, plain HTTP polling, or even a chat app's existing message pipe, and use it purely to shuttle offer/answer/candidate messages until the peer connection is up. Once the peers are connected, most designs stop depending on the signaling channel for the media path — though many products keep it alive for things like "user left the call" or renegotiation. Readers already comfortable with the WebSocket half of this can go deeper in our [WebSocket interview questions](/blog/websocket-interview-questions) guide — the signaling channel in most WebRTC apps *is* a WebSocket server.
## Offer/answer negotiation: how two browsers agree on a session
Once a signaling channel exists, the two peers exchange **SDP** (Session Description Protocol) — a plain-text description of what each side can send and receive: codecs, resolutions, encryption fingerprints, media directions.
```js
// Peer A: create and send an offer
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
stream.getTracks().forEach((track) => pc.addTrack(track, stream));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signalingChannel.send({ type: 'offer', sdp: pc.localDescription });
```
```js
// Peer B: receive the offer, send an answer
signalingChannel.onmessage = async (msg) => {
if (msg.type === 'offer') {
await pc.setRemoteDescription(msg.sdp);
const answer = await pc.createAnswer();
await pc.setLocalDescription(answer);
signalingChannel.send({ type: 'answer', sdp: pc.localDescription });
} else if (msg.type === 'ice-candidate') {
await pc.addIceCandidate(msg.candidate);
}
};
```
The pattern interviewers listen for: `createOffer`/`createAnswer` build the SDP, `setLocalDescription` commits it to your own connection, and `setRemoteDescription` on the other side is what actually starts ICE gathering and negotiation. A common code-review question is "what happens if both sides call `createOffer()` at the same time?" — the answer is a **glare** (collision), handled by a **perfect negotiation** pattern where one side is designated "polite" and backs off its own offer in favor of the incoming one.
## ICE candidates and NAT traversal
Almost every real device sits behind **NAT** (Network Address Translation) — a home router, a mobile carrier gateway, a corporate firewall — which means the browser's actual IP address isn't reachable from the public internet. **ICE** (Interactive Connectivity Establishment) is the protocol WebRTC uses to find a path through that anyway.
Each peer gathers a list of **ICE candidates** — possible addresses it might be reachable at: its local network IP, its public IP as seen by a STUN server, and (as a last resort) a relay address from a TURN server. Both sides exchange their candidate lists over the signaling channel, and the ICE agent tries pairs of candidates until it finds one that actually works, picking the lowest-latency working pair. This is why `pc.onicecandidate` fires multiple times per connection — it's not one candidate, it's a stream of them, sent to the signaling channel as they're discovered.
## STUN vs TURN — and why TURN is the one that costs money
This is the single most commonly mis-answered WebRTC interview question, and it's worth memorizing precisely because the two are so easy to conflate.
**STUN** (Session Traversal Utilities for NAT) is a lightweight server that a peer briefly contacts to ask "what's my public IP and port, as seen from the outside?" It doesn't relay any traffic — it just tells you your own reflection through the NAT, which is often enough for the two peers to connect directly once they know each other's public address. STUN servers are cheap to run and Google's public STUN server (`stun.l.google.com:19302`) is free and widely used.
**TURN** (Traversal Using Relays around NAT) is the fallback for when direct connection fails entirely — symmetric NATs, restrictive corporate firewalls, some mobile carrier networks. A TURN server sits between the two peers and **relays every packet of media**, meaning it's no longer peer-to-peer at all — it's your server in the middle, paying for bandwidth on every byte of every call that needs it. Industry estimates commonly cited by TURN server operators put the share of real-world calls that need a TURN relay somewhere around 10–20%, which is directional, not exact, but the number a hiring manager wants to hear is "not zero and not free" — a production WebRTC system that ships without a TURN server will have a real, measurable slice of users who simply cannot connect.
The one-line answer that lands well in an interview: *STUN tells you your address; TURN carries your traffic when nobody can reach that address directly.*
A 6-person mesh call means each browser uploads its own stream 5 times over — the reason almost nobody ships mesh past a handful of participants.
## Scaling group calls: mesh vs SFU vs MCU
A one-to-one call is one `RTCPeerConnection`. A group call is where the architecture question starts, and it's a favorite at any company building a real product on top of WebRTC.
**Mesh (full peer-to-peer).** Every participant opens a direct `RTCPeerConnection` to every other participant. For *n* people, each browser sends its own upload stream *n − 1* times — a 6-person call means each device is uploading 5 copies of its own video simultaneously. It works for 2–3 participants and falls over fast after that; a laptop's upload bandwidth and CPU (encoding the same stream multiple times) are both the bottleneck, not the network core.
**SFU (Selective Forwarding Unit).** Each participant uploads *one* stream, to a media server, which forwards (routes, doesn't decode/re-encode) copies to every other participant. Upload cost per client stays flat regardless of group size; the server pays the fan-out cost instead. This is what almost every production video product (Zoom, Google Meet, Discord voice channels, most livestreaming and telehealth platforms) actually runs in 2026 — it's the answer interviewers are fishing for when they ask "how would you scale this past 2 users."
**MCU (Multipoint Control Unit).** An older model where the server *decodes* every incoming stream, mixes them into a single composited stream (e.g., one video with everyone in a grid), and sends that single stream back to each participant. It's lighter on client bandwidth and CPU — clients don't juggle multiple incoming streams — but far heavier on server CPU, since it's doing real video decode/encode work per call, not just forwarding packets. Interviewers rarely expect you to have shipped an MCU, but naming it and explaining the CPU/bandwidth trade-off correctly against SFU is a strong senior signal.
## Where this actually comes up in interviews
WebRTC questions cluster at companies building anything with a live audio/video/data layer: video conferencing (Zoom, Google Meet, Microsoft Teams), voice AI products, live-streaming and creator platforms, telehealth, online proctoring, multiplayer games with voice chat, and collaborative tools with live cursors or co-editing. The questions come in three shapes: **conceptual** ("explain the WebRTC connection flow end to end," "STUN vs TURN"), **debugging** ("a user reports the call connects but no audio arrives — where do you look first?" — usually a codec mismatch or a one-way NAT issue caught by inspecting `pc.getStats()`), and **system design** ("design a group video call for 50 participants" — which is really the mesh/SFU/MCU question wearing a different hat). Related networking fundamentals — NAT, routing, subnetting — get their own treatment in our [network engineer interview questions](/blog/network-engineer-interview-questions) guide, which is worth a pass if STUN/TURN felt shaky above; the MDN WebRTC API documentation is the standard reference for API-level specifics beyond what an interview needs.
## What Greenroom does differently — and what it doesn't
A LeetCode-style question dump or a GeeksforGeeks WebRTC page will hand you the same definitions this guide has. What neither does is make you *explain* the ICE-candidate-exchange flow out loud, under a follow-up, with someone waiting for your answer — which is a genuinely different skill from recognizing "STUN doesn't relay traffic, TURN does" on a page. I built Ari, Greenroom's AI interviewer, after years of walking out of my own technical interviews knowing I'd understood the concept but not been able to produce it verbally under pressure — the gap wasn't knowledge, it was rehearsal. Greenroom runs spoken mock interviews that ask real follow-ups ("okay, but why not just use TURN for everything and skip STUN?") the way an actual interviewer would, and gives feedback on how clearly you explained yourself, not just whether the final answer was technically correct. It won't write your WebRTC signaling server for you, and it isn't a substitute for actually building one — reading this guide and then wiring up a toy `RTCPeerConnection` demo will teach you more than either alone.
## Frequently asked questions
### What is WebRTC and why do interviewers ask about it?
WebRTC (Web Real-Time Communication) is a set of browser APIs and protocols for direct peer-to-peer audio, video, and data exchange without plugins. Interviewers ask about it for any role touching a real-time product — video calling, voice AI, live collaboration, telehealth — because it tests whether a candidate understands networking fundamentals (NAT, relays) alongside browser APIs, not just one or the other.
### What is signaling in WebRTC, and why doesn't WebRTC define it?
Signaling is the exchange of SDP offers/answers and ICE candidates between two peers before a direct connection exists — typically carried over a WebSocket or similar channel you build yourself. WebRTC doesn't standardize the transport because signaling needs vary by product (a 1:1 call, a group call with presence, a multiplayer game all need different session logic around the same core messages), so the spec leaves it as an application-level choice.
### What's the difference between STUN and TURN servers?
STUN tells a peer its own public IP and port as seen from outside its NAT, so two peers can often connect to each other directly once they know that address — it doesn't relay any media. TURN is the fallback when a direct connection fails (symmetric NATs, restrictive firewalls): a TURN server relays every packet of media between the peers, which means it's no longer peer-to-peer and it costs real bandwidth to run.
### What is an SDP offer and answer in WebRTC?
SDP (Session Description Protocol) is a plain-text description of a peer's media capabilities — codecs, resolutions, network info, encryption fingerprints. One peer calls `createOffer()` and `setLocalDescription()` to propose a session and sends the resulting SDP over signaling; the other peer calls `setRemoteDescription()` with that offer, then `createAnswer()` and `setLocalDescription()` to respond, sending its own SDP back.
### What's the difference between mesh, SFU, and MCU architectures?
Mesh has every participant connect directly to every other participant, so upload bandwidth and CPU scale with the number of participants and it stops working past a handful of people. An SFU (Selective Forwarding Unit) has each client upload one stream to a media server that forwards copies to everyone else, keeping client upload cost flat — this is what most production video products use. An MCU (Multipoint Control Unit) goes further and decodes/mixes all incoming streams into one composited stream server-side, which is lighter on clients but far heavier on server CPU.
### Is WebRTC still relevant in 2026 or has it been replaced?
Yes — WebRTC remains the standard for browser-based real-time audio, video, and data, and it underpins most production video calling, voice AI, and live collaboration products in 2026. Newer transport ideas (like WebTransport, built on QUIC) address some overlapping use cases for data, but they don't replace WebRTC's browser-native, plugin-free audio/video pipeline, and WebRTC interview questions remain common for any real-time-product role.
Practise explaining the mechanism — not just recognizing the definitions — with a real interviewer who asks real follow-ups. [Greenroom](/) runs spoken technical mock interviews and gives feedback on how clearly you explain concepts like this one. Free to start. See how it works in our [AI mock interview](/blog/ai-mock-interview) guide, or brush up on [coding-interview communication tips](/blog/coding-interview-communication-tips) before your next round.
