面试整体结构

一共是两轮面试，每轮 45 分钟，中间休息 15 分钟。我的两轮整体结构其实挺相似的，前 15 分钟是 BQ，中间大概 20 分钟做题，最后 5 分钟给我提问。不过和朋友交流之后发现，MS 的面试流程确实没那么模板化，不同面试官风格差异挺大的。有的会弱化甚至直接跳过 BQ，有的在做题过程中会不断追问 follow-up，把时间拉得很长。

BQ：偏合作与 Ownership，不会技术深挖

BQ 部分整体压力不大，明显不像亚麻那样反复深挖，但还是建议提前准备好几个完整故事。问题更多集中在合作、冲突处理、ownership 之类，不太会往技术细节上 deep dive。

Coding 总体风格：口述需求 + 讨论驱动

coding 题整体都比较开放。我遇到的两个面试官都没有把完整题目直接贴到 Hackerrank 里，而是主要靠口头描述需求，边聊边补充约束和功能，更像是一个小型的 design 加实现的讨论。

第一轮：基于接口约束的数据结构设计

第一轮面试官给的是一道偏接口设计的题目，要求实现一个简单的文件路径管理器。核心需求是支持 addPath(path) 和 getParent(path) 这样的操作，保证路径层级合法，并且不能重复创建已经存在的路径。题目本身不复杂，但面试官更关心你怎么建模路径结构，以及如何在保证效率的前提下处理非法输入和边界情况。

整个实现思路基本是围绕一棵树结构展开的，用 HashMap 维护每一层的子节点映射，从 root 一路往下解析 path。过程中面试官会不断确认一些细节，比如中间路径不存在时要不要允许创建、重复 add 的行为应该返回什么、以及整体时间复杂度是不是和路径深度成正比。整体感觉不像是在考你会不会这道题，而是看你能不能把约束想清楚、设计讲清楚。

代码写完之后面试官也没有让我实际跑测试，只是快速过了一下 corner case 和复杂度，就直接进入了 QA。

第二轮：状态变化 + 查询结合的问题

第二轮面试官给的题目更偏业务背景，场景大概是一个消息订阅系统。需要实现 subscribe(user, topic) 和 unsubscribe(user, topic)，同时提供一个 query(topic) 方法，返回当前订阅了某个 topic 的所有用户。需求看起来很简单，但面试官在过程中不断加条件，比如用户可能重复订阅、取消一个不存在的订阅该如何处理，以及如何保证 query 的效率。

核心其实就是双向映射的问题，但这一轮明显更强调你对数据一致性和状态变化的理解。面试官会顺着你的实现追问，如果未来支持按用户反查订阅列表怎么办、数据量变大时内存和性能怎么权衡之类的问题，整体更像是一个逐步演进的小系统设计。这一轮 QA 聊得特别久，从团队协作、过往项目一直聊到对不同业务场景的偏好，最后甚至超时了大概 5 分钟才结束。

总体感受

整体来看是大组统一招人，hc 比较充足，具体会被分到哪个 team 目前还不确定。