投的是美国 Zoom SWE ，偏 backend / product engineering。从投递到口头 offer 大约三周多：投递 → Recruiter Screen → Online Assessment → Technical Screen → Virtual Onsite（多轮）→ 最终对齐。不同团队轮次会有增减，下面按我实际走完的标准全流程写，每轮记一下遇到的题和当时怎么处理的。
Step 1：投递与简历
走的 Zoom Careers 官网。简历尽量写可量化的结果（延迟降了多少、吞吐提了多少），并和 JD 里的关键词对齐。Cover letter 不是必须，我只在邮件里简短写了为什么对 real-time communication 感兴趣。
大约两周后收到 Recruiter 邮件，约了 30 分钟电话。
Step 2：Recruiter Screen（约 30 分钟）
内容偏背景和动机，没有手撕代码。
被问到的大致是：
- 介绍背景、最近在做什么
- Why Zoom
- 对 Video Infrastructure / Platform 哪块更感兴趣
- 远程协作里遇到过什么挑战、怎么解决
- 时间线和期望的大致范围
Why Zoom 我没有只说「远程方便」，而是结合以前做的实时消息和低延迟相关项目，说对 enterprise collaboration、可靠性、用户体验这块更想深入。面试官态度友好，主要确认 match 和后勤。通过后约了 Online Assessment。
Step 3：Online Assessment
工程岗常见是 HackerRank / CodeSignal 一类，2–3 道算法题，时间大概 70–90 分钟量级。
我这边题偏：
- 数组 / 滑动窗口一类
- 树或图的基础遍历
- 一道需要注意边界的实现题
策略是先扫全卷，简单的先落分，再啃稍难的。写的时候注意空输入、单元素、大数据量下的复杂度，提交前自己过一遍样例。OA 过了之后很快约了 Technical Screen。
Step 4：Technical Screening（45–60 分钟）
Zoom 上共享编辑器（CoderPad 一类），live coding。
开场自我介绍 + 简短 Why Zoom，然后一道偏 array / hashmap 的题，难度 medium 不到。我先 clarify 输入输出和边界，讲了 brute force，再优化到更优做法，写完 dry run 了两个 case，并说了 time / space。
Follow-up 问了：
- 如果数据量变大，怎么继续优化
- 这段逻辑如果在多线程环境下跑，可能有什么问题
公开反馈里 Zoom 近年会追 concurrency 意识，即使早期轮次也可能问「多线程下对不对」。我简单说了共享状态、锁或无锁结构的取舍，面试官点头后进入 Q&A。
这一轮通过后，进入 Virtual Onsite。
Step 5：Virtual Onsite（The Loop，约 4 轮）
一天内背靠背，每轮大约 45 分钟，中间有短休息。轮次覆盖 Coding、System Design、Behavioral，以及一轮偏项目 / 协作的讨论。
Coding 轮 又是一道 DSA，方向接近 Screening，但更强调边写边讲和边界。写完后面试官追问了复杂度和一个扩展场景（例如需要支持并发读写时怎么改）。思路仍是 clarify → 暴力 → 优化 → dry run。
System Design 轮 题是设计一个能支撑大规模并发的实时聊天 / 会议相关能力（和 Zoom 产品强相关）。我从用户场景和约束开口：延迟、丢包、百万级并发、是否需要持久化。
大致结构：
- 接入层 + 负载均衡
- 信令与媒体路径的大致拆分
- 状态存储（在线、房间、消息）
- 水平扩展和故障时的降级
讨论里重点讲了 latency 和 consistency 的取舍，以及为什么某些路径要走 UDP/专用通道而不是什么都 REST。面试官会追问瓶颈和监控怎么做，我按「先保证核心通话，再增强体验」的优先级答的。
Behavioral / Culture 轮 STAR 为主，和 Zoom 的 Care、Deliver Happiness、协作相关。被问到的包括：
- 压力下解决复杂问题的一次经历
- 远程团队里意见不合怎么处理
- 为用户或同事多做一步的例子
- 持续学习的具体故事
尽量用具体项目：当时情况、我负责什么、采取了什么行动、结果和复盘。空泛的「我很有责任心」不如一段带数字和取舍的故事好用。
项目 / 协作向一轮 深挖简历里的一个 backend 项目：为什么选这个方案、遇到最难 debug 的问题是什么、如果 PM 和工程对 priority 不一致怎么办。我按「用数据和对用户的影响对齐，而不是站队」来答，并补了当时的 trade-off。
Step 6：最终对齐与结果
有的流程会再加一轮和 Director / HM 的 30–45 分钟，聊团队 impact、成长方向和匹配度。我这边在 Loop 之后反馈汇总得比较快，HR 约了电话，沟通了 level、团队和口头 offer，几天后书面 offer 跟进。
评价维度公开资料里也提到：解题是否清晰、协作和沟通、是否和 Zoom 的 mission / 价值观合拍。技术过关之外，远程场景下的表达和同理心会被认真看。
Zoom SWE 复盘与准备建议
| 阶段 | 我实际体感 | 建议 |
|---|---|---|
| Recruiter | 偏动机和 fit | Why Zoom 落到产品与实时通信，不要只说远程 |
| OA | 经典 DSA，注意边界 | 先易后难，提交前自测 |
| Tech Screen | Coding + 简单并发追问 | 边讲边写，准备多线程下的正确性 |
| Onsite Coding | 同 Screening，更重沟通 | dry run + 复杂度说清 |
| System Design | 视频 / 实时聊天向 | 从 latency、scale 开口，画清取舍 |
| Behavioral | STAR + Care / 协作 | 准备 4–5 个带结果的故事 |
Zoom SWE 的流程不长，但每轮都看沟通和产品感——Coding 要边写边讲，System Design 最好能落到实时通信和延迟，Behavioral 也要有具体故事。一个人准备时很容易漏掉并发追问、Why Zoom 的讲法，或者 Design 只停留在通用框框图。
我这边当时对 Tech Screen 的表达和 Onsite 的 Design 追问做过针对性梳理，节奏会踏实很多。如果你也在准备 Zoom 或其他实时协作类公司，又觉得 OA、VO 或项目深挖不好抓重点，可以了解一下 InterviewShow：有 OA 辅助、VO 实时助攻和模拟，按你的场次和薄弱点来。有需要的可以自己联系了解。
也祝大家顺利拿到 offer。