OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导，已帮助多位候选人斩获 Senior 级别 Offer。
Bloomberg NG 和 intern 的面经写了不少，翻翻之前的文章就能找到。这里重点聊聊level更高的社招。Bloomberg 的 SDE 社招整体流程不算花哨，但强度非常实在。它不像某些公司那样流程拉得很长，却在关键环节上给足时间，让你在高压下完整展示能力。如果你准备面试，这个流程一定要提前了解，因为时间安排和节奏把控非常重要。
第一轮是标准的电话技术面，只有 coding，没有bq面。题目难度一般在 LeetCode medium 偏上，重点在于数据结构选择是否合理，以及代码是否干净利落。我当时遇到的题目是设计一个支持插入、删除、以及返回当前 Top K 高频元素的数据结构。面试官并不满足于你直接用现成库，而是希望你解释为什么选择 HashMap + Min Heap，而不是排序或者 TreeMap。时间控制在 45 分钟左右，但 coding 本身大概 30 分钟，剩下时间会追问复杂度优化、边界情况处理，以及如果数据规模上亿怎么办。Bloomberg 的 phone screen 风格很直接，没有太多寒暄，写代码的过程比较严肃。建议提前适应共享文档或在线编辑器的 coding 方式，保持边写边讲思路的节奏。
Bloomberg 的 system design 给的时间非常充裕。真正讨论设计的时间接近 60 分钟，刨除开头介绍和最后提问，大概能完整讲 50 分钟以上。这和 Meta 的 45 分钟、Amazon 的 30 分钟相比明显更深入，也意味着你必须准备更细致的设计。我遇到的题目是设计一个实时股票行情推送系统。用户可以订阅多个股票代码，当价格变化时需要毫秒级推送到客户端。刚开始需要明确需求，是偏重低延迟还是高吞吐，是全球用户还是单区域，是推送给终端用户还是内部系统。Bloomberg 很看重你对 trading 场景的理解，比如行情更新频率可能达到每秒上万次，如何避免 fan-out 风暴，如何做 backpressure 控制。设计过程中必须从 high level architecture 讲起，明确数据源、消息队列、实时处理层、缓存层以及推送层。面试官会不断追问，比如如果某个股票特别热门，订阅人数暴增怎么办？如果 websocket server 崩溃如何快速恢复？是否需要分区？如何保证顺序性？时间足够长，所以一定要准备 storage 设计、缓存策略、数据一致性、监控、限流策略、容量估算。Bloomberg 面试官很喜欢问 numbers，你需要能大概算出 QPS 和带宽。
这一轮 coding 会有两个面试官同时在场。气氛比 phone screen 稍微 relaxed，但节奏依然紧张。一般会给两道题。并不是说必须写完两道题才算通过，有些面试官会频繁让你 dry run，或者要求你手动写 test case，这些都会消耗时间。所以节奏一定要自己掌控。我遇到的第一题是实现一个 LRU Cache，但要求支持 TTL 过期机制。也就是说不仅要支持 O(1) 的 get/put，还要自动清理过期数据。这题考察你对双向链表 + HashMap 的熟练程度，以及如何在不增加复杂度的前提下处理时间戳。
第二题是给定一个股票价格数组，设计一个 API，可以实时返回过去 N 秒内的最大价格。这个题本质上是 sliding window maximum，但场景被包装成 market data stream。面试官会追问如果是实时流而不是数组怎么办，如何在多线程环境下保证安全。Bloomberg coding 的特点是非常重视你写代码时的表达能力。他们会让你解释每一个关键选择，有时还会故意打断你，让你优化空间复杂度或者讨论 corner case。时间非常容易被拖慢，所以第一题一定要稳准快。