银行数据岗笔试实战：招行信用卡中心SQL、统计与案例分析全解析

招商银行信用卡中心2018秋招数据方向笔试题这份题目放在今天来看依然有不少值得琢磨的地方。我当时参加的是2018年秋季那一批整体感受是题量大、覆盖面广、金融业务场景多和纯粹互联网公司的数据岗笔试风格有明显差异。如果你是准备银行系数据岗位或者对金融场景下的数据分析感兴趣这篇内容可以帮你省掉不少摸索的时间。1. 笔试整体设计与筛选逻辑1.1 招行信用卡中心数据岗考什么先聊点实际的银行系数据岗和互联网大厂的数据岗笔试风格差别真的很大。互联网公司喜欢考算法题、机器学习推导、AB测试设计招行信用卡中心这场笔试更看重三样东西统计学基础、SQL功力、业务敏感度。整张卷子大概是120分钟题型涵盖单选、多选、SQL大题和案例分析题。选择题部分有不少统计学和概率论的内容难度大约在理工科本科中上水平比考研数学一里的概率论部分略简单一些但比一般学校的期末考试要难。SQL部分给了两张表要求完成若干查询考察点包括聚合、关联、窗口函数、去重逻辑难度属于中等偏上。案例分析题是整张卷子的重头戏也是很多候选人觉得最没底的题目。题目通常会给你一个业务场景比如某个月的信用卡活跃用户数出现了明显下滑或者某类分期产品的转化率异常低让你分析可能的原因并给出数据监控方案。这类题目没有标准答案但很能拉开差距。1.2 笔试在整条招聘链路中的定位商业银行的校园招聘流程通常是网申、笔试、面试通常两到三轮、体检、发offer。笔试的作用是粗筛把不具备基本数据能力的候选人拦在门外。信用卡中心的数据岗日常要做报表取数、指标体系搭建、用户分层、策略效果评估等工作这些都需要候选人具备扎实的SQL和统计基础。笔试通过率各个批次不太一样网申阶段会筛掉一批学校和专业背景不匹配的候选人笔试环节通过率大致在20%到30%之间。也就是说100个人参加笔试大约20到30人能够进入面试环节。面试环节还会问项目经历和数据分析思路所以笔试只是第一道坎别因为笔试过了就以为稳了。2. 核心知识板块拆解与准备要点2.1 统计学与概率论基本功中的基本功这一板块大概占了卷面分数的三成左右考察内容集中在以下几个方面描述统计部分会考均值、中位数、众数的关系和适用场景比如一组右偏分布的收入数据用哪个指标代表集中趋势更合理。答案是中位数因为均值受极端值影响太大这个知识点在业务分析中非常常用。概率论部分常考条件概率和贝叶斯公式题目通常披着业务外衣。比如某信用卡产品的逾期率为2%风控模型在逾期用户中的识别准确率为90%在非逾期用户中有5%的误报率问模型判定为逾期风险的用户中真正会逾期的概率是多少。这就是典型的贝叶斯公式应用题算下来大概是26.8%左右。推断统计部分需要掌握假设检验的基本流程、p值的含义、置信区间的解读。这里有个坑是不少人容易把p值理解为“原假设成立的概率”这是不严谨的。p值是在原假设成立的前提下观察到当前样本结果或更极端结果的概率和“原假设成立的概率”是两码事。分布部分重点掌握正态分布、二项分布、泊松分布。信用卡交易量的建模常常会用到泊松分布来描述一段时间内的交易笔数这个需要理解分布的特征和适用条件。2.2 SQL能力直接决定笔试结果SQL大题通常有3到4小问给定两张业务表要求写出查询语句。信用卡中心常见的两张表是用户信息表和交易流水表或者订单表和还款记录表。考察的核心语法包括聚合函数group by是必考的写过交易流水分析的人都知道计算日均交易额、月均消费笔数这类指标离不开聚合。这里面容易出现的问题是group by的字段和select的字段不匹配写SQL时心里要有一张虚拟表的执行顺序from、where、group by、having、select、order by、limit。Join相关的考察比较灵活包括inner join、left join、right join的区别和实际应用场景。信用卡业务里有一类典型场景是计算“已注册但从未发生过交易的用户数”用left join加is null条件就能搞定。如果还不熟悉join的执行逻辑建议自己在本地装个MySQL多练练。窗口函数的出现频率很高。比如计算每个用户最近三次消费金额、按时间排序后计算累计消费金额、对用户分组后取每组消费最高的记录这些都是窗口函数的典型应用题。在2018年的时候很多人对窗口函数还不熟悉如果你现在准备笔试一定要把row_number、rank、dense_rank、sum over、lag这几种用法练熟。去重逻辑也是一道常见的实践题distinct和group by的区别要了然于胸。distinct适合对整行去重group by更灵活可以配合聚合函数使用。2.3 业务案例分析最能拉开差距的题型案例分析题看起来主观实际上是有章法的。拿到一道业务分析题可以先按“定义问题、拆解指标、定位原因、给出建议”这四步走。先说定义问题。如果题目说“某月活跃用户数下降了10%”先别急着分析原因要搞清楚这个活跃用户数是怎么定义的是月活还是日活统计口径有没有变化。很多业务指标的异常波动最后追溯下来是口径变化导致的比如之前统计的是激活用户后来改成统计有过消费行为的用户数字自然就变了。拆解指标这一步可以把“活跃用户数”拆成“新增活跃用户”和“存量活跃用户”存量活跃用户又可以拆成“上月留存用户中的活跃部分”和“非上月用户中重新激活的部分”。这样一层层拆下去定位原因的范围就清晰多了。定位原因可以从内部和外部两个维度去思考。内部分析渠道投放量是否下降、产品功能是否有变动、优惠活动是否结束外部看竞品表现、季节性因素、整体市场环境。这些分析角度即使没有真实数据也需要在答题时体现出来。最后给出的建议要具体可落地。举个面试中常见的例子如果分析发现活跃用户下降主要来自某个渠道的新客质量变差可以建议对该渠道的获客ROI进行监控调整投放策略如果发现是老用户的高频消费群体消费频次下降就要考虑做流失预警和召回策略。给出建议时要注意优先级排序按照“影响面大、见效快、成本可控”的标准挑选最关键的1到2条作为主建议。3. 实操过程与完整解题思路演示3.1 统计概率题一道真题的完整拆解我当时印象最深的一道题目大致意思是一个信用卡营销活动目标客户的响应率为10%。营销团队用了一个响应模型在预测为高响应概率的客户群体中真实响应率为30%。问模型提升度Lift是多少。这道题看起来简单但很多人容易在概念上绕晕。提升度等于模型预测为正样本的群体中真实正样本的比例除以总体中正样本的比例。代入数据30%除以10%等于3所以提升度是3。含义是用模型筛选后的客群响应密度是随机抽取客群的3倍营销ROI大幅提升。类似的考法可能会换一种包装模型预测为高响应的人群有1000人其中实际响应300人随机抽样1000人中平均响应100人问提升度。依然是3。理解提升度的本质后怎么变着花样出题都不用慌。3.2 SQL题从读题到写出的完整过程假设题目给出这样两张表用户表user包含user_id、register_date、channel交易表transaction包含trans_id、user_id、trans_amount、trans_date。第一个问题通常是统计每个注册渠道的用户数按注册人数降序排列。标准的写法是SELECT channel, COUNT(*) AS user_cnt FROM user GROUP BY channel ORDER BY user_cnt DESC;第二问常见的是找出注册后7天内产生过交易的用户的注册渠道分布。这里要注意“注册后7天内”这个窗口的计算不能把时间维度搞错。写法是这样的SELECT u.channel, COUNT(DISTINCT u.user_id) AS active_user_cnt FROM user u LEFT JOIN transaction t ON u.user_id t.user_id AND t.trans_date BETWEEN u.register_date AND DATE_ADD(u.register_date, INTERVAL 7 DAY) WHERE t.trans_id IS NOT NULL GROUP BY u.channel;第三问是窗口函数统计每个用户最近一笔交易的金额和交易时间。正确的写法是用row_number或rank做窗口排序然后取排名为1的记录。SELECT user_id, trans_amount, trans_date FROM ( SELECT user_id, trans_amount, trans_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY trans_date DESC) AS rn FROM transaction ) t WHERE rn 1;这一问的隐蔽考点是如果用户同一天发生多笔交易要用trans_id做二级排序确保取到的是真正“最近一笔”而不是同一批次中的任意一条。在这个基础上可以加一个ORDER BY trans_date DESC, trans_id DESC避免随意排序带来的误差。3.3 综合案例题的系统分析示范案例分析题常用的是“信用卡月度账单分期转化率下降”这类场景。如果遇到这种题可以这样组织答题结构。定义问题账单分期转化率指完成账单分期的用户数除以账单已出账的用户数。先确认统计口径无异常变化。拆解指标将转化率拆成三部分——看到分活动入口的用户比例、点击进入活动页面的用户比例、在活动页面完成申请的用户比例。哪个环节下降最多重点分析哪个环节。定位原因如果发现点击进入的比例大幅下降可能要关注活动页面的曝光量、入口位置是否被调整、推广素材是否过期如果申请完成比例下降需要检查申请流程是否出现bug、风控策略是否收紧导致通过率降低。给出建议建立漏斗监控看板每日输出各环节转化率针对异常环节做归因分析同时搭建AB测试能力对活动页面改版和小流量实验提供数据支持。这样回答下来既体现了分析框架又展示了业务落地能力面试官能看到你具备完整的数据分析思维。4. 常见问题与备考避坑经验4.1 笔试中的高频失误失误集中在以下几类SQL中on和where混用——left join时如果对右表字段加了where条件会把left join变成inner join这是最常见的坑统计题中忽略了独立性问题比如直接把两个事件独立相乘没有考虑实际业务含义案例分析只写了原因没给建议分析再全面也只是半成品时间分配不合理过多的选择题研究导致大题没时间写。这套笔试题量不小建议先快速过一遍选择题把不确定的题目标记好优先保障SQL和案例题有充足的作答时间。4.2 更高效的备考路径备考路径按优先级安排先系统性刷SQL题LeetCode的数据库板块和牛客网的SQL专项都可以重点是吃透group by、join、窗口函数再复习统计学基础梳理假设检验、置信区间、贝叶斯公式的核心概念和典型题型然后搜集银行系数据岗的笔试面经了解案例题出题风格和答题框架最后做几次限时模拟把握做题节奏。简历上如果项目经历突出可以多准备几个和金融业务相关的数据分析case面试时会更有优势。5. 数据岗位后续的职场观察笔试只是进入这个行业的第一步上岸后你会发现金融数据岗实际上和我们想象中不太一样。银行系的数据岗和互联网公司有个明显区别这里不只是做数据的挖掘和分析还要面对大量的报表需求、监管报送、业务部门临时取数和口径对齐。每天的工作常常在“写SQL取数”和“做分析报告”之间切换纯算法模型类的工作占比没有互联网公司那么高。我身边不少同事从互联网跳到银行系起初都不太适应这种节奏。但稳定下来之后会发现银行系的好处在于业务场景稳定数据资产丰富用户行为链条完整消费、分期、取现、积分、权益各个模块都有大量分析需求可以做深。而且金融行业对数据合规的要求极高在这里养成的数据安全习惯和严谨的分析态度是通用的职业素养。想进这一行的人建议在校期间就多接触金融业务相关的数据场景哪怕是通过公开的数据集做信用卡用户行为分析也比闷头刷算法题更贴近实际工作内容。如果能在笔试案例题中展现出对金融业务的理解深度你在候选人中的优势会非常明显。另外多说一句笔试通过后面试环节会有一段业务面喜欢问“如果让你搭建信用卡用户流失预警模型你会怎么设计”。这类问题考察的不只是模型方法更是对业务定义、特征体系、评估指标的整体思考。建议平时多关注行业里关于用户生命周期管理的案例和分析文章积累一些业务感觉。