Li demonstrated good initiative during the mock system design session and showed potential in navigating complex technical systems. Some of the core strengths observed included:

Areas of strength:

• Able to list functional requirements with some hints, including edge scenarios like delete messages and handling online/offline users
  
  
• Identified a number of non-functional requirements, and made thoughtful choices around protocol and database (e.g., websocket for real-time comms, Cassandra for heavy-write workloads)
  
  
• Demonstrated awareness of data storage strategies: using blob storage for large media files and linking them via foreign keys, soft-deletion with boolean flags
  
  
• Considered caching techniques for reducing latency, particularly in mapping client to websocket server
  
  

Areas for improvement:

• Clarification phase: Jump into requirements gathering more promptly and explicitly check scale early on
  
  
• Time management:
  
  
  
  • ~5 minutes used for functional requirements
    
    
  • ~10 minutes by the time non-functional requirements wrapped up
    
    
  • Still incomplete high-level design after 25 minutes
    
    
  • Suggest:
    
    
    
    • Requirements + entities + APIs (≤10 min)
      
      
    • High-Level Design (per-FR fulfillment, ≤15 min)
      
      
    • Deep Dives (15–20 min)
      
      
• Avoid vague NFRs like “good availability”—quantify instead (e.g., “99.99% uptime”)
  
  
• Avoid diving into deep dives too early—follow a progressive system-building flow: requirements → baseline design → scaling strategies
  
  
• Improve discussion of server orchestration:
  
  
  
  • Rather than relying on cache lookup for websocket routing, discuss component-based strategies like orchestrators, service registries (e.g., ZooKeeper), or pub/sub for message delivery
    
    
• Entity schema design needs refinement:
  
  
  
  • Avoid storing full message text directly in DB
    
    
  • Clarify thread/user/channel relationships
    
    
  • Profile metadata may not be a core field in message-related tables
    
    
• Media upload path unclear:
  
  
  
  • Where/how is media_id generated?
    
    
  • When/where is (S3) or preassigned URL created? What’s the difference between url and s3_url?
    
    
• Handling offline users:
  
  
  
  • Discussion of notifications and message delivery mechanisms (e.g., inbox table, unseen message queues) was missing or shallow
    
    
• Overall data flow and component roles were underdeveloped:
  
  
  
  • Clarify how data moves, what’s persisted, and how system constraints (capacity, latency, etc.) affect design decisions

‍