去年春天走了 Microsoft senior 的 SWE loop，目标是 L63。过了。这里专门分享 system design 部分，因为网上流传的信息很多都过时了。
先说形式。在 L63（大概对应 senior 的 IC，类似其他公司 L5 的位置），会有一轮专门的 system design，而且面试官在看一个很明确的点：你能不能主导讨论，还是你只会等着被带着走。
我拿到的是经典题：设计一个大规模通知系统。我问了些 scope 问题，画了高层架构，然后深入到 fanout 问题。这部分表现还不错。我短暂卡住的是他们让我讲 message queue 层的 failure modes。我之前没把 dead-letter queue 和重试逻辑提前想透，他们就追问了。不是敌意，但很直接。
在 senior/L63 他们更看重： 先广度，再在你选择的点上深入。别在错误的点上深挖 20 分钟。 要把 tradeoff 明说出来。讲清楚为什么选 Kafka 而不是更简单的队列。「更可扩展」不算答案。 处理模糊性。高级别信号从你怎么处理一个不够明确的问题开始，而不是你多快给出方案。 他们不像 Google 那样痴迷纸算。粗估 OK，除非数字本身是问题核心，不会要求精确。
面试官是 principal，follow-up 会探你的 consistency vs. availability 理解。我们最后聊到了分布式缓存的 eventual consistency，还挺有质量。我感觉那一段才是真正的 signal。
有个我没想到的点：他们还问了我会怎么测试这个系统。不深，大概 5 分钟，但据说是 L63 rubric 的一部分。
design 这一轮总共 55 分钟，最后 5 分钟自我介绍/提问。我有时间覆盖大部分内容，不算赶。
如果你在准备，欢迎问细节。
5 条回复
content_cole (Primly starter)
他们 db design 会追问多深？比如你真的需要选具体的 sql vs nosql 并解释理由，还是更偏泛泛而谈？
由 AI 翻译，查看原文
qa_quinn (Primly starter)
一点也不虚。我选了 postgres 做 user preference store，然后 notification log 用了类似 dynamodb 的方案（写多读少，访问模式简单），而且得解释这两个选择。他们没有考我具体的 dynamo 内部细节，但问了我为什么不直接用一个 db 解决所有东西。你要准备好真正为你的存储选择辩护。
由 AI 翻译，查看原文
staff_steph (Primly starter)
「把取舍明确地说出来」这点是真的。我作为 contractor loop participant 给 microsoft 的岗位面过不少候选人，那些会说「我会用 X，因为在这个具体场景下它在 Y 上比 Z 做得更好」的人会立刻很突出。那些只说「我会用 microservices」但不给理由的人，就算架构本身可行也会被扣分。
由 AI 翻译，查看原文
qa_quinn (Primly starter)
没想到他们会问怎么测试系统。这其实是个好信号，说明他们关注质量，不只是“能跑起来就行”。他们是想听 unit 级别的东西，还是更偏 e2e / load testing 这类思路？
由 AI 翻译，查看原文
hardware_hugo (Primly starter)
更偏 e2e 和 failure injection。比如：你怎么确认通知真的送达了、下游 SMS provider 挂了会怎样、你怎么检测并告警 fanout latency 的突刺。不是 unit tests。
由 AI 翻译，查看原文