面试这几年聊下来，我最大的感受是：视频平台的数据岗面试，题目本身往往不难，难的是你能不能站在“业务 + 工程 + 数仓”的交叉点上回答问题。爱奇艺2024年这批数据面试题，看似是在考SQL、考Python、考指标体系，实际上是在筛三类能力：业务敏感度、数据工程基本功、以及把脏数据“洗”成能直接服务决策的干净数据的能力。这篇文章我结合自己的面试复盘和身边同事的真实经历，把这类面试的考点、典型题目、完整解法和踩坑记录整理出来。无论是准备社招还是校招，只要你投的是数据开发、数据分析、数据挖掘这类岗位，这份拆解应该都能直接用到。
1. 面试到底在考什么：从岗位JD看能力模型
1.1 三类数据岗位，考察侧重完全不同
先搞清楚一个基本问题：同样是“数据岗”，爱奇艺这种体量的平台，面试官想考察的东西是完全不同的。数据开发岗重点是数仓分层、调度、ETL性能，SQL是基本功；数据分析岗则更偏指标口径、业务归因、AB实验设计，Excel甚至都比SQL出现得更频繁；数据挖掘/算法岗则聚焦特征工程、模型训练、数据集构建。很多候选人挂在第一轮，不是技术不行，而是压根没判断清楚自己面的是哪一类。
我见过一个真实案例：候选人面的是数据分析岗，结果上来就开始讲Flink实时计算、讲数据湖选型，面试官礼貌点头，但没有一个追问。原因很简单，数据分析师的核心价值是帮助业务做决策，不是搭建数据基础设施。你讲的东西再深，和岗位不匹配就是最大的减分项。反过来，面数据开发岗如果只讲PPT式的业务分析，同样会被认为技术深度不够。
所以，准备面试的第一步，是去JD里找出它反复强调的三四个关键词。如果它强调“指标体系建设”，那你要重点准备留存、漏斗、DAU这类口径问题；如果它强调“数据治理”，那元数据、血缘、质量校验这些内容就要提前整理成体系。爱奇艺2024年的数据岗位JD里，“数据治理”“数据质量”“指标体系”三个词出现的频率明显提高了，这茬儿后面单独讲。
1.2 2024年面试的新变量
2024年这批题还有一个以前不太常见的趋势：面试官开始追问“如何把关系数据库里的数据加工成大模型读懂的数据”。这个变化很关键，它不只是问一个技术方案，而是在考察你对数据准备全链路的理解。
我在面试中被问到过类似的问题，当时的回答思路是分四步拆解。第一步是数据收集和清洗，用SQL做基本过滤、去重、异常值处理，再用pandas完成缺失值填充和类型转换，这一步的目标是保证数据“干净”；第二步是结构化建模，把业务表转换成适合模型消费的格式，比如JSON、Markdown表格、向量数据库中的embedding；第三步是添加上下文和元数据，让模型知道字段含义、单位、时间范围；第四步是数据标注和评测，构造问答对，做质量抽检。这样既能体现你对数据库技术的熟练度，也能体现你对大模型落地场景的理解。
这类题目的出现，本质上是数仓工程师、数据分析师和算法工程师的边界在模糊。面试官想听的不是某个具体工具的名称，而是你有没有一套完整的数据加工方法论。后面第3部分我展开讲这套方法论怎么落地。
2. 必考核心知识点逐项拆解
2.1 业务指标与口径定义：面试里的“隐形送分题”
凡是视频平台的数据面试，业务指标这关是绕不过去的。爱奇艺的核心指标离不开这几个：DAU/MAU、播放量、播放时长、完播率、留存率、会员转化率。表面上你只要会算就行，但真正拉开差距的是“口径定义”。
举一个典型例子：播放量怎么算？是一次播放请求算一次，还是播放超过3秒算一次？是去重后的用户数，还是播放事件的总次数？不同口径下，同一个业务看板的数字可能差出好几倍。面试官问这类问题，不是要一个标准答案，而是看你会不会意识到口径不一致会导致决策偏差。
我整理了一个通用口径表，面试时可以直接套用：
| 指标 | 常见口径 | 口径差异导致的业务解读差异 |
|---|---|---|
| 播放量 | 播放事件总数 / 去重用户数 | 事件总数反映热度，去重数反映人群规模 |
| 完播率 | 完整播完的用户占比 / 播放时长达标的占比 | 前者严格，后者容忍度更高 |
| 留存率 | 次日留存 / 7日留存 / 30日留存 | 不同周期反映不同产品粘性 |
| 会员转化率 | 付费用户/注册用户 / 付费用户/活跃用户 | 分母不同，反映转化漏斗不同层级 |
准备这类问题时，建议把口径回答结构固定成“分母是谁 + 分子是谁 + 去重键是什么 + 时间窗口怎么切”。面试官听着就会觉得你思路清晰。比如回答DAU：“以设备ID或用户ID为去重键，统计当天有任意一次播放或浏览行为的独立用户数，时间窗口按自然日切分。”这样一个公式化的回答，永远比“就是每天活跃的人数”得分高。
2.2 SQL窗口函数：留存、漏斗、排名的通用解法
SQL是数据岗面试逃不掉的一环。爱奇艺这类平台面试官最爱考的三个场景：留存计算、漏斗转化、TopN排行。这三个场景有一个共同的解法底子——窗口函数。
先看留存计算。留存的核心思路是：先找到每个用户首次活跃日期，再判断该用户在后继第N天是否活跃。这里先用ROW_NUMBER()给用户的活跃记录按日期排序，取排名为1的记录作为首日，再通过日期差判断后续活跃情况。写出来大概是：
WITH first_active AS ( SELECT user_id, MIN(dt) AS first_date FROM user_active_log WHERE dt >= '2024-01-01' GROUP BY user_id ) SELECT DATEDIFF(b.dt, a.first_date) AS day_diff, COUNT(DISTINCT a.user_id) AS retained_users FROM first_active a JOIN user_active_log b ON a.user_id = b.user_id WHERE b.dt >= a.first_date AND b.dt <= DATE_ADD(a.first_date, INTERVAL 30 DAY) GROUP BY DATEDIFF(b.dt, a.first_date) ORDER BY day_diff;这里有一个容易被忽略的细节：按天做留存时，JOIN后会产生多对多的匹配，比如用户在第1天和第2天都活跃，第2天也被计为“首日后第1天”的留存用户。所以留存计算的核心不是COUNT，而是COUNT(DISTINCT)，否则结果会被放大。很多面试者在这里翻车，写出来的留存率超过100%，一眼就被看穿没真正做过留存分析。
再看TopN问题，这个更常考。比如统计每个频道播放量最高的3个视频，解法是使用ROW_NUMBER()按频道分区并按播放量排序，取排名小于等于3的记录。类似的，如果用DENSE_RANK，则允许并列名次，适合“并列也要展示”的场景。我会在实际面试中同时说出两种函数的区别，因为面试官就是通过这种细节判断你到底是刷过题还是有实战经验。
2.3 数据仓库分层：从ODS到ADS的设计逻辑
爱奇艺数据开发岗的面试，基本必问数据仓库分层。如果面试官问“你们数仓怎么分层的”，最好不要只背出“ODS、DWD、DWS、ADS”四个缩写，而是要能讲清楚每一层解决什么问题、数据进来之后怎么加工、层与层之间的流转规则是什么。
我用一个非常直白的类比来解释：ODS层是原料仓库，业务库、日志、第三方数据进来后原样存放，对应“买到什么菜就放什么菜”；DWD层是清洗车间，做去重、标准化、字段补全，对应“把菜洗干净、切好”；DWS层是半成品加工区，按主题聚合出用户粒度、频道粒度、内容粒度的汇总表，对应“把配菜按菜谱搭配好”；ADS层是成品菜，直接面向报表和业务取数，对应“上桌的菜，客户直接吃”。
面试时如果能把这个类比讲出来，再配上实际场景，基本能拿高分。举个例子：一个播放日志，进数仓之后，ODS层保留原始JSON，DWD层解析出用户ID、视频ID、播放时长、时间戳，DWS层按天聚合出每个用户在每个频道的播放总时长，ADS层输出DAU和播放时长报表。逐层拆完，面试官就知道你不是只背了概念，而是真的做过这套流转。
值得多提一句的是，现在主流数仓都强调“数据治理前置”，也就是在DWD层就做质量规则校验，而不是等ADS层出报表了才发现数据异常。这一点在下一章详细展开，因为它是2024年面试题里反复出现的考法。
2.4 埋点、日志与数据采集：容易被忽略的暗面
另一个高频但容易被忽略的考点是埋点和日志分析。很多候选人对SQL、Python准备得很充分，但一问到“数据从哪儿来的”，就开始含糊。
视频平台的埋点体系通常分两类：页面浏览类事件和服务端行为类事件。页面浏览类事件由前端SDK上报，包含页面ID、用户ID、设备ID、时间戳；服务端行为类事件则记录播放、暂停、拖动、完播等操作。两道数据最终汇入Kafka，再由Flink或Spark Streaming写入数仓。
在爱奇艺这类场景下，面试官常问的一个具体问题是：如何判断一次播放是否“有效”。这里需要引入一个时长阈值。比如播放时长小于3秒就判定为无效播放，可能是用户误触或者网络加载失败。这类阈值在面试时最好能给出具体数值，比如说“我们当时定的是3秒，因为用户主动播放时长低于3秒后跳出，分析价值极低”。给具体数值，说明你真的处理过这类日志。
另外，如果讨论技术栈，Elasticsearch经常出现在日志检索和分析场景中。面试时可以提一句：ES里的数据写入主要是通过API或Logstash完成的，为了保证写入性能，会按天建索引，再结合别名（alias）切换，避免频繁重建索引影响查询。这既回应了热词里“ES+插入数据”的搜索需求，也展示了你的工程经验。
3. 拿一道爱奇艺风格的SQL题完整做一遍
3.1 原题背景与表结构
我根据多家视频平台的真实面试题，整理出一道非常有代表性的“爱奇艺风格”SQL题。题目背景是：平台想分析用户观看行为，给出三张表：
- user_login：用户登录记录表，字段为user_id（用户ID）、login_date（登录日期）；
- video_play：视频播放记录表，字段为play_id、user_id、video_id、play_date、play_duration（播放时长，单位秒）、channel（频道）；
- user_order：会员订单表，字段为order_id、user_id、order_date、order_amount。
面试题拆成三个小问：第一，计算2024年2月每天的活跃用户数和人均播放时长；第二，计算2024年2月新用户的次日、3日、7日留存率；第三，统计各频道播放时长Top3的视频。
3.2 第一问：活跃用户数与人均播放时长
活跃用户数不能直接用video_play表。原因很简单，用户可能只登录没播放，也可能只播放没登录。如果只统计有播放记录的用户，会低估活跃用户。正确的做法是把login_date和play_date两张表的用户做并集去重，再按天聚合。
WITH daily_active AS ( SELECT login_date AS dt, user_id FROM user_login WHERE login_date BETWEEN '2024-02-01' AND '2024-02-29' UNION SELECT play_date AS dt, user_id FROM video_play WHERE play_date BETWEEN '2024-02-01' AND '2024-02-29' ) SELECT dt, COUNT(DISTINCT user_id) AS dau FROM daily_active GROUP BY dt ORDER BY dt;人均播放时长的计算，最容易踩的坑是“分母用谁”。这里分母应该用当天的DAU，而不是当天有播放行为的用户数。如果你用播放用户数当分母，算出来的人均播放时长会偏高，业务方会觉得“用户每天都在看很久”，但实际上是因为很多用户当天只登录了没看视频，被你从分母里剔除了。
WITH daily_active AS ( SELECT login_date AS dt, user_id FROM user_login WHERE login_date BETWEEN '2024-02-01' AND '2024-02-29' UNION SELECT play_date AS dt, user_id FROM video_play WHERE play_date BETWEEN '2024-02-01' AND '2024-02-29' ), play_summary AS ( SELECT play_date AS dt, user_id, SUM(play_duration) AS total_duration FROM video_play WHERE play_date BETWEEN '2024-02-01' AND '2024-02-29' GROUP BY play_date, user_id ) SELECT a.dt, COUNT(DISTINCT a.user_id) AS dau, COALESCE(SUM(b.total_duration), 0) / COUNT(DISTINCT a.user_id) AS avg_play_duration FROM daily_active a LEFT JOIN play_summary b ON a.dt = b.dt AND a.user_id = b.user_id GROUP BY a.dt ORDER BY a.dt;这个答案里有一个很关键的细节：LEFT JOIN时如果用户当天没有播放记录，SUM会返回NULL，所以必须用COALESCE兜底，否则人均播放时长会算成NULL。这种细节往往是面试官通过一个追问暴露出来的，“如果你的LEFT JOIN没有匹配上怎么办”，能接住这个追问，就已经领先大部分候选人了。
3.3 第二问：新用户留存率
新用户的定义，一般取该用户第一次活跃的日期。这里“第一次活跃”同样要综合登录和播放两类行为，否则可能把一个老用户误判成新用户。SQL写法是先求每个用户的最小活跃日期，再针对每个新用户去关联后续日期的活跃记录。
WITH user_first AS ( SELECT user_id, MIN(dt) AS first_date FROM ( SELECT login_date AS dt, user_id FROM user_login UNION SELECT play_date AS dt, user_id FROM video_play ) t GROUP BY user_id ), active_daily AS ( SELECT login_date AS dt, user_id FROM user_login UNION SELECT play_date AS dt, user_id FROM video_play ), retention AS ( SELECT a.first_date, COUNT(DISTINCT a.user_id) AS new_users, COUNT(DISTINCT CASE WHEN b.dt = DATE_ADD(a.first_date, INTERVAL 1 DAY) THEN a.user_id END) AS day1_retained, COUNT(DISTINCT CASE WHEN b.dt = DATE_ADD(a.first_date, INTERVAL 3 DAY) THEN a.user_id END) AS day3_retained, COUNT(DISTINCT CASE WHEN b.dt = DATE_ADD(a.first_date, INTERVAL 7 DAY) THEN a.user_id END) AS day7_retained FROM user_first a LEFT JOIN active_daily b ON a.user_id = b.user_id WHERE a.first_date BETWEEN '2024-02-01' AND '2024-02-29' GROUP BY a.first_date ) SELECT first_date, new_users, day1_retained / new_users AS day1_retention_rate, day3_retained / new_users AS day3_retention_rate, day7_retained / new_users AS day7_retention_rate FROM retention ORDER BY first_date;这个题最容易翻车的点是：很多面试者会直接拿user_first去JOIN video_play，忽略了“留存”应该定义为“该用户当天是否活跃”，而不是“该用户当天是否播放”。如果只看播放，漏掉了只登录的用户，留存率会偏低。爱奇艺这种平台，很多用户是打开App刷一刷首页、看看预告片就退出，这部分行为虽然不构成播放，但确实是活跃行为，应该计入留存。
3.4 第三问：各频道播放时长Top3
这个问题的标准解法是用窗口函数ROW_NUMBER()。分区键是频道，排序键是播放总时长，取排名在前3的视频。
WITH channel_play AS ( SELECT channel, video_id, SUM(play_duration) AS total_duration FROM video_play WHERE play_date BETWEEN '2024-02-01' AND '2024-02-29' GROUP BY channel, video_id ), ranked AS ( SELECT channel, video_id, total_duration, ROW_NUMBER() OVER (PARTITION BY channel ORDER BY total_duration DESC) AS rn FROM channel_play ) SELECT channel, video_id, total_duration FROM ranked WHERE rn <= 3 ORDER BY channel, rn;这里可以主动向面试官解释ROW_NUMBER()和RANK()、DENSE_RANK()的区别。简单说，ROW_NUMBER()即使有两个并列第一名，也会给它们编1、2号；RANK()则会给出两个1号，下一个是3号；DENSE_RANK()给出两个1号后，下一个是2号。在实际业务中，如果频道榜单需要并列展示，通常用DENSE_RANK()；如果只需要展示固定数量的视频卡片，用ROW_NUMBER()更合适。这个细节讲出来，面试官会觉得你有自己的判断力。
3.5 用pandas实现同一套逻辑
爱奇艺的面试还有一部分是Python题，尤其是数据分析岗。上面这道SQL题，面试官经常要求你用pandas再实现一遍。核心的pandas思路如下。
先读取数据，三个DataFrame分别叫login_df、play_df、order_df。计算DAU时，先把login_df和play_df的日期、用户ID拼接，然后去重，再按日期分组统计用户数：
import pandas as pd # 假设login_df列名为login_date, user_id # play_df列名为play_date, user_id, video_id, play_duration, channel login_active = login_df[["login_date", "user_id"]].rename(columns={"login_date": "dt"}) play_active = play_df[["play_date", "user_id"]].rename(columns={"play_date": "dt"}) daily_active = pd.concat([login_active, play_active]).drop_duplicates() dau = daily_active.groupby("dt")["user_id"].nunique().reset_index() dau.columns = ["dt", "dau"]人均播放时长要按天先聚合每个用户的总播放时长，再和DAU表合并：
play_daily = play_df.groupby(["play_date", "user_id"])["play_duration"].sum().reset_index() play_daily = play_daily.rename(columns={"play_date": "dt"}) merged = dau.merge(play_daily, on="dt", how="left") merged["play_duration"] = merged["play_duration"].fillna(0) merged["avg_play_duration"] = merged["play_duration"] / merged["dau"]这里fillna(0)对应SQL里的COALESCE，很多人第一次写pandas版本会漏掉，导致平均播放时长全是NaN。这个坑我踩过，面试时也面试官见过我踩，可以主动说出来，展示你处理缺失值的经验。
新用户留存率的pandas实现，思路是用groupby取每个用户的首次活跃日期，再对每个用户判断第1、3、7天是否有活跃记录：
first_active = daily_active.groupby("user_id")["dt"].min().reset_index() first_active.columns = ["user_id", "first_date"] active_dates = daily_active.copy() retained = first_active.merge(active_dates, on="user_id", how="left") retained["day_diff"] = (pd.to_datetime(retained["dt"]) - pd.to_datetime(retained["first_date"])).dt.days result = retained.groupby("first_date").apply( lambda x: pd.Series({ "new_users": x["user_id"].nunique(), "day1_retained": x.loc[x["day_diff"] == 1, "user_id"].nunique(), "day3_retained": x.loc[x["day_diff"] == 3, "user_id"].nunique(), "day7_retained": x.loc[x["day_diff"] == 7, "user_id"].nunique(), }) ).reset_index() result["day1_retention_rate"] = result["day1_retained"] / result["new_users"] result["day3_retention_rate"] = result["day3_retained"] / result["new_users"] result["day7_retention_rate"] = result["day7_retained"] / result["new_users"]这个过程中有一个容易踩雷的操作：直接拿字符串日期做减法，会得到object类型的timedelta，计算day_diff之前一定要先转成datetime类型。这类细节属于“面试中如果被追问能救命”的细节，写代码时主动说出来，会显得非常有实战经验。
3.6 数据清洗与数据集构建：从“能用”到“好用”
面试中还有一个高频场景，就是在你跑完SQL或pandas之后，面试官会追问：如果这些数据有问题，你怎么处理？这个问题实际上是数据清洗和数据集构建的考察。常见的有：字段缺失、异常值（播放时长为负数）、重复记录、类型不一致。
我的标准应对流程是四步：先做数据探查，用df.info()和df.describe()看有没有缺失、异常；再做类型标准化，把日期字符串统一转换成datetime，把金额字段统一成数值型；然后处理重复记录，根据主键去重；最后做质量校验，验证处理前后数据量变化。这个流程不仅适用于面试回答，也是实际做数据分析的通用方法。
比如在pandas里，探查缺失可以用df.isnull().sum()，探查异常值可以用df.describe()看min和max。如果发现播放时长有负数，大概率是埋点上报错误，直接过滤掉还是置为0，取决于业务口径；如果在面试中遇到，建议补充一句“我会先和业务方确认这部分数据的采集逻辑，再决定清洗策略”，这句话会让面试官觉得你不是机械地执行清洗，而是有业务意识。
4. 数据治理、数据质量与备份恢复：送命题的满分答法
4.1 数据质量校验的六个维度
2024年的面试题和几年前最大的不同，是数据治理类问题的比例明显上升。数据岗的面试官会直接问：“你们平台的数据质量怎么保障？”如果你只回答“我们有告警”，基本等于没答。比较完整的答案，是从完整性、准确性、一致性、及时性、唯一性和有效性六个维度来拆。
- 完整性：检查是否有字段缺失，比如播放记录表里video_id为空的比例是否超过阈值；
- 准确性：抽样核对数据是否和业务系统一致，比如订单金额是否等于数据库中的值；
- 一致性：同一指标在不同报表中口径是否统一，比如DAU在数据中台和业务看板中是否一致；
- 及时性：数据延迟是否在可接受范围内，比如每日报表是否在凌晨6点前产出；
- 唯一性：主键是否唯一，比如同一订单ID是否出现重复记录；
- 有效性：数据是否符合业务规则，比如播放时长是否大于0。
回答时最好结合一个实际案例。我当时分享的案例是：在DWD层对订单表做唯一性校验，用SQL跑一个COUNT比COUNT(DISTINCT)的差值，一旦发现差值超过阈值就触发告警。这个方案很简单，但很实用，面试官要的就是这种能落地的东西，而不是停留在理论层面。
4.2 数据备份与恢复：原则比工具更重要
数据备份与恢复是另一个常考话题。面试官问“你们怎么做备份”，不是想听你用哪个工具，而是想听你的备份策略设计思路。
我的面试回答框架是三大原则：异地备份、定期演练、分级分类。异地备份是为了防止单点故障；定期演练是确保备份真的能恢复，而不是备份完就万事大吉；分级分类是指核心业务数据每天备份，一般数据每周备份，日志数据可以只保留汇总结果。
实操层面，MySQL场景下可以用mysqldump做逻辑备份，也可以用Percona XtraBackup做物理备份。面试时可以提一句：逻辑备份适合数据量不大的场景，导出的是SQL文本；物理备份直接拷贝数据文件，恢复速度快，但要求版本一致。如果面试官追问“你们备份恢复过吗”，一定要能讲出一次真实的恢复演练，哪怕是测试环境的小规模演练，也比“我们没试过”强得多。
4.3 元数据、数据血缘与治理调研清单
数据血缘是数据治理里很加分的一个点。面试官问到“数据回溯怎么做”或者“指标口径混乱怎么解决”时，如果你能主动提到数据血缘表的建设思路，会明显拔高你的回答层级。
一个比较基础的方案是：在数仓的调度系统中，每个任务节点都记录上游表名和下游表名，通过解析调度依赖生成血缘关系图。当某个指标输出异常时，顺着血缘关系向上游逐层排查，能快速锁定是哪一层的数据出了问题。这个思路虽然简单，但很多面试者想不到，建议提前准备好。
另外，如果面试官让你“做一个数据治理项目调研方案和清单”，可以按五个板块回答：现状盘点、问题诊断、治理目标、治理举措、评估机制。现状盘点包含数仓分层现状、调度任务数量、核心表清单；问题诊断包含数据质量问题的具体表现和影响范围；治理目标要量化，比如“核心表数据质量规则覆盖率从60%提升到95%”；治理举措包括元数据平台建设、血缘采集、质量规则配置；评估机制包括月度数据质量报告、问题闭环率等指标。这个框架可以直接背下来，现场套用。
4.4 现场模拟：面试官问“怎么评估一个数据集能不能用”
还有一种更具体的问法，和“数据集”“数据标注”“数据增强”这些关键词相关：面试官给你一个数据集，问你怎么判断它能不能用于训练模型。
我当时遇到类似问题时，回答分了三步。第一步是统计分布，看样本量、类别分布、缺失值情况和异常值比例；第二步是检查标注质量，抽取一部分样本人工核对标注是否正确，计算标注一致率；第三步是做简单的基线实验，找一个baseline模型跑一遍，观察训练集和验证集的效果差异。
对于标注类数据集，面试时可以补充一个原则：标注指南的颗粒度直接决定了数据质量。颗粒度太粗，标注员会凭感觉标；颗粒度太细，标注成本和一致性都会出问题。比较好的做法是每次标注任务前先让标注员标20条，验收通过后再正式开工，这样能提前发现对标注规范理解不一致的情况。这类实践细节在数据集、数据标注相关岗位的面试里非常加分。
5. 避坑指南：这些雷区我基本都踩过
5.1 三种典型的“答非所问”
第一种是面试官问指标，你去答技术。比如面试官问你“完播率怎么定义”，你上来就讲Flink的窗口计算，这个问题的重点被完全带偏了。正确顺序是先回答口径定义，再说技术能力如何支撑。
第二种是面试官问场景，你去背结论。比如面试官问你“有哪些数据清洗方法”，你如果只回答“缺失值填充、去重、异常值处理”，这个答案太机械了。更好的做法是现场结合一个场景，比如“播放记录表中有大量播放时长小于1秒的记录，可能是加载失败导致的，我会结合视频ID和上报类型做判断，而不是简单删除”。能把方法和真实场景绑定，面试官才会觉得你是真做过。
第三种是面试官问“为什么”，你答“是什么”。比如问“数仓为什么要分层”，如果你只回答“性能好、易维护”，没有解释清楚“性能好是因为可以减少重复计算，易维护是因为下游对上游屏蔽了复杂性”，这个答案会显得很空。无论什么题，都要习惯性追问自己一层“为什么”，面试官最看重的就是这层思考深度。
5.2 项目复盘不要讲成“流水账”
面试中的项目介绍，我见过太多候选人从头开始讲：某年某月接手了某个项目，需求是什么，做了几张表，上线后效果如何。这个讲法信息密度太低，面试官根本抓不住重点。推荐用STAR法则，但要注意，不是简单罗列Situation、Task、Action、Result，而是把重点放在Action上，尤其是“你做了什么别人不会做的选择”。
举个例子，不要只说“我建了一张用户留存明细表”，要说清楚当时面临的选择：是按设备ID去重还是按用户ID去重，最终选择了哪个，为什么。这样讲30秒的信息量，可能比流水账讲3分钟还多。面试官要的从来不是项目本身多复杂，而是你的决策质量。
5.3 手写代码的细节规范
最后提醒一个面试现场非常实际的问题：手写SQL或Python时，一定要注意代码可读性。面试官看你的代码，会下意识地按团队协作的标准来评价。用WITH而不是嵌套子查询，列名写清楚别名，聚合条件写在CASE WHEN而不是WHERE里，这些细节能反映你日常写代码的习惯。
还有一个小技巧：写完代码后，主动说一遍“这段代码的时间复杂度/数据量级大概是什么水平”。比如“这个SQL在亿级表上跑，如果party分区键能过滤掉90%的数据，性能问题不大”。这会让面试官觉得你有性能意识，而不是只会写出一段对但跑不动的代码。我在面试中栽过几次跟头之后，才总结出这个细节，分享出来是希望后来者少走弯路。
爱奇艺2024年这批数据面试题看下来，我的整体感受是：题目本身并不难，难的是你能不能像一个真正在数据行业做了几年的人那样去思考。SQL和Python是敲门砖，业务指标和数据治理是分水岭，大模型时代的数据加工能力是加分项。如果你在准备面试，建议照着这篇文章的框架把每块内容都亲手练一遍——不要只看，要写，要算，要能用自己的话讲出来。面试不是考试，是你在向未来的同事证明，你是一个能一起扛事的人。
