企业官网建设流程全解析

2024届秋招刚拉开帷幕，贝壳找房就放出了第一批机器学习/数据挖掘工程师的笔试。我第一时间报名参加，考完之后最大的感受是：这套卷子不是单纯考你会不会背模型公式，而是考你能不能在限时高压下，把机器学习、数据挖掘、SQL和工程代码整合到一起解决真实问题。整理这份复盘，是因为贝壳这套题很有代表性——它兼顾了算法基础、业务理解和coding能力，对准备互联网大厂算法岗、数据挖掘岗秋招的同学都有很强的参考价值。无论你是2025届在校生，还是正在跳槽的数据从业者，这篇内容都能帮你厘清复习重点和考场策略。

1. 贝壳这套笔试题，到底在考什么

1.1 贝壳的数据岗位，核心业务场景是什么

先说一个最基本的判断：不同公司出的算法题，气质完全不一样。字节爱考动态规划和海量数据处理，快手爱考视频推荐场景下的策略，拼多多偏重工程实现和分布式。贝壳这套题，处处透露出居住服务行业的业务底色。

贝壳找房的业务核心是房产交易和居住服务，覆盖二手房、新房、租赁、家装、物业等场景。数据挖掘工程师在这家公司要解决的核心问题，绕不开这几类：

• 房源画像与真房源治理：房源信息去重、真实性检测、字段补全。
• 推荐与排序：用户看房过程中的房源推荐、探索发现、搜索结果排序。
• 价格预估：房价评估、租金预测、成交周期预估。
• 转化率预估：从浏览到咨询、从咨询到带看、从带看到成交的每一步转化建模。
• 经纪人与运营效率：经纪人工作台排序、客源匹配、服务响应速度优化。

如果你提前想过这些业务场景，再看这套笔试题，就会觉得很多题目是有"出处"的。它不是在真空里考机器学习，而是希望候选人具备把算法落地到具体业务链路里的能力。

1.2 整体题目结构：三模块评价体系

按照我对第一批笔试的回忆以及考后和同学们的交流，整体题量大约在32到35题左右，考试时长120分钟，题型可以分成三个模块：

分值上，编程题和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、AUC）
• SVM与核函数
• 聚类算法与距离度量
• 概率图模型与朴素贝叶斯

其中有一道关于L1和L2正则化的题，印象很深。题目大概是这样描述的：在高维稀疏特征场景下，L1正则化比L2正则化更容易产生稀疏解，问以下哪个说法正确。选项里混着"L1正则化是L2正则化的近似""L2正则化可以让权重严格等于0""L1正则化对异常值更敏感"这类干扰项。

这道题的考点很干净：为什么L1能让权重变成0，而L2只能让权重趋近于0。

我的理解方式是画损失函数和约束条件的等高线图。L1的约束区域是菱形，角点落在坐标轴上，最优解很容易出现在角点位置，对应某些特征的权重为0；L2的约束区域是圆形，边界平滑，最优解一般不会精确落在坐标轴上。换成数学表达：L1正则化的目标函数在零点不可导，梯度下降过程中容易把参数"推"到0；L2正则化的梯度在零点附近是连续的，参数只会被压缩但不会严格归零。

注意：多选题里还有一个陷阱，问你"哪些方法可以有效缓解过拟合"。除了L1/L2、Dropout、数据增强，还有一个选项是"增加模型训练轮数到收敛"，这个不是缓解过拟合，反而是过拟合的催化剂，很多人一着急就把它也选上了。

2.2 决策树与集成学习：从ID3到LightGBM的脉络

贝壳对决策树和集成学习的考察非常细，选择题、问答题都会涉及。选择题里考过一道"CART回归树在做特征分裂时，用的是什么指标"，选项有信息增益、信息增益率、基尼指数、均方误差。这个题其实是在考察CART分类树和回归树的区别：分类树用基尼指数，回归树用均方误差。

集成学习方面，重点放在GBDT和XGBoost的区别上。我的笔记里有一张自己的对比表，笔试前反复看了几遍：

有一道多选题问"XGBoost相比GBDT做了哪些改进"，选项里有"引入了二阶导数""加入了正则项""支持列采样""可以自动处理缺失值"。如果只是听说过XGBoost的名字而不了解实现细节，这题很容易漏选"列采样"和"缺失值处理"。

2.3 评估指标：为什么准确率在有些场景是陷阱

