Just finished my Snap L5 loop last month and the system design round was honestly the most interesting one. Wanted to write this up while it's fresh.
The format was 45 minutes with two interviewers. One was a senior SWE on the Stories infra team, the other was from the messaging side. They gave me about 5 minutes of framing before jumping into the prompt.
The actual prompt: Design a real-time story view counter for a platform that handles hundreds of millions of views per day. Classic distributed systems territory.
What they were really testing wasn't my ability to recite CAP theorem. It was how I handled the tradeoffs out loud. When I said I'd use eventual consistency with a write-behind cache, the infra interviewer pushed back: what if we need the count to feel real-time to the creator? So we detoured into hybrid approaches, maintaining a hot-path counter in Redis with periodic Postgres syncs. They seemed genuinely interested in the conversation, not just the answer.
Things that came up: sharding strategy for a high-cardinality key space, handling thundering herd for viral snaps, graceful degradation when the cache layer goes down. One of the interviewers mentioned Snap's Kafka usage pretty casually mid-conversation, which I took as a hint.
I did NOT get a design-an-entire-messaging-system prompt. From what I've heard that was more common two years ago. The 2025-2026 loops seem more scoped and focused on a specific subsystem.
Time allocation: They wanted roughly 10 min requirements, 15 min high-level design, 20 min deep dive. I ran over on the deep dive (my fault) and had to rush through failure modes at the end. Don't do that.
For background: I'm a backend eng with about 7 years in distributed systems, previously at a fintech. I prepped on Grokking and did a few mock sessions. The Snap interviewers were friendly, no trick questions, but they do follow the conversation threads you open so be careful what you claim you know deeply.