2 月走完了 Slack 的完整 SWE loop，面的是 Staff 级别岗位。总共五轮：recruiter screen、technical screen、system design、两轮背靠背 behavioral，最后还有一个简短的 hiring manager sync。
technical screen 是 LeetCode medium-ish。带点变化的图遍历。不算残酷，但节奏很快。system design 那轮才真正开始有意思。我拿到的是：设计 Slack 的通知投递系统。他们想聊 push vs pull，移动端 vs 桌面端的投递保障，离线用户怎么处理，还有当你在 500 个频道时的 fan-out 问题。我画了一堆框，也很坦诚地说哪些我会先 defer，哪些会先做。他们看起来更喜欢我对优先级取舍的推理，而不是我给出“正确”的架构。
behavioral 是最 Slack-specific 的部分。很多问题都在问跨团队协作、在没有完全权限的情况下做决策、以及书面沟通。有个面试官甚至直接问我「how do you know a proposal has landed?（你怎么判断一个提案被真正接受并落地了？）」，我感觉他们一半在评估答案，一半在看我怎么把解释组织出来。
总体面试官都很强也很认真。最终面完大概 10 天给反馈。我拿到了 offer。谈薪也很顺，从初始数字往上谈了一点，没有任何戏。
5 条回复
pm_priya (Primly starter)
那个 notification system 的题太经典了。我在 PM loop 也遇到过一个变体，但换了个表述："how would you improve notification reliability for enterprise customers." 本质问题一样，视角不同。他们真的想看你是否对产品有深入理解，而不只是懂软件架构。
由 AI 翻译，查看原文
staff_steph (Primly starter)
对，他们从两个角度问同一个场景也合理。说实话 PM 版本听起来更难，因为你不能只靠技术细节躲过去。
由 AI 翻译，查看原文
corp_refugee (Primly starter)
那个“你怎么知道一个 proposal 真正落地了”的问题太 on-brand 了。他们在测你是默认“我把文档发了”就完事，还是会真的把闭环做完。在我之前的大厂，我们叫它“writing at people”和“writing for them”的区别。听起来 Slack 也把类似理念吸收进了招聘方式里。
由 AI 翻译，查看原文
tired_recruiter (Primly starter)
final 之后 10 天才有结果，对 Staff 这个级别、公司规模也差不多算正常。只是想让大家知道，这段时间的沉默一般不代表坏消息，他们在对齐定级和 comp。真正不妙通常是拖到 3 周。
由 AI 翻译，查看原文
Primly Team
在 Staff 这种级别里，有一关经常被低估：system design 里内置的对齐检查点。它不只是画框和讲 tradeoff，而是看你如何把一个模糊题目转成大家共享的问题定义，以及一串别人能照着执行的决策。
一个好用的结构是： 澄清“north star”指标和约束（延迟、可靠性、成本、用户影响）。 早点点出最难的边界情况（离线客户端、重复、背压、fan-out）。 提出一个 baseline 设计，然后明确列出你会用数据或和合作团队去验证什么。 最后定义成功标准和 rollout 计划（埋点、guardrail、降风险步骤）。
常见失误：直接钻进组件细节，但没说你到底在优化什么，于是 tradeoff 听起来就很随意。
最近做过 Staff 流程的人，你最希望在 system design 那轮更早问的一个对齐问题是什么？
由 AI 翻译，查看原文