企业官网建设流程全解析

贝壳找房2023届校招算法卷1，这套题我刷完之后的第一反应是：出题人真的很懂“既要又要”——既要考察基本功扎不扎实，又要看你在真实业务场景里能不能把算法用起来。对比同一年其他大厂的校招算法题，贝壳这套卷子不算刁钻，但覆盖面很广，代码题、机器学习基础、深度学习原理、业务场景设计都有涉及，而且有些题目表面在考算法，实际上在考你对复杂度的敏感度、对数据分布的理解，甚至是对推荐系统、房产匹配这类业务逻辑的直觉。

这篇文章我就以这套卷子为线索，把题目背后真正想考察的点拆开揉碎了讲。不管你是正在备战校招的应届生，还是想查漏补缺的算法工程师，都能在这里找到一些比“刷题”更值钱的东西。

1. 贝壳这套算法卷到底在考什么：整体题型与策略复盘

先给还没做过这套题的同学一个整体认知。贝壳找房2023届校招算法卷1的题型结构基本是这样的：选择题（覆盖数据结构、机器学习、深度学习基础）、手写代码题（2-3道，难度从中等到偏难）、简答/设计题（涉及业务场景和算法原理推导）。整体时间大概120分钟，题量不算特别大，但如果你在选择题上磨蹭太久，代码题很容易写不完。

我自己的感受是，这套卷子最核心的考察点有两个：一是基础算法的熟练度，二是对算法边界条件的敏感度。很多同学刷题喜欢背模板，但贝壳的出题风格是“模板题换个马甲”——比如KMP不直接让你求next数组，而是让你在字符串匹配场景里处理特定模式串；排序不直接让你手写快排，而是结合稳定性、时间复杂度让你选方案。这种出法其实比LeetCode原题更贴近真实工作，因为你平时写代码也不会有人告诉你“这题用DP”，一切都得自己判断。

从准备策略来讲，我建议按这个优先级来分配精力：代码题 > 机器学习基础 > 深度学习原理 > 业务设计题。代码题是硬通货，写不出来基本就凉了；机器学习基础决定你的上限，选择题里大量送分题和陷阱题都集中在这里；深度学习原理通常考得比较浅，主要是CNN、RNN、Transformer这些常规内容；业务设计题反而不用太紧张，因为大家都没什么经验，能给出合理的分析框架就算赢。

1.1 选择题部分的隐藏陷阱：看似送分实则杀人的高频考点

贝壳这套卷子的选择题我印象很深，因为它不是那种“一眼就能看出答案”的题，而是每个选项都经过了精心设计，专门用来区分“真懂”和“背过”的选手。

举几个例子。数据结构的题里考了“在KMP算法中，对于模式串p=‘abacaba’，其next数组的值”，这题如果你只是背了next数组的定义（next[i]表示模式串前i个字符组成的子串的最长相等前后缀长度），很容易算错。因为不同的教材对next数组的下标起始定义不一样，有的从0开始，有的从1开始，有的还要整体减1。我当时就差点在这个细节上翻车，后来总结了一个习惯：做KMP相关的题，第一步永远是确认next数组定义，而不是急着算。这就像你接了一个需求，第一步永远是确认输入输出格式，而不是急着写代码。

还有个选择题考了排序算法的稳定性，选项里有冒泡排序、堆排序、快速排序、归并排序。这题本身不难，但出题人加了一个干扰条件：“要求时间复杂度为O(n log n)且稳定”。很多人一看O(n log n)就选了快排，忘了快排是不稳定的。正确答案是归并排序。这类题考察的不是你会不会写排序，而是你脑子里有没有一张“排序算法全景图”——时间复杂度、空间复杂度、稳定性、适用场景四个维度都要能随时调用。

深度学习的选择题也很有意思，比如考了ReLU激活函数在x<0时的梯度，很多人知道是0，但题目继续追问“这会导致什么问题”，答案是“神经元死亡”。这种连环追问的设计思路就是：如果你只背了ReLU的公式而没有理解它的梯度传播特性，第二问必错。我建议大家在复习激活函数的时候，不要只记公式，把每个激活函数的公式、导数、梯度范围、优缺点、适用场景做成一张表，这样不管选择题怎么变着法考，你都能接住。

