Design Slack
Real-time team messaging: channels, DMs, presence, history and search for millions of concurrent users.
3 questions on this site are reported in Slack 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, webhooks, retries, isolation, multi-tenancy, ssrf, actors, presence, wide-column.
Run an AI mock Slack 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 Slack. 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.
Deliver 3 billion signed webhooks a day to a million customer endpoints, retrying for three days, without one slow endpoint delaying anyone else.
Community chat and voice: servers with a million members, years of history, roles and presence, for 20 M concurrent users.
45–60 minutes. Prompts are reported to sit close to Slack: messaging, notifications or presence, or integrations that act on commands typed into a message and call outside services.
Presenting a finished design without talking it through. A Slack engineering leader has said the back-and-forth matters as much as the solution, so ask about the requirements and check in with the interviewer as the design takes shape.
From public interview guides and candidate reports, and Slack’s own interview guidance where it publishes any. Not endorsed by Slack. 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 Slack interviews under different names.
Questions reported in Slack system design interviews include Slack, Webhook Delivery System and Discord. Between them they test real time, websockets, fan out, chat, webhooks and retries. The reports come from public interview guides and candidate accounts, not from Slack, so practise the patterns rather than memorising one list.
45–60 minutes. Prompts are reported to sit close to Slack: messaging, notifications or presence, or integrations that act on commands typed into a message and call outside services.
Reports say the Slack round weighs 4 things. 1. Clarifying the product and technical requirements before designing. 2. Back-and-forth with the interviewer, not a finished design presented in one go. 3. Tradeoffs explained with reasons, for a product someone has to ship and support. 4. On messaging prompts: the data model, real-time delivery and fan-out to channels. Presenting a finished design without talking it through. A Slack engineering leader has said the back-and-forth matters as much as the solution, so ask about the requirements and check in with the interviewer as the design takes shape.
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.