我这次微软组招四轮的体验非常集中，面试官几乎都是老员工，整体流程没有要求 share screen，氛围相对自由，但节奏还是很紧凑。四轮的风格差异比较明显，但整体覆盖了 coding、system design 和 BQ，能感觉到他们的侧重点不是单一的刷题，而是更看重候选人处理问题的方式

第一轮：纯做题

第一轮完全是做题，没有任何 BQ 或简历上的闲聊。面试官来自别的组，是Microsoft 365 的 senior。他直接给了一个算法题，难度相当于 LeetCode medium 之下，不过题干很长，需要花时间理解。我在 15 分钟左右写完，接着他没有停在 correctness，而是追问很多系统层面的优化问题，比如如何在高并发场景下处理，怎么提升整体性能。这一轮给我的感觉是，他们借助 coding 来引导讨论思路，并不是单纯打分能不能写出来。

第二轮： 20 分钟 BQ + 40 分钟 coding

第二轮的结构是 20 分钟 BQ + 40 分钟 coding，面试官是 Azure Cosmos DB 的senior。前面半段的 BQ 偏轻松，他并没有深挖技术细节，更多是随意聊项目。后面 coding 的题目是 LeetCode 269 Alien Dictionary 的变体。我一开始尝试用 DFS 来写一个基于依赖关系的构建方法，但很快发现自己在处理环和多入度的时候容易出错，面试官也立刻追问了一些 edge cases。于是我果断切换到更系统化的拓扑排序（Kahn’s algorithm）思路，明确用入度表和队列逐步输出结果。过程中我不断解释为什么这种方法能避免死循环并保证字典序的正确性。最后代码顺利跑通所有测试。

第三轮： 15 分钟 BQ + 45 分钟 system design

第三轮是 15 分钟 BQ + 45 分钟 system design，面试官是 Azure 的 Manager。BQ 部分还是问我之前的项目，但完全没有深入技术实现。真正的重点是 system design，题目是设计一个 ticket booking system。我一开始同样是花时间去梳理 requirements，比如支持高并发下的 seat booking、避免 double booking、以及如何处理候补或退款等场景。但面试官很快引导我直接画出 high-level diagram，不需要展开到 API 或数据库设计。后续的讨论更多集中在优化点上，比如如何在全球多个场馆或数据中心之间保持一致性，如何在抢票高峰期缓解热点压力，以及在 tradeoff 上如何权衡延迟、可用性和一致性。整体氛围更像是一次真实工作中的 brainstorming，需要我快速抓住大方向。

第四轮：5 min 聊简历 + 25 min 做题 + 其他

第四轮的面试官是另一位 manager，开头只聊了五分钟简历，完全是走个形式。随后进入 coding，题目是实现一个 async notification system。这不是标准的 LeetCode 算法题，而是让我口头描述设计思路。我一开始明确需求，然后提到可以采用基于队列的架构，让生产者把消息推到队列，消费者异步拉取和分发，并且讨论了如何做消息持久化和失败重试机制。差不多二十分钟就完成了一个 workable 的方案，面试官对整体设计思路很满意。剩下的时间我们随意聊了些细节，比如幂等性处理和延迟与吞吐之间的权衡，最后提前几分钟结束。这一轮的感觉是，他们更看重候选人能否在有限时间里快速落地一个可运行的系统，而不是追求过度复杂或完美的实现。

整体下来，我的总结是：微软的这组面试并没有特别刁钻的题目，coding 部分难度中等偏下，但他们很看重解题后的延展思考，比如系统层面的扩展、高并发优化、tradeoff 分析。而 system design 也是以高层讨论为主，不会抠 API 和 schema 的细节。BQ 在不同面试官那里比重不一样，但总体来说不算压力大。整个过程更像是他们在考察我是否具备工程直觉和沟通能力，而不是单纯的 LeetCode 能力。