2023年秋招季我投了知乎的数据分析岗笔试做完第一感觉是题量不大但每道题都踩在业务痛点上。和很多互联网大厂那种“海量客观题两道SQL”的套路不同知乎这套笔试卷子对数据分析思维的考察比重相当高特别是案例题非常贴合内容社区的业务场景。当时我在牛客和知乎上翻了大量数据分析面经、数据分析面试题发现大家普遍焦虑的点是“不知道考点范围”和“不知道怎么组织案例题答案”。这篇文章我把整场笔试完整复盘一遍从题型分布、考点拆解到答题思路、踩坑教训都写清楚给后面准备数据分析岗笔试的同学一个可参考的坐标系。1. 笔试前的信息侦察岗位JD解读与知识地图拿到笔试邀请后我做的第一件事不是埋头刷题而是把知乎数据分析岗的JD反复读了三遍。这一步非常关键因为笔试内容基本是JD的映射——JD里写了什么能力要求试卷上就会围绕什么出题。1.1 从招聘JD反推考点数据分析岗的能力模型我印象很深知乎数据分析岗的JD里反复出现几个关键词指标体系搭建、异动分析、AB实验、用户增长、内容推荐。这些关键词基本就圈定了笔试的考点范围。以我拆解JD的经验数据分析岗的能力模型可以分成四层第一层是工具能力包括SQL、Python、Excel这是底线要求笔试一定会考而且考得比较细。第二层是统计学基础假设检验、置信区间、回归分析、因果推断这些是数据分析师做判断的理论依据。第三层是业务理解也就是你能不能把一个业务问题翻译成数据问题再翻译成可落地的策略。第四层是沟通表达笔试里通常通过案例题来考察看你能不能结构化地把分析思路写清楚。对照这个能力模型我给自己列了一张知识清单把每一层的核心知识点都过了一遍。工具能力我重点复习了窗口函数和pandas的数据清洗操作统计学基础我把假设检验和AB实验的流程从头理了一遍业务理解这块我专门去看了知乎的社区产品形态、创作者生态、内容分发机制相关的公开资料。1.2 知乎笔试的差异化特征内容社区的“业务感”和微众银行这类金融数据岗的笔试相比知乎的笔试题有一个非常明显的差异金融数据分析岗的题目更侧重风控模型、反欺诈规则这类强逻辑、强数学的考点而内容社区的数据分析岗考的是对内容生态的理解。什么叫“内容生态”简单说就是知乎这个平台上有创作者、有读者、有内容、有互动这四个要素互相影响。比如创作者发了一篇高质量回答读者点了赞同赞同数多了内容进入推荐池更多读者看到又带来更多互动——这是一个正向循环。笔试的案例题就是基于这类场景出的所以备考时不能只刷LeetCode式的SQL题还得积累对社区产品运行逻辑的理解。我当时就是在梳理知乎的推荐机制和创作者成长路径时隐约感觉案例题一定会围绕这些场景展开结果确实如此。提示不同行业的数据分析岗笔试风格差异很大。金融风控岗考模型和规则电商岗考漏斗和复购内容社区岗考活跃和推荐。投简历之前先花半小时研究目标公司的业务模式远比盲目刷题有效。1.3 备考资料怎么选面经、题库和工具书关于备考资料我踩过一些弯路也总结出一套搭配。初期的信息收集阶段数据分析面经是必须看的但不要只看题目的标准答案重点看别人是怎么分析题目的——遇到一道案例题他的思考链路是什么用了什么框架。题库方面SQL题我主要在力扣和牛客上刷重点刷窗口函数、多表关联、留存计算这三类。Python数据分析部分除了刷题我还把《Excel Python飞速搞定数据分析与处理》这本书的核心章节过了一遍倒不是说笔试会考excel python这种偏门操作而是书里讲的批处理思路对理解pandas的操作逻辑很有帮助。统计学知识我用的是一本经典的统计学教材外加在线课程。AB实验这一块我看了不少关于实验设计、样本量计算、显著性检验的博客文章因为AB实验几乎是所有大厂数据分析岗的必考内容。工具方面平时我用DBeaver比较多它是开源免费的支持多种数据库而且做数据分析图表可视化也很方便。笔试环境不一定会用DBeaver但它帮你养成的SQL书写习惯和调试思路是可以迁移的。我建议备考期间把主力的SQL客户端熟悉到不用想就能操作的熟练度这样笔试时可以把精力集中在解题上而不是浪费在工具操作上。2. 客观题部分的真实考点从统计基础到业务理解笔试的第一部分是客观题单选、多选、判断混合。这一部分考察的知识面比较宽从统计学原理到业务指标都有可能涉及需要备考时把基础打牢。2.1 统计与概率假设检验、AB实验和贝叶斯统计相关的题目占比不低而且出题方向非常实务。我记得有几道题是围绕假设检验出的给出一个业务场景然后问你应该用什么检验方法或者给你一组p值问你这意味着什么。这类题目最坑的地方在于很多人记住了假设检验的公式和流程但对p值的含义理解是模糊的。比如一道题说“AB实验的p值小于0.05所以实验组的指标提升是显著的”这个说法严格来说是不完整的——p值小于0.05只能说明在原假设为真时观察到当前或更极端结果的概率很低并不能直接说“A比B好”。笔试里这种表述陷阱非常常见备考时一定要把p值、置信区间、统计功效这些概念真正吃透而不是背定义。贝叶斯相关的题目也考了但难度不高考的是最基础的先验概率和后验概率的转换本质上是要理解条件概率。这类题如果没有把握可以用最朴素的方式画个概率树一步一步列举所有可能不容易出错。AB实验是重中之重。考题不是直接问你“AB实验的步骤是什么”而是给一个实验场景然后问实验已经跑了两周观察组和对照组的转化率差异是0.3个百分点p值小于0.05这时候能不能提前结束实验并全量上线正确的思路是要考虑样本量是否预先计算过、是否做过多重检验修正、是否存在新奇效应、是否控制了干扰因素。如果只看p值就做决定很容易犯“提前偷看”的错误。我在备考时专门花时间把AB实验的完整流程梳理了一遍从实验假设、指标选取、样本量计算、实验时长、检验方法到实验结果的可信度评估这个知识体系在笔试和面试中都很有用。2.2 指标与业务常识北极星指标、留存和漏斗知乎的笔试里指标题考得很“活”不直接问“什么是留存率”而是给一个具体业务背景让你判断应该关注哪个指标。有一道题我记忆很清晰大意是知乎想要评估创作者激励策略的效果下列哪个指标最能反映策略的核心目标选项有创作者发文量、创作者人均赞同数、新创作者次月留存率、内容举报率。这道题考的不是单一指标的计算而是指标和业务目标的匹配能力。创作者激励策略的核心目标是提升创作者的活跃度和持续贡献意愿新创作者次月留存率直接反映创作者有没有因为激励而持续留下来创作比单纯的发文量更能说明激励策略的长期效果。人均赞同数更多反映内容质量内容举报率反映社区氛围都是辅助指标而非核心指标。这道题给我的启发是数据分析师不能只会算指标更要理解指标背后的业务含义。北极星指标、留存、漏斗这些概念不能停留在会算公式的水平要能做到“看到业务问题自动联想到该用哪一套指标来衡量”。2.3 容易被忽略的交叉考点辛普森悖论和数据可视化客观题里还出现了一个很有意思的交叉考点辛普森悖论。题目给了一个分组的转化率数据整体趋势和分组趋势相反问你最可能的原因是什么。辛普森悖论的本质是“分组对比”和“整体对比”方向不一致通常是因为各组的样本量分布不均匀混杂变量没有被控制。这在现实业务中非常普遍——比如按渠道拆分看转化率A渠道的转化率在iOS和Android两端都比B渠道高但合并在一起B渠道的总体转化率反而更高原因可能是B渠道在iOS端转化率高的平台的流量占比远大于A渠道。这种考题就是在提醒你数据分析不能只看汇总数字一定要做下钻分析同时留意数据口径和权重。我在复盘的时候意识到这类看似偏门的知识点恰恰是区分“会跑数”和“会分析”的分水岭。数据可视化相关的题也有一两道但考的不是“哪种图表好看”而是“要表达什么关系时应该选哪种图表”。我复习时专门过了一遍各类型图表的适用场景比如趋势用折线图、占比用饼图或堆叠柱状图、分布用直方图或箱线图、相关性用散点图。这些基础知识虽然简单但在实际分析中准确选用图表确实能提升分析观点的传达效率。3. SQL和Python实操题数据清洗与分析题型的解题套路实操题是整个笔试的重头戏也是拉开分差的地方。知乎的实操题看起来不复杂但每道题都藏着几个容易忽视的细节稍不注意就会掉进陷阱。3.1 SQL题型分析窗口函数、留存计算和连续登录SQL题一共两道都是在线的SQL编辑环境给定数据表结构要求写查询语句。第一道题是计算用户次日留存率第二道题是找出连续登录N天的用户。次日留存率这道题数据表大概是这样的结构-- 用户登录日志表 user_login -- user_id 用户ID -- login_date 登录日期要算次日留存率核心是判断“某天活跃的用户中有多少人在次日还活跃”。最直接的方式是用自连接把今天的活跃用户和明天的活跃用户关联起来然后按日期分组统计。SELECT a.login_date, COUNT(DISTINCT a.user_id) AS active_users, COUNT(DISTINCT b.user_id) AS retained_users, COUNT(DISTINCT b.user_id) / COUNT(DISTINCT a.user_id) AS retention_rate FROM user_login a LEFT JOIN user_login b ON a.user_id b.user_id AND b.login_date DATE_ADD(a.login_date, INTERVAL 1 DAY) GROUP BY a.login_date ORDER BY a.login_date;这道题看着简单但有三个细节必须注意。第一需要用COUNT(DISTINCT user_id)因为一个用户一天可能登录多次不去重的话活跃用户数会被高估。第二如果用的是LEFT JOINBASE表今天活跃的用户保留全部记录没有次日登录的用户的retained_users就是NULLCOUNT(DISTINCT)函数会自动忽略NULL值所以不会算错。第三留存率公式中的分子和分母必须是同一批用户也就是说分母是当天活跃的用户数分子是这批用户中次日仍在活跃的人数不能拿全量用户做分母。连续登录N天这道题经典的解法是“行号相减”技巧。先把每个用户按登录日期去重排序生成一个行号然后用登录日期减去行号得到一个日期差如果日期差相同说明这些天是连续的。WITH user_dates AS ( SELECT DISTINCT user_id, login_date FROM user_login ), user_with_row AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM user_dates ), date_diff AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL rn DAY) AS diff FROM user_with_row ), continuous_groups AS ( SELECT user_id, diff, COUNT(*) AS con_days FROM date_diff GROUP BY user_id, diff ) SELECT user_id FROM continuous_groups WHERE con_days N;这个解法的核心逻辑是如果一个用户连续登录那么“登录日期减去行号”得到的日期是固定的。比如用户1号、2号、3号登录行号分别是1、2、3日期减去行号分别是第0号、0号、0号这三条记录的diff相同说明是连续三天。这里有一个容易踩的坑千万要先做DISTINCT去重否则一个用户一天内登录多次行号就会错乱导致连续天数的判断出错。我在练习的时候就因为忘了这一步结果算出来的连续登录天数和正确答案对不上排查了很久才发现是重复登录记录导致的。3.2 Python数据清洗与分析题pandas的应用与细节Python实操题给了一张用户行为表要求做数据清洗并计算某些指标。数据表具体字段记不太清了大概是用户ID、行为类型、行为时间、行为详情之类的字段。这道题的核心考点是pandas的数据清洗能力。我当时的解题思路是分三步走第一步读取数据后先看数据的基本信息包括列名、数据类型、缺失值情况。用df.info()和df.isnull().sum()快速定位哪些字段有缺失值。第二步处理缺失值和异常值。对于用户ID这类关键字段如果有缺失值通常直接删除记录对于行为时间如果有缺失值可以根据上下文推断如果无法推断也删除对于数值型字段的异常值用描述性统计结合业务逻辑来判断。这里要注意的就是不要盲目地把异常值都删掉要看它是否符合业务场景。比如行为时长这个字段如果出现负数那明显是异常数据可以删除如果是0可能是用户秒关了页面属于正常业务状态不能删。第三步按需求计算指标。如果要求按用户维度计算行为频次可以用groupby加agg组合实现如果要求算某个时间段内的活跃用户数可以用时间过滤加nunique去重统计。我当时用了一个比较巧妙的写法用pd.cut()把时间段切分成多个区间然后按区间统计用户行为活跃度。这样做的好处是能一次性看出用户在不同时间段的行为差异而不是只算一个总量。这种写法在笔试里比较容易拿到加分因为它体现了你对时间维度的敏感度。import pandas as pd # 假设数据已经读取为df df[behavior_time] pd.to_datetime(df[behavior_time]) df[hour] df[behavior_time].dt.hour # 按小时分段统计用户行为 bins [0, 6, 12, 18, 24] labels [凌晨, 上午, 下午, 晚间] df[time_bucket] pd.cut(df[hour], binsbins, labelslabels, rightFalse) result df.groupby([time_bucket, user_id])[behavior_type].count().reset_index() result.columns [时间段, 用户ID, 行为次数]这道题整体难度不大但要注意代码的规范性。笔试环境里没有IDE的智能提示所有函数名和参数都要靠记忆所以平时一定要形成肌肉记忆不能依赖自动补全。另外代码的注释也很重要哪怕笔试不要求写上注释也能让阅卷人看出你的逻辑链条。3.3 笔试环境的适应在线IDE的“隐形坑”这里我想特别提醒一下在线IDE的问题。很多人平时用PyCharm或者Jupyter Notebook写代码习惯了语法高亮、自动补全、分步运行这些功能但笔试的在线IDE往往非常裸就是一个编辑框加一个运行按钮错误提示也不够友好。我参加的那场笔试在线代码环境有一个很尴尬的特点SQL不能分步执行调试只能一次性提交整个脚本如果SQL中间某行报错返回的错误信息也比较晦涩。Python这边稍微好一些可以print输出调试但没有任何语法提示。适应这个环境的最好方法是备考后期就刻意用在线编辑器来刷题比如直接用LeetCode的在线SQL环境和一些牛客的在线编程环境强迫自己适应没有智能提示的书写方式。平时写代码的时候也要养成“写完自查一遍语法和拼写”的习惯。提示笔试前一定要确认好目标公司在线的笔试环境有些用的是自带SQL编辑器有些用的是第三方平台提前把环境用熟了能减少很多临场发挥的不确定性。4. 案例分析题的拆解思路如何用数据分析思维拿高分案例题是知乎笔试里最考验综合能力、也最拉分的一道大题。它不会直接问你“某指标下降了怎么办”而是给你一个非常具体的业务场景让你完整地写出分析思路和建议。4.1 案例题的结构化应答框架目标、指标、数据、方法和结论我当时遇到的案例题场景大致是知乎发现近一个月“关注页”的日均活跃用户数下降了5%需要分析可能的原因并给出建议。这道题看着像一道开放题但阅卷人的评判标准其实是看你有没有结构化的分析能力。我的答题框架分五步第一步明确分析目标。这道题的核心目标不是“找到原因”而是“找到可落地的改进建议”。所以分析过程要围绕“数据表现、原因假设、验证方案、改进策略”这条链展开。第二步拆解指标。关注页DAU下降5%要拆不能只盯着这个总量指标。可以从用户分层拆比如新用户、老用户、核心用户各自的DAU变化可以从端侧拆比如iOS端、Android端、Web端各自的变化可以从路径拆比如关注页的曝光人数、点击率、人均浏览时长、互动率这些环节看看是哪个环节掉了。第三步列数据需求。为了验证假设需要哪些数据比如分端的DAU趋势、不同用户群的关注页行为数据、同期推荐页的DAU变化用来判断是关注页自身的问题还是整体流量下降的问题、最近上线的功能或策略变更记录。第四步用数据验证假设。这一步是关键的转折点单纯列数据需求是不够的要展示你拿到数据之后怎么分析。比如发现核心用户的关注页DAU下降明显而新用户变化不大那么问题可能出在核心用户的关注内容供给上比如发现关注页的曝光量没有降、点击率降了那问题可能出在内容质量和匹配上。分析时还要用对比思维比如对比关注页和推荐页的趋势就能判断是全局性问题还是局部性问题。第五步给出建议。建议必须具体、可落地、可验证。比如如果是内容供给不足导致核心用户活跃下降建议可以包括优化关注页的排序算法、增加对高活跃创作者的激励、对流失预警用户做push召回等。每个建议都要说明预期效果和验证指标。这个框架的优势在于它把看似无边界的问题拆解成了有明确步骤的分析流程。哪怕你对知乎的业务不熟悉按这个框架走也能保证答案的结构性让阅卷人看到你的思路是清晰的。4.2 知乎业务场景的案例分析内容推荐、创作者激励和用户增长知乎的案例题大概率会围绕内容推荐、创作者激励、用户增长这三个方向出题因为这是内容社区的生命线。备考前可以针对每一个方向准备一套分析框架。内容推荐方向核心是理解推荐系统的目标。分析时不能只盯着CTR和人均时长还要关注内容的多样性、创作者生态的健康度。比如一个推荐策略上线后人均时长提升了但中小创作者的曝光量大幅下降这就不一定是好策略因为长期看可能会损害内容供给。创作者激励方向核心是激励ROI。分析时可以拆成几个环节激励覆盖了哪些创作者、激励触发了什么行为、行为带来了什么内容产出、内容产出又带来了什么数据表现。每个环节都要有对应的指标比如覆盖度、参与度、内容产出量、内容质量分、流量分成等。用户增长方向核心是留存。分析时关注新增用户的来源渠道质量、新用户体验的关键行为、激活和留存的漏斗转化。比如知乎新人进来后如果7天内关注了5个以上话题或者3个以上创作者次月留存率会显著提升这就是一个可以驱动增长策略的关键洞察。这些框架不要求记住每一个细节关键是养成“把业务问题翻译成指标和链路”的习惯。平时多看看优秀的数据分析案例特别是那些公开分享的赛后复盘因为这类内容通常都会完整展示分析者的思考路径。4.3 如何让答案有区分度量化思维和方案对比案例题拿高分的核心不是把步骤写全而是让阅卷人看到你有“量化思维”和“方案对比”的意识。量化思维体现在你说“核心用户活跃下降”不能只用这个词要定义什么是核心用户——比如“近30天登录天数大于15天的用户”——然后给出具体的下降幅度和样本量。你的答案越量化就越接近一个真实数据分析师的工作方式。方案对比体现在你给出建议时不能只给一个方案至少要给两个以上方案并对比它们的优劣。比如针对“关注页内容供给不足”的问题A方案是优化推荐排序算法见效快但可能影响部分创作者的流量B方案是增加创作者激励见效慢但长期有助于内容生态。两个方案各有优劣你要分析它们的适用条件并给出你的推荐和理由。我当时在答题时特意用了一个表格来对比两个方案从预期收益、实施成本、风险程度、见效周期四个维度评估。这种呈现方式在笔试里很难得也是我后来复盘时觉得自己卷面比较有区分度的原因之一。注意案例题的文字量要控制好。不是写得越多越好而是每个论证环节都要有信息增量。如果只是把分析框架的几个步骤用不同的话重复说反而会让阅卷人觉得你在凑字数。我给自己定的标准是每写一个结论都要有对应的数据、逻辑或案例支撑。5. 踩坑复盘那些笔试结束后才想明白的细节考试过程中有些当时没意识到的坑复盘时才想明白。这部分的经验对准备笔试的人来说可能比标准答案更有价值。5.1 时间分配上的失策做题顺序和卡壳处理我踩的最后一个坑是时间分配。整场笔试120分钟我的时间分配是客观题40分钟SQL题30分钟Python题20分钟案例题30分钟。这个分配表面上看是合理的但实际操作中出现了问题。SQL第一道题我用了将近20分钟因为我在窗口函数的写法上犹豫了很久担心语法错误。结果SQL整体用了40分钟Python题压缩到15分钟案例题最后只剩25分钟赶得比较仓促。复盘时我意识到笔试不像面试没有追问的机会所以时间分配要留有余量。更好的策略是先把所有题目浏览一遍评估每道题的难度和分值然后先做分值高、自己最有把握的题目。比如案例题分值最高如果前面时间被卡住优先级应该时刻记住案例题要留够时间。卡壳的处理也很重要。如果一道题花了10分钟还没有头绪说明你的思路可能有问题暂时放一放先做后面的题最后再回来用排除法或暴力枚举的方式尝试。不要在一道题上死磕否则很容易心态爆炸。5.2 审题细节上的教训数据口径和单位陷阱笔试的客观题里有一道题问的是“某指标的环比增长率”数据表里给出了两个月的数值。我直接用“本月-上月/上月”计算得到的结果在选项里找不到。后来仔细读题才发现题目问的是“同比增长率”也就是和去年同月比而不是和上个月比。这个低级失误提醒了我审题时一定要圈出关键限定词。比如“同比”和“环比”、“日均”和“总量”、“DAU”和“WAU”一字之差答案天壤之别。实操题里也有类似陷阱。有一道SQL题的表结构里没有明确写主键我以为user_id就是主键结果数据里同一个user_id在同一天有两条记录导致我算出来的数据比预想的多了一倍。所以拿到数据表之后不能理所当然地假设字段的唯一性要默认“数据是脏的”先想清楚是否需要去重。5.3 写给后来者秋招笔试准备的优先级建议如果能重新准备这场笔试我会把精力按这个优先级分配第一优先级SQL窗口函数。不要只停留在会写、能跑对要理解每类窗口函数的语义和适用场景。连续登录、留存、TopN、同比环比这类题型每类都要练到闭卷能写的熟练度。第二优先级AB实验和统计推断。这是客观题和面试题的高频考点而且非常考验理解深度。不要只背流程要能解释每个步骤背后的为什么。第三优先级业务指标和案例题框架。每天抽30分钟试着把生活中的问题用数据分析的框架拆解一遍比如“某家奶茶店最近的营业额为什么下降了”逼自己从指标拆解、数据需求、假设验证的角度思考。第四优先级Python数据清洗和可视化。这部分考点相对基础但也不能掉以轻心要熟悉pandas的常用操作特别是groupby、merge、apply、cut这些高频函数。另外工具链的前期准备也很重要。我备考时重度使用DBeaver做SQL练习它的自动补全和结果集展示对初学者很友好做Python数据分析练习时我用Jupyter Notebook来调试pandas代码每一步的中间结果都可视化展示出来对理解数据处理逻辑帮助很大。笔试环境和这些工具有差别但底层的数据处理思维是一样的。最后想说笔试不过是一道门槛真正决定你能否拿到offer的是面试中展现的分析思维和业务感觉。但笔试这道门槛值得认真对待——它既是对你知识储备的检验也是一次很好的自我梳理机会。准备过程中建立起来的知识体系和方法论会在你之后的工作中持续发挥作用。