关于评估指标的考察，已经不是单纯问你"准确率和召回率公式"了，而是放在业务场景里考。比如问"在房源推荐场景中，用户点击率只有0.5%，选择什么指标评估推荐效果最合适"。正确方向是AUC或GAUC，而不是准确率。

原因很简单：正负样本极度不平衡时，模型把所有样本都预测为负样本，准确率依然能达到99.5%。但推荐系统的真实目标是从海量房源中找出用户可能感兴趣的少量item，准确率这个指标在这种场景下是失效的。

我在复习时整理过一套关于AUC的理解，笔试前又强化了一遍：

1. AUC的物理意义：随机抽取一个正样本和一个负样本，模型给正样本打分高于负样本的概率。
2. AUC的取值范围：0.5代表随机猜，0.5到0.7之间属于弱学习器，0.7到0.85之间说明有区分度，0.85以上需要考虑是否过拟合。
3. 计算方式：按预测分数排序，用公式或者用梯形法近似。

问答题里如果让你设计推荐排序模型，评估指标方面除了AUC，还要能说出GAUC。GAUC按用户分组计算AUC再加权平均，更能反映推荐系统对每个用户的"相对好排"能力，这个点能说出来会加分。

2.4 概率统计与线性代数：容易被忽略的送分题

这一块选择题约4到5题，虽然不深，但范围很广。考到了极大似然估计的基本思想、朴素贝叶斯条件独立性、期望与方差的运算性质，还有一道矩阵特征值的题。

概率题里典型的一道：假设患某种疾病的概率是0.1%，检测试剂的敏感性是99%，特异性（假阳性率）是1%，一个人检测结果为阳性，问他真正患病的概率是多少。这是贝叶斯公式的经典应用题。计算过程是：

• P(患病) = 0.001
• P(阳性|患病) = 0.99
• P(阳性|未患病) = 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))

这道题有几个容易写错的边界条件：

1. 字符串为空：max_len初始为0，直接返回0，没问题，但要确保代码不抛异常。
2. 所有字符都相同：比如aaaa，left会不断调整到当前位置，max_len始终为1。
3. 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, key=lambda 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:2+n] result = solve(n, k, records) for bid in result: print(bid)

这道题有两个坑：

• Python的heapq默认是小顶堆，要找最大的k个，直接把负数放进堆里就行。但如果我还想按"次数降序、ID升序"输出，就需要仔细设计堆内的比较元组，光是(次数, ID)的排序逻辑就够写错一次的。
• 堆的比较规则：元组先比较第一个元素，再比较第二个元素。如果我把(-cnt, bid)入堆，那么堆顶永远是次数最小（取负后值最大）或者ID最大的元素，出堆的时候要注意顺序。

另外要说一句：这种TopK题看上去很简单，但越简单的题越容易在细节上扣分。贝壳的笔试评测系统比较严格，时间复杂度过高的暴力解法虽然能过部分用例，但在大数据量用例上会超时。所以看到TopK先想堆而不是排序，这是基本素养。

3.4 编程题的整体策略：暴力解法的价值

有一个很真实的经验：在线笔试的得分机制通常是按通过的测试用例比例给分。也就是说，就算你只写出暴力解，也能拿到一部分用例的分数。贝壳的第一批笔试里有一道偏向动态规划的题，我当时第一时间没想出来最优解，就先写了一个指数级的暴力搜索，然后又跑了一下小数据用例，确认输出正确后再去优化。

做题顺序上，我的建议是：

1. 先看所有编程题的题目描述，判定难度梯度。
2. 先把最有把握的满分题写完并测试通过。
3. 再集中时间攻克中等难度题，优先写出暴力版本保底。
4. 最后剩时间再去想优化，不要在一开始就死磕最难题。

4. 数据挖掘场景题：把居住服务业务翻译成建模任务

4.1 带看转化率预估：样本不平衡怎么设评估指标

贝壳的场景问答题中，带看转化率预估这个方向出现的概率相当高。原因很简单，带看是房产交易中非常关键的中间环节——用户从线上浏览到线下看房，每一次带看都意味着经纪人和用户的时间投入，如果能对带看概率做准确预估，平台就能优化经纪人的资源分配和用户推荐策略。

题目大致这样问：给定一批用户与房源的交互行为数据，目标是对每一对"用户-房源"预测其产生带看的概率。正样本（产生带看的）占比约为0.2%，请问你会怎么建模？选择什么评估指标？