1.2 手写代码题的常见翻车点与做题节奏

贝壳这套卷子的代码题，我做完之后最大的感触是：它考的算法本身不冷门，但每个题都有至少一个“坑”。这些坑不是算法层面的，而是工程习惯层面的——比如边界条件处理、数据结构的选择、空间复杂度的优化。

举个例子，有一道题是典型的DP（动态规划），但题目描述很长，里面藏了一个条件：“每个位置只能向右或向下走”。很多同学读完题就开始写状态转移方程，结果忽略了“只能向右或向下”意味着这是一个DAG（有向无环图），可以用更简单的递推解决，根本不需要记忆化搜索。我当时是先花了30秒画了一个简单的状态图，确认了递推关系后才动手写的，这样写出来的代码不仅简洁，而且不容易出Bug。

做题节奏方面，我强烈建议：先花3-5分钟把三道代码题全部看一遍，再决定先做哪道。贝壳的题目难度排序不一定是递增的，有时候第一道就是最难的。我的习惯是先挑一道“思路最清晰”的题来做，比如一眼就能看出是二分答案或者滑动窗口的题，做完拿到保底分，再啃难题。这样即使最后时间不够，也不会出现“前面耗时太久、后面送分题没写”的惨剧。

还有一个小技巧想分享给正在准备校招的同学：写代码题的时候，一定要在开头注释里写清楚你的思路，比如“使用双指针，时间复杂度O(n)，空间复杂度O(1)”。一方面，这是给面试官看的，展现你的思维过程；另一方面，如果你写到一半卡住了，回头看一眼注释能帮你快速找回思路。我见过太多同学一上来就狂敲代码，写着写着忘了自己在干什么，这种情况在考试压力下太容易发生了。

3. 手写代码题专题：KMP、排序与动态规划的实战解题思路

代码题是算法笔试的硬骨头，贝壳这套卷子也不例外。我抽三道代表性题目来详细讲讲解题思路，这三道题分别对应字符串匹配（KMP）、排序算法、动态规划三个高频考点，把它们吃透，基本就能覆盖贝壳这类大厂校招代码题80%的套路。

3.1 KMP算法：next数组不再是背出来的公式

“在KMP算法中，对于模式串p=‘abacaba’，其next数组的值”这道题，我上面已经提过，但值得展开讲讲。不同教材对next数组有两种常见定义：一种是next[i]表示“模式串前i个字符组成的子串的最长相等真前后缀长度”（即不包含自身）；另一种是next[i]表示“当第i个字符失配时，模式串应该回退到的位置”，这时通常会对第一种定义做整体减一或整体加一的处理。

我的解题习惯是直接基于定义来做，不背代码。对于p = “abacaba”，先求每个前缀的最长相等真前后缀长度：

• p[0:1] = “a”，真前后缀为空，最长长度为0；
• p[0:2] = “ab”，真前后缀为空，最长长度为0；
• p[0:3] = “aba”，真前缀有“a”，真后缀有“a”，最长长度为1；
• p[0:4] = “abac”，最长长度为0；
• p[0:5] = “abaca”，真前缀“a”匹配真后缀“a”，最长长度为1；
• p[0:6] = “abacab”，真前缀“ab”匹配真后缀“ab”，最长长度为2；
• p[0:7] = “abacaba”，真前缀“aba”匹配真后缀“aba”，最长长度为3。

所以next数组（不含自身的最长相等前后缀长度）就是[0, 0, 0, 1, 0, 1, 2, 3]（注意数组下标从0到7，长度为8）。如果题目采用“失配时回退位置”的定义，则需要另算。我的经验是：在考场上如果遇到这类题，先想清楚题目给的next数组定义是哪个版本，再动笔算。算的时候用“画前缀后缀匹配图”的方式，不要脑内空转，这样即使模式串再长，也不容易出错。

3.2 排序算法：从“会写”到“会选”

贝壳这套卷子的排序题考察方式比较灵活，不是简单让你手写快排，而是给出一个具体业务场景让你选排序算法。比如有一个题目大概意思是：有一批房源数据需要按价格从低到高排序，但数据量很大，无法一次性加载到内存，该用什么排序算法？

