2016年秋天那阵，网易研发工程师的校园招聘笔试在求职论坛上的讨论热度一直很高。当时江湖上流传一句话：网易的笔试题不靠偏题怪题取胜，它更擅长在“基础算法”和“工程思维”的交叉点上做文章。我因为亲身经历过那一轮笔试，后来也帮学弟学妹复盘过几轮题目，所以对这套题的整体结构、考察维度，甚至一些藏在评测背后的评分逻辑都有比较深的印象。今天这篇博文不打算做成简单的“题目回忆录”，更想把它当作一份求职者的诊断样本：网易2016研发工程师编程题到底在筛选什么人，哪些准备上的盲区最容易导致翻车，以及用今天的视角回头看，我们还能从中榨出哪些真正有用的经验。
1. 2016届网易研发岗笔试形态：先把对手看清楚
1.1 在线笔试流程与考场环境
2016年，网易校园招聘研发工程师岗位的笔试已经统一采用在线笔试系统。和现在相比，当时的系统功能不算复杂，基本就是：题目展示区、代码编辑区、运行按钮和提交按钮。整场考试时长通常在120分钟左右，题目分为客观选择题和若干道编程大题。
很多第一次参加在线笔试的同学会忽略一个关键问题：评测机不会提前告诉你全部测试用例。你本地跑样例通过，不代表提交后能拿满分。网易这种规模的公司，出题组在用例设计上非常细致，专门喜欢用刁钻边界来卡人——空字符串、长度为1的数组、输入带额外空格、数据范围顶到上限，这些都是常规操作。
我记得当时有同学在用本地IDE调试时一切正常，一提交到在线系统就报“运行错误”或“无输出”，整个人都懵了。后来才发现，本地编译器对越界访问可能只是警告，而评测机的运行环境更严格，直接报错终止。这种体验其实是很好的警示：笔试环境不是你的训练场，它是一个高度形式化的“黑盒验收”，你交上去的代码必须足够健壮。
1.2 从题型结构反推岗位需求
复盘那批题目，我感受最深的是整套题有一个明显的分层逻辑：
- 客观选择题负责“广度体检”：操作系统、计算机网络、数据库、语言基础、概率统计。这部分筛的是大学期间是否真正把计算机核心课程学扎实了；
- 编程大题负责“深度体检”：动态规划、字符串处理、搜索、贪心、数据结构设计。这部分筛的是算法训练量和面对陌生问题时的建模能力。
网易不同事业部（网易游戏、网易云音乐、网易有道、电商等）的笔试题会有差异，但共同点非常一致：编程题绝对不是“背模板就能过”。它要求你在有限时间内独立完成思路推导、代码实现、边界处理和复杂度论证。这跟实际业务里“既要写功能，又要保证稳定”的工作模式高度相似。所以出题人真正想筛选的，不是“你知道多少算法”，而是“在压力下能不能把算法落地成可运行的代码”。
1.3 编程题的得分分布与隐藏信号
从我和身边朋友的交流反馈来看，那批编程题的得分大致分三个档次：
- 4-6分档：能想出最直观的暴力解法或简单的单维动态规划，能过一部分用例，但数据量一大就超时；
- 7-8分档：能理出正确思路，写对核心转移方程或搜索逻辑，边界处理大部分到位，但某一个小条件漏了；
- 9-10分档：思路正确、代码高效、边界完整，运行时间和内存控制都做得很好。
这个分数分布透露了一个非常实际的信息：面试官不指望你是满分选手，但你的分数段会直接影响后续面试的走向。拿7分以上的选手，面试时会被追问更多系统设计或项目问题；拿4-6分的选手，面试官大概率会重新花时间考察算法基础。所以准备这类笔试的正确目标不是“做对每一题”，而是“稳定拿到中高难度题目的高分，同时零失误地把简单题满拿”。
2. 核心算法原型拆解：高频考点的解题惯性
2.1 动态规划：状态定义决定了生死
网易2016研发岗编程题中，动态规划出镜率极高，而且通常占据大题位置。题型倒不偏：最长上升子序列、背包变种、区间匹配计数、棋盘走法，都是经典款。但越经典的题，越考验基本功是否扎实。
做DP题有一个关键心法：状态定义一定不要贪大求全。很多同学一上来就想设计一个能同时覆盖多个限制条件的三维dp数组，结果转移方程写到一半发现状态之间互相纠缠，最后只能推翻重来。更稳妥的路线是：先从最简单的一维状态开始定义，比如“dp[i]表示前i个元素能达成的最大/最小值”，如果题目有第二个维度限制（容量、数量、区间），再逐层叠加。
举一个典型场景。假设题目给了一组任务，每个任务有开始时间、持续时间和收益，要求选择互不重叠的任务使总收益最大。这类题的原型是加权区间调度。第一反应可能会设计“dp[t] = 到时间t为止的最大收益”，然后对每个任务遍历检查是否能放到当前时间点之前。但更干净的写法是：先按结束时间排序，再用二分查找找到“当前任务开始时间之前最后一个结束的任务”，把复杂度从O(n²)降到O(nlogn)。“排序+二分+DP”这套组合拳在真实笔试里非常常见，因为网易的用例往往让O(n²)直接超时。
复盘时我最大的体会是：DP题的分数差异，往往不取决于你会不会写转移方程，而取决于你是否根据题目给定的数据范围选择了正确的复杂度。数据规模n≤1000可以接受O(n²)，n≤10⁵就必须想O(nlogn)，n≤10⁶基本要考虑O(n)或O(nlogn)。如果题目没有明确给数据范围，那就按最坏情况估算，宁可多做一步优化，也不能心存侥幸。
2.2 字符串处理：藏陷阱最多的一类题
字符串题在那批笔试里也是常客。网易出字符串题有个特点：表面是常规处理，实际上到处是暗坑。比如判断一个字符串是否是另一个字符串的某种变形、提取满足规则的最长合法子串、大数相加相乘、在字符串集合中统计前缀出现次数等。
容易被扣分的点，我总结下来有三个。
第一是索引越界。很多同学写循环时习惯用字符串长度直接减一，但遇到空串、只有单字符的串，循环条件一旦写错就是整题覆没。后来我养成一个习惯：写完代码，先在脑子里跑三个用例——空字符串、长度为1的字符串、全相同字符的字符串。这三个用例几乎能拦下80%的边界bug。
第二是字符集问题。题目没说字符集时，默认按ASCII处理；但如果题面写着“包含所有可见字符”，那就要用哈希表而不是固定长度数组。用固定数组时还要注意下标换算，比如大写字母映射到0-25，小写字母映射到26-51。很多人在这里直接把字符当成大写减'A'，小写字母一进来就数组越界。
第三是字符串拼接的性能问题。在C++/Java里反复用字符串拼接，复杂度可能退化到O(n²)，在笔试环境里是致命的。更稳的做法是用字符数组或StringBuilder，先估算好总长度再分配内存。这种细节题目不会明说，但超时的用例会直接把你打回原形。
2.3 搜索与图论：剪枝比搜索本身更考验功力
搜索类题目在网易笔试中通常占一题左右。常见的有迷宫最短路径、八数码变种、连通块计数、拓扑排序相关问题。简单题直接用BFS就能过，中等难度的可能要配合优先队列做Dijkstra，偏难一些的则DFS+记忆化直接替代DP。
搜索题的通用套路其实很固定：状态定义、状态转移、终点判断、判重。但真正拉开差距的是剪枝和判重的设计。比如BFS，队列里存什么？只有坐标，还是坐标+步数+当前状态？判重用visited数组还是set？当处理二维平面时，把(row, col)编码为row×cols+col的一维下标，既能省空间又能省时间，这属于基操。
之前听过一个比较典型的题目：棋盘上有若干障碍物，求从起点到终点且经过某些关键点的最短路径。暴力BFS会在状态里叠加“是否已经经过所有关键点”这一维度，导致状态爆炸。如果想到把关键点做状态压缩位运算，用bitmask表示已经经过哪些关键点，整个题目就从“看似无解的搜索题”变成了“可解的BFS+状态压缩”题。这种能力不是一天练成的，它靠的是刷题时见过的模型足够广，遇到新题时才能快速类比迁移。
2.4 贪心与构造：细节决定成败
贪心题通常是整套编程题里“最不像算法题”的题，代码量可能只有20行，但证明过程相当烧脑。网易2016那批题目中，贪心多数以“排序+扫描”的形式出现，比如区间覆盖、任务调度、按属性排序后做选择。
做贪心题最怕“想当然”。你发现某个规则看起来对，写代码，本地测试用例也通过，交上去却只过了30%。原因很简单：你的贪心策略只在部分场景下成立。判断贪心策略是否靠谱，最粗暴但有效的方法是举反例。5秒内能举出反例，说明策略错了；举不出反例，也不代表一定对。这时候可以退一步，考虑动态规划，或者“贪心+优先队列”的组合方案。
我在这类题上栽过的跟头是：排序时只按一个关键字升序排，但题目真正需要的是“第一关键字升序、第二关键字降序”的复合排序。如果不仔细读题，或者不自己构造几个边界数据，很容易漏掉这个隐藏条件。笔试里这种“细节杀”最可惜，因为代码逻辑本身没有问题，错的是对题目条件的理解。
3. 边界条件与复杂度陷阱：最容易丢分也最能拉分的环节
3.1 边界条件不是“玄学”，而是工程素养
前面反复提到边界条件，因为它实在太重要了。很多人的刷题习惯是：照着教程敲一遍 → 提交 → 通过 → 继续下一题。这个流程缺了最关键的一步，就是刻意构造边界用例去测试自己的代码。
网易这类公司的出题人，通常会把边界用例安排在评测数据的后段。你前几个用例跑通了，心态刚刚放松，然后一个空数组输入直接让你的代码报段错误，整题分数断崖式下跌。这种事真的见过太多次。
我在实际做题时给自己定了几条硬规矩：
- 输入为0、输入为1、输入为最大值：这三个数值必须单独过一遍；
- 目标值不存在时：分支逻辑是否走到正确位置，会不会访问无效下标；
- 多个答案都满足条件时：题目要求的是最小、最大还是任意一个，输出格式是否匹配；
- 浮点精度：如果涉及除法或平方根，能不能用整数运算避免精度误差。
这些规则听着简单，但考场上能避免大量无谓失分。有个朋友就是字符串题里忘了处理空输入，一道10分题只拿了2分，后面面试时被问到这段经历，场面非常尴尬。
3.2 时间复杂度的两难：想清楚再动键盘
笔试对时间复杂度的要求比面试时更严格。评测机是全员共享的，某个节点一旦超时，系统可能不直接提示“超时”，而是显示“运行错误”或“无输出”。这种情况下，你很难判断是算法错误还是性能不足，容易陷入无意义的debug循环。
更稳妥的做法是：写代码之前先根据数据范围推导目标复杂度。如果有n个元素，每个元素需要和一个有序结构比较，大概率需要nlogn级别的排序+二分；如果每个元素会被多次使用，就要考虑记忆化缓存或预处理前缀和；如果数据规模达到10⁸数量级，暴力循环基本不用想，直接考虑数学公式、递推或二分查找。
那次笔试我踩了一个典型坑：第一道编程题看起来非常简单，我按O(n²)写了个双循环，前面小用例全过，最后报超时。再回头改成O(nlogn)时，时间已经很紧张，后面的题目发挥大受影响。此后我养成了新习惯：不管题目多简单，先花30秒看数据范围。n超过5000，默认不用双循环；n超过10万，默认不用任何n²级别的结构。
3.3 空间复杂度与初始化：容易被忽略的另一半
除了时间复杂度，空间也是一个隐形扣分点。有些同学喜欢把数组开到最大范围，比如声明int a[100005]，然后在多个测试用例之间忘记清空，导致上一次用例的数据污染了这一次的结果。这种问题在本地IDE里不一定复现，因为评测机往往在同一个进程里连续调用多个测试函数。
正确的做法是：在主逻辑开始前，把所有用到的数据结构显式初始化；使用动态规划时，注意dp数组的初始值是0还是正无穷，这个细节直接影响转移方程的正确性。还有一个实用技巧是滚动数组——当状态转移只依赖前一行或前一列时，把二维dp压成一维，空间复杂度从O(n²)降到O(n)。笔试判分时空间要求不一定卡得很死，但这个习惯能让你在面对内存限制严格的老式评测环境时从容不少。
4. 从“有思路”到“拿高分”：实战排查链与代码素养
4.1 考场上一定要跑的三步debug流程
很多同学笔试时有误区：代码写完，样例输出一致，立刻提交。这其实是最危险的做法。样例通常只覆盖最常规路径，评测机里却藏着大量非常规路径。我建议执行下面的三步流程，哪怕每题多花两三分钟，也值得。
第一步，构造最小用例。输入规模最小的情况，比如n=1或数组为空，检查程序是否还能正常输出。这一步能暴露大部分初始化和越界问题。第二步，构造极端用例。数据规模顶到上限，或使用全为最大值、全为0这类极端数据，观察是否超时、是否溢出、输出是否仍正确。第三步，重读一遍输出格式。如果题目要求输出YES或NO，你输出True或False，再好的算法也是零分。这类低级失误最不值得。
4.2 代码风格：不仅仅是给面试官看的
2016年的时候，在线笔试系统已经支持按用例得分了。但代码风格依然会间接影响你的最终结果。因为后续面试环节中，面试官经常调出你的笔试代码来聊。一份变量命名混乱、函数逻辑堆叠、注释缺失的代码，即使最终答案正确，也容易让面试官对你的工程素养产生疑问。
我在写作时比较强调两个习惯：
一是变量名要有意义。nums、target、dp、visited，这些名字比a、b、c、d好太多。二是每个独立逻辑块之间用空行隔开，关键转移方程或复杂判断条件旁边加一行简短注释。笔试时间紧张，不需要写长篇注释，但转移方程前写一句“dp[i]表示以i结尾的最大值”，效果立竿见影。面试官能一眼看出思路清晰，你调试时也更容易定位逻辑错误。
4.3 答题顺序和时间分配：先稳拿送分题
一上来就啃最难的大题，是最容易翻车的策略。我复盘自己的考试经历，也和不少朋友讨论过，大家比较一致认可的策略是：先把整套卷子快速扫一遍，标出送分题、适中题和难题；然后从送分题开始做，确保简单题满拿；再做适中题；最后留出时间攻克难题的入口部分，至少写出暴力解法拿到部分分数。
时间配比可以参考：总时长120分钟，客观题和读题花20分钟，送分题30分钟，适中题30分钟，难题15分钟，剩下25分钟统一检查边界和格式。这个分配不是绝对值，但核心思想很明确：不要让一道卡住的题拖垮全局。一道题纠结超过15分钟还毫无进展，果断标记，先做后面的。笔试是压力测试，它不仅考你会不会，更考你在资源受限时能不能做出最优决策。
5. 用这套题反推备考路线：一个月能做什么
5.1 先补基础数据结构，再做专项突破
如果距离笔试还有一个月，建议不要盲目海量刷题，先把数据结构基础过一遍：数组、链表、栈、队列、哈希表、二叉树、堆、图的基本表示，以及排序和二分查找的常见写法。大量笔试失分不是因为不会难题，而是因为基础数据结构手写不够快，导致简单题也花了很长时间。
一个实用的自查标准是：给你10分钟，能不能不查资料写出完整的快速排序？能否写出二叉树的层序遍历？能否用链地址法实现哈希表冲突处理？如果这些还磕磕绊绊，就先别急着刷难题，先补齐基础。网易笔试的编程题整体风格偏向“基础知识点+一定程度的组合变化”，极少出现竞赛级别的冷门套路。
5.2 按“题型-模型-变体”的方式刷题
刷题不是越多越好，关键看你会不会归类。我个人的刷题框架是：每做完一道题，在笔记里写三行——这题属于什么题型？用了什么模型？如果题目加一个限制条件，会变成什么变体？
举个例子，做过“最长上升子序列”之后，遇到“字典序最小的最宽上升子序列”“最多能选多少个互不重叠区间”这类问题，背后都用到了类似的排序思想和动态规划。当你能把模型抽象出来，真题再怎么出新变体，也能快速映射到熟悉的模型上。
当时大家刷题喜欢“按标签刷”，比如连续刷100道动态规划。这个做法有一定效果，但不建议只按标签刷，因为真实笔试不会告诉你“这是DP题”或“这是图论题”。无标签的混合练习更能训练模型判别能力。建议60%时间做混合套题，40%时间按弱点专项突击。
5.3 最后三天：放弃难题，回归模板与总结
考前最后三天，我个人的经验是不再碰新题。这时候最重要的是梳理模板库：快排、二分查找、BFS/DFS模板、并查集、单调栈、常见DP转移方程（LCS、LIS、01背包、完全背包）、字符串匹配核心思想。把每个模板的手写实现过一遍，确保没有记忆模糊。
同时准备一份“易错点清单”。我自己的清单里包括：凡是排序相关，先想是否要求稳定排序；凡是用到递归，先想会不会爆栈；凡是数组下标，先想越界；凡是有除法，先想除零。这些规则看着基础，考场上能救命的恰恰就是这种基础细节。考前一晚不熬夜，把笔记本合上好好休息。笔试考的不只是知识，还有状态。
6. 多年后再看这套题：它真正教会了我什么
现在回看2016年那批网易研发工程师编程题，最大的感受是：它其实是一份很好的“行业入门诊断”。它刻意避开偏题怪题，把所有研发岗位需要的基本功放在有限时间里让你展示——算法基础、代码能力、边界处理和取舍决策。
我在这套题上最大的收获，第一是养成了“先看数据范围再设计算法”的思维习惯。这个习惯在后来的工作中帮助很大，无论写业务代码还是做系统性能优化，都得先明确规模再定方案。第二是学会了“不跟一道题死磕”。笔试、面试、甚至工作中的技术选型，道理一样：在有限资源下找到局部最优解，比追求完美但一直卡在原地要重要得多。
如果有人问我备考这类题型最该练什么，我的答案会很简单：不是那些你不会的难题，而是你“会做但容易出错”的简单题。把简单题做到零失误，把中等题做到稳定满分，把难题做到能拿部分分，这套组合拳在绝大多数公司的笔试里都是上游水平。2016年的题如此，放到今天，依然如此。
