Bloomberg NG 和 intern 的面经写了不少，翻翻之前的文章就能找到。这里重点聊聊level更高的社招。

Bloomberg 的 SDE 社招整体流程不算花哨，但强度非常实在。它不像某些公司那样流程拉得很长，却在关键环节上给足时间，让你在高压下完整展示能力。如果你准备面试，这个流程一定要提前了解，因为时间安排和节奏把控非常重要。

第一轮：Phone Screen —— 纯 Coding

第一轮是标准的电话技术面，只有 coding，没有bq面。题目难度一般在 LeetCode medium 偏上，重点在于数据结构选择是否合理，以及代码是否干净利落。我当时遇到的题目是设计一个支持插入、删除、以及返回当前 Top K 高频元素的数据结构。面试官并不满足于你直接用现成库，而是希望你解释为什么选择 HashMap + Min Heap，而不是排序或者 TreeMap。时间控制在 45 分钟左右，但 coding 本身大概 30 分钟，剩下时间会追问复杂度优化、边界情况处理，以及如果数据规模上亿怎么办。Bloomberg 的 phone screen 风格很直接，没有太多寒暄，写代码的过程比较严肃。建议提前适应共享文档或在线编辑器的 coding 方式，保持边写边讲思路的节奏。

Virtual Onsite 第一轮：System Design（60 分钟高强度）

Bloomberg 的 system design 给的时间非常充裕。真正讨论设计的时间接近 60 分钟，刨除开头介绍和最后提问，大概能完整讲 50 分钟以上。这和 Meta 的 45 分钟、Amazon 的 30 分钟相比明显更深入，也意味着你必须准备更细致的设计。我遇到的题目是设计一个实时股票行情推送系统。用户可以订阅多个股票代码，当价格变化时需要毫秒级推送到客户端。刚开始需要明确需求，是偏重低延迟还是高吞吐，是全球用户还是单区域，是推送给终端用户还是内部系统。Bloomberg 很看重你对 trading 场景的理解，比如行情更新频率可能达到每秒上万次，如何避免 fan-out 风暴，如何做 backpressure 控制。设计过程中必须从 high level architecture 讲起，明确数据源、消息队列、实时处理层、缓存层以及推送层。面试官会不断追问，比如如果某个股票特别热门，订阅人数暴增怎么办？如果 websocket server 崩溃如何快速恢复？是否需要分区？如何保证顺序性？时间足够长，所以一定要准备 storage 设计、缓存策略、数据一致性、监控、限流策略、容量估算。Bloomberg 面试官很喜欢问 numbers，你需要能大概算出 QPS 和带宽。

Virtual Onsite 第二轮：Coding（两道题，60 分钟）

这一轮 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。时间非常容易被拖慢，所以第一题一定要稳准快。

Onsite 之后：Hiring Manager + HR

通过两轮 virtual onsite 后，会安排 hiring manager 面试以及 HR talk。通常默认是飞去纽约线下，但可以沟通改成线上。Hiring manager 更关注你做过的项目、ownership、以及是否适合 Bloomberg 的工程文化。会聊 trade-off、真实线上问题、以及为什么想加入。HR talk 就比较常规。