这类题目考察的是外部排序的概念。当数据量超过内存容量时，常规的QuickSort、MergeSort都不能直接使用，因为它们的递归调用或辅助数组需要大量内存空间。这时候应该通过“分割-排序-归并”的思路，把数据分块读入内存，每块排序后写入磁盘，最后进行多路归并。这就是早期数据库系统用到的外部排序思路，贝壳的房源数据量和数据库系统里的情况很像，出题人是有意把业务场景和经典算法结合在一起来考察的。

再比如，有题给了这样几种排序算法：冒泡排序、堆排序、归并排序、快速排序，问哪个是稳定的、哪个在基本有序的数组上效率更高。这几个问题的标准答案大家都能背出来：稳定的有冒泡和归并；基本有序数组上插入排序效率最高（O(n)），但选项里如果没有插入排序就选冒泡或快排的优化版本。但我要提醒的是：考试中遇到排序题，先审题看选项，不要默认题目在考“手写代码”。贝壳不少排序题都是选择题，考的是你对排序算法特性的横向对比能力，而不是背代码能力。

3.3 动态规划：从状态定义到边界条件的完整推导

贝壳的DP题难度中等偏上，不会出特别冷门的题目，但会在状态定义上做文章。我遇到的一道题大概是：给定一个网格，每个格子有一个代价，从左上角走到右下角，只能向右或向下，求最小代价路径。

这道题的核心解法非常经典，设dp[i][j]表示从左上角走到格子(i,j)的最小代价，转移方程为： dp[i][j] = grid[i][j] + min(dp[i-1][j], dp[i][j-1]) 需要注意的边界条件是：第一行只能从左边走过来，所以dp[0][j] = grid[0][j] + dp[0][j-1]；第一列只能从上面走下来，所以dp[i][0] = grid[i][0] + dp[i-1][0]。初始化时dp[0][0] = grid[0][0]。

写代码时最常犯的错误是数组越界——很多人会在循环里直接处理所有格子，忘了单独处理第一行和第一列。我的建议是：不用在循环里做一堆if判断，直接先初始化第一行和第一列，再对i>=1且j>=1的格子做双重循环。这样代码会更清晰，也能避免越界。这类题目反映出贝壳对代码细节的重视，不是写得出转移方程就完事了，还得写得干净、不出错。

3.4 手写代码时容易被忽略的复杂度分析

我在贝壳这套卷子的代码题答题区，每一道题都写了两行注释：时间和空间复杂度。比如上面这道网格DP题，我就写了“时间复杂度O(m×n)，空间复杂度O(m×n)”。如果要优化空间，通常可以用滚动数组把空间复杂度降到O(n)（只用一行的dp值），因为dp[i][j]只依赖当前行左边和上一行的同一个位置。

写复杂度分析，不完全是给面试官看的，也是逼自己思考“这个解法是不是最优的”的方法。有时候你写着写着发现某一步空间复杂度可以优化，顺便就能提升整个方案的含金量。在笔试里，同样是AC的代码，能写出“空间O(n)的优化解法”和只能写出“空间O(mn)的朴素解法”，在面试官心里的评分是完全不同的。贝壳这种大厂尤其看重代码质量，不是“能跑就行”，而是“跑得漂亮”。

4. 机器学习与深度学习考点：从原理推导到场景应用的完整链路

贝壳作为一家以居住服务为核心业务的公司，算法岗位的考察范围很广，但机器学习、深度学习相关的内容占了相当大的比重。这部分选择题和简答题的设计思路，明显是“从原理中来、到场景中去”——既考你对基础公式的理解，又考你能不能把算法用在实际业务里。

4.1 机器学习基础：从线性回归到集成学习的核心原理

贝壳这套卷子的机器学习部分，覆盖了线性回归、逻辑回归、决策树、SVM、聚类、集成学习等常规考点。题目本身不难，但有些细节要特别注意。

