作为面试官，观察到的一些面试中常见的错误

最近看到不少小伙伴在 System Design 面试（Meta 称作 Product Architecture Design）中遇到挑战，作为曾经在Meta做过一年半的面试官，楼主总结了一些常见的错误，希望能帮助大家更好地准备！
📌 1. Requirement Gathering
❌ 常见错误：

• 不问背景问题：
  

• 忘记问Why
  

作为面试官，楼主很期待小伙伴们能问问Why，比如为什么要build这个系统，我们要达到什么样的目的等等。如果有小伙伴能问到，这是一个很大的加分项

• 忘记了解我们的Customer
  

如果有小伙伴能够问一些关于我们的Customer的相关问题，这也是一个很大的加分项，比如楼主在问“Design Internalization System”问题的时候就很期待小伙伴们能问问谁是我们的customer，他们使用的是什么操作系统，他们用这个系统干什么

• 忽略 E2E Workflow：
  

不少的小伙伴经常只列出了关键的需求，但往往忽视了从E2E workflow的角度考虑系统的StakeHolders。拿“Design a Online Coding Competition"系统举例，很多小伙伴就只管据了怎么查找比赛，怎么加入比赛，怎么查看coding problem，submission以及查看leaderboard的问题，如果有小伙伴能问问谁来组织比赛，怎么添加比赛问题，怎么发布比赛结果，如果发放比赛奖励的问题，这将是一个大的加分项
📌 2. Non-Functional Requirements
❌ 常见错误：只CAP、Latency、Scalability。

• 关于CAP，这些小伙伴们都比较了解，就不再赘述了，
• 下面的一些non-function requirements希望小伙伴们也能关注一下：
• 
  
  • Privacy
  • Legal
  • Security and Fraud
  • Monitoring and Operation
    

📌 3. Back-of-the-Envelope Calculation
    ❌ 常见错误：计算过于细致，浪费时间。
楼主大多数不太care这些计算，除非这些计算能够影响关键技术选型时进行估算（如数据库、缓存策略）。
📌 4. API Design
   ❌ 常见错误：

• 直接列出所有 API，浪费时间
  

对于一些非关键的API，楼主个人意见是可以跳过

• 只选 REST，没有分析为什么不用 GraphQL/gRPC。
  

很多小伙伴往往直接选择用Rest，但没有提到为什么。楼主希望小伙伴们在选择Rest的同时也可以提提问什么不用GraphQL或者gRPC

• 忽略一些现实问题
  

有的API design的时候楼主希望小伙伴能考虑一下现实问题，比如在"Design a chat System"面试中，关于获取offline message一块，最后能够加上pagination和page_size支持。在"Design a Online Coding Competition”中，应为submission很费时间，最好加一个query submission status的API
📌 5. High-Level Design（高层架构设计）
❌ 常见错误：

• 缺少关键组件
  

完整性很重要，楼主看到不少的小伙伴往往忘了一些不重要但是非常关键的系统，比如在"Design ticketmaster“中，就有不少小伙伴忘了提search service，payment service这些需要但不是非常关键的component

• 讲解过于细节，导致失去节奏控制。
  

有的小伙伴在讲解的时候往往把关键的component讲的太过于detail了，以至于面试官不停的追问细节，反而打乱了小伙伴们的思路，从而失去了面试节奏的控制


📌 6. Data Model & Schema Design
❌ 常见错误：

• 关键的data model缺失。
• Data model的数据库选择不匹配
  

在面试中最常见到的错误就是小伙伴们选择 NoSQL作为DB，却用 SQL 方式建模。

• 缺少关键的Schema
• 忽略现实设计
  

有的小伙伴在设计的时候没有考虑到这个现实，比如在"design a online coding competition System"中，有的小伙伴就把test case放在problem表里面，这个就是很大的一个减分项，因为这个不Scalable，另外忽视了MySQL单个field不能超过4096字节的限制
📌 7. Key Component Design
🔹 Cache
❌ 只提 Memcached/Redis。
不少的小伙伴在提出cache的时候，往往就提到使用memcache或者redis，但 没有说明为什么选择他们，另外往往没有提到TTL，尤其是TTL比较关键的时候，另外cache server crash这也是一个关键问题


🔹 Queue
❌ 给出错的的detail回答
提到message queue的时候，不少小伙伴就提到Apache kafka和Amazon SQS，楼主往往就会问小伙伴一些detail的问题，比如SQS 是否支持多个 Consumer，怎么保证Kafka消息的ordering，为什么选择SQS不选择Kafka等等
🔹 数据库（DB）
❌ 数据库选择说服力不够
当小伙伴们做数据库选择的时候，楼主往往会问为什么选择MySQL而不用PostgreSQL, vice versa, 楼主最常听见的回答是这个我比较熟悉
🔹 WebSocket
❌ 只提 WebSocket，不解释为何不用 Long Polling。另外对于Websocket，不要的小伙伴直接把它放到了load balance后面
🔹 Failure Foreseen
在面试中，面试官经常期待小伙伴们能够foreseen design会带来的一些failure，能够提出解决方案
💡 先写这么多，很多还没有设计，希望这篇总结能帮到大家，祝各位 System Design 面试顺利！🔥另外楼主正在准备面试中，想看面经。看在楼主写的比较多的份上求大米，多谢了！

SD这个面试过于主观了 楼主表达的可能是楼主想要的 不同面试官想要的东西完全不一样 有的就很care api db schema design

真的看面试官。 之前面meta 让设计game system，我问多少人，他随口说1 billion ，还说超级碗的时候美国很容易有这么多traffic 。 我当时脑子也短路了，直接问他美国有这么多人口吗？ 场面很尴尬。

从我的经验来看，大部分面试官没有楼主这么多思考，大概面前拿一张纸，等着你背，这时候你直接给最优解其实是最简单的。

问题问多了，暴露了面试官的无知其实很没必要。大部分面试官也不会对问题有太多思考。

说你行你就行 不行也行
说你不行你就不行 行也不行

没有对错。对方按照你想象的来就是对的吗？当然，你有权决定，那你就是对的。

多谢楼主的分享

不是全部赞同，比如你提到的那个Online coding system,怎么发送奖励之类的，头次听说，哪有时间给你问这些边角料问题。
加分！地里需要多点讲SD的帖子。

谢谢楼主，非常有用的总结

感谢楼主🙏希望楼主有空的时候，还能再补充一些🙏

大厂有rubrics可以参考

websocket放在lb后面有啥问题？你难道以为websocket不走lb？