这是微软 26 SDE intern 面试的复盘。总共有两轮，每轮 45 分钟，中间休息 15 分钟。两轮的结构大致类似，开头十五分钟是行为问题，中间二十分钟做题，最后五分钟是自由提问。不过和 Amazon 不同，微软的流程没有那么死板，面试官之间差别很大。有的会直接跳过行为问题直接进入代码题，有的则喜欢在代码题里加很多 follow up。整体感觉行为问题不会像亚麻那样“拷打”，主要是简单了解你在团队协作、解决问题方面的经验，所以准备几段 STAR 框架的故事就足够，也不会要求技术上的深挖。

第一轮

第一轮面试的题目背景是 Azure 存储服务，面试官要求实现一个简化的 Key-Value Store。系统需要支持 put、get 以及 getWithPrefix 操作。我的思路是先用 HashMap 来完成 put 和 get，这样最直观，但是 getWithPrefix 的时候需要遍历所有 key，时间复杂度是 O(n)，在大规模场景下不够高效。于是我进一步提出用 Trie 结构或者有序的 TreeMap 来存储 key，这样前缀查询就能更快完成。面试官比较在意我是否能从基本实现逐步扩展到可扩展性设计，于是我们讨论了如果数据量非常大，如何在分布式环境下存储，如何分片，怎么处理一致性，甚至如何在高频访问的场景下做缓存优化。代码实现到一个基础版本就停下来，没有真正跑测试，而是进入了关于设计和扩展性的问答。

第二轮

第二轮面试的题目背景则和 Bing 或 Teams 的场景更相关，要求实现一个简化的 Rate Limiter。函数接口是 allowRequest(userId, timestamp)，如果用户在某个时间窗口内的请求数超过阈值，就拒绝请求返回 false，否则返回 true。我最开始给出的方法是为每个用户维护一个请求时间戳的列表，每次新请求时先清理过期的时间戳，再看剩下的请求数是否超过阈值。这种做法简单但在数据量大时会有 O(n) 的开销。于是我进一步提出用队列（Sliding Window）或者令牌桶算法，可以在 O(1) 的复杂度内完成检查。面试官的 follow up 很多，既问了不同算法的优缺点。最后 QA 的环节聊了很多，甚至超时五分钟才结束。

小总结

整体下来，这两轮面试既有微软业务相关的背景，又保留了常规算法题的本质。题目虽然开放，但都能通过和面试官的互动逐渐明确范围。我的感受是微软更看重你能否在有限的时间里先把一个清晰的基础解法写出来，然后再通过讨论展示你对系统扩展和复杂度优化的思考。