举个例子，关于逻辑回归，有一道题问的是“为什么逻辑回归的损失函数不用均方误差而用交叉熵”。这个问题几乎是机器学习面试必考题。直接原因很简单：逻辑回归的预测值是sigmoid函数的输出，如果用MSE作为损失函数，损失函数是一个非凸函数，用梯度下降法容易陷入局部最优；而交叉熵损失与sigmoid组合后，损失函数是凸函数，梯度下降能保证收敛到全局最优。更深层次的原因是：MSE假设误差服从高斯分布，而逻辑回归的标签实际上是伯努利分布，交叉熵才是对应伯努利分布的最大似然估计。所以这道题表面在考损失函数，实际上在考你对“模型假设-损失函数-优化方法”三者关系的理解。

还有一个高频考点是集成学习。题目常常会给出Bagging和Boosting的对比，比如随机森林和XGBoost分别属于哪一类、它们的区别是什么。我的回答套路是：先从“降低方差 vs 降低偏差”的角度切入，随机森林通过并行训练多个决策树并平均结果来降低方差，XGBoost通过串行训练多个弱学习器并不断拟合残差来降低偏差。然后再补充一个业务场景的例子：在贝壳的房源估价业务中，如果特征维度很高、存在大量缺失值，随机森林的表现通常更稳定；而如果对预测精度要求极高、且训练数据足够多，XGBoost往往更有优势。这样回答既展示了原理理解，又展示了业务思维，非常加分。

再聊聊KNN算法，这是热搜词里也提到的点。KNN在贝壳这类业务中其实很常用，比如推荐相似房源：给定一个房源的特征向量（价格、面积、户型、所在商圈等），KNN可以找出距离最近的K个房源作为相似推荐。这里有一个容易被忽视的细节：KNN对特征的量纲非常敏感。如果面积是几十到几百的数值，而价格是几百万的数值，直接算欧式距离，价格会完全主导距离计算，面积的影响会被淹没。所以做KNN之前一定要做特征标准化，要么用StandardScaler（归一化到均值为0方差为1），要么用MinMaxScaler（缩放到[0,1]区间）。我在实际项目里还经常用L2归一化来处理文本特征，效果也不错。

4.2 深度学习：CNN、RNN/Transformer的结构特点与适用场景

贝壳对深度学习的考察深度不算特别深，但很重视“这个模型能解决什么问题”以及“和业务怎么结合”。最常见的题目是让你对比CNN、RNN、Transformer的优缺点，或者让你给一个具体业务场景选型。

以CNN为例，它的核心特点是局部连接和权值共享，天然适合处理网格结构数据，比如图像和序列数据。在贝壳的业务里，CNN可以用于户型图的图像识别，比如自动识别户型图中的承重墙、门窗位置，这对房源信息结构化很有价值。RNN则适合处理变长序列数据，比如对房源描述文本做情感分析，判断业主描述中透露的卖房急迫程度。但RNN的缺点是难以并行计算，且存在长距离依赖问题，所以近年来的主流方案逐渐转向Transformer。

Transformer的核心是自注意力机制，可以捕捉序列中任意两个位置之间的关系，而且可以并行计算，训练效率远高于RNN。在贝壳的场景中，Transformer可以用于房产领域的语义匹配，比如用户搜索“朝阳区三居室近地铁”，系统需要和房源库里的描述做语义匹配，而不是简单地进行关键词匹配。这种任务用BERT这类预训练模型效果会很好，而BERT的底层就是Transformer的Encoder部分。所以备考时，不仅要懂Transformer的结构，还要能把它拆解成业务语言，才知道怎么用。

4.3 经典算法与前沿方向的交叉考点：粒子群、模拟退火、卡尔曼滤波

贝壳这套卷子还出现了一些不那么“主流”的算法考点，比如粒子群算法、模拟退火算法、卡尔曼滤波算法。这些算法在互联网大厂的校招笔试题里并不常见，但在贝壳这类涉及物理空间、位置服务的业务场景里，反而显得合理。

以粒子群算法（PSO）为例，它是一种基于群体智能的优化算法，灵感来自鸟群觅食行为。核心思路是：每个“粒子”代表解空间中的一个候选解，粒子根据自身历史最优位置和群体历史最优位置来更新速度，从而不断逼近全局最优解。在贝壳的业务中，这种算法可以用于多目标优化问题，比如“在满足用户预算和面积偏好的前提下，找到通勤时间最短的房源组合”就是一个典型的多目标优化问题。

