Design Slack
Real-time team messaging: channels, DMs, presence, history and search for millions of concurrent users.
7 questions on this site are reported in Discord software engineer interviews. Each has a full reference design (requirements, back-of-envelope numbers, components, user flows and deep dives with interviewer follow-ups). Each one can be walked through turn by turn and then sat as a mock. Patterns covered: real-time, websockets, fan-out, chat, queues, scheduling, latency, gaming, comment-trees, voting, ranking, listings, caching, webrtc, sfu, real-time-media, congestion-control, multi-region, live-video, low-latency, transcoding, cdn, request-coalescing, moderation, perceptual-hashing, review-queues, policy-engine, audit-log, actors, presence, wide-column.
Run an AI mock Discord interview →One of these questions, run as a live round in that style, with a debrief at the end.
Attribution comes from public interview guides and candidate reports, not from Discord. It indicates where a question has been asked, nothing more.
Real-time team messaging: channels, DMs, presence, history and search for millions of concurrent users.
Group online game players into fair, low-latency matches within seconds, at millions of concurrent players.
Serve communities of posts with deeply nested comment threads, take tens of thousands of votes a second, rank by hot and best, and keep a 50,000-comment thread fast while it is still growing.
Real-time audio, video and screen share for 2 to 1,000 people per meeting, 300 M participants a day, under 150 ms mouth to ear.
Ingest 100 k live broadcasts, transcode them in real time, and deliver each about three seconds behind live, to three viewers or 500 k.
Catch spam, nudity, hate and illegal media in 4 billion daily posts and comments before they spread, with 15,000 reviewers for the hard cases.
Community chat and voice: servers with a million members, years of history, roles and presence, for 20 M concurrent users.
45–60 minutes, in one or two architecture sessions. The problem is one Discord has faced or might, often real-time chat or messaging, and sometimes a general one such as a URL shortener.
Designing in silence. Asking questions and checking in with the interviewer is part of what is assessed and knowledge of the domain is not, so ask about an unfamiliar area rather than guessing.
From public interview guides and candidate reports, and Discord’s own interview guidance where it publishes any. Not endorsed by Discord. Formats change; treat it as a prior, not a promise.
Large-company loops run 45 to 60 minutes, expect numbers, and spend most of the time on deep dives. Walk through a question to see how a strong candidate paces the hour, sit the same question as a mock until you can produce the requirements, the estimates and the design without looking, then read the interview framework guide for how to structure the hour. The other questions on the site teach patterns that show up in Discord interviews under different names.
Questions reported in Discord system design interviews include Slack, Matchmaking System, Reddit, Zoom, Twitch, Content Moderation System and Discord. Between them they test real time, websockets, fan out, chat, queues and scheduling. The reports come from public interview guides and candidate accounts, not from Discord, so practise the patterns rather than memorising one list.
45–60 minutes, in one or two architecture sessions. The problem is one Discord has faced or might, often real-time chat or messaging, and sometimes a general one such as a URL shortener.
Reports say the Discord round weighs 4 things. 1. Requirements: the questions asked, and how the answers shape the design. 2. Tradeoffs with reasons, fitted to what the problem actually needs. 3. Simplicity: the simplest design that works, and whether it still holds at 2x and 10x. 4. On real-time prompts: long-lived connections, fan-out to very large servers and reconnecting after a drop. Designing in silence. Asking questions and checking in with the interviewer is part of what is assessed and knowledge of the domain is not, so ask about an unfamiliar area rather than guessing.
Practise the questions reported there out loud, under a 45-minute clock: requirements with numbers first, then estimates, a high-level design, and deep dives into the two or three hardest parts. Start with Slack: watch a strong candidate answer it turn by turn, then sit it yourself. Then cover the patterns the round leans on (real time, websockets, fan out and chat) with one more question each.