滴滴校招数据分析岗面试经验——求职精灵（finsight.work）

先说结论：这类题的关键是把「连续」转成「日期减序号」的等差判断，窗口函数只是实现手段。

1. 去重取每日活跃司机：按 driver_id 与 dt 做 DISTINCT，避免同一司机一天多单被重复计数。
2. 排序做差：用 row_number() over (partition by driver_id order by dt) 得到序号 rn，再用 date_sub(dt, rn) 得到分组标识 grp，连续日期会落进同一个 grp。
3. 聚合筛选：group by driver_id, grp having count(1) >= 7，输出满足条件的司机。

如果追问性能，补一句：大表场景先按日期分区裁剪，再在 Hive 或 Spark 中用同样的窗口逻辑，避免全表 shuffle。写不完整也要把三步伪代码说清楚，逻辑比语法更能加分。

按「先证伪数据、再拆指标、后找外因、最后给动作」四步走。

1. 校验数据：看埋点上报、ETL 任务、统计口径是否变更，确认 10% 是真实下跌，而不是延迟或口径调整造成的假信号。
2. 拆解指标：订单量 = 活跃用户数 × 下单率 × 完单率，先定位问题在需求端还是供给端。
3. 维度下钻：按城市、新老客、渠道、时段、车型逐层拆，找出跌幅集中的那一块；供给端再看在线司机数、接单率、应答时长、取消率。
4. 排查外因：天气、节假日、竞品补贴、运力政策、大型活动封路都要过一遍。

收尾给结论和动作：若定位到某城市应答时长上升导致取消率上涨，就先补运力、再调派单半径，并设三天观察窗口验证。强调先定位再动手，不要一上来就给方案。

先定目标和口径，再谈分流与统计，最后说陷阱。

1. 定指标：主指标用 7 日留存或 7 日 GMV，而不是活动期完单量，因为补贴容易带来一次性订单；同时设护栏指标，如客单价、取消率、补贴成本占 GMV 的比例。
2. 定单元与样本：以用户为实验单元按 user_id 哈希分流，对照组保持原策略；先算最小样本量和所需天数，避免中途反复看数据就下结论。
3. 处理干扰：出行存在网络效应，同城实验组可能抢走对照组运力，建议按城市做聚类随机，或选可比城市作对照。
4. 评估：看组间差异是否显著，再做分层分析，确认不是某一类用户拉高了均值。

收尾补一句：实验期间不要同时上线其他运营活动，否则归因会失效。

用 OSM 模型搭主干，再用指标树补细节。

1. 定目标：先确认业务当前最在意什么，是规模增长、匹配效率还是留存与利润，北极星指标随之不同，例如日均完单量或单均毛利。
2. 拆策略：把目标拆成可执行抓手，增长拆成拉新、促活、召回，效率拆成派单时长、应答率、取消率。
3. 落指标：每个策略配两到三个过程指标，拉新看新增注册与首单转化，促活看 DAU 与下单频次，召回看沉默用户激活率与召回成本。
4. 做分层：城市、车型、新老客维度都要能切，避免总量掩盖结构性问题。

收尾补一句：指标体系要配版本管理与口径文档，业务阶段变化后定期下线失效指标，否则看板会越堆越乱、没人再看。

先判断成因，再选处理方式，最后用业务兜底。

1. 异常值识别：箱线图看四分位距、Z-score 看偏离度，同时用业务规则卡边界，例如单次行程超过 500 公里、时长超过 24 小时，基本可判为采集错误。
2. 异常值处理：占比极低且明确错误的直接剔除；连续型字段可用 99 分位盖帽；不确定的先打标保留，不要为了数据好看随意删除。
3. 缺失值判断：先区分随机缺失与非随机缺失，某渠道埋点故障造成的缺失本身就携带信息，应新增「是否缺失」标识，而不是简单填充。
4. 填充方式：数值型用中位数或分组均值，时序数据用前向填充，关键字段缺失宁可回上游修复。

收尾举例：GPS 漂移导致的轨迹点缺失要和地图团队联合排查，不能拍脑袋补一个坐标。