模拟退火算法也是一种启发式搜索算法，适合求解组合优化问题，思想源于金属退火过程：温度高时，粒子运动剧烈，即使新解比当前解差也有一定概率接受它，从而跳出局部最优；随着温度降低，接受差解的概率逐渐减小，最终收敛到近似全局最优解。在贝壳的场景里，模拟退火可以用于经纪人带看路径规划——一个经纪人一天要看多个房源，如何规划路径使通勤时间最短，本质上是一个TSP旅行商问题，用模拟退火比用精确算法（如动态规划）更实用。

卡尔曼滤波算法则是一种线性最优状态估计方法，在定位、导航、跟踪等领域有广泛应用。贝壳的App里有大量的用户位置信息，用于推荐附近房源、计算通勤时间。由于GPS信号存在噪声，直接使用原始定位数据往往不够准确，卡尔曼滤波可以综合历史轨迹和当前观测，给出更平滑、更准确的位置估计。这套卷子出现卡尔曼滤波，说明贝壳的算法团队确实在做这类位置服务相关的算法优化，而不仅仅是纯线上的推荐系统。

4.4 算法评估与模型验证：AUC、Precision、Recall和业务指标的一致性

贝壳的选择题或简答题中，也有关于模型评估指标的讨论。这类题目通常不会直接问“AUC是什么”，而是结合场景问“在房源推荐业务中，应该重点关注哪个指标”。

比如在房产推荐里，用户可能翻了很多页都找不到满意的房子，这时候召回率比精确率更重要。因为如果推荐的10套房子里只有1套合适，虽然精确率只有10%，但用户看到了那1套，就可能成交。反过来说，如果推荐的10套房子里有9套都不合适，用户就会觉得这个推荐“太不靠谱”，流失率会很高。所以实际业务中，通常要用“召回率+精确率的平衡点”来评估，也就是F1分数，或者在业务指标上直接看“用户点击率”和“最终成交量”。

我在实际项目里发现一个很值得注意的现象：离线指标和线上业务指标经常不一致。比如离线AUC明明很高，但线上点击率却没有明显提升。原因有很多：离线评估的数据分布和线上实时数据分布不一致；离线评估用的是历史数据，无法反映用户对推荐反馈的即时影响；还有就是推荐系统本身的“曝光偏差”——离线数据里只有被曝光过的房源，而那些没有被展示过的房源，我们无法知道用户是否喜欢。所以做算法评估时，不要只盯着AUC刷，要和产品、运营同事对齐业务目标，设计一套“离线和线上强相关”的评估体系。

5. 综合题与业务场景设计：贝壳考官到底想听什么样的答案

贝壳这套卷子的最后一部分通常会有综合题或业务场景设计题，这也是最能体现“算法工程师”和“刷题机器”区别的地方。这类题目没有标准答案，但考官心里都有一把尺子，用来衡量你的思路是否完整、逻辑是否缜密。

5.1 推荐系统类设计题：从召回、排序到重排的完整链路

贝壳的业务天然适合出推荐系统相关的问题。比如一道典型的综合题：“请设计一个贝壳找房App的房源推荐系统，用户打开首页后，如何从几十万套房源中挑选出10套最可能成交的房源展示给用户？”

这类题我建议按“召回-粗排-精排-重排”四个环节来回答。召回阶段：通过多路召回策略，把候选集从几十万缩小到几千套。常见召回通道包括：基于用户画像的召回（预算、户型偏好、区域偏好）、基于协同过滤的召回（相似用户看过的房源）、基于地理位置的召回（用户当前所在商圈附近的房源）、基于搜索历史的召回（用户最近搜过的关键词对应的房源）。粗排阶段：用轻量级的模型（如双塔模型）把几千套快速过滤到几百套，保证后续精排的效率。精排阶段：用更复杂的模型（如DeepFM、DIN）对几百套进行精准打分，排序后选出Top 20。重排阶段：考虑多样性、商业规则、新鲜度等因素，比如同一小区最多展示3套、带有“VR看房”标签的房源优先展示，最终从20套里选出10套。

