小满春招数据分析岗笔试复盘：从SQL到业务题的完整拆解

参加了2023年小满春招数据分析岗的第二批笔试过去一个多月了有些题目细节已经开始模糊但这次笔试给我的整体冲击感反而越来越清晰。市面上关于“数据分析面经”“数据分析面试题”的总结很多但大多是零散的知识点清单真正讲清楚“考场上一道题该怎么下笔、时间怎么分配、答案写到什么程度才算合格”的内容很少。成绩出来之后我复盘了很久也对比了几个同期进面试的朋友的答案发现有些丢分点其实可以提前规避。这篇就把我的完整经历、答题思路、以及考后复盘整理出来给后续准备数据分析岗笔试的同学一个参考。先说清楚背景这里说的“小满”是一家以线上信贷和金融科技为主营方向的公司数据分析岗笔试和互联网大厂的数据分析笔试有明显区别——它更看重你对金融业务的理解而不只是SQL和Python写得溜不溜。笔试全程在线有摄像头监控时长三个小时题目量不大但每一道都需要写不少字。整体给人的感觉是不是考你会不会做这道题而是考你能不能像一个在职数据分析师一样去回答问题。1. 先说清楚这件事二批笔试到底考什么1.1 关于“小满”和这批笔试的背景春招的分析岗通常分两批笔试一批在一月底二月初二批在二月底左右。我参加的是二批按惯性思维会觉得二批是“补录”“捡漏”但实际考下来发现完全不是这么回事。二批的题目比一批更侧重实操甚至有几道题明显是从在职员工的日常工作中改编出来的。后来我加了几个也在准备春招的群对比之后发现一批和二批的重合度不高二批整体更“硬核”尤其是SQL部分难度明显上了一个台阶。在投递之前我研究过这家公司的业务模式。它主要做的是小额信贷、消费分期和智能风控所以数据分析岗位围绕的核心指标不外乎通过率、逾期率、复借率、授信额度使用率、件均金额、风险损失这类的业务指标。准备笔试前我建议你一定要去把这类公司的岗位JD重新读三遍JD里如果出现“具备信贷业务分析经验优先”“熟悉风险指标体系”这类描述说明笔试里大概率会有风控场景的题目。1.2 三个小时、一张线上试卷的整体印象整张试卷可以分成三类题型客观选择题、编程与SQL题、业务方案设计题。选择题大概15道覆盖面很广包括概率论、统计学基础、常见的机器学习概念、SQL语法细节以及少量业务理解题。编程题是两道一道是Python一道是SQL需要在在线编辑器里直接写代码跑通并提交。业务设计题是三大道每道下面还有两三个小问需要写比较长的文字方案。三个小时听起来充裕但实际写起来非常紧凑。选择题我用了大概40分钟两道编程题用了一个小时剩下80分钟全花在三道业务题上。这个节奏其实有点被动——我的业务题写得偏仓促后面复盘时发现有两处关键点没有展开这大概率是最终分数不够理想的主要原因之一。所以第一点建议是考前一定要模拟“三个小时连续作答”的完整流程不要只刷知识点。很多人在收到笔试链接之后习惯性先看一遍题目难度然后挑软柿子捏这种策略在时间紧张的时候很容易翻车。我的做法是拿到试卷先花5分钟把全部题目扫一遍标出每道题预计耗时再决定作答顺序这一点在后面细说。2. 拿分顺序我拿到试卷后先做的是业务题还是代码题2.1 我的作答顺序和理由笔试开始后我没有按题号顺序从选择题开始做而是先翻到了最后一道业务题。原因很简单业务方案题是按点给分的而且不需要完全正确只要有结构、有逻辑、有数据支撑就能拿到大部分分数。但是选择题和编程题不一样选择题的答案是硬性的不确定就是不确定编程题跑不出来就是零分。头脑清醒的时候先解决“能拿分但需要思考”的题比在选择题里死磕一道概率题效率高得多。当时我先把三道业务题完整看了一遍在草稿纸上快速写下每道题的回答框架然后才开始做选择题。这样做的好处是在做选择题的过程中大脑其实在后台处理业务题的思路等到正式写业务题时很多逻辑已经自动理顺了。实践下来这个策略效果不错。三道业务题我都写到了比较完整的程度而不是像以前那样因为时间不够草草收尾。2.2 时间分配可以抄作业的版本以下是我本次笔试的实际时间分配另一个朋友也采用了类似节奏最后他进了二面。大家可以做一个参考总时长180分钟选择题建议控制在35到40分钟每道题如果超过2分钟还没头绪先标记跳过最后再回来蒙两道编程题建议控制在60到70分钟先做自己更有把握的那道业务题预留70到80分钟每道题写900字左右的分析框架宁可字写得紧凑一些也一定要把要点铺开。题型题量建议用时备注客观选择题15道35-40分钟不会的先标记不恋战Python编程1道35分钟先跑通再优化SQL编程1道30分钟注意字段口径和边缘样例业务方案题3道70-80分钟每题留出5分钟检查这里特别提醒一点在线笔试平台的代码编辑器通常没有本地IDE那么好用没有自动补全、没有报错提示有些有有些没有而且不同平台对SQL语法的支持差异很大。建议考前一定要去对应平台做一套模拟题至少熟悉一下代码编辑界面、运行按钮的位置以及输入输出的格式避免在考场上浪费时间去阅读使用说明。3. 业务场景题答案不能只有“分析思路”还要有“业务动作”3.1 一道典型的用户流失分析题我是这样拆解的这次笔试的第一道业务题大意是“某信贷产品的月活跃用户数连续三个月下降但整体注册量没有明显减少请给出你的分析思路和落地动作。”这类题目在数据分析面试题里太常见了市面上流传的模板基本都是“拆分子群、对比同期、看留存漏斗”这一套。但这次我吸取了过往面试失败的教训把答案写得更贴近业务动作。我的回答分成四层第一层是定义问题。我写明了“月活跃用户数”在信贷场景里应该拆成“登录用户数”“申请用户数”“放款用户数”“复借用户数”几个层次首先需要确定下降最明显的是哪个环节不同环节对应的分析策略完全不同。如果下降主要发生在登录环节那是触达和留存的问题如果下降发生在申请环节可能是产品流程或通过率出了变化如果是复借下降那要重点排查客群结构和风险策略的调整。第二层是拆解维度。从客群维度新客、次新客、老客、渠道维度各大应用市场、信息流、自然流量、产品维度不同额度段、不同利率档、不同期限、地域维度来交叉分析定位流失是全局性的还是局部性的。第三层是建立假设并验证。比如假设“三个月前风控策略收紧导致次新客的通过率降低申请意愿下降”那么应该用通过率数据和用户调研数据交叉验证再比如假设“竞品在同时期上线了更低利率的产品”则需要拉取行业数据和竞品监控信息来佐证。第四层是落地动作。我写了两点短期动作是圈选近90天未复借但在历史上有良好还款记录的客群做定向的利率优惠和还款券召回并通过AB实验验证召回效果长期动作是搭建用户流失预警监控体系按月追踪关键转化路径的漏斗衰减设置预警阈值。这题我事后对比了一个进了下一轮的同学的答案他说他额外补充了“成本收益测算”——召回活动的预计成本、拉动的放款规模和风险损失之间的平衡。这一点我当时完全没想起来而这恰恰是金融数据分析区别于普通互联网分析的关键。只讲分析思路是不够的分析完之后这个动作值不值得做、投入产出比如何才是业务决策层真正关注的东西。3.2 风控语境里的“异动指标排查”怎么答才像做过的人第二道业务题更是纯风控场景。题目大意是“某产品近一周的逾期率M1从2.5%上升到3.2%你会如何排查原因”这个题分数占比最高三个小问层层递进。第一问是排查思路第二问是需要哪些数据第三问是如果发现是新激活渠道所致你会怎么做。排查思路我的答案是分“真假变化”和“结构变化”两条线。真假变化指的是首先确认指标计算口径是否调整过比如逾期定义从“到期未还”改成了“到期未还且催收失败”或者数据入库链路出现重复计算、字段映射错误这些都会导致指标“假性上升”。然后是结构变化排除了口径和数据问题之后再看客群结构是否发生偏移比如新渠道进来的客群年龄、收入、地域分布和历史客群明显不同风险天然偏高或者风控策略近期调参通过率上升边际客群资信水平下降。需要的核心数据我列了这么几类逾期明细表客户ID、逾期天数、剩余本金、历史还款行为、申请记录表渠道来源、申请时间、审批结果、放款记录表放款时间、产品类型、利率、期限、催收记录表催收覆盖状态、承诺还款情况以及渠道维度的每日新增客户画像数据。这几张表的数据字段、关联键、口径说明我在答案里都做了标注这能让阅卷人看出你不是背模板是真的处理过这些数据。第三问“确认是新渠道所致你会怎么做”很多人会答“调整渠道策略、停止投放”。我写得稍微细了一些先测算该渠道客群的坏账贡献度如果坏账贡献度显著高于其他渠道那么考虑暂停或限制该渠道流量同时对历史已通过客户做名单回溯根据风险等级采取不同的贷后策略如果坏账贡献度不算高只是逾期暴露得更早则不一定要停量而是调整审批策略比如下调该渠道的通过率上限、增加人工审核环节、提高首借额度管控等。这样的答案才不会显得“一刀切”也更符合实际业务中“既要控制风险又要兼顾规模”的诉求。3.3 这类题阅卷人想看到的三层结构做完这批题我发现业务题的答题结构其实有规律可循。不管题目怎么变化阅卷人期望看到的都是三层结构定义清楚问题 → 拆解到可执行的分析动作 → 给出有业务价值的后续动作。如果把“定义清楚问题”比作医生问诊时的“主诉确认”拆解就是“检查项”落地动作就是“处方”。只写检查项说明你只懂技术不懂业务只写处方说明你缺乏过程思考。具体到写作层面每一大题都要做到“先概述、后细节”。开头用两三句话给出整体思路然后用分点的方式展开细节最后用一小段强调“分析完成后如何决策”。不要把业务题当成论文来写写成密密麻麻一整段会严重影响阅卷体验。我的习惯是每个小问控制在250到300字逻辑链条简单清晰不堆形容词。4. SQL与取数题字段口径是笔试中的隐藏扣分点4.1 实际遇到的SQL题型与考点分布SQL编程题我印象很深因为和平时在牛客上刷的题风格不一样。牛客上的SQL题大多是传统的“学生选课”“员工工资”类但这次笔试给的是一张用户借款记录表和一张还款流水表要求统计“每个客户在2022年内的首次借款日期、首次放款日期、以及首次借款后90天内的还款总额”。题目听起来不复杂但藏着好几个坑。考点主要集中在三块多表关联的去重问题、日期口径的边界处理、以及窗口函数的使用。多表关联去重是很多人翻车的地方。借款表和还款流水表是一对多关系如果直接join一张借款记录会被多条还款记录撑开再用SUM汇总时金额就会被重复计算。正确做法是先对还款流水表按借据维度做聚合再用有唯一键的明细表和聚合结果关联。日期边界处理也容易出问题。“首次借款后90天内”这个窗口有人用BETWEEN DATE_ADD(first_loan_date, INTERVAL 90 DAY)但实际应该看清题目要求是包含第90天还是不包含是自然日还是工作日。这些都是阅卷时能够通过测试用例直接判定的点边界条件错了就是零分。4.2 窗口函数、去重口径和空值处理的细节这道题里我用了ROW_NUMBER()来取每个客户的首笔借款记录。具体思路是先用窗口函数对借款表按客户ID分组、按借款申请日期排序筛选出rn 1的客户首借记录然后把还款流水表先按借据ID聚合出“90天内还款总额”最后关联两个结果集。这里最关键的技巧是**“先聚合、后关联”**这能从根本上避免一对多膨胀。另一个细节是空值处理。借款表里有些客户的放款日期为空说明申请通过但最终没放款。这种情况下“首次放款日期”应该怎么处理题目没有明确说。我在代码里用了COALESCE把空值统一处理成1900-01-01并且标注了注释说明这部分客户会在后续分析中单独剔除。这种思路即使不是最优解也能让阅卷人看到你注意到了数据质量问题比默默忽略空值要强很多。4.3 笔试用工具DBeaver这类客户端的体验有一点值得拿出来说这次笔试的SQL编辑器本身没有提供数据库连接信息只能通过在线网页编写代码并模拟运行。但在实际工作里我习惯用DBeaver这类数据库客户端来跑SQL它可以直连各种数据库、查看表结构、快速预览数据。建议平时练习时就用DBeaver接一个本地数据库比如MySQL或PostgreSQL来刷题不要只依赖在线平台。原因很简单在线平台通常只告诉你“通过了几个用例”但不会告诉你“没通过的用例是什么”而DBeaver这类可视化工具可以让你直接查看中间结果一旦遇到“明明逻辑对了但结果不对”的情况你可以手把手把每步查询结果导出来排查。这和在IDE里调试代码是一个道理。另外DBeaver有一个很实用的功能就是可以给SQL写变量和参数这在处理“不同周期、不同口径”的数据集时非常方便。笔试时虽然用不了但在日常练习中建立这种“先探查、后查询”的习惯对培养取数思路的帮助很大。面试官问到“你平时用什么工具取数”时你能说出这类客户端的实际使用细节也会显得更专业。5. Python与统计建模不考手推公式但考“会不会用”5.1 统计学题假设检验和AB实验的口径选择题里统计学部分占比不小大约有5道。但考察方式并不是“写出t分布的公式”而是给你一段业务描述然后问你在某个样本量下是否应该拒绝原假设、p值是多少、或者AB实验的最小样本量怎么估算。这类题目对统计学的基本概念要求比较扎实。有一道题我印象很深大意是“某团队做了一个新用户授信额度策略的AB实验实验组和对照组各5000人实验组平均授信额度比对照组高5%p0.03是否说明应该全量上线”选项中最容易踩坑的是“应该全量上线因为p0.05。正确答案应该是”需要看效应量和业务成本不能仅凭p值判断“。这个题考察的就是统计学假设检验的误用——显著性不等于实际重要性。还有一道题和多重比较有关问“在一个策略实验中同时对比了10个不同指标每个指标单独看p值都小于0.05但整体结论是否可信”。答案是“需要考虑多重比较带来的假阳性问题”。这类题在校招笔试里越来越常出现说明企业不只是想要会调包的人更想要能理解统计推断逻辑的人。5.2 Python编程题从数据清洗到无监督聚类两道编程题中Python那道做题要求是处理一个CSV文件文件里有用户的借款金额、借款期限、年收入、历史逾期次数、所在城市等字段任务分三步第一是数据清洗处理缺失值和异常值第二是做特征工程把城市映射成数值编码第三是使用无监督学习KMeans对用户进行分群输出每个群的平均借款金额和逾期率。这道题做完之后我的最大感受是它考的其实不只是你能不能写出KMeans代码而是你在写代码之前有没有先做数据探查。我用了df.info()和df.describe()先查看了缺失情况和分布发现借款金额字段有少量负值这明显是异常数据在清洗时直接过滤掉了。年收入字段有大约3%的缺失我用中位数填充因为收入通常右偏用中位数比用均值更稳。KMeans的部分我选择了k4但没有只跑一个模型就提交。我做了两步验证画了不同k值下的簇内误差平方和曲线肘部图虽然笔试卷面上不能提交图片但我把心路历程写在注释里了——这种“过程性注释”会让阅卷人觉得你平时就是这么干活的而不是背了段代码。分群之后我还统计了每个群的逾期率差异发现其中一群的逾期率明显偏高结合年收入最低、历史逾期次数最高的特征我把这个群命名为“高风险资金紧张人群”。这种输出方式已经贴近实际业务里的客群分层。5.3 模型评估为什么不能只看AUC选择题里有一道和模型评估相关的题目问的是“在信贷风控模型中AUC为0.85KS为0.35模型上线后你还会关注哪些指标”这道题没有标准答案但考察的核心是是否理解风控模型的价值不只是区分度还有校准度和稳定性。我当时选了“PSI特征稳定性”“预期损失EL”“坏样本捕获率”等几个选项。事后和朋友讨论大家一致认为这道题想引导的是在风控场景里一个模型即使KS很高但如果某个月份特征分布发生漂移PSI过高线上效果也会急剧恶化如果模型的概率校准不准那么用预测概率去做额度定价和损失计提就会出问题。同时“坏样本捕获率”比AUC更直观——在最坏的10%客群里抓到多少坏账直接决定了催收资源投放的效率。6. 复盘批改三个我考后才想明白的丢分点6.1 业务题回答缺少“成本收益”视角这是我在这次笔试里最大的遗憾。三道业务题里我至少有两道都给出了“怎么做分析”“怎么定位原因”“怎么调整策略”的思路但几乎没有回答“这个动作预计花多少钱、带来多少收益”。站在业务方视角数据分析师的价值不在于“发现问题”而在于“帮业务做决策”决策必然涉及成本收益。如果在一道用户流失分析题里你提到“可以做一场针对流失用户的利率优惠召回活动”那么紧接着就应该补充“预计触达X万人假设响应率Y%人均让利Z元预计拉动放款规模A亿元测算的获客成本在B元以内”这才算完整。6.2 SQL没有考虑数据倾斜和性能我写的SQL逻辑是没问题的但存在一个隐藏扣分点对历史全量还款流水表直接做聚合没有在WHERE里加日期过滤条件。笔试的数据量不大能跑通但在实际工作中这种表动辄上亿行不加分区过滤会引发严重的数据倾斜和超时。正确的做法应该是先根据客户首借日期生成“90天内”的时间窗口再在关联还款流水表时用BETWEEN first_loan_date AND DATE_ADD(first_loan_date, INTERVAL 90 DAY)去限定扫描范围。这个教训让我意识到笔试的隐含评分标准里很重要的一条是“你的代码到了生产环境能不能跑”。6.3 对数据清洗的“业务定义”重视不够Python那道题里数据清洗部分我只处理了明显的缺失值和异常值。但还是漏了一个点借款金额字段正负号的问题我处理了却没有进一步思考“借款人年收入为0但借款金额很高”的样本是否合理。这类样本可能是虚假申请或数据录入错误应该在特征工程前剔除或标记。这个问题的本质是数据清洗不能只理解技术上的“缺失”“异常”还要结合业务规则去定义什么数据在业务上是不合理的。现在很多热门的分析流程里“数据清洗”已经被提升到一个很高的位置——不是简单dropna和fillna而是要理解字段背后的业务含义、口径变化和来源链路。笔试里能不能体现这种意识恰恰是拿高分和拿及格分的分水岭。考完之后我又花了两天时间把这次笔试的错题和盲点重新整理了一遍。我的整体感受是这家公司的数据分析笔试没有跑偏它考的确实是这个岗位日常要用的技能——业务理解、取数、分析建模、做出业务建议。虽然今年的结果如何还不确定但至少这次笔试让我知道了准备数据分析笔试不能只背面试题更重要的是把每个知识点放进业务场景里重新理解一遍。如果你也正在准备类似岗位的笔试希望我的这些复盘能帮你少走弯路。