今年早些时候我走了 Zendesk senior 的 SWE loop（拿到 offer，入职后 4 个月因为无关原因离职，这个另开贴说）。想留点 system design 那轮的有效信息，因为我准备时几乎找不到。
Zendesk 的 system design 面试是 60 分钟，一个面试官，虚拟白板（Miro 或类似）。他们给的经典题是「design a ticketing system」（设计一个工单系统），说实话跟公司做的东西很契合，有点讽刺。我觉得这是故意的，他们想看你是不是理解他们的产品空间。
他们最在意的点： scope。我一上来就问澄清问题，面试官明显放松了。后来他跟我说大部分候选人会直接开始画框。 写 vs 读的模式。工单创建时写多，在支持流程里读多，这点要说出来。 跨工单字段搜索的索引策略。我聊了 elasticsearch vs. postgres full-text，他们会强追 tradeoff。 用 queue/async 处理 SLA 告警和 webhook 投递。
他们没有死磕的点： 规模精确数字（要有粗估，但不需要把数学算到很准） kubernetes 细节或基础设施拓扑 microservices vs monolith 的宗教战争（他们有 service mesh，不需要你重做一遍）
目标级别是 senior/L5 等价。他们想要的信号是：你能不能主导对话、把 tradeoff 讲清楚、在 60 分钟里足够狠地做优先级。更少是「你知不知道标准答案」，更多是「你的思路在真实 design review 里站不站得住」。
我最希望有人提前告诉我的一件事：他们会从真实的 Zendesk 产品 surface 抽题。大概了解 Zendesk 作为产品怎么运作。你不需要每天用，但至少要理解工单生命周期、路由、SLA tracking 的概念。这个背景能让你的设计选择更 grounded，而不是模板化。