回答这类题时，还有两个加分项。第一，要提到冷启动问题：新用户没有任何行为数据，怎么推荐？一般是用热门房源和基于地理位置（用户当前所在城市）的推荐兜底。第二，要提到评估指标：怎么知道推荐系统做好没做好？线上可以做A/B测试，对比实验组和对照组的点击率、转化率、停留时长等指标，离线可以用Recall@K、NDCG等指标。能说出“召回-排序-重排”的完整链路，再加冷启动和评估方案，基本就能拿到这道题的大部分分数。

5.2 估价类设计题：机器学习模型的完整落地流程

另一类高频综合题是关于房价估值的。比如：“如何用机器学习模型预测一套房源的市场成交价？”

这个问题，我建议从“特征工程-模型选择-训练验证-上线监控”四个环节展开。特征方面，可以分为房源自身属性（面积、户型、楼层、朝向、楼龄、装修程度、是否临街）、小区属性（绿化率、容积率、物业费、建造年代）、周边配套（学校、医院、地铁站距离、商圈距离）、时间特征（挂牌时间、季节因素）。另外还要加上交易类特征，比如该小区最近的成交均价、带看次数等。模型选择方面，推荐使用XGBoost或LightGBM等GBDT模型，它们对表格型数据的拟合能力很强，而且能自动处理缺失值，不需要做太复杂的特征工程。如果数据量特别大，也可以用深度学习模型，但在房产交易这种数据量级下，GBDT往往是更稳妥的选择。训练验证时要注意时间序列的坑：不能用随机划分训练集和测试集，而要按照时间顺序划分，否则会引入未来信息，导致评估结果虚高。上线后还要做实时监控，关注特征分布漂移和预测误差的变化，因为房地产市场受政策、市场情绪影响很大，模型很容易“过期”。

我在实际做这类项目时还有一个深刻体会：估价模型的误差往往不是模型的问题，而是数据标注的问题。房产的“真实成交价”本身有噪声，比如同一套房源，不同时间点的成交价可能差异很大；不同信息来源的价格口径也不一致（有的含税、有的不含税）。所以在做估价模型之前，先要花大量时间清洗和对齐数据，建立一个统一的价格口径。这个工作枯燥繁琐，但对最终模型效果的影响，往往比调参还要大。

5.3 关于简历深挖题：项目经历如何讲出算法亮点

贝壳的面试流程中（包括笔试后的面试轮），很喜欢深挖简历里的项目经历。这不是技术题，但性价比很高，我建议提前准备一个“项目故事”模板：项目背景、我的角色、技术难点、解决方案、最终效果，每个环节都要能展开讲。

讲项目的时候，最关键的一点是“量化”。比如你做一个用户画像项目，不要只说“我用了K-Means聚类算法”，要说“我用了K-Means聚类算法，对10万用户进行分群，特征包括消费金额、活跃度、访问频次，最终分成5个群体，其中一个高价值群体的客单价是平均水平的3.2倍”。这样一讲，面试官马上就能理解你的项目价值和你的贡献。

还有一个容易被忽略的地方：主动讲失败经历和踩坑过程。比如你在做聚类时，一开始直接用原始特征跑K-Means，结果发现聚类效果很差，后来做了特征标准化和PCA降维之后效果才变好。这种经历比一个“从头到尾顺风顺水”的项目更有说服力，因为你展示了“发现问题-分析原因-解决问题”的闭环能力，而这正是算法工程师日常工作里最核心的能力。

6. 笔试实战策略与个人经验总结：如何在有限时间内稳定发挥

最后这部分，我想结合贝壳2023届校招算法卷1的实战体验，聊聊一些笔试通用的策略和个人经验。这些内容没有什么高深的理论，但都是我在实际笔试、面试中一点点踩坑踩出来的，希望对正在备考的同学有实实在在的帮助。

6.1 时间分配策略：把最容易拿的分先拿到手

我的建议是把整个笔试时间按“6:3:1”的比例分配：60%的时间给代码题，30%的时间给选择题和简答题，10%的时间留给自己检查。代码题是硬分，写不出来就是0分，所以一定要留足时间；选择题虽然分值不高，但数量多，分数积少成多，也不能放弃；最后的10%留出来做检查，主要检查代码题的边界条件（空数组、全0、只有一个元素等）和是否漏掉题目条件。

