2024届秋招刚拉开帷幕贝壳找房就放出了第一批机器学习/数据挖掘工程师的笔试。我第一时间报名参加考完之后最大的感受是这套卷子不是单纯考你会不会背模型公式而是考你能不能在限时高压下把机器学习、数据挖掘、SQL和工程代码整合到一起解决真实问题。整理这份复盘是因为贝壳这套题很有代表性——它兼顾了算法基础、业务理解和coding能力对准备互联网大厂算法岗、数据挖掘岗秋招的同学都有很强的参考价值。无论你是2025届在校生还是正在跳槽的数据从业者这篇内容都能帮你厘清复习重点和考场策略。1. 贝壳这套笔试题到底在考什么1.1 贝壳的数据岗位核心业务场景是什么先说一个最基本的判断不同公司出的算法题气质完全不一样。字节爱考动态规划和海量数据处理快手爱考视频推荐场景下的策略拼多多偏重工程实现和分布式。贝壳这套题处处透露出居住服务行业的业务底色。贝壳找房的业务核心是房产交易和居住服务覆盖二手房、新房、租赁、家装、物业等场景。数据挖掘工程师在这家公司要解决的核心问题绕不开这几类房源画像与真房源治理房源信息去重、真实性检测、字段补全。推荐与排序用户看房过程中的房源推荐、探索发现、搜索结果排序。价格预估房价评估、租金预测、成交周期预估。转化率预估从浏览到咨询、从咨询到带看、从带看到成交的每一步转化建模。经纪人与运营效率经纪人工作台排序、客源匹配、服务响应速度优化。如果你提前想过这些业务场景再看这套笔试题就会觉得很多题目是有出处的。它不是在真空里考机器学习而是希望候选人具备把算法落地到具体业务链路里的能力。1.2 整体题目结构三模块评价体系按照我对第一批笔试的回忆以及考后和同学们的交流整体题量大约在32到35题左右考试时长120分钟题型可以分成三个模块模块题型大致题量考察重点基础选择单选多选20题左右机器学习、概率统计、数据结构、线性代数主观问答简答/方案设计3题左右业务建模思路、模型选型与评估、算法原理编程与SQL代码实现3到4题算法题2道左右、SQL题1到2道分值上编程题和SQL是大头几乎占到一半。这传递出一个明确信号贝壳的数据挖掘岗位不是科学家型的纯理论岗位而是需要动手能力的工程型算法岗。你可以不会推导SVM的KKT条件但你不能写不出一个能跑的TopK推荐候选集。1.3 能力考察的三个层级把这套题横向拆开可以归纳出三个考察层级这也是我在复习后期才真正想明白的框架第一层是理论层。机器学习基础概念、常见模型的原理与适用场景、概率统计基本功。这一层决定你的选择题能不能拿分。第二层是工程层。编程题的AC能力、SQL的书写规范、对数据结构和复杂度的敏感度。这一层决定你能不能过硬性门槛。第三层是业务层。给你一个业务问题你能不能拆解成指标定义、特征构建、模型选型、评估方案、上线迭代这样的完整链路。这一层决定你和其他候选人拉开差距的地方。三层缺一不可。只刷LeetCode不复习机器学习选择题会崩只背模型公式不写代码编程题会挂两者都OK但没想过业务场景问答题就只能写两行干巴巴的用XGBoost。2. 机器学习基础高频考点与易错点复盘2.1 正则化与偏差方差一道选择题考出理论功底选择题部分机器学习基础占了将近一半。最常出现的考点我按出现频率排个序过拟合与正则化L1/L2、Dropout、早停决策树与集成学习ID3/C4.5/CART、GBDT/XGBoost/LightGBM偏差与方差的分解分类评估指标准确率、精确率、召回率、F1、AUCSVM与核函数聚类算法与距离度量概率图模型与朴素贝叶斯其中有一道关于L1和L2正则化的题印象很深。题目大概是这样描述的在高维稀疏特征场景下L1正则化比L2正则化更容易产生稀疏解问以下哪个说法正确。选项里混着L1正则化是L2正则化的近似L2正则化可以让权重严格等于0L1正则化对异常值更敏感这类干扰项。这道题的考点很干净为什么L1能让权重变成0而L2只能让权重趋近于0。我的理解方式是画损失函数和约束条件的等高线图。L1的约束区域是菱形角点落在坐标轴上最优解很容易出现在角点位置对应某些特征的权重为0L2的约束区域是圆形边界平滑最优解一般不会精确落在坐标轴上。换成数学表达L1正则化的目标函数在零点不可导梯度下降过程中容易把参数推到0L2正则化的梯度在零点附近是连续的参数只会被压缩但不会严格归零。注意多选题里还有一个陷阱问你哪些方法可以有效缓解过拟合。除了L1/L2、Dropout、数据增强还有一个选项是增加模型训练轮数到收敛这个不是缓解过拟合反而是过拟合的催化剂很多人一着急就把它也选上了。2.2 决策树与集成学习从ID3到LightGBM的脉络贝壳对决策树和集成学习的考察非常细选择题、问答题都会涉及。选择题里考过一道CART回归树在做特征分裂时用的是什么指标选项有信息增益、信息增益率、基尼指数、均方误差。这个题其实是在考察CART分类树和回归树的区别分类树用基尼指数回归树用均方误差。集成学习方面重点放在GBDT和XGBoost的区别上。我的笔记里有一张自己的对比表笔试前反复看了几遍对比维度GBDTXGBoost泰勒展开一阶导数二阶导数收敛更快正则项无显式正则叶子节点数L2正则缺失值处理需自行填充自动学习缺失值分裂方向特征抽样通常不抽样支持列抽样防过拟合并行化串行特征维度并行有一道多选题问XGBoost相比GBDT做了哪些改进选项里有引入了二阶导数加入了正则项支持列采样可以自动处理缺失值。如果只是听说过XGBoost的名字而不了解实现细节这题很容易漏选列采样和缺失值处理。2.3 评估指标为什么准确率在有些场景是陷阱关于评估指标的考察已经不是单纯问你准确率和召回率公式了而是放在业务场景里考。比如问在房源推荐场景中用户点击率只有0.5%选择什么指标评估推荐效果最合适。正确方向是AUC或GAUC而不是准确率。原因很简单正负样本极度不平衡时模型把所有样本都预测为负样本准确率依然能达到99.5%。但推荐系统的真实目标是从海量房源中找出用户可能感兴趣的少量item准确率这个指标在这种场景下是失效的。我在复习时整理过一套关于AUC的理解笔试前又强化了一遍AUC的物理意义随机抽取一个正样本和一个负样本模型给正样本打分高于负样本的概率。AUC的取值范围0.5代表随机猜0.5到0.7之间属于弱学习器0.7到0.85之间说明有区分度0.85以上需要考虑是否过拟合。计算方式按预测分数排序用公式或者用梯形法近似。问答题里如果让你设计推荐排序模型评估指标方面除了AUC还要能说出GAUC。GAUC按用户分组计算AUC再加权平均更能反映推荐系统对每个用户的相对好排能力这个点能说出来会加分。2.4 概率统计与线性代数容易被忽略的送分题这一块选择题约4到5题虽然不深但范围很广。考到了极大似然估计的基本思想、朴素贝叶斯条件独立性、期望与方差的运算性质还有一道矩阵特征值的题。概率题里典型的一道假设患某种疾病的概率是0.1%检测试剂的敏感性是99%特异性假阳性率是1%一个人检测结果为阳性问他真正患病的概率是多少。这是贝叶斯公式的经典应用题。计算过程是P(患病) 0.001P(阳性|患病) 0.99P(阳性|未患病) 0.01代入贝叶斯公式 P(患病|阳性) 0.99 × 0.001 / (0.99 × 0.001 0.01 × 0.999) ≈ 9.02%这个结果让很多人意外——即使检测阳性真患病的概率也不到10%。原因在于人群基数大假阳性数量远远超过真阳性。这种题考察的不是计算能力而是对先验概率和后验概率关系的直觉。线性代数方面推荐系统矩阵分解、PCA降维这些内容都有可能涉猎。重点掌握特征值分解、奇异值分解的几何意义和基本计算不用陷入太深的推导。3. 编程题复盘从题目到AC的完整推演3.1 考场环境在线评测的那些隐藏规则贝壳的笔试用的在线评测系统和牛客、赛码这类平台类似。虽然题目不会要求你写标准输入输出格式的解释性文字但有几个考场细节如果不知道第一题可能就卡十几分钟。第一语言选择。系统支持C、Java、Python、Go等主流语言但Python版本和第三方库有限制别指望能用numpy。所有算法题都需要纯Python手写数据结构只能用list、dict、deque这些基础容器。第二输入读取方式。必须用sys.stdin.readline()循环读取而不是一次性的input()。多组测试用例时input()的性能会拖后腿导致超时。第三输出格式。题目如果要求每个数占一行或数字之间用空格分隔严格按照要求来。输出末尾多了空格也可能判错。3.2 第一道编程题最长不含重复字符的子字符串这是印象中比较有代表性的一道题也是每家互联网公司常考的原型题在LeetCode上是第3题。题目描述是给定一个字符串找出其中不含有重复字符的最长子串的长度。输入示例abcabcbb输出3因为最长无重复子串是abc。这道题最直观的解法是暴力枚举所有子串时间复杂度O(n²)在字符串长度10万级别的时候必然超时。正确解法是滑动窗口哈希表时间复杂度O(n)。我当时的实现思路import sys def length_of_longest_substring(s: str) - int: # 用字典记录每个字符最近一次出现的位置 last_pos {} left 0 max_len 0 for right, ch in enumerate(s): # 如果字符在窗口内出现过移动左边界 if ch in last_pos and last_pos[ch] left: left last_pos[ch] 1 # 更新字符最近出现位置 last_pos[ch] right # 更新最大长度 max_len max(max_len, right - left 1) return max_len data sys.stdin.readline().strip() print(length_of_longest_substring(data))这道题有几个容易写错的边界条件字符串为空max_len初始为0直接返回0没问题但要确保代码不抛异常。所有字符都相同比如aaaaleft会不断调整到当前位置max_len始终为1。last_pos[ch] left 的判断如果不加这个条件当字符在滑动窗口之外出现过时left会被错误地回退。考场上的一个教训是第一遍写完后别急着交自己补一个全部字符都相同的测试用例和空字符串用例跑一遍这两个边界最容易挂。3.3 第二道编程题TopK类问题业务感拉满第二道编程题很有意思带了一点业务背景。大意是给定n条带看记录每条记录包含楼盘ID和带看时间要求输出带看次数最多的k个楼盘ID按带看次数降序输出如果次数相同按ID升序。这类题的核心考点是hashmap统计频次 TopK选择。TopK可以用排序做也可以用堆做。我用的解法是先统计频次再用最小堆维护大小为k的堆最后取出堆中元素。import sys import heapq def solve(n: int, k: int, records) - list: freq {} for record in records: # record格式: id bid record freq[bid] freq.get(bid, 0) 1 # 构建最小堆堆内元素为(次数, id) heap [] for bid, cnt in freq.items(): if len(heap) k: # 次数为负数实现最大堆效果次数相同则id小的优先级高 heapq.heappush(heap, (-cnt, bid)) elif (-heap[0][0], heap[0][1]) (cnt, bid): heapq.heappop(heap) heapq.heappush(heap, (-cnt, bid)) result sorted(heap, keylambda x: (x[0], x[1])) return [bid for _, bid in result] if __name__ __main__: data [] for line in sys.stdin: data.append(line.strip()) n int(data[0]) k int(data[1]) records data[2:2n] result solve(n, k, records) for bid in result: print(bid)这道题有两个坑Python的heapq默认是小顶堆要找最大的k个直接把负数放进堆里就行。但如果我还想按次数降序、ID升序输出就需要仔细设计堆内的比较元组光是(次数, ID)的排序逻辑就够写错一次的。堆的比较规则元组先比较第一个元素再比较第二个元素。如果我把(-cnt, bid)入堆那么堆顶永远是次数最小取负后值最大或者ID最大的元素出堆的时候要注意顺序。另外要说一句这种TopK题看上去很简单但越简单的题越容易在细节上扣分。贝壳的笔试评测系统比较严格时间复杂度过高的暴力解法虽然能过部分用例但在大数据量用例上会超时。所以看到TopK先想堆而不是排序这是基本素养。3.4 编程题的整体策略暴力解法的价值有一个很真实的经验在线笔试的得分机制通常是按通过的测试用例比例给分。也就是说就算你只写出暴力解也能拿到一部分用例的分数。贝壳的第一批笔试里有一道偏向动态规划的题我当时第一时间没想出来最优解就先写了一个指数级的暴力搜索然后又跑了一下小数据用例确认输出正确后再去优化。做题顺序上我的建议是先看所有编程题的题目描述判定难度梯度。先把最有把握的满分题写完并测试通过。再集中时间攻克中等难度题优先写出暴力版本保底。最后剩时间再去想优化不要在一开始就死磕最难题。4. 数据挖掘场景题把居住服务业务翻译成建模任务4.1 带看转化率预估样本不平衡怎么设评估指标贝壳的场景问答题中带看转化率预估这个方向出现的概率相当高。原因很简单带看是房产交易中非常关键的中间环节——用户从线上浏览到线下看房每一次带看都意味着经纪人和用户的时间投入如果能对带看概率做准确预估平台就能优化经纪人的资源分配和用户推荐策略。题目大致这样问给定一批用户与房源的交互行为数据目标是对每一对用户-房源预测其产生带看的概率。正样本产生带看的占比约为0.2%请问你会怎么建模选择什么评估指标这类题的答题框架我建议按问题定义、样本构建、特征工程、模型选型、评估指标、上线方案六步回答。每一部分写清楚思路问题定义这是二分类问题但本质上是排序问题。业务上更关心的是在有限的经纪人服务能力下优先触达带看概率最高的用户。样本构建正样本是曝光后产生带看的用户-房源对。负样本不能只看曝光未带看因为存在还没到决策时机的情况要注意观察窗口的设计。比如选择曝光后7天内是否带看作为label避免时间截断偏差。特征工程用户特征历史房源浏览量、历史带看次数、所在城市、购房偏好户型/面积/总价区间房源特征房源价格、面积、户型、楼层、朝向、小区品质评分、周边配套交叉特征用户偏好户型与房源户型是否匹配、用户预算与房源价格差上下文特征推荐位次、所属频道、城市等级、时间特征模型选型常规方案是GBDT/XGBoost/LightGBM也可以尝试深度模型如DIN/DIEN但需要足够的样本量。工业界更常用的是LightGBMLR/WideDeep的组合。评估指标正样本占比0.2%准确率必然虚高。应该用AUC评估排序能力同时关注PR曲线下的面积AUPRC以及TopK命中率——比如平台只会给用户展示10个推荐位那就要看带看转化率预估Top10里的真实带看覆盖率。上线方案离线评估通过后小流量AB实验观察带看率、经纪人响应效率、用户满意度等指标。这一类题目其实没有标准答案面试官看重的是你有没有完整闭环的建模思维。只写用XGBoost建模用AUC评估这种三行字肯定拿不到高分。4.2 房源推荐冷启动从用户搜索词到候选集扩展另一个场景题考的是推荐冷启动。给你一个新用户只在平台上搜索过一次北京朝阳区 三居室 800万以内没有任何点击和带看记录请设计一个推荐策略。这个问题核心在如何从稀疏的单一信号扩展到丰富的候选集。我当时的大体思路是分三路召回第一路文本匹配把搜索词解析成结构化条件包括城市北京、区域朝阳、户型三居、总价上限800万直接从房源库中筛选出满足硬性条件的房源。第二路相似房源扩展基于楼盘字典、房源属性之间的相似度找到与目标房源风格相近的房源。比如用户在搜索三居室可以尝试推荐同小区或周边小区的三居/四居室用户预算在800万以内可以适当扩展到850万以内的房源。第三路热门兜底如果以上两路候选集太小使用平台热门房源、精选房源作为冷启动的兜底内容。排序阶段因为缺少用户行为数据更多依赖规则和热度信号比如房源质量分、房天下指数、周边配套评分、距离地铁站距离、经纪人响应速度等做一个加权打分。这道题背后的考察点是冷启动的本质是信号稀疏你的核心任务是构建信号扩展路径而不是急着一上来就训练深度学习模型。4.3 房价预估模型特征工程的经验陷阱房价预估也是贝壳的典型业务问题。问题通常是给定一个城市过去两年的二手房成交记录包括小区、面积、朝向、楼层、房龄、装修、成交时间、成交总价预测一套新上架房源的合理挂牌价。你会做哪些特征工程用什么模型怎么处理异常值这类题的得分点不在模型而在特征工程和异常值处理的细节上。特征工程的关键维度时间特征成交月份、季节用来捕捉房价的季节性波动面积区间化50平米以下、50-90、90-120、120以上不同面积段单价差异明显楼层/朝向独热顶层和中间楼层的价差、朝南朝向的溢价小区聚合特征小区近180天成交均价、成交量、中位数单价周边配套学区属性、地铁距离、商圈距离时间衰减按成交时间加权近3个月的数据权重高半年前的数据权重低这里有个容易犯的错误直接把面积和总价同时放进模型训练。这两个变量高度线性相关模型会把几乎全部权重都放在面积上小区位置、品质这些同样重要的信息反而学不到。更合理的做法是单价作为预测目标面积作为特征或者预测总价但通过log变换等方式把量纲差拉平。异常值处理是另一个得分点。二手房成交记录里经常出现1元成交、车位单独成交这类特殊样本。我的处理方式是删除单价和总价在1%和99%分位数之外的极端值。通过小区内单价比对剔除单价与小区中位数偏差超过3倍标准差的数据。保留明显偏高的样本可能是学区房加成盲目剔除会损失真实模式。模型选型常规选择是LightGBM因为它对数值型特征的非线性拟合能力强、训练速度快、支持缺失值处理。价格预测的评价指标常用MAPE平均绝对百分比误差和RMSE面试时要能说清楚为什么不用准确率这种分类指标。5. SQL与大数据题数据挖掘工程师的隐形门槛5.1 为什么算法岗笔试还要考SQL很多人会有疑惑我做机器学习为什么还要写SQL答案很简单——数据挖掘工程师日常工作中数据提取和预处理占掉的时间比重非常高。贝壳的房源数据分散在几十张表里你不会SQL连训练样本都抽不出来更别说建模了。贝壳这套题里SQL占1到2题分值不低而且直接手写代码几乎没有含糊空间。5.2 连续N天登录用户窗口函数的标准写法有一道题考的是连续活跃用户这也是各大公司SQL题的经典套路。题目大意给定用户登录日志表login_log(user_id, login_date)找出连续3天及以上有登录记录的用户。这类题几乎只有一个标准解法使用row_number()窗口函数按用户分组、按日期排序生成序号然后计算日期减去序号得到一个分组标识连续日期会落在同一个分组标识里。WITH t1 AS ( SELECT user_id, login_date, row_number() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log ), t2 AS ( SELECT user_id, login_date, date_sub(login_date, INTERVAL rn DAY) AS diff_date FROM t1 ) SELECT user_id FROM t2 GROUP BY user_id, diff_date HAVING COUNT(*) 3;这个解法背后的原理是对于连续的日期每行序号加1日期也加1两者差值保持不变一旦出现断档差值就会变化。理解了原理就不仅能写连续3天还能扩展成连续7天、连续30天。有个容易出错的地方如果登录日志里同一天有重复记录需要先对(login_date, user_id)去重否则日期和序号对应不上。可以在外层加DISTINCT。5.3 每组TopN分城市统计成交榜Top3板块这道题和业务走得比较近给定二手房成交记录house_deal(name, city, district, deal_amount)要求统计每个城市成交量Top3的城区。MySQL 8.0和主流在线评测环境都支持窗口函数直接用rank()或者dense_rank()按城市分组建序。WITH t1 AS ( SELECT city, district, COUNT(*) AS deal_cnt, ROW_NUMBER() OVER (PARTITION BY city ORDER BY COUNT(*) DESC) AS rn FROM house_deal GROUP BY city, district ) SELECT city, district, deal_cnt FROM t1 WHERE rn 3;这道题有三个考点先聚合再开窗窗口函数里不能直接用COUNT(*)需要先在GROUP BY里算出每个城区的成交量再在子查询里对聚合结果排序。RN 3的选择如果要求并列情况全部输出要用rank()如果只要第1到第3名各一个用row_number()。题目通常会说清楚但如果没有说清楚优先使用rank()更安全。NULL处理如果district字段有NULL值分组时会单独成组。真实业务中通常需要过滤掉这类脏数据。5.4 SQL题的通用审题技巧考场上的SQL题建议先冷静读两遍题目把表结构、连接字段、聚合粒度、过滤条件、排序方式这五要素写下来再动手。写SQL最容易犯的错是连接条件写错比如用户表和日志表关联的时候多关联了一层导致数据重复膨胀。还有一个经验写完SQL后自问一句如果同一用户在一天内有多条记录结果会不会错。很多SQL题的隐藏考点就是去重。真实数据不是教科书的干净数据这个意识会帮你避开很多坑。6. 时间分配与应试策略一次真实考场的踩坑记录6.1 题目顺序决定心态心态决定发挥我这次踩过的一个大坑是前面的选择题花的时间太多导致后面编程题的时间被压缩了。回头算账20道选择题我做了将近40分钟平摊到每道题2分钟但实际很多题应该10秒就能判断的。考后反思正确的节奏应该是模块建议用时核心策略选择题20-25分钟会就选不会标记跳过不要恋战SQL题20-25分钟先搭框架再写细节特别注意去重编程题40-50分钟先暴力保底再逐步优化场景问答题20-30分钟按六步框架写宁可多写思路不写废话这个顺序也有讲究我建议把问答题放在编程题之前。原因是问答题不需要调试环境想到多少写多少越写思路越开阔而编程题容易卡住一旦卡住半小时就没了会严重影响后面的状态。6.2 选择题的取舍策略别让完美主义毁掉后面选择题里的多选题是最容易丢分的选错一个选项就是零分少选可能只拿部分分。对于不确定的选项我的策略是如果完全没把握宁可少选不要多选。因为多选一个错误选项全题零分少选一个可能还有部分分。知识点覆盖上优先保证机器学习基础这一块的正确率。贝壳选择题的理论深度适中没有到让非数学系的人无从下手的地步。但前提是你真的理解而不是死记硬背。6.3 编程题的稳比快更重要编程题最怕的不是不会而是会但写错。我写第一道滑动窗口题时本来思路是对的但手滑把left的更新条件写成了last_pos[ch] left而不是导致重复字符被错误地跳过。这种题目根本没有报错提示逻辑错误只能靠自测用例发现。所以我强烈建议写完每道编程题都要自己构造3个测试用例做一次手算验证。一个正常输入、一个边界输入空/单元素、一个极端输入全重复/全递增。这个习惯在在线笔试中能帮你挽回大量无谓的失分。另外如果考场提供的在线编辑器有本地运行或者自测功能一定要用。没有的话就在脑子里模拟运行一遍代码流程把关键变量的变化过程走一遍。6.4 心态管理的两个细节第一个细节是做完一题清零一题。在线笔试系统不像面试有回看的机会很少与其纠结上一题哪个用例没过不如把精力放在下一题上。第二个细节是最后5分钟不要写新代码。这时候大概率是匆匆忙忙写出来的残次品反而容易把原本可以通过的答案覆盖掉。最后几分钟应该用来检查编程题的输出格式和SQL题的语法拼写。7. 复盘后的备考路线别再用期末复习的思路准备秋招7.1 知识主干两本书一本都不能只读一遍考完贝壳这套题我对备考资料的认知有了一次刷新。很多同学还在拿机器学习期末复习的思路准备秋招把周志华《机器学习》和李航《统计学习方法》里的公式从头推导一遍推导完觉得自己无敌了一到笔试写代码就抓瞎。我的体会是这两本书的定位完全不同周志华《机器学习》构建知识框架西瓜书胜在覆盖面广从线性模型、决策树到集成学习、聚类、降维都有。读这本书的目标是看到题目知道考哪个模块并理解每个模型的核心假设。李航《统计学习方法》深入理解经典算法尤其是感知机、逻辑回归、SVM、EM算法、隐马尔可夫模型这些推导细节。这本书适合精读每个算法的损失函数、优化方法、收敛性都要能用自己的话讲一遍。但光读这两本远远不够。笔试真正拉开差距的是代码能力和业务建模能力这两个能力只能靠输出来训练——写代码、写SQL、写方案。7.2 建立业务场景→算法选型的映射表我在复盘贝壳这套题时整理了一张映射表对后续面试帮助很大业务问题典型算法/工具关键评估指标房源推荐召回ItemCF/向量召回 排序LightGBM/DIN点击率、AUC、GAUC价格预估LightGBM/回归树MAPE、RMSE带看转化预估LightGBM/逻辑回归PR-AUC、TopK命中率文本搜索BM25/向量检索NDCG、MRR异常检测孤立森林/统计阈值精确率、召回率经纪人分单匹配评分模型配对成功率、效率提升这种映射表的用处在于笔试场景题给你一个业务问题你能很快定位到这是推荐问题、预估问题还是匹配问题然后顺藤摸瓜写出完整方案。7.3 编程题的刷题策略高质量重复胜过大范围覆盖针对算法笔试我推荐的刷题顺序是LeetCode Hot 100两遍以上第一遍按题型刷第二遍随机打乱。高频题优先数组、字符串、哈希表、双指针、滑动窗口、二叉树、动态规划。SQL专项牛客SQL实战题库每天3到5题重点练窗口函数。模拟笔试每周至少一次2小时全真模拟用牛客或者赛码的在线环境。贝壳这次考到了滑动窗口、TopK、动态规划、SQL连续登录全部都在高频题型范围内。没有偏题怪题说明出题人是希望通过笔试筛出基础扎实的人而不是筛刷过偏门题库的人。7.4 针对贝壳的独特准备点如果你确定要投贝壳的数据挖掘岗有一个加分项容易被忽略提前了解贝壳的业务术语和数据体系。比如楼盘字典真房源VR带看经纪人合作网络。这些名词不是考点本身但它们会出现在场景题的题干背景里。如果你对这些概念有基本认知读题速度和理解深度都会不一样。我在笔试前花了两小时看贝壳的公开资料和典型业务功能介绍后来写场景题的时候明显能感觉到对房源、带看、经纪人效率这些环节的敏感度高了很多。这种准备不会直接告诉你答案但它能让你在场景题里写出更贴合实际业务的方案而不是一套放之四海皆准的空话。7.5 最后一条实用建议考完贝壳这套题我最大的感受是笔试考察的不是你会什么而是你在有限时间内能调用出什么。知识储备是地基代码能力是手脚业务思维是眼睛。三者缺一成绩都会打折扣。如果你还在备战秋招我的建议是拿一套往届真题做一次完整的全真模拟严格计时不允许中途查资料。第一次模拟的成绩大概率不理想但那不重要——重要的是通过模拟暴露自己在时间分配和知识点切换上的短板。我在第一次模拟的时候选择题用了45分钟编程题只写完一题半惨不忍睹。正是那次教训让我在后面真正参加贝壳笔试时能有意识地控制节奏。笔试是个熟能生巧的活练得多了手感自然就来了。整理这份复盘也是给自己留个存档方便后续面试时复盘这些高频考点。希望正在准备秋招的你看完这篇能少走一点弯路。 贝壳秋招算法岗笔试复盘：机器学习与数据挖掘考点全解析
2024届秋招刚拉开帷幕贝壳找房就放出了第一批机器学习/数据挖掘工程师的笔试。我第一时间报名参加考完之后最大的感受是这套卷子不是单纯考你会不会背模型公式而是考你能不能在限时高压下把机器学习、数据挖掘、SQL和工程代码整合到一起解决真实问题。整理这份复盘是因为贝壳这套题很有代表性——它兼顾了算法基础、业务理解和coding能力对准备互联网大厂算法岗、数据挖掘岗秋招的同学都有很强的参考价值。无论你是2025届在校生还是正在跳槽的数据从业者这篇内容都能帮你厘清复习重点和考场策略。1. 贝壳这套笔试题到底在考什么1.1 贝壳的数据岗位核心业务场景是什么先说一个最基本的判断不同公司出的算法题气质完全不一样。字节爱考动态规划和海量数据处理快手爱考视频推荐场景下的策略拼多多偏重工程实现和分布式。贝壳这套题处处透露出居住服务行业的业务底色。贝壳找房的业务核心是房产交易和居住服务覆盖二手房、新房、租赁、家装、物业等场景。数据挖掘工程师在这家公司要解决的核心问题绕不开这几类房源画像与真房源治理房源信息去重、真实性检测、字段补全。推荐与排序用户看房过程中的房源推荐、探索发现、搜索结果排序。价格预估房价评估、租金预测、成交周期预估。转化率预估从浏览到咨询、从咨询到带看、从带看到成交的每一步转化建模。经纪人与运营效率经纪人工作台排序、客源匹配、服务响应速度优化。如果你提前想过这些业务场景再看这套笔试题就会觉得很多题目是有出处的。它不是在真空里考机器学习而是希望候选人具备把算法落地到具体业务链路里的能力。1.2 整体题目结构三模块评价体系按照我对第一批笔试的回忆以及考后和同学们的交流整体题量大约在32到35题左右考试时长120分钟题型可以分成三个模块模块题型大致题量考察重点基础选择单选多选20题左右机器学习、概率统计、数据结构、线性代数主观问答简答/方案设计3题左右业务建模思路、模型选型与评估、算法原理编程与SQL代码实现3到4题算法题2道左右、SQL题1到2道分值上编程题和SQL是大头几乎占到一半。这传递出一个明确信号贝壳的数据挖掘岗位不是科学家型的纯理论岗位而是需要动手能力的工程型算法岗。你可以不会推导SVM的KKT条件但你不能写不出一个能跑的TopK推荐候选集。1.3 能力考察的三个层级把这套题横向拆开可以归纳出三个考察层级这也是我在复习后期才真正想明白的框架第一层是理论层。机器学习基础概念、常见模型的原理与适用场景、概率统计基本功。这一层决定你的选择题能不能拿分。第二层是工程层。编程题的AC能力、SQL的书写规范、对数据结构和复杂度的敏感度。这一层决定你能不能过硬性门槛。第三层是业务层。给你一个业务问题你能不能拆解成指标定义、特征构建、模型选型、评估方案、上线迭代这样的完整链路。这一层决定你和其他候选人拉开差距的地方。三层缺一不可。只刷LeetCode不复习机器学习选择题会崩只背模型公式不写代码编程题会挂两者都OK但没想过业务场景问答题就只能写两行干巴巴的用XGBoost。2. 机器学习基础高频考点与易错点复盘2.1 正则化与偏差方差一道选择题考出理论功底选择题部分机器学习基础占了将近一半。最常出现的考点我按出现频率排个序过拟合与正则化L1/L2、Dropout、早停决策树与集成学习ID3/C4.5/CART、GBDT/XGBoost/LightGBM偏差与方差的分解分类评估指标准确率、精确率、召回率、F1、AUCSVM与核函数聚类算法与距离度量概率图模型与朴素贝叶斯其中有一道关于L1和L2正则化的题印象很深。题目大概是这样描述的在高维稀疏特征场景下L1正则化比L2正则化更容易产生稀疏解问以下哪个说法正确。选项里混着L1正则化是L2正则化的近似L2正则化可以让权重严格等于0L1正则化对异常值更敏感这类干扰项。这道题的考点很干净为什么L1能让权重变成0而L2只能让权重趋近于0。我的理解方式是画损失函数和约束条件的等高线图。L1的约束区域是菱形角点落在坐标轴上最优解很容易出现在角点位置对应某些特征的权重为0L2的约束区域是圆形边界平滑最优解一般不会精确落在坐标轴上。换成数学表达L1正则化的目标函数在零点不可导梯度下降过程中容易把参数推到0L2正则化的梯度在零点附近是连续的参数只会被压缩但不会严格归零。注意多选题里还有一个陷阱问你哪些方法可以有效缓解过拟合。除了L1/L2、Dropout、数据增强还有一个选项是增加模型训练轮数到收敛这个不是缓解过拟合反而是过拟合的催化剂很多人一着急就把它也选上了。2.2 决策树与集成学习从ID3到LightGBM的脉络贝壳对决策树和集成学习的考察非常细选择题、问答题都会涉及。选择题里考过一道CART回归树在做特征分裂时用的是什么指标选项有信息增益、信息增益率、基尼指数、均方误差。这个题其实是在考察CART分类树和回归树的区别分类树用基尼指数回归树用均方误差。集成学习方面重点放在GBDT和XGBoost的区别上。我的笔记里有一张自己的对比表笔试前反复看了几遍对比维度GBDTXGBoost泰勒展开一阶导数二阶导数收敛更快正则项无显式正则叶子节点数L2正则缺失值处理需自行填充自动学习缺失值分裂方向特征抽样通常不抽样支持列抽样防过拟合并行化串行特征维度并行有一道多选题问XGBoost相比GBDT做了哪些改进选项里有引入了二阶导数加入了正则项支持列采样可以自动处理缺失值。如果只是听说过XGBoost的名字而不了解实现细节这题很容易漏选列采样和缺失值处理。2.3 评估指标为什么准确率在有些场景是陷阱关于评估指标的考察已经不是单纯问你准确率和召回率公式了而是放在业务场景里考。比如问在房源推荐场景中用户点击率只有0.5%选择什么指标评估推荐效果最合适。正确方向是AUC或GAUC而不是准确率。原因很简单正负样本极度不平衡时模型把所有样本都预测为负样本准确率依然能达到99.5%。但推荐系统的真实目标是从海量房源中找出用户可能感兴趣的少量item准确率这个指标在这种场景下是失效的。我在复习时整理过一套关于AUC的理解笔试前又强化了一遍AUC的物理意义随机抽取一个正样本和一个负样本模型给正样本打分高于负样本的概率。AUC的取值范围0.5代表随机猜0.5到0.7之间属于弱学习器0.7到0.85之间说明有区分度0.85以上需要考虑是否过拟合。计算方式按预测分数排序用公式或者用梯形法近似。问答题里如果让你设计推荐排序模型评估指标方面除了AUC还要能说出GAUC。GAUC按用户分组计算AUC再加权平均更能反映推荐系统对每个用户的相对好排能力这个点能说出来会加分。2.4 概率统计与线性代数容易被忽略的送分题这一块选择题约4到5题虽然不深但范围很广。考到了极大似然估计的基本思想、朴素贝叶斯条件独立性、期望与方差的运算性质还有一道矩阵特征值的题。概率题里典型的一道假设患某种疾病的概率是0.1%检测试剂的敏感性是99%特异性假阳性率是1%一个人检测结果为阳性问他真正患病的概率是多少。这是贝叶斯公式的经典应用题。计算过程是P(患病) 0.001P(阳性|患病) 0.99P(阳性|未患病) 0.01代入贝叶斯公式 P(患病|阳性) 0.99 × 0.001 / (0.99 × 0.001 0.01 × 0.999) ≈ 9.02%这个结果让很多人意外——即使检测阳性真患病的概率也不到10%。原因在于人群基数大假阳性数量远远超过真阳性。这种题考察的不是计算能力而是对先验概率和后验概率关系的直觉。线性代数方面推荐系统矩阵分解、PCA降维这些内容都有可能涉猎。重点掌握特征值分解、奇异值分解的几何意义和基本计算不用陷入太深的推导。3. 编程题复盘从题目到AC的完整推演3.1 考场环境在线评测的那些隐藏规则贝壳的笔试用的在线评测系统和牛客、赛码这类平台类似。虽然题目不会要求你写标准输入输出格式的解释性文字但有几个考场细节如果不知道第一题可能就卡十几分钟。第一语言选择。系统支持C、Java、Python、Go等主流语言但Python版本和第三方库有限制别指望能用numpy。所有算法题都需要纯Python手写数据结构只能用list、dict、deque这些基础容器。第二输入读取方式。必须用sys.stdin.readline()循环读取而不是一次性的input()。多组测试用例时input()的性能会拖后腿导致超时。第三输出格式。题目如果要求每个数占一行或数字之间用空格分隔严格按照要求来。输出末尾多了空格也可能判错。3.2 第一道编程题最长不含重复字符的子字符串这是印象中比较有代表性的一道题也是每家互联网公司常考的原型题在LeetCode上是第3题。题目描述是给定一个字符串找出其中不含有重复字符的最长子串的长度。输入示例abcabcbb输出3因为最长无重复子串是abc。这道题最直观的解法是暴力枚举所有子串时间复杂度O(n²)在字符串长度10万级别的时候必然超时。正确解法是滑动窗口哈希表时间复杂度O(n)。我当时的实现思路import sys def length_of_longest_substring(s: str) - int: # 用字典记录每个字符最近一次出现的位置 last_pos {} left 0 max_len 0 for right, ch in enumerate(s): # 如果字符在窗口内出现过移动左边界 if ch in last_pos and last_pos[ch] left: left last_pos[ch] 1 # 更新字符最近出现位置 last_pos[ch] right # 更新最大长度 max_len max(max_len, right - left 1) return max_len data sys.stdin.readline().strip() print(length_of_longest_substring(data))这道题有几个容易写错的边界条件字符串为空max_len初始为0直接返回0没问题但要确保代码不抛异常。所有字符都相同比如aaaaleft会不断调整到当前位置max_len始终为1。last_pos[ch] left 的判断如果不加这个条件当字符在滑动窗口之外出现过时left会被错误地回退。考场上的一个教训是第一遍写完后别急着交自己补一个全部字符都相同的测试用例和空字符串用例跑一遍这两个边界最容易挂。3.3 第二道编程题TopK类问题业务感拉满第二道编程题很有意思带了一点业务背景。大意是给定n条带看记录每条记录包含楼盘ID和带看时间要求输出带看次数最多的k个楼盘ID按带看次数降序输出如果次数相同按ID升序。这类题的核心考点是hashmap统计频次 TopK选择。TopK可以用排序做也可以用堆做。我用的解法是先统计频次再用最小堆维护大小为k的堆最后取出堆中元素。import sys import heapq def solve(n: int, k: int, records) - list: freq {} for record in records: # record格式: id bid record freq[bid] freq.get(bid, 0) 1 # 构建最小堆堆内元素为(次数, id) heap [] for bid, cnt in freq.items(): if len(heap) k: # 次数为负数实现最大堆效果次数相同则id小的优先级高 heapq.heappush(heap, (-cnt, bid)) elif (-heap[0][0], heap[0][1]) (cnt, bid): heapq.heappop(heap) heapq.heappush(heap, (-cnt, bid)) result sorted(heap, keylambda x: (x[0], x[1])) return [bid for _, bid in result] if __name__ __main__: data [] for line in sys.stdin: data.append(line.strip()) n int(data[0]) k int(data[1]) records data[2:2n] result solve(n, k, records) for bid in result: print(bid)这道题有两个坑Python的heapq默认是小顶堆要找最大的k个直接把负数放进堆里就行。但如果我还想按次数降序、ID升序输出就需要仔细设计堆内的比较元组光是(次数, ID)的排序逻辑就够写错一次的。堆的比较规则元组先比较第一个元素再比较第二个元素。如果我把(-cnt, bid)入堆那么堆顶永远是次数最小取负后值最大或者ID最大的元素出堆的时候要注意顺序。另外要说一句这种TopK题看上去很简单但越简单的题越容易在细节上扣分。贝壳的笔试评测系统比较严格时间复杂度过高的暴力解法虽然能过部分用例但在大数据量用例上会超时。所以看到TopK先想堆而不是排序这是基本素养。3.4 编程题的整体策略暴力解法的价值有一个很真实的经验在线笔试的得分机制通常是按通过的测试用例比例给分。也就是说就算你只写出暴力解也能拿到一部分用例的分数。贝壳的第一批笔试里有一道偏向动态规划的题我当时第一时间没想出来最优解就先写了一个指数级的暴力搜索然后又跑了一下小数据用例确认输出正确后再去优化。做题顺序上我的建议是先看所有编程题的题目描述判定难度梯度。先把最有把握的满分题写完并测试通过。再集中时间攻克中等难度题优先写出暴力版本保底。最后剩时间再去想优化不要在一开始就死磕最难题。4. 数据挖掘场景题把居住服务业务翻译成建模任务4.1 带看转化率预估样本不平衡怎么设评估指标贝壳的场景问答题中带看转化率预估这个方向出现的概率相当高。原因很简单带看是房产交易中非常关键的中间环节——用户从线上浏览到线下看房每一次带看都意味着经纪人和用户的时间投入如果能对带看概率做准确预估平台就能优化经纪人的资源分配和用户推荐策略。题目大致这样问给定一批用户与房源的交互行为数据目标是对每一对用户-房源预测其产生带看的概率。正样本产生带看的占比约为0.2%请问你会怎么建模选择什么评估指标这类题的答题框架我建议按问题定义、样本构建、特征工程、模型选型、评估指标、上线方案六步回答。每一部分写清楚思路问题定义这是二分类问题但本质上是排序问题。业务上更关心的是在有限的经纪人服务能力下优先触达带看概率最高的用户。样本构建正样本是曝光后产生带看的用户-房源对。负样本不能只看曝光未带看因为存在还没到决策时机的情况要注意观察窗口的设计。比如选择曝光后7天内是否带看作为label避免时间截断偏差。特征工程用户特征历史房源浏览量、历史带看次数、所在城市、购房偏好户型/面积/总价区间房源特征房源价格、面积、户型、楼层、朝向、小区品质评分、周边配套交叉特征用户偏好户型与房源户型是否匹配、用户预算与房源价格差上下文特征推荐位次、所属频道、城市等级、时间特征模型选型常规方案是GBDT/XGBoost/LightGBM也可以尝试深度模型如DIN/DIEN但需要足够的样本量。工业界更常用的是LightGBMLR/WideDeep的组合。评估指标正样本占比0.2%准确率必然虚高。应该用AUC评估排序能力同时关注PR曲线下的面积AUPRC以及TopK命中率——比如平台只会给用户展示10个推荐位那就要看带看转化率预估Top10里的真实带看覆盖率。上线方案离线评估通过后小流量AB实验观察带看率、经纪人响应效率、用户满意度等指标。这一类题目其实没有标准答案面试官看重的是你有没有完整闭环的建模思维。只写用XGBoost建模用AUC评估这种三行字肯定拿不到高分。4.2 房源推荐冷启动从用户搜索词到候选集扩展另一个场景题考的是推荐冷启动。给你一个新用户只在平台上搜索过一次北京朝阳区 三居室 800万以内没有任何点击和带看记录请设计一个推荐策略。这个问题核心在如何从稀疏的单一信号扩展到丰富的候选集。我当时的大体思路是分三路召回第一路文本匹配把搜索词解析成结构化条件包括城市北京、区域朝阳、户型三居、总价上限800万直接从房源库中筛选出满足硬性条件的房源。第二路相似房源扩展基于楼盘字典、房源属性之间的相似度找到与目标房源风格相近的房源。比如用户在搜索三居室可以尝试推荐同小区或周边小区的三居/四居室用户预算在800万以内可以适当扩展到850万以内的房源。第三路热门兜底如果以上两路候选集太小使用平台热门房源、精选房源作为冷启动的兜底内容。排序阶段因为缺少用户行为数据更多依赖规则和热度信号比如房源质量分、房天下指数、周边配套评分、距离地铁站距离、经纪人响应速度等做一个加权打分。这道题背后的考察点是冷启动的本质是信号稀疏你的核心任务是构建信号扩展路径而不是急着一上来就训练深度学习模型。4.3 房价预估模型特征工程的经验陷阱房价预估也是贝壳的典型业务问题。问题通常是给定一个城市过去两年的二手房成交记录包括小区、面积、朝向、楼层、房龄、装修、成交时间、成交总价预测一套新上架房源的合理挂牌价。你会做哪些特征工程用什么模型怎么处理异常值这类题的得分点不在模型而在特征工程和异常值处理的细节上。特征工程的关键维度时间特征成交月份、季节用来捕捉房价的季节性波动面积区间化50平米以下、50-90、90-120、120以上不同面积段单价差异明显楼层/朝向独热顶层和中间楼层的价差、朝南朝向的溢价小区聚合特征小区近180天成交均价、成交量、中位数单价周边配套学区属性、地铁距离、商圈距离时间衰减按成交时间加权近3个月的数据权重高半年前的数据权重低这里有个容易犯的错误直接把面积和总价同时放进模型训练。这两个变量高度线性相关模型会把几乎全部权重都放在面积上小区位置、品质这些同样重要的信息反而学不到。更合理的做法是单价作为预测目标面积作为特征或者预测总价但通过log变换等方式把量纲差拉平。异常值处理是另一个得分点。二手房成交记录里经常出现1元成交、车位单独成交这类特殊样本。我的处理方式是删除单价和总价在1%和99%分位数之外的极端值。通过小区内单价比对剔除单价与小区中位数偏差超过3倍标准差的数据。保留明显偏高的样本可能是学区房加成盲目剔除会损失真实模式。模型选型常规选择是LightGBM因为它对数值型特征的非线性拟合能力强、训练速度快、支持缺失值处理。价格预测的评价指标常用MAPE平均绝对百分比误差和RMSE面试时要能说清楚为什么不用准确率这种分类指标。5. SQL与大数据题数据挖掘工程师的隐形门槛5.1 为什么算法岗笔试还要考SQL很多人会有疑惑我做机器学习为什么还要写SQL答案很简单——数据挖掘工程师日常工作中数据提取和预处理占掉的时间比重非常高。贝壳的房源数据分散在几十张表里你不会SQL连训练样本都抽不出来更别说建模了。贝壳这套题里SQL占1到2题分值不低而且直接手写代码几乎没有含糊空间。5.2 连续N天登录用户窗口函数的标准写法有一道题考的是连续活跃用户这也是各大公司SQL题的经典套路。题目大意给定用户登录日志表login_log(user_id, login_date)找出连续3天及以上有登录记录的用户。这类题几乎只有一个标准解法使用row_number()窗口函数按用户分组、按日期排序生成序号然后计算日期减去序号得到一个分组标识连续日期会落在同一个分组标识里。WITH t1 AS ( SELECT user_id, login_date, row_number() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log ), t2 AS ( SELECT user_id, login_date, date_sub(login_date, INTERVAL rn DAY) AS diff_date FROM t1 ) SELECT user_id FROM t2 GROUP BY user_id, diff_date HAVING COUNT(*) 3;这个解法背后的原理是对于连续的日期每行序号加1日期也加1两者差值保持不变一旦出现断档差值就会变化。理解了原理就不仅能写连续3天还能扩展成连续7天、连续30天。有个容易出错的地方如果登录日志里同一天有重复记录需要先对(login_date, user_id)去重否则日期和序号对应不上。可以在外层加DISTINCT。5.3 每组TopN分城市统计成交榜Top3板块这道题和业务走得比较近给定二手房成交记录house_deal(name, city, district, deal_amount)要求统计每个城市成交量Top3的城区。MySQL 8.0和主流在线评测环境都支持窗口函数直接用rank()或者dense_rank()按城市分组建序。WITH t1 AS ( SELECT city, district, COUNT(*) AS deal_cnt, ROW_NUMBER() OVER (PARTITION BY city ORDER BY COUNT(*) DESC) AS rn FROM house_deal GROUP BY city, district ) SELECT city, district, deal_cnt FROM t1 WHERE rn 3;这道题有三个考点先聚合再开窗窗口函数里不能直接用COUNT(*)需要先在GROUP BY里算出每个城区的成交量再在子查询里对聚合结果排序。RN 3的选择如果要求并列情况全部输出要用rank()如果只要第1到第3名各一个用row_number()。题目通常会说清楚但如果没有说清楚优先使用rank()更安全。NULL处理如果district字段有NULL值分组时会单独成组。真实业务中通常需要过滤掉这类脏数据。5.4 SQL题的通用审题技巧考场上的SQL题建议先冷静读两遍题目把表结构、连接字段、聚合粒度、过滤条件、排序方式这五要素写下来再动手。写SQL最容易犯的错是连接条件写错比如用户表和日志表关联的时候多关联了一层导致数据重复膨胀。还有一个经验写完SQL后自问一句如果同一用户在一天内有多条记录结果会不会错。很多SQL题的隐藏考点就是去重。真实数据不是教科书的干净数据这个意识会帮你避开很多坑。6. 时间分配与应试策略一次真实考场的踩坑记录6.1 题目顺序决定心态心态决定发挥我这次踩过的一个大坑是前面的选择题花的时间太多导致后面编程题的时间被压缩了。回头算账20道选择题我做了将近40分钟平摊到每道题2分钟但实际很多题应该10秒就能判断的。考后反思正确的节奏应该是模块建议用时核心策略选择题20-25分钟会就选不会标记跳过不要恋战SQL题20-25分钟先搭框架再写细节特别注意去重编程题40-50分钟先暴力保底再逐步优化场景问答题20-30分钟按六步框架写宁可多写思路不写废话这个顺序也有讲究我建议把问答题放在编程题之前。原因是问答题不需要调试环境想到多少写多少越写思路越开阔而编程题容易卡住一旦卡住半小时就没了会严重影响后面的状态。6.2 选择题的取舍策略别让完美主义毁掉后面选择题里的多选题是最容易丢分的选错一个选项就是零分少选可能只拿部分分。对于不确定的选项我的策略是如果完全没把握宁可少选不要多选。因为多选一个错误选项全题零分少选一个可能还有部分分。知识点覆盖上优先保证机器学习基础这一块的正确率。贝壳选择题的理论深度适中没有到让非数学系的人无从下手的地步。但前提是你真的理解而不是死记硬背。6.3 编程题的稳比快更重要编程题最怕的不是不会而是会但写错。我写第一道滑动窗口题时本来思路是对的但手滑把left的更新条件写成了last_pos[ch] left而不是导致重复字符被错误地跳过。这种题目根本没有报错提示逻辑错误只能靠自测用例发现。所以我强烈建议写完每道编程题都要自己构造3个测试用例做一次手算验证。一个正常输入、一个边界输入空/单元素、一个极端输入全重复/全递增。这个习惯在在线笔试中能帮你挽回大量无谓的失分。另外如果考场提供的在线编辑器有本地运行或者自测功能一定要用。没有的话就在脑子里模拟运行一遍代码流程把关键变量的变化过程走一遍。6.4 心态管理的两个细节第一个细节是做完一题清零一题。在线笔试系统不像面试有回看的机会很少与其纠结上一题哪个用例没过不如把精力放在下一题上。第二个细节是最后5分钟不要写新代码。这时候大概率是匆匆忙忙写出来的残次品反而容易把原本可以通过的答案覆盖掉。最后几分钟应该用来检查编程题的输出格式和SQL题的语法拼写。7. 复盘后的备考路线别再用期末复习的思路准备秋招7.1 知识主干两本书一本都不能只读一遍考完贝壳这套题我对备考资料的认知有了一次刷新。很多同学还在拿机器学习期末复习的思路准备秋招把周志华《机器学习》和李航《统计学习方法》里的公式从头推导一遍推导完觉得自己无敌了一到笔试写代码就抓瞎。我的体会是这两本书的定位完全不同周志华《机器学习》构建知识框架西瓜书胜在覆盖面广从线性模型、决策树到集成学习、聚类、降维都有。读这本书的目标是看到题目知道考哪个模块并理解每个模型的核心假设。李航《统计学习方法》深入理解经典算法尤其是感知机、逻辑回归、SVM、EM算法、隐马尔可夫模型这些推导细节。这本书适合精读每个算法的损失函数、优化方法、收敛性都要能用自己的话讲一遍。但光读这两本远远不够。笔试真正拉开差距的是代码能力和业务建模能力这两个能力只能靠输出来训练——写代码、写SQL、写方案。7.2 建立业务场景→算法选型的映射表我在复盘贝壳这套题时整理了一张映射表对后续面试帮助很大业务问题典型算法/工具关键评估指标房源推荐召回ItemCF/向量召回 排序LightGBM/DIN点击率、AUC、GAUC价格预估LightGBM/回归树MAPE、RMSE带看转化预估LightGBM/逻辑回归PR-AUC、TopK命中率文本搜索BM25/向量检索NDCG、MRR异常检测孤立森林/统计阈值精确率、召回率经纪人分单匹配评分模型配对成功率、效率提升这种映射表的用处在于笔试场景题给你一个业务问题你能很快定位到这是推荐问题、预估问题还是匹配问题然后顺藤摸瓜写出完整方案。7.3 编程题的刷题策略高质量重复胜过大范围覆盖针对算法笔试我推荐的刷题顺序是LeetCode Hot 100两遍以上第一遍按题型刷第二遍随机打乱。高频题优先数组、字符串、哈希表、双指针、滑动窗口、二叉树、动态规划。SQL专项牛客SQL实战题库每天3到5题重点练窗口函数。模拟笔试每周至少一次2小时全真模拟用牛客或者赛码的在线环境。贝壳这次考到了滑动窗口、TopK、动态规划、SQL连续登录全部都在高频题型范围内。没有偏题怪题说明出题人是希望通过笔试筛出基础扎实的人而不是筛刷过偏门题库的人。7.4 针对贝壳的独特准备点如果你确定要投贝壳的数据挖掘岗有一个加分项容易被忽略提前了解贝壳的业务术语和数据体系。比如楼盘字典真房源VR带看经纪人合作网络。这些名词不是考点本身但它们会出现在场景题的题干背景里。如果你对这些概念有基本认知读题速度和理解深度都会不一样。我在笔试前花了两小时看贝壳的公开资料和典型业务功能介绍后来写场景题的时候明显能感觉到对房源、带看、经纪人效率这些环节的敏感度高了很多。这种准备不会直接告诉你答案但它能让你在场景题里写出更贴合实际业务的方案而不是一套放之四海皆准的空话。7.5 最后一条实用建议考完贝壳这套题我最大的感受是笔试考察的不是你会什么而是你在有限时间内能调用出什么。知识储备是地基代码能力是手脚业务思维是眼睛。三者缺一成绩都会打折扣。如果你还在备战秋招我的建议是拿一套往届真题做一次完整的全真模拟严格计时不允许中途查资料。第一次模拟的成绩大概率不理想但那不重要——重要的是通过模拟暴露自己在时间分配和知识点切换上的短板。我在第一次模拟的时候选择题用了45分钟编程题只写完一题半惨不忍睹。正是那次教训让我在后面真正参加贝壳笔试时能有意识地控制节奏。笔试是个熟能生巧的活练得多了手感自然就来了。整理这份复盘也是给自己留个存档方便后续面试时复盘这些高频考点。希望正在准备秋招的你看完这篇能少走一点弯路。