这类题的答题框架，我建议按"问题定义、样本构建、特征工程、模型选型、评估指标、上线方案"六步回答。每一部分写清楚思路：

问题定义：这是二分类问题，但本质上是排序问题。业务上更关心的是在有限的经纪人服务能力下，优先触达带看概率最高的用户。

样本构建：正样本是曝光后产生带看的用户-房源对。负样本不能只看曝光未带看，因为存在"还没到决策时机"的情况，要注意观察窗口的设计。比如选择"曝光后7天内是否带看"作为label，避免时间截断偏差。

特征工程：

• 用户特征：历史房源浏览量、历史带看次数、所在城市、购房偏好（户型/面积/总价区间）
• 房源特征：房源价格、面积、户型、楼层、朝向、小区品质评分、周边配套
• 交叉特征：用户偏好户型与房源户型是否匹配、用户预算与房源价格差
• 上下文特征：推荐位次、所属频道、城市等级、时间特征

模型选型：常规方案是GBDT/XGBoost/LightGBM，也可以尝试深度模型如DIN/DIEN，但需要足够的样本量。工业界更常用的是LightGBM+LR/Wide&Deep的组合。

评估指标：正样本占比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. 删除单价和总价在1%和99%分位数之外的极端值。
2. 通过小区内单价比对，剔除单价与小区中位数偏差超过3倍标准差的数据。
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;

这道题有三个考点：

1. 先聚合再开窗：窗口函数里不能直接用COUNT(*)，需要先在GROUP BY里算出每个城区的成交量，再在子查询里对聚合结果排序。
2. RN <= 3的选择：如果要求"并列情况全部输出"，要用rank()；如果只要"第1到第3名各一个"，用row_number()。题目通常会说清楚，但如果没有说清楚，优先使用rank()更安全。
3. NULL处理：如果district字段有NULL值，分组时会单独成组。真实业务中通常需要过滤掉这类脏数据。

5.4 SQL题的通用审题技巧

考场上的SQL题，建议先冷静读两遍题目，把"表结构、连接字段、聚合粒度、过滤条件、排序方式"这五要素写下来再动手。写SQL最容易犯的错是连接条件写错，比如用户表和日志表关联的时候多关联了一层，导致数据重复膨胀。

还有一个经验：写完SQL后，自问一句"如果同一用户在一天内有多条记录，结果会不会错"。很多SQL题的隐藏考点就是去重。真实数据不是教科书的干净数据，这个意识会帮你避开很多坑。

6. 时间分配与应试策略：一次真实考场的踩坑记录

6.1 题目顺序决定心态，心态决定发挥

我这次踩过的一个大坑是：前面的选择题花的时间太多，导致后面编程题的时间被压缩了。回头算账：20道选择题我做了将近40分钟，平摊到每道题2分钟，但实际很多题应该10秒就能判断的。

考后反思，正确的节奏应该是：

这个顺序也有讲究：我建议把问答题放在编程题之前。原因是问答题不需要调试环境，想到多少写多少，越写思路越开阔；而编程题容易卡住，一旦卡住半小时就没了，会严重影响后面的状态。

6.2 选择题的取舍策略：别让"完美主义"毁掉后面

选择题里的多选题是最容易丢分的，选错一个选项就是零分，少选可能只拿部分分。对于不确定的选项，我的策略是：如果完全没把握，宁可少选不要多选。因为多选一个错误选项=全题零分，少选一个可能还有部分分。

知识点覆盖上，优先保证"机器学习基础"这一块的正确率。贝壳选择题的理论深度适中，没有到让非数学系的人无从下手的地步。但前提是你真的理解，而不是死记硬背。

6.3 编程题的"稳"比"快"更重要

编程题最怕的不是不会，而是会但写错。我写第一道滑动窗口题时，本来思路是对的，但手滑把left的更新条件写成了last_pos[ch] > left，而不是>=，导致重复字符被错误地跳过。这种题目根本没有报错提示，逻辑错误只能靠自测用例发现。

所以我强烈建议：写完每道编程题，都要自己构造3个测试用例做一次手算验证。一个正常输入、一个边界输入（空/单元素）、一个极端输入（全重复/全递增）。这个习惯在在线笔试中能帮你挽回大量无谓的失分。

另外，如果考场提供的在线编辑器有"本地运行"或者"自测"功能，一定要用。没有的话，就在脑子里模拟运行一遍代码流程，把关键变量的变化过程走一遍。

