What you get
after every round.

• Biggest strength

  Did the numbers early and used them to make decisions, not as a ritual.

  Requirements and estimates

• Biggest gap

  Chose storage before looking at how the data is read: one database for three very different access patterns.

  Data and storage

• Do this next

  Redo this design starting from its three reads: open a chat, scroll history, show unread counts. Pick the store and keys after.

  Data and storage

• Requirements and estimates

  4 of 5 · Above the bar

  Bar for Mid-level

  Opened by agreeing scope: one-to-one and group chats up to 500 people, history and unread counts; left calls and media out. Estimated about 1,200 messages a second at peak and 20 reads per write within five minutes, and came back to those numbers twice. Did not ask how long history is kept, which moves storage by a factor of ten.

  What a 5 looks like

  A 5 looks like

  Agrees the functional and non-functional needs, then does quick sums for traffic, storage and read-to-write ratio that drive later choices.

  Meeting the bar at Mid-level

  Gets to numbers (requests per second, storage per year) and uses them.

• High-level design

  4 of 5 · Above the bar

  Bar for Mid-level

  Clean first diagram: clients on WebSockets to a gateway, a chat service, a message store and a fan-out worker behind a queue. Walked one message end to end without being asked. Presence was added late and never connected to the gateway.

  What a 5 looks like

  A 5 looks like

  A clear diagram of the main parts and how a request moves through them, built in steps from simple to scaled.

  Meeting the bar at Mid-level

  A clean design that covers the main flows and explains each part's job.

• Data and storage

  2 of 5 · Below the bar

  Bar for Mid-level

  Put messages, memberships and unread counts in one Postgres instance and did not revisit it. Asked how history reads hold up for a 500-person group, suggested an index on (chat_id, created_at) but not partitioning by chat or a wide-column store. A COUNT(*) per chat for unread counts would not survive this read rate.

  What a 5 looks like

  A 5 looks like

  Chooses data stores by access pattern, designs the schema and keys, and explains partitioning and consistency choices.

  Meeting the bar at Mid-level

  Matches stores to access patterns and designs keys and indexes.

• Scale and trade-offs

  3 of 5 · At the bar

  Bar for Mid-level

  Spotted that fan-out to large groups is the hot path and moved it onto a queue, the right call. Talked about caching recent history but could not say what to evict, or what happens to message order when a worker retries. Needed a prompt to consider a gateway node going down.

  What a 5 looks like

  A 5 looks like

  Finds the bottleneck, scales it with caching, queues or sharding, and names what each choice gives up.

  Meeting the bar at Mid-level

  Scales the busy path and explains one or two trade-offs.

• Communication

  4 of 5 · Above the bar

  Bar for Mid-level

  Kept a clear order (scope, numbers, design, deep dive) and checked in before each deep dive. Took the hint on unread counts well. Spent eight minutes on the shape of the send API, which left the storage deep dive short.

  What a 5 looks like

  A 5 looks like

  Keeps a clear structure, signposts each step and checks in on what the interviewer wants to dig into.

  Meeting the bar at Mid-level

  Follows a clear order and keeps the interviewer with them.

• Went wellRequirements and estimates

  Around minute 6: “If it's 20 reads per write, I'd rather pay on write and keep reads cheap.” That one line shaped the rest of the design.

• Went wellScale and trade-offs

  Moved fan-out for big groups onto a queue as soon as the 500-member case came up, and named the cost: a second or two of delay for the last reader.

• Cost youData and storage

  At 32 minutes, asked how to show unread counts for 40 chats when the app opens, proposed a COUNT(*) per chat. A per-user counter updated on write was the answer we were looking for.

• Cost youCommunication

  Eight minutes on the send API left five for the storage deep dive, the part that mattered most in this design.

1. 1

   Data and storage · now 2 of 5

   Days 1 to 5 · 5 sessions of 45 min

   For three systems, write the main queries first, then the tables and keys that serve them.

   From your interviewer: Redo this design starting from its three reads: open a chat, scroll history, show unread counts. Pick the store and keys after.

   • Practise: Caching a slow product pageMedium · about 40 min
   • Practise: URL shortener with click countsEasy · about 45 min
2. 2

   Scale and trade-offs · now 3 of 5

   Days 4 to 10 · 4 sessions of 30 min

   Take one design and ask 'what breaks at 10 times the traffic?' three times; write the fix and its cost each time.

   From your interviewer: Shard the messages table by chat on paper, then find the hot partition (the 500-person group) and fix it.

   • Practise: Search box suggestionsMedium · about 40 min
   • Practise: Multi-channel notification serviceMedium · about 45 min
3. 3

   Requirements and estimates · now 4 of 5

   Days 8 to 14 · 3 sessions of 20 min

   Do the sums for three well-known products: users, requests per second, storage per year, read-to-write ratio.

   From your interviewer: Before every design, ask how long the data must be kept, and redo the storage sum with it.

   • Practise: Photo app capacity estimatesEasy · about 30 min

• Requirements and estimates4+1
• High-level design4+2
• Data and storage2+1
• Scale and trade-offs3+1
• Communication4+1

Round 1, 16 Sep · Round 2, 30 Sep · Round 3, 14 Oct. The dashed line is the bar (3 of 5).

• Three roundsMilestone
• Requirements and estimates · ProficientSkill
• High-level design · ProficientSkill
• Communication · ProficientSkill