Bloomberg · Primly 社区

Bloomberg data scientist 面试(SQL + case + stats):我这次 loop 的完整拆解

ds_dmitri (Primly starter) · 5 条回复

2026 年 Q1 走了 Bloomberg 的 DS 面试 loop,申请的是 mid-level 的 data scientist 职位。网上几乎没有 Bloomberg 的 DS 流程信息,所以我把全貌写一下。

我经历的轮次: Recruiter screen(15 分钟,走流程) Technical phone screen:45 分钟。两道 SQL + 一道 stats 概念题。就这些。 Onsite(远程):4 轮。 Advanced SQL / analytics Stats + experiment design Case 风格的 product analytics Behavioral

SQL 细节: Bloomberg 的 SQL 题不是玩具题。不管是 phone screen 还是 onsite,他们都希望看到 window functions、CTEs、time-series 聚合。有一题是算跨多个 instrument 的 running P&L。如果你工作里没真的用过 window functions,你需要专门练。RANK()、LAG()、按 partition 的累计 SUM() 都出现了。

Stats 问题: 「Walk me through how you'd design an A/B test for a change to how we display a data metric.」(带你逐步讲:你会如何为展示数据指标的改动设计 A/B 测试。) 「What's the difference between statistical significance and practical significance? When have you had to explain this to a stakeholder?」(统计显著性和实际显著性的区别是什么?你什么时候需要向干系人解释这个?) 「What's a situation where a model was accurate but not useful?」(有没有一种情况是模型很准确但没用?)

Case 风格分析: 给了一个虚构场景:Bloomberg 上线了一个新的 analytics 功能,DAU 3 周内下降了 10%。让我讲怎么诊断。标准的产品分析 case,但他们会很用力地追 instrumentation:「What data would you need that you might not have?」(你可能需要但手上没有的数据是什么?)这个问题能把只做过干净数据分析的人和真的做过数据落地的人区分开。

他们在意什么: 统计推理的严谨、SQL 熟练度、以及你是否用业务视角而不只是模型视角思考。这个 level 不看深 ML,更偏应用分析,带一点实验。

Comp(我拿到的 offer,2026 年 6 月,NYC): 总包大概 $185K(base + bonus)。Base 是 $145K。这个 level 的 DS 没有 equity,我挺意外的。

由 AI 翻译,查看原文

5 条回复

analyst_ana (Primly starter)

窗口函数要求在金融服务类 DS 面试里很常见,尤其是 LAG() 和 LEAD()。我在另一家 fintech 的 loop 前练了好几周,确实很有用。

由 AI 翻译,查看原文

de_derek (Primly starter)

「What data would you need that you might not have(你可能还缺哪些你需要的数据)」真的是个好问题。在真实 DS 工作里,很多时候业务问题的答案会卡在你还没有的埋点和数据上。

由 AI 翻译,查看原文

ds_dmitri (Primly starter)

没错。而且错误的回答是,假设你已经有了所需的一切,然后只是描述分析。正确的回答应该包括主动识别数据缺口,并提出怎么补齐。他们想要的是那种以前撞过这堵墙的人。

由 AI 翻译,查看原文

finance_faye (Primly starter)

从我看到的情况来说,Bloomberg 的 mid-level DS 没有 equity 挺常见的。他们的薪酬结构相对纯科技公司更偏 bonus,而不是 equity。 如果你在意长期 equity 上行空间,提前知道这一点很重要。

由 AI 翻译,查看原文

Primly Team

在这种 DS 面试流程里,有一关候选人经常低估:case 这一轮的范围对齐。即使题目听起来很开放,面试官通常在看你是否能:(1)定义团队真正要做的一个决策,(2)把它翻译成 1 到 2 个可衡量的结果,(3)说明什么数据会改变你的建议。

一个简单但很有用的结构是:澄清用户与场景(谁看这个指标、在哪看),定义成功和 guardrail(主指标加 2 个 sanity check,比如延迟、覆盖率或下游行为),再概述分析步骤(分群、前置趋势,以及什么会让结果不可执行)。常见失误是直接上建模或花哨方法,却没说明决策阈值。

做过这种产品分析 case 的人,哪个 guardrail 指标救过你,避免一次“统计显著但很糟糕”的上线?

由 AI 翻译,查看原文