6.4 心态管理的两个细节

第一个细节是"做完一题清零一题"。在线笔试系统不像面试，有回看的机会很少，与其纠结上一题哪个用例没过，不如把精力放在下一题上。第二个细节是"最后5分钟不要写新代码"。这时候大概率是匆匆忙忙写出来的残次品，反而容易把原本可以通过的答案覆盖掉。最后几分钟应该用来检查编程题的输出格式和SQL题的语法拼写。

7. 复盘后的备考路线：别再用期末复习的思路准备秋招

7.1 知识主干：两本书，一本都不能只读一遍

考完贝壳这套题，我对备考资料的认知有了一次刷新。很多同学还在拿"机器学习期末复习"的思路准备秋招，把周志华《机器学习》和李航《统计学习方法》里的公式从头推导一遍，推导完觉得自己无敌了，一到笔试写代码就抓瞎。

我的体会是，这两本书的定位完全不同：

• 周志华《机器学习》：构建知识框架，西瓜书胜在覆盖面广，从线性模型、决策树到集成学习、聚类、降维都有。读这本书的目标是"看到题目知道考哪个模块"，并理解每个模型的核心假设。
• 李航《统计学习方法》：深入理解经典算法，尤其是感知机、逻辑回归、SVM、EM算法、隐马尔可夫模型这些推导细节。这本书适合精读，每个算法的损失函数、优化方法、收敛性都要能用自己的话讲一遍。

但光读这两本远远不够。笔试真正拉开差距的是代码能力和业务建模能力，这两个能力只能靠"输出"来训练——写代码、写SQL、写方案。

7.2 建立"业务场景→算法选型"的映射表

我在复盘贝壳这套题时，整理了一张映射表，对后续面试帮助很大：

这种映射表的用处在于：笔试场景题给你一个业务问题，你能很快定位到"这是推荐问题、预估问题还是匹配问题"，然后顺藤摸瓜写出完整方案。

7.3 编程题的刷题策略：高质量重复胜过大范围覆盖

针对算法笔试，我推荐的刷题顺序是：

1. LeetCode Hot 100，两遍以上，第一遍按题型刷，第二遍随机打乱。
2. 高频题优先：数组、字符串、哈希表、双指针、滑动窗口、二叉树、动态规划。
3. SQL专项：牛客SQL实战题库，每天3到5题，重点练窗口函数。
4. 模拟笔试：每周至少一次2小时全真模拟，用牛客或者赛码的在线环境。

贝壳这次考到了滑动窗口、TopK、动态规划、SQL连续登录，全部都在高频题型范围内。没有偏题怪题，说明出题人是希望通过笔试筛出"基础扎实"的人，而不是筛"刷过偏门题库"的人。

7.4 针对贝壳的独特准备点

如果你确定要投贝壳的数据挖掘岗，有一个加分项容易被忽略：提前了解贝壳的业务术语和数据体系。比如"楼盘字典""真房源""VR带看""经纪人合作网络"。这些名词不是考点本身，但它们会出现在场景题的题干背景里。如果你对这些概念有基本认知，读题速度和理解深度都会不一样。

我在笔试前花了两小时看贝壳的公开资料和典型业务功能介绍，后来写场景题的时候，明显能感觉到对"房源、带看、经纪人效率"这些环节的敏感度高了很多。这种准备不会直接告诉你答案，但它能让你在场景题里写出更贴合实际业务的方案，而不是一套放之四海皆准的空话。

7.5 最后一条实用建议

考完贝壳这套题，我最大的感受是：笔试考察的不是"你会什么"，而是"你在有限时间内能调用出什么"。知识储备是地基，代码能力是手脚，业务思维是眼睛。三者缺一，成绩都会打折扣。

如果你还在备战秋招，我的建议是拿一套往届真题做一次完整的全真模拟，严格计时，不允许中途查资料。第一次模拟的成绩大概率不理想，但那不重要——重要的是通过模拟暴露自己在"时间分配"和"知识点切换"上的短板。我在第一次模拟的时候，选择题用了45分钟，编程题只写完一题半，惨不忍睹。正是那次教训，让我在后面真正参加贝壳笔试时能有意识地控制节奏。

笔试是个熟能生巧的活，练得多了，手感自然就来了。整理这份复盘，也是给自己留个存档，方便后续面试时复盘这些高频考点。希望正在准备秋招的你，看完这篇能少走一点弯路。