这次在 Google 的一场后端面试中，遇到了一道和餐厅排队相关的系统设计题。

题目给出的业务场景是：
餐厅维护一个 FIFO 的 waitlist。餐厅会通过你提供的 API 来管理排队的 party。当有桌子空出来时，需要从 waitlist 中选出一组客人入座，选择逻辑要结合当前桌子的 size。

面试官明确要求 API 至少支持三件事：
加入 waitlist、从 waitlist 中移除某个 party、在给定桌位大小的情况下找到一个可以安排入座的 party。

在面试刚开始阶段，候选人先复述了题意，但对一些隐含规则并不确定。比如 party 是否有唯一 ID，移除操作是否需要精确定位；匹配桌位时是否要求尽量坐满；FIFO 的约束范围是全局还是只在可选 party 中生效。

我们在这一阶段做的辅助，是先帮候选人把这些规则整理成一套自洽的假设，并且用简短的话表达出来，让面试官确认也就是clarification。确认完成后，候选人再基于这套规则继续往下设计。

接下来进入数据结构和接口设计阶段。我们先让候选人给出一个简单的方案：使用一个顺序队列来维护 waitlist，在有桌子时顺序扫描，找到第一个可以坐下的 party。这个方案在逻辑上是通的，但在复杂度上存在被追问的空间。

果然面试官追问了复杂度，我们csoahelp随机提出更优化的方案：可以考虑按 party size 进行分组或索引，以减少每次匹配时的扫描范围。随后将这个思路自然地补充进自己的设计中。

当面试官继续追问 remove 操作的实现细节时，我们继续给出优化：一开始发现仅靠单一队列不太方便精确删除。我们在现场辅助他补充了 party ID 与内部结构的映射关系，让移除操作的逻辑保持清晰，也避免了大段推翻重写。

整个过程中，我们的辅助重点放在三件事上：
保证前后假设一致；
在面试官追问前提前铺好可扩展方向；
让所有调整看起来像是设计的自然演进，而不是临时补救。

这道题最终没有要求写完整可运行代码，重点放在接口设计、数据结构选择以及应对追问时的稳定性。客户在结束时完整讲清了 add、remove 和 match 三个 API 的职责边界，逻辑能够自洽地覆盖整个业务流程。

如果你也在准备Apple、Meta、TikTok等大厂的算法与系统设计面试，却不清楚如何拆题和应对各种边界，欢迎添加微信，即可领取北美面试求职通关秘诀。我们也有代面试，面试辅助，OA代写等服务助您早日上岸~