Slack · Primly Community

Slack senior / L5 system design interview, what to expect in 2026

remote_swe_42 · 5 replies

Just cleared the Slack senior (L5-equivalent) system design round last month so writing this while it's fresh.

The format: one hour, one interviewer, fully virtual. No collaborative doc or shared whiteboard by default. They'll drop you into a Figma-like tool if you ask but most people just talk through it verbally with occasional ASCII doodles in the chat.

The prompt I got was essentially: design a real-time notification delivery system at scale. Classic Slack territory. You need to think about: Fan-out strategies: push vs. pull, how you handle channels with 100k members Presence and delivery guarantees: at-least-once vs. exactly-once, message ordering Storage layer choices: hot vs. cold, message retention policies Connection management: WebSockets at scale, reconnect logic, mobile vs. desktop clients

They care a lot about the tradeoffs, not the perfect answer. I said "I'd start with Kafka for async fan-out" and the interviewer immediately asked what the failure mode is if a consumer lags. That's the kind of depth they're probing for.

Level of difficulty: harder than a typical senior round at a Series B but not as grueling as Google's L5 design round. They'll stop you and redirect if you go too deep in the wrong area. Felt more conversational than adversarial.

Prep that helped: Designing Data-Intensive Applications (the real-time chapters), and doing a few mock designs around messaging/notification systems specifically. Slack's own engineering blog has some decent posts on their channel message storage architecture that are worth reading.

Total loop was five rounds: one coding, one system design, two behavioral, one cross-functional. System design is the hardest to skip prep on. Budget at least two weeks.

5 replies

consultant_cam

The fan-out question is a trap they almost always follow up on. If you say Kafka they'll ask about consumer lag. If you say direct push they'll ask about thundering herd on a big channel. There's no winning answer, they want to see you reason through it, not recite one.

remote_swe_42

Exactly. The moment I acknowledged "there's a tradeoff between write amplification and read latency" things got a lot friendlier. They just want to know you're not cargo-culting a solution.

jp_newgrad

Did they ask about database schema at all or mostly stay at the architectural level?

remote_swe_42

Stayed mostly architectural. Briefly touched on indexes for message retrieval (channel_id + timestamp) but didn't go deep on schema. That might vary by interviewer though.

frontend_fran

Good write-up. The WebSockets at scale piece caught me off guard in my loop. Not something frontend engineers typically think about at that depth.