Design Slack
Real-time team messaging: channels, DMs, presence, history and search for millions of concurrent users.
8 questions on this site are reported in OpenAI 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, gpu-batching, streaming, scheduling, kv-cache, tool-calling, context-management, rate-limiting, prompt-caching, frontier, politeness, dedupe, distributed-queues, peer-to-peer, chunking, bandwidth, integrity, stragglers, rag, vector-search, hybrid-search, permissions, multi-tenancy, latency-budget, cancellation, prefix-caching, context-assembly, code-completion, ann-indexes, quantisation, segments.
Run an AI mock OpenAI 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 OpenAI. 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.
Serve a large language model behind an API: queue the requests, batch them onto scarce GPUs, stream tokens back, and keep every accelerator busy without blowing the latency budget.
An AI chat assistant for 100 M weekly users whose streamed answers survive dropped connections, call tools mid-answer, and share scarce GPUs across tiers.
Fetch billions of pages a month politely, discover new links, skip duplicates, and keep the copy fresh without getting the crawler banned.
Get a 200 GB checkpoint from one origin onto 10,000 machines in five data centres within minutes, under capped links, verifying every byte.
An assistant that answers employees’ questions from their company’s documents, with citations, only from what each user may open, minutes after edits.
Inline AI code suggestions for 10 M developers, shown within 300 ms of a pause in typing, when most requests are never used.
A managed vector database: 10,000 tenants, 20 B vectors, filtered top-k in under 50 ms at 0.95 recall, and writes searchable in seconds.
45–60 minutes, frequently on the infrastructure behind model serving, data pipelines or developer-facing APIs.
Treating an AI product as a standard CRUD app. The interesting constraints are capacity, streaming and cost per request.
From public interview guides and candidate reports, and OpenAI’s own interview guidance where it publishes any. Not endorsed by OpenAI. 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 OpenAI interviews under different names.
Questions reported in OpenAI system design interviews include Slack, LLM Inference Service, ChatGPT, Web Crawler, Large File Distribution System, RAG System, GitHub Copilot and Vector Database. Between them they test real time, websockets, fan out, chat, gpu batching and streaming. The reports come from public interview guides and candidate accounts, not from OpenAI, so practise the patterns rather than memorising one list.
45–60 minutes, frequently on the infrastructure behind model serving, data pipelines or developer-facing APIs.
Reports say the OpenAI round weighs 4 things. 1. Latency and cost tradeoffs under expensive, constrained compute. 2. Streaming, batching and backpressure on the request path. 3. Safety, abuse and quota mechanics as part of the design, not an afterthought. 4. Pragmatism: what you would actually ship first. Treating an AI product as a standard CRUD app. The interesting constraints are capacity, streaming and cost per request.
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.