有一个小技巧是：选择题如果卡了超过90秒，先随便选一个跳过去，在草稿纸上记下题号，等做完代码题再回来推敲。因为选择题的分值通常不高，纠结太久反而挤压代码题时间，非常不划算。我见过有同学在一道纠结的选择题上花了10分钟，最后代码题没写完，直接崩盘。

6.2 考前两周的刷题重点：刷高频题而不是刷题量

距离笔试还有两周左右的时候，我不建议再盲目刷题了，而是要把时间花在刀刃上。具体来说，要优先刷以下几类题目：

• 字符串类：KMP、Trie树、字符串哈希、回文串系列（中心扩展、马拉车算法）。

• 数组类：二分查找（包括变体）、双指针（快慢指针、左右指针）、滑动窗口、前缀和。

• 动态规划：背包问题、最长上升子序列、编辑距离、区间DP、状态压缩DP（高频但难）。

• 树/图：二叉树遍历（前中后序、层序）、最近公共祖先（LCA）、拓扑排序、Dijkstra最短路径、并查集。

• 机器学习基础概念：损失函数、梯度下降、正则化、过拟合、激活函数、注意力机制。

这些高频题，不需要每一道都从零开始手写，但至少要能清晰讲出思路，并能在20分钟内写完核心代码。贝壳这类大厂的代码题难度上限一般不会超过LeetCode Medium偏难，所以不用去死磕Hard题，把Medium题吃透性价比最高。

6.3 笔试环境的适应和心态管理

贝壳的校招笔试通常是在牛客网或者赛码网这类在线评测平台上进行的，和LeetCode的界面有差异。我强烈建议平时刷题的时候就用牛客网或者赛码网刷，提前适应在线IDE的环境，尤其是输入输出格式。很多同学在LeetCode上刷题习惯了核心代码模式（只需要写函数），突然要处理“从标准输入读取多行测试数据”时会手忙脚乱，这种失误太可惜了。

心态方面，我想说一句有点反鸡汤但很真实的话：笔试挂了不代表你不行，有时候只是运气不好。比如你抽到的题目恰好是你前一天没复习的冷门考点，或者你所在的考场网络不稳定导致提交超时。所以不要把一次笔试的成败看得太重，校招是一个漫长的过程，贝壳的笔试只是其中一个节点，后面还有很多机会。我当年校招也挂了不少笔试，但最终也拿到了心仪的offer，所以就算这次没发挥好，重要的是总结经验，下一次做得更好。

另外一个很实用的建议是：笔试结束后，趁记忆还新鲜，赶紧把题目和你的解法复盘一遍。哪怕当时没做出来，也要把题目记下来，去查资料搞懂解题思路。因为大厂的题目经常在不同年份、不同岗位之间相互借鉴，你今天在贝壳遇到的问题，很可能就是你下周在另一家公司笔试时的原题。用这种方式积累，你的“笔试题库”会越滚越大，后面会越来越顺手。

6.4 个人复盘：贝壳这套卷子教给我的三件事

最后，我想以个人复盘的方式给这篇分享收个尾。贝壳找房2023届校招算法卷1刷完之后，我最大的感触有三点。

第一，基础的权重远比我以为的要高。整套卷子里没有特别刁钻的题目，但每个基础考点都设置了“陷阱”或“变体”，比如KMP的next数组、排序的稳定性、逻辑回归的损失函数。这让我意识到，与其疯狂刷难题、背冷门技巧，不如把最基础的知识点吃透，做到真正理解而不是“背答案”。

第二，业务理解是算法能力的一部分。贝壳这套卷子明显在考察“算法能否落地”，推荐系统、估价模型、位置服务这些都是真实业务场景。一个算法工程师如果不理解业务，只会调包调参，很难在公司里创造价值。所以我现在看任何算法，都会下意识问自己：这个算法可以用在什么业务场景？能解决什么问题？有什么约束条件？

第三，稳定的心态比临场发挥更重要。笔试是一场和时间的赛跑，遇到不会的题太正常了，关键是要学会取舍、稳住节奏。哪怕前一部分做得很差，只要不崩盘，最后结果也不会差到哪里去。

希望这篇拆解能帮到正在准备校招的你。祝你在贝壳的笔试中稳定发挥，也祝你在整个校招季里都能收获满意的结果。