先给定义，再给一个闭环完整的案例。
定义：数据驱动不是「有数据」，而是把决策拆成可验证的假设，用数据判断方向对不对、效果有多大，再决定加码还是回撤。
案例按五步讲：

1. 发现问题：某校园活动报名转化低于预期，漏斗显示落地页到表单这一步流失最严重。
2. 提出假设：表单字段过多、移动端首屏加载慢、文案没讲清权益，是三个可能原因。
3. 数据验证：拆分设备与来源渠道对比，发现移动端流失率是桌面端的两倍，进一步定位到首屏加载超过三秒。
4. 推动落地：压缩图片、延后加载非关键模块，把表单字段从八项减到四项。
5. 效果复盘：改版后转化提升，用同周期同渠道对照，排除活动热度自然变化的影响。

收尾强调：案例规模不重要，有假设、有对照、有结论才重要。

分「预测—匹配—定价」三层讲，每层都落到指标。

1. 供需预测：用历史订单、天气、节假日、大型活动做分区城的单量预测，提前把运力往高需求区域引导，降低乘客等待时长。
2. 实时匹配：对比就近派单与全局最优派单的差异，观察接单距离、应答率、取消率、完单时长四个指标，找到体验与效率的平衡点；同时分析司机接单意愿，不能只看乘客侧。
3. 动态定价：用数据确定调价触发阈值与幅度，验证价格信号是否真的把司机吸引过来，同时监控乘客侧的价格敏感与流失。

收尾给判断标准：匹配效率的提升要同时满足乘客等待变短、司机空驶变少、平台补贴不增，只看单一指标容易做出假优化。能说出指标的相互关系，比罗列名词更有说服力。

先给使用场景，再讲核心操作，最后说优化。

1. pandas：读取与清洗用 read_csv、dropna、fillna、astype；筛选聚合用 loc、iloc、groupby 加 agg、pivot_table；多表合并要区分 merge 与 concat 的适用场景；时间序列用 to_datetime、resample、shift 做同比环比。
2. numpy：用向量化运算替代循环，mean、std、percentile 做描述统计，布尔索引做条件筛选，广播机制处理不同形状的数组。
3. 优化经验：低基数字段转 category 降内存，避免逐行 apply 优先用内置函数，大文件分块读取，能在库内聚合就不要全量拉到本地。

收尾说清边界：工具只是手段，面试官更想听用它解决过什么问题，准备一个从取数、清洗到出结论的完整例子，比背 API 列表有效得多。

先拆供需，再看体验与竞品，最后落到可验证的结论。

1. 需求端：看拼车渗透率、用户画像与使用场景，是价格敏感的通勤人群还是时间充裕的休闲出行；再看价格优势是否被感知，等待时长是否劝退。
2. 供给端：看开通拼车功能的司机占比、接拼车单的意愿、拼成率与绕路时长，以及拼车单对司机时薪的影响。司机不愿意接，需求再旺也增长不起来。
3. 体验链路：从下单、等待、拼成、绕路到支付逐段看流失，找出最痛的一环。
4. 竞品对标：对比同类产品的价格、等待时长、拼成率与覆盖城市。

收尾给判断：若数据显示价格优势不明显且绕路时长偏高，优先做路线算法优化与拼车专属补贴，先小范围实验验证再推广，不要一上来就全量补贴。

先讲分工，再讲协作机制，最后讲分析师自身的定位。

1. 与算法工程师：分析师负责定义问题、拆解指标、设计评估方案，算法负责特征、模型与调优。简单说，分析师回答「这个方向值不值得做、做完效果如何」，算法回答「怎么做得更好」。
2. 与产品经理：产品提出业务假设与方案，分析师用数据验证或证伪，把模糊的「感觉不好用」翻译成可测的漏斗和指标。
3. 协作机制：需求评审时就把口径、样本、评估周期定下来，避免结论出来才发现口径不一致；重要结论要能复现，指标口径写成文档。

收尾给判断标准：好的分析师不是被动接需求，而是能主动提出「这个功能该用什么指标验收」，在项目里承担数据侧的 owner 责任，这也是数据合伙人区别于取数工具人的地方。