Airbnb数据科学家面试真题与SQL编程2026
一句话总结
Airbnb的数据科学家岗位不是在找会写SQL的人，而是在找能用数据定义问题的人。大多数候选人花了20分钟优化一个JOIN语句，却说不清为什么这个指标会影响房东留存。真正的筛选标准不是你能不能写出窗口函数，而是你能不能在没有明确问题的情况下，从混乱的日志数据中识别出关键杠杆点。
面试官真正关注的不是你刷了多少LeetCode，而是在你解释A/B测试方案时，是否主动质疑实验的假设前提。数据建模的考察重点不是范式理论，而是你是否会用反事实推理来判断因果方向。那些以为背下高频题就能过的候选人，第一轮就被淘汰了——因为他们的思维还停留在“答题”，而Airbnb要的是“定义题”。
适合谁看
这篇文章专为三类人准备：一是正在冲刺FAANG级别数据科学岗的中级从业者，已有1-3年数据分析经验，但始终卡在终面或Hiring Committee（HC）阶段；二是转型者，例如从商业分析、BI转向数据科学，对Airbnb这类以“产品+数据+实验”三位一体驱动决策的公司缺乏系统认知；三是已经拿到面试通知，但发现官方JD写得模糊，网上信息陈旧，真实考察重点与2020年甚至2023年已完全不同的人。如果你还在用“漏斗分析+留存率+AB测试”这三板斧准备Airbnb面试，那你准备的方向就错了。
Airbnb当前的数据科学家角色，早已脱离传统“取数+报表”定位，转而要求候选人具备产品思维、实验设计敏感度，以及在模糊信息下构建可行动洞察的能力。尤其在2025年公司完成新一轮组织架构调整后，数据团队被明确划入“产品决策中枢”，这意味着面试中对“数据如何影响产品决策”的追问频率显著上升。适合阅读本文的人，应该已经掌握基础SQL和统计学知识，但需要知道Airbnb到底在用什么标准做判断。
为什么Airbnb的SQL面试和其他公司不一样
Airbnb的SQL面试不是在考你能不能写对语法，而是在测试你对业务逻辑的还原能力。大多数公司把SQL当作技术筛选工具，比如Meta会出“连续登录天数”这类算法化题目，谷歌喜欢考复杂子查询嵌套，而Airbnb的SQL题从不脱离实际业务场景——它们全部来自真实产品迭代中的决策困境。比如2025年Q3，房源推荐排序策略调整后，房东的“首次回复时间”指标异常上升，数据团队需要快速定位是算法问题、用户行为变化，还是数据上报异常。这个真实事件被抽象成一道面试题：“给定消息表、订单表、房东表，找出过去30天内，收到3个以上预订请求但回复率低于50%的房东，并分析其地理分布和房源类型集中度。
” 这道题的难点不在语法，而在你是否意识到“收到预订请求”不等于“请求有效”——有些请求可能已被系统自动拒绝，或用户在1分钟内取消。如果你直接用booking_status = 'accepted'来筛选，就会漏掉关键噪声。真正的解法必须先定义“有效请求”：即状态为pending超过10分钟且未被取消。这不是SQL技巧，而是对业务流程的理解。
更深层的考察在于指标构建。面试官会追问：“为什么选50%作为阈值？” 正确的回应不是说“这是常见标准”，而是提出用历史分位数或行业基准来校准。
比如你可以说：“根据2024年Q2的数据，Top 20%房东的平均回复率是72%，因此50%确实偏低，但我们应检查这部分房东是否集中在新兴市场，因有时区差异导致表面‘低回复’。” 这种回应展示了数据敏感度，而不是机械答题。内部debrief记录显示，2025年有7位候选人写出完全正确的SQL，但只有2人进入下一轮——区别就在于是否主动讨论指标的合理性。
另一个典型场景来自2024年的一次跨部门冲突。增长团队认为“延长免预付政策”能提升预订转化，但风控团队担心欺诈率上升。数据科学家被要求快速评估历史类似政策的影响。面试中对应的题目是：“计算2023年Q4‘免预付’实验期间，欺诈订单在新用户中的占比，并与对照组比较。” 很多人直接写：
`sql
SELECT
COUNT(CASE WHEN fraudflag = 1 THEN 1 END) 1.0 / COUNT() as fraudrate
FROM bookings
WHERE experimentgroup = 'treatment' AND usertype = 'new'
`
这是BAD版本。问题在于：它没有处理时间窗口偏移——实验组用户可能在实验结束后才发生欺诈行为，而对照组观察期不一致。GOOD版本必须加入事件时间与观察时间的对齐逻辑：
`sql
WITH userfirstbook AS (
SELECT userid, MIN(bookingdate) as first_date
FROM bookings
WHERE experimentperiodstart <= bookingdate AND bookingdate <= experimentperiodend
GROUP BY user_id
),
event_outcomes AS (
SELECT
u.user_id,
u.experiment_group,
MAX(CASE WHEN b.bookingdate <= u.firstdate + INTERVAL '14 days' AND b.fraudflag = 1 THEN 1 ELSE 0 END) as fraudwithin_14d
FROM userfirstbook u
LEFT JOIN bookings b ON u.userid = b.userid
GROUP BY u.userid, u.experimentgroup
)
SELECT
experiment_group,
SUM(fraudwithin14d) 1.0 / COUNT() as fraud_rate
FROM event_outcomes
WHERE user_type = 'new'
GROUP BY experiment_group;
`
这个写法体现了两个关键判断：一是欺诈行为有滞后性，必须用固定观察窗口；二是只分析首次预订，避免老用户混杂。这正是Airbnb要的——不是你会不会写CTE，而是你有没有构建稳健指标的思维。在一次HC讨论中，一位面试官说：“他SQL写得一般，但主动提出要check数据延迟上报的问题，这个意识比语法正确更重要。” 这就是裁决标准。
面试流程的每一关到底在考什么
Airbnb数据科学家面试共五轮，每轮60分钟，全部远程。第一轮是HR电话筛查，30分钟，主要确认简历真实性与动机匹配度。典型问题如：“你为什么想来Airbnb而不是Meta？
” 回答“因为喜欢旅行”是BAD的。GOOD回答是：“Airbnb的数据决策链条更短，数据科学家可以直接参与产品原型讨论，比如2024年‘一键入住’功能上线前，DS团队用模拟数据预估了房东操作成本，这种深度介入在其他公司较少见。” 这展示了你做过功课，并理解其组织特性。
第二轮是技术SQL轮，由L4/L5数据科学家主面。题目通常为1道复杂SQL+1道简单统计题。例如：“用给定表计算房东的‘活跃密度’——即过去90天内有预订的天数占总天数的比例，并找出该指标与房源评分的相关性。” 考察重点是窗口函数与NULL值处理。很多人忽略“总天数”应为maxdate - mindate + 1，而误用COUNT()。
更深层的陷阱是：如果房东在期间下架房源，是否还应计入？这需要你主动提问澄清。面试官期待你问：“房源状态变化是否影响活跃天数计算？” 而不是闷头写代码。
第三轮是产品分析轮，由产品负责人（PM）或资深数据科学家主持。典型问题是：“如果发现全球预订量突然下降5%，你会怎么分析？” 多数人从漏斗拆解：流量→搜索→预订。这是A，但Airbnb要的是B——即先验证数据本身是否可靠。
GOOD回答是：“我先检查数据管道是否有延迟或ETL失败，比如查看dailyingestionlog表的record_count是否突降。确认数据可信后，再按国家、设备、渠道分层，看是否集中在某个区域。” 2025年4月的真实案例中，一次“全球下降”其实是印度站API故障导致数据未上报。能想到先验数据质量的候选人，通过率高出3倍。
第四轮是实验设计轮，由实验平台团队或增长DS主持。题目如：“设计一个实验测试‘首页增加房东评分’对预订转化的影响。” 多数人直接说“随机分组，看转化率差异”。这是A。
B是：你是否考虑网络效应？房东评分展示会影响多个用户对同一房源的决策，违反独立性假设。正确做法是“按用户地理聚类分组”或“按房源分组，衡量整体转化”。在HC讨论中，一位候选人的方案被否决，不是因为统计错误，而是他忽略了“如果用户看到高分房东但价格更高，可能产生负面情绪”，这种产品心理层面的考量才是高阶区分点。
第五轮是行为面（Bar Raiser），由跨部门资深员工主持。问题如：“讲一个你推动数据文化改变的例子。” 回答“我做了个仪表盘”是BAD。GOOD回答是：“在前公司，产品经理常根据单日数据做决策。我推动建立了‘统计显著性检查表’，要求任何结论必须附p值和置信区间。
三个月后，临时决策减少40%。” 这展示了影响力。五轮结束后，Hiring Committee需达成共识。2025年HC会议记录显示，一名候选人四轮高分，但被拒——因为“他在实验设计中完全依赖传统AB测试，未提及贝叶斯方法或多臂老虎机的适应场景”，暴露了方法论僵化。
你准备的SQL题库可能已经过时了
2026年Airbnb的SQL考察重点已从“复杂语法”转向“数据质量与指标一致性”。过去高频的“连续登录”“最长连胜”题几乎绝迹。取而代之的是三类新题型：一是事件时间 vs 处理时间的校准，二是漏斗口径一致性的定义，三是反事实场景的SQL建模。比如一道新题：“计算2025年1月使用新搜索排序算法的用户，其30天内的预订率，并与旧算法用户比较。” 表面是简单分组统计，实则陷阱重重。
BAD解法直接按algorithm_version分组算预订率。GOOD解法必须解决三个问题：一是新旧算法用户可能重叠，需按首次使用版本分组；二是处理时间延迟，1月的操作可能在2月才产生订单，需延长观察窗口；三是选择偏差，使用新算法的用户可能是早期尝鲜者，本身转化率高。
正确写法应包含：
`sql
WITH first_exposure AS (
SELECT
user_id,
MIN(eventtimestamp) as firstexp_time,
algorithmversion as firstversion
FROM search_events
WHERE DATE(event_timestamp) BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY userid, algorithmversion
),
outcomes AS (
SELECT
f.user_id,
f.first_version,
MAX(CASE WHEN b.bookingdate <= DATE(f.firstexptime) + INTERVAL '30 days' THEN 1 ELSE 0 END) as booked30d
FROM first_exposure f
LEFT JOIN bookings b ON f.userid = b.userid
GROUP BY f.userid, f.firstversion
)
SELECT
first_version,
SUM(booked30d) 1.0 / COUNT() as convrate
FROM outcomes
GROUP BY first_version;
`
这个写法体现了三个关键判断：按首次曝光分组、固定30天观察期、处理时间对齐。在一次内部培训中，面试官被提醒：“不要只看SQL是否跑通，要听候选人如何定义‘用户’和‘时间窗口’——这才是区分点。”
另一道题来自真实产品争议。2024年，Airbnb推出“灵活价格建议”工具，但初期数据显示使用该工具的房东收入反而下降。数据团队需排查是工具无效，还是用户选择偏差。
面试题抽象为：“比较使用价格建议工具的房东与未使用者的收入增长率。” BAD做法直接分组均值比较。GOOD做法是：先用PSM（倾向得分匹配）平衡两组在房源类型、地理位置、历史评分上的差异。SQL中虽不直接写PSM，但你要能说出“我会先构建匹配样本，再比较差异”，并用SQL展示特征分布对比：
`sql
SELECT
'treated' as group_type,
AVG(price) as avg_price,
AVG(reviewscore) as avgscore,
COUNT() as n
FROM hosts WHERE used_tool = 1
UNION ALL
SELECT
'control',
AVG(price),
AVG(review_score),
COUNT()
FROM hosts WHERE used_tool = 0;
`
然后说：“如果两组在关键协变量上显著不同，我会建议用匹配或回归调整。” 这种回应让面试官知道你理解因果推断的底层挑战。而那些只写SELECT...GROUP BY...的人，即使语法正确，也被标记为“缺乏批判性思维”。
薪资结构与职业路径的真实情况
Airbnb数据科学家的薪酬分为三部分：base、RSU（限制性股票）、bonus。L3（初级）总包约$220K：base $110K，RSU $80K/4年（每年$20K），bonus 5%（$5.5K）。L4（中级）总包$320K：base $140K，RSU $144K/4年（每年$36K），bonus 10%（$14K）。
L5（高级）总包$500K+：base $180K，RSU $240K/4年（每年$60K），bonus 15%（$27K）。注意，RSU是分4年归属，第一年通常只拿25%，并非一次性到账。2025年起，公司引入绩效RSU（PSU），额外增加10%-20%的浮动股票，与团队OKR挂钩。
职业路径上，L4是分水岭。L3主要执行分析需求，L4开始独立主导实验设计。一位L5在内部会议中说：“L4的考核不是你做了多少报告，而是你是否能定义‘该问什么问题’。
” 2025年晋升案例中，一位L4因主动发现“搜索页加载时间每增加100ms，新兴市场转化率下降2.3%”，推动前端优化，被提前晋升。而另一位L4尽管完成所有分配任务，但HC评价“缺乏主动性，总是等待指令”，被建议再观察一年。
晋升委员会（Promotion Committee）的讨论记录显示，技术能力只是基础。L4升L5的关键是“影响力”：你是否改变了产品方向？是否建立了可复用的分析框架？例如，有人开发了“房东健康度”综合指标，被多个团队采用，这就是典型晋升案例。
薪资谈判时，base涨幅通常不超过15%，但RSU可协商空间大。建议在offer阶段提出：“我希望RSU能反映我对长期价值的贡献”，而非只谈base。公司目前不提供signing bonus，但可匹配竞争对手的总包。
准备清单
- 精通时间窗口对齐：必须能区分事件时间与处理时间，掌握固定观察期设计，避免领先指标污染。
- 掌握反事实推理：面对“比较A/B组”类问题，先问“是否存在选择偏差”，再决定是否需要匹配或回归调整。
- 熟悉Airbnb核心指标：DAU/MAU、预订转化率、房东回复率、NPS、LTV/CAC，能解释其业务含义。
- 理解实验设计边界：知道何时用AB测试，何时需用差分-in-差分或合成控制法。
- 准备3个深度项目：每个项目需包含问题定义、数据挑战、分析过程、业务影响，用STAR-L结构（Situation, Task, Action, Result, Learning）。
- 模拟HC答辩：找人扮演“怀疑者”，挑战你的结论，练习如何 defend 分析假设。
- 系统性拆解面试结构（PM面试手册里有完整的数据科学家面试实战复盘可以参考）——包括如何应对“数据不可用”“指标冲突”等模糊场景。
常见错误
错误一：只写SQL，不解释假设
BAD案例：面试题“计算用户预订转化率”，候选人直接写：
`sql
SELECT COUNT(DISTINCT bookeduser) 1.0 / COUNT(DISTINCT visiteduser) FROM logs;
`
未定义“visited”是否去重、是否过滤机器人、转化时间窗口。面试官追问后才补救。
GOOD做法：先说“我假设转化窗口为7天，且用户需完成邮箱验证才算有效访问”，再写代码。不是先写代码，而是先定义口径。
错误二：混淆相关性与因果
BAD案例：发现“使用App的用户留存更高”，直接建议“推动全员下载App”。未考虑自选择偏差。
GOOD回应：“使用App的用户可能本身更活跃，我会用工具变量或PSM来估计因果效应。” 不是看到关联就行动，而是先评估偏差来源。
错误三：忽略数据上游问题
BAD案例：分析预订下降，直接拆解漏斗。
GOOD案例：先查数据管道，“我注意到ETL任务在过去24小时延迟3小时，建议先确认数据完整性再深入分析。” 不是立即分析，而是先验证数据可信度。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：Airbnb还考“连续登录最长天数”这类题吗？
不考了。2024年后，这类纯算法题已被淘汰。现在所有SQL题都来自真实业务场景，例如“计算房东在取消政策变更后的预订接受率变化”。重点不是窗口函数语法，而是你是否考虑“取消政策变更前后的用户构成是否一致”。
2025年有候选人写出完美代码，但被拒——因为他没意识到，主动更改政策的房东本身更灵活，不能代表全体。面试官要的不是代码正确，而是你能否识别选择偏差。真实案例中，一位候选人主动提出：“我会先比较改策房东与未改策房东的历史行为差异”，这句话直接让他通过。所以，别再刷LeetCode风格题了，去研究产品决策逻辑。
Q：没有Airbnb实习经历，能通过吗？
能。2025年入职的12位L4中，8位无实习。关键是你能否展示“Airbnb式思维”。例如，有位候选人分析Uber数据时，特意对比“司机响应时间对乘客取消率的影响”，并提到“类似Airbnb房东回复时间对预订的影响”，展示了迁移能力。
面试官在debrief中说：“他没在Airbnb工作过，但理解我们的核心杠杆点。” 相反，有位前Airbnb实习生被拒——因为他的项目只是“生成周报”，没有推动决策。公司不在乎你在哪里做过，而在乎你是否具备“用数据定义问题”的能力。建议准备一个项目，模拟Airbnb场景，比如“如何优化房源推荐多样性”。
Q：Python/机器学习会考吗？
会，但不是重点。L3/L4轮通常不考手写机器学习算法。如果考Python，也是用pandas做数据清洗，例如“处理预订表中的时间重叠订单”。机器学习更多出现在项目深挖中。例如，你提到“用随机森林预测房东流失”，面试官会问：“为什么不用逻辑回归？特征重要性是否可解释？
” Airbnb当前偏向可解释模型，因需向产品和法务团队解释。2024年有位候选人提出用BERT做评论情感分析，被挑战：“模型更新频率多快？如何监控漂移？” 他答不上来。不是模型越复杂越好，而是是否适合生产环境。建议聚焦在特征工程、A/B测试评估、指标监控，而非SOTA模型。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。