What to Expect in the Zoom System Design Interview

The Zoom onsite includes a system design round of about 60 minutes. Candidates report two formats: high-level design and low-level design. High-level design means planning a whole system: its services, databases, and traffic flow. Low-level design means planning the classes and APIs inside one service. Zoom builds real-time communication products, so real-time systems are the natural topic to practice. The single most useful practice question is: design a video conferencing service.

The Two Formats

High-level design starts from a product goal. An example goal: design a chat system for millions of users. You draw the architecture, choose databases, and explain how the system scales. The interviewer pushes on trade-offs and failure cases.

Low-level design starts from one service or feature. You define classes, interfaces, and API contracts. An API contract is the agreed shape of requests and responses between two programs. Clean structure and clear naming matter most here.

Mid-level candidates may get either format. Senior candidates should expect the high-level form with deeper follow-up questions.

Question Types to Practice

Zoom's products point to the topics worth practicing. The company sells Meetings, Zoom Phone, Team Chat, Contact Center software, and the AI Companion assistant. Systems like these depend on speed and reliability. Practice these types:

• A video conferencing service. The signature topic, walked through below.
• A chat system. Message ordering, delivery receipts, and offline users are the hard parts.
• A notification service. Millions of pushes, retries, and rate limits. A rate limit caps how many requests a client may send per second.
• Scaling one service. Take a working service and handle ten times the load without downtime.

For background on how the real product works, see the technical architecture of Zoom.

Walkthrough: Design a Video Conferencing Service

Here is a high-level path through the signature question.

1. Clarify requirements. Ask about meeting size, screen sharing, and recording. Set a latency target. Latency is the delay between one person speaking and another hearing it. For live talk, aim under about 200 milliseconds.
2. Pick the transport. Use WebRTC, the browser standard for real-time audio and video. Send media over UDP, a protocol that skips delivery confirmation. Waiting for confirmation, as TCP does, adds delay that live audio cannot afford.
3. Choose the server model. A mesh, where every user sends video to every other user, fails beyond a few people. Use an SFU, a server that forwards each participant's stream to the others without mixing. An MCU, which mixes all streams into one, saves client bandwidth but costs heavy server compute. State this trade-off out loud.
4. Go global. Place media servers in many regions. Route each user to the nearest server to keep latency low.
5. Add the extras. Recording, chat, and transcription can run on separate services. They read the media stream but never sit inside the latency path of the call.

What Interviewers Grade

Four signals decide this round. First, you clarified requirements before designing anything. Second, you respected latency in every choice. Third, you named trade-offs without being asked. Fourth, you explained the design so simply that anyone could redraw it.

Common Mistakes

• Designing before asking. Jumping to boxes and arrows without requirements fails at any company. At a real-time company it fails faster.
• Treating video like a web request. Sending live media over TCP, with no reason given, shows a gap in real-time knowledge.
• One giant server. A single media server cannot serve a global user base. Regions and routing must appear in your design.
• Silence about limits. Every choice has a cost. An answer with no stated downsides sounds memorized.

How to Prepare

• Master the standard building blocks first. Load balancers, caches, queues, and database choices appear in every question. Grokking the System Design Interview teaches them with worked problems.
• Then study reusable patterns. Real-time systems reuse patterns like publish-subscribe messaging. System Design Patterns shows where each pattern fits.
• Practice the signature question twice. Design video conferencing once alone, once out loud with a timer. The second run will be twice as clear.
• Prepare the rest of the loop. See the Zoom interview process round by round for the other rounds. The motivation question needs its own answer: see how to answer why you want to work at Zoom. For the culture rounds, read the top Zoom behavioral questions.