网易2016实习研发工程师编程题全解析：洗牌、奖学金与路灯

如果你正在准备互联网公司的研发岗实习面试，网易2016实习研发工程师编程题这套题大概率绕不开。2016年前后，“校招笔试线上化”刚好走到一个转折点，网易把这套题目放到在线笔试平台上，题目量不大、难度梯度合理，很快就在牛客网和各种面经帖里流传开来，成了当时练手最狠的一套题。它不考冷门算法，数清楚知识点就是数组、排序、贪心，再加上一堆藏在细节里的边界条件。适合两类人：一类是马上要参加笔试的应届生，另一类是刷题刷到麻木、想找套题检验基本功的工程师。这篇文章我不打算把三行代码甩给你就完事，我会把每道题怎么想、怎么写、为什么这么写、在哪里容易翻车，全部摊开讲。

1. 2016年这套题，究竟在考什么

1.1 三道题背后的三种核心能力

网上流传的网易2016实习研发工程师编程题，不同人回忆的版本略有出入，但主流版本稳定在三个题目：洗牌、奖学金、路灯。这三道题不是随机拼凑的，它们分别对应了研发岗笔试里最常出现的三种能力维度。

第一道洗牌，考的是模拟能力。题目给你一段完整的流程描述，要求你把这个过程原封不动地用代码再现。这类题不考智商，也不考算法设计，它考的是你能否耐心地把“自然语言”翻译成“代码逻辑”，尤其考下标计算和循环边界。很多同学算法题能做出难题，反而在模拟题上栽跟头，就是因为不重视这种基本功。

第二道奖学金，考的是贪心策略。在资源有限的前提下，怎么用最小的代价达成目标。贪心是面试里出现频率最高的算法思想之一，因为它在真实业务中无处不在：预算有限怎么做渠道投放、服务器资源有限怎么排任务、库存有限怎么分配赠品。它的难点不是写代码，而是判断“贪心是否成立”并给出让人信服的理由。

第三道路灯，考的是排序加边界处理。题目本身不复杂，排序之后扫一遍数组就能出结果，但它有一个非常典型的细节坑：你必须同时照顾到首尾两个端点。这种“思路五分钟、边界两小时”的题，恰恰是笔试里最能拉开区分度的类型。三道题合在一起，其实就是一套完整的研发基本功检验组合。

1.2 难度定位：基础但不送分

网易这套题的整体难度，放在2025年回头看，属于“中等偏下”。没有线段树，没有动态规划，没有字符串匹配，更没有图论。凡是参加过几次校招笔试的人，都会觉得这套题的算法门槛很低。但它的难点从来不在算法，而在“能不能一次写对”。

我自己的感受是，这套题最大的杀伤力在于细节。比如洗牌题，洗牌方向是“左半张先出”还是“右半张先出”，不同版本题目描述不一样，想当然就会做反。比如路灯题，路灯数量可能为1，路的两端有没有灯、要不要覆盖到端点，都是送命题。再比如奖学金题，金币总数可能远超int范围，用int存结果直接溢出。

所以这套题看起来很基础，但想全部AC并不轻松。从当年牛客网讨论区的反馈来看，很多人的分数集中在通过1到2题，三题全过的比例并不高。它本质上是一套“看你会不会认真读题、会不会严谨处理边界”的试卷，而不是“看你会不会高级算法”的试卷。

1.3 为什么过了这么多年还值得刷

我知道很多人会有疑问：2016年的题，现在都2025年了，还有必要看吗？我的回答是有必要，而且非常有必要。原因很简单：这套题覆盖的基础能力，和现在校招笔试考查的核心能力几乎没有变化。现在的大厂笔试确实更卷了，题目更偏向LeetCode中高难度题型，但模拟、贪心、排序、边界处理这些基础盘依然是所有难题的地基。

你去做任何一套现在的笔试题，拆到最后，底层能力不会超出这几个范畴。而且这套题比LeetCode单题更有价值的地方在于：它是一个完整的“笔试场景”，需要你自己读题、自己设计输入输出、自己跑样例、自己排查边界。这种综合性训练，是零散刷题给不了的。把它当成校招笔试的“入门自测题”，再合适不过。

2. 三道经典题逐个拆解：思路、解法与现场实现

2.1 洗牌：纯粹拼下标计算的模拟题

洗牌这道题，我印象太深了。第一次写的时候，我直接栽在下标上。

题目大意是这样的：有一个长度为2n的数组，表示一叠牌。洗牌一次的过程是：先把数组分成左右两半，各n张，然后左右交替重新排列。比如数组是[1,2,3,4,5,6]，n等于3，洗一次牌，左半是[1,2,3]，右半是[4,5,6]，交替排列之后得到[1,4,2,5,3,6]。现在要求重复洗k次，输出最终顺序。

拿到这个题，第一个想法就是直接模拟。定义一个新数组，遍历左半部分，把左半第i张放到2*i的位置，把右半第i张放到2*i+1的位置，一轮洗牌结束之后，把新数组复制回原数组，重复k次。这里的n和k一般都在几十到几百，时间复杂度O(kn)，空间复杂度O(n)，完全够用。

#include <cstdio> #include <vector> using namespace std; int main() { int T; scanf("%d", &T); while (T--) { int n, k; scanf("%d%d", &n, &k); vector<int> a(2 * n); for (int i = 0; i < 2 * n; i++) { scanf("%d", &a[i]); } while (k--) { vector<int> b(2 * n); for (int i = 0; i < n; i++) { b[2 * i] = a[i]; b[2 * i + 1] = a[n + i]; } a.swap(b); } for (int i = 0; i < 2 * n; i++) { if (i) printf(" "); printf("%d", a[i]); } printf("\n"); } return 0; }

这里我想强调一个很容易被忽略的细节：左右交替的先后顺序。有的题面描述是“先取左半第一张，再取右半第一张”，也就是我上面代码里的写法；但如果你遇到的版本是“先取右半第一张”，那b[2*i]和b[2*i+1]的赋值就要反过来。笔试的时候不能凭记忆，必须回到题面一字一字确认。就这一个顺序问题，当年不知道卡掉了多少人。

这道题的进阶做法是找索引映射关系，直接算某一轮之后每张牌去到了哪个位置，从而把复杂度优化到O(k)。但笔试场景下我不建议这么做，除非n特别大。原因有两个：一是直接模拟的代码最短，越短的代码越不容易出错；二是笔试时间紧张，与其折腾映射公式，不如直接用最简单可靠的办法把分拿稳。

2.2 奖学金：贪心策略为什么能保证最优

奖学金这道题，不同人回忆的细节不完全一样，但核心结构很稳定。大致意思是：有n门课，每门课已经有一个当前成绩，课程有满分上限，通常按100分算。如果你想拿到奖学金，所有课程的平均分不能低于某个目标值avg。现在可以花金币给某门课提高成绩，每提高1分需要消耗一定数量的金币，不同课程的成本可能不同。问最少需要花多少金币。

这类题的标准解法是贪心：把所有课程按照“提高1分需要花费的金币数”从小到大排序，优先给成本最低的课补分，直到平均分达标。

为什么贪心在这里是对的？因为目标是补足一个固定的总分缺口，而每个“单位分数”之间是等价的，可以拆开购买。这门课补1分、那门课补1分，本质上没有区别，区别只在价格。所以每次选择当前价格最低的“1分”去购买，就能保证总花费最小。这跟你去超市买东西一个道理：同样的商品，哪家便宜就在哪家买，钱花得就少。它本质上是一个分数背包问题，因为分数可以按1分为单位无限细分，所以贪心成立；如果换成每个物品只能整体选或不选，那就是01背包，贪心就不一定对了。

代码实现上要注意几个点。第一，需要补的总分是n * avg - 当前总分，如果这个值小于等于0，直接输出0，不用补。第二，每门课能补的分数是满分 - 当前成绩，不能补过头。第三，金币总数要用long long或int64来存，因为n、avg、金币单价都乘起来之后，int很容易溢出。

def min_coins(n, avg, courses): # courses: [(cost_per_point, current_score, max_score)] missing = n * avg - sum(c[1] for c in courses) if missing <= 0: return 0 courses.sort(key=lambda x: x[0]) coins = 0 for cost, score, max_score in courses: if missing <= 0: break can_add = max_score - score add = min(can_add, missing) coins += add * cost missing -= add return coins

我在实际写这道题的时候，犯过一个低级错误：排序之后没有判断剩余可补分数，直接把can_add全补上去了，导致多算了很多金币。笔试这种环境下，越简单的题越容易因为“想当然”出错。每次循环结束前，一定要确认missing到底减少了多少，最好在草稿纸上先推一组小数据再动手写。

2.3 路灯：排序之后真正的坑在端点

路灯这道题，题目描述大概是：有一条长度为L的路，坐标从0到L，路上有若干个路灯，每个路灯的坐标已知。路灯的照射半径是R，要求整条路的所有点都能被至少一个路灯照亮，求R的最小值。

第一眼看过去，最简单直观的思路就是排序。把所有路灯坐标排序之后，两个相邻路灯之间的路段，需要两边的灯各覆盖一半，才能保证中间那段也被照亮。所以相邻路灯间距的一半，就是一个候选答案。但很多人会漏掉两个关键端点：第一个路灯到起点0的距离，以及最后一个路灯到终点L的距离。这两段路上只有一侧有灯，所以必须由端点那盏灯单独覆盖，半径至少等于这个距离。

所以完整答案是三个候选值里的最大值：

• 第一个路灯的坐标，也就是从0到第一个灯的距离；
• L减去最后一个路灯坐标，也就是最后一个灯到L的距离；
• 相邻路灯之间最大间距的一半。

#include <cstdio> #include <algorithm> using namespace std; int main() { int n, L; while (scanf("%d%d", &n, &L) != EOF) { int a[1005]; for (int i = 0; i < n; i++) { scanf("%d", &a[i]); } sort(a, a + n); int gap2 = max(2 * a[0], 2 * (L - a[n - 1])); for (int i = 1; i < n; i++) { gap2 = max(gap2, a[i] - a[i - 1]); } printf("%.2f\n", gap2 / 2.0); } return 0; }

这里有一个实战技巧：因为最后答案要输出两位小数，而计算过程中涉及“半”这种除法，我习惯把所有距离都乘以2，用整数比较大小，最后再统一除以2。这样能完全避开浮点数比较误差的问题，也不用担心printf的精度问题。比如两个路灯距离是5，乘以2之后是10，另一个端点距离是6，乘以2之后是12，直接整数比较，最后输出12 / 2.0得到6.00，干净利落。

另外还要注意，输入里的路灯坐标可能是无序的，也可能有重复值，排序之后一定要去重或者接受重复坐标的存在。重复坐标不会影响正确性，因为相邻距离为0，不会成为最大值，但如果你写的是“坐标减1”之类的逻辑，就可能在重复坐标上翻车。

2.4 把三道题放一起看：笔试的共性逻辑

三道题晾在这里，你会发现它们有一个共同的特点：算法层面都很朴素，但每个题都藏着一两个“语言陷阱”或“边界陷阱”。洗牌要你确认交替方向，路灯要你确认端点，奖学金要你确认成本和上限。这不是偶然，而是笔试出题人有意为之。HR和面试官真正想筛选的，不是谁见过更多高级算法，而是谁能在有限时间里把一道简单题完整做对。

所以如果你想从这套题里提炼一套复用方法论，我建议按这个顺序来：先读题三遍，把题目里的每一个数字约束和操作步骤都圈出来；再在草稿纸上手动跑一遍样例，确认自己对流程的理解没有偏差；最后再动手写代码，写完立刻构造边界用例自测。这套流程应对任何基础题都管用。

3. 笔试现场的全流程：从审题到调试

3.1 在线笔试环境的隐形门槛

2016年前后，校招笔试正在从线下纸质试卷转向线上OJ，网易当时用的就是牛客网这类平台。这种平台有一个特点：核心代码模式？不是。它要求你提交一个完整的可运行程序，自己处理输入输出，也就是我们常说的ACM模式。

这意味着什么？意味着你不仅要写出算法逻辑，还要正确解析输入格式，可能有多组测试用例，需要循环读取；输出格式也要严格匹配，多一个空格、少一个换行都有可能被判错。LeetCode刷习惯了的人，第一次做这种题会非常不适应，因为LeetCode把输入输出都帮你封装好了，你只需要实现一个函数。但笔试现场没有这层封装。

以洗牌题为例，输入可能是先给一个T，表示有T组测试数据，然后每组先给n和k，再给2n个数。如果你只处理了一组就跑完了，后面所有测试用例都读不到，等来的就是“通过0%”。正确的做法是外层套一层while(T--)，或者用while(scanf(...) != EOF)循环处理，直到输入结束。这一层逻辑写对，至少能保住基础分。

3.2 拿到三题后的15分钟怎么分配

我个人的习惯是，拿到卷子先不着急写代码，花5分钟把三道题全部通读一遍。重点看三样东西：数据范围、输入格式、输出格式。数据范围决定你用不用long long，输入格式决定你写不写循环，输出格式决定你有没有保留两位小数。这三样看漏任何一个，后面都是灾难。

然后按难度排序。以这套题为例，路灯和洗牌属于“模拟+排序”的简单题，奖学金属于“贪心”的中档题。如果是我，我会先写路灯，再写洗牌，最后写奖学金。原因很简单：路灯的代码最短，思路最直接，容易快速拿分；洗牌虽然也简单，但下标细节多，需要留足时间慢慢调；奖学金涉及排序加累加，逻辑上最容易出现“差一点错”的情况，适合放在最后专注处理。

这里有个反常识的建议：不要一上来就做你“感觉最简单”的题，而是先看一眼所有题，然后从“代码量最少”的题开始。因为笔试时间有限，先把确定性高的分拿到手，后面才有余裕啃硬骨头。

3.3 写代码时的自检清单

写代码的过程本身，需要不断对照一份心理清单。我总结下来核心就是四条。

第一，数组下标。是从0开始还是从1开始？题目给的坐标范围是否直接对应数组下标？这个在洗牌题里特别明显，左右半的边界划分是[0, n)和[n, 2n)，如果你习惯写<=，立刻就会数组越界。

第二，数据类型。所有可能累乘累加的变量，一律默认用long long。奖学金题里，n最大可能上万，平均分目标接近满分，金币单价再上百，相乘之后轻松突破int的21亿上限。用int存结果，样例也许能过，一上大数据就溢出。

第三，多组输入的状态重置。全局变量、累加器、标志位，每一组数据开始前都必须重新初始化。很多人第一组样例过了，第二组开始答案莫名其妙错，就是因为忘了重置。

第四，输出格式。字段之间是空格还是换行？最后一行有没有多余空格？浮点数要求几位小数？这些细节在OJ判题里一个字都不能差。一个很土但有效的办法：把题目给的输入样例和输出样例完整复制到程序里跑一遍，逐字符对比。

3.4 用最小用例和边界用例做最后自测

代码写完、样例通过，不代表万事大吉。真正的考验是边界用例。以这三道题为例，我建议每个题至少补测三组数据。

洗牌题，测n=1, k=1，数组长度只有2，看左右交替是否还能正确执行；再测k=0或k很大的情况，确保循环不会死循环。

路灯题，测只有一个路灯的情况，此时答案是max(路灯坐标, L - 路灯坐标)，很多人的代码在只有一个点时相邻路灯循环根本不会执行，如果端点逻辑没写好，答案就是错的。

奖学金题，测已经达到目标平均分的情况，应该输出0；再测所有课程都补到满分仍达不到目标的情况，虽然题目可能保证有解，但万一没保证，你的代码要能正确处理而不是死循环。

这三组自测全部通过，这道题才算真正做完。笔试里有个残酷的现实：部分正确不给分，边界不过等于没做。多花两分钟自测，可能省下的是一整年的遗憾。

4. 实操中容易踩的坑与排查技巧实录

4.1 高频报错与评分异常的速查表

我把这些年带新人时遇到的高频问题整理成一张速查表，遇到类似现象可以直接对照排查。

这张表里的每一行，都是我或者身边人真实踩过的坑，不是凭空编的。笔试出错的规律永远惊人的一致：不是不会，而是粗心。

4.2 一次真实的排查过程复盘

我自己在练习这套题时，遇到过一件特别有意思的事。路灯这道题，我本地测试样例全过，提交上去就是0分。反复看了好几遍代码，逻辑上实在找不出问题。后来我做了个很笨的操作——把题目给的输入样例连同输出样例一起复制到本地，用diff工具逐字符比对。结果发现，我的程序输出是2.00，题目要求的是2.00，看起来一模一样，但我的输出末尾多了一个空格。

问题出在printf的写法上。我在输出每个数字之后都习惯性加了一个空格，最后一位后面也加了。OJ判题时把“多空格”视为格式错误，直接给0分。这个错误后来让我养成了一个习惯：所有涉及输出的代码，循环里用if (i) printf(" ")这样的方式控制空格，而不是在数字后面无脑跟空格。这个细节在洗牌题和路灯题里都很关键。

还有一个排查技巧是“二分注释法”。当代码逻辑比较复杂、不知道怎么定位问题时，先把一半代码注释掉，看程序行为是否变化。如果注释掉前半段程序就正常，说明问题在前半段；如果程序依旧报错，说明问题在后半段。反复几次就能把问题收敛到很小的范围。这个方法在笔试现场可能没时间用，但在平时练习时非常高效。

4.3 “样例过了但被判错”的几种常见来源

网上讨论区里经常能看到有人发帖：“样例过了，为什么0分？”这类问题十个里有八个是下面几种来源。

第一，理解偏差。题目描述里明明写了“洗牌k次”，你只洗了k-1次；题目写了“输出保留两位小数”，你直接输出了整数。这些都属于没有逐字读题。我的建议是，把题面里的每个数字、每个动词都当作约束条件，在草稿纸上圈出来，一个都不能漏。

第二，输入处理不完整。题目可能有多组测试数据，但你只处理了一组，或者处理完一组之后没有正确跳过空行。用cin >>或scanf这类流式读取时，空白字符（空格、换行、Tab）都会自动跳过，通常没问题；但如果你混用getline和cin >>，就可能出现“读了空行”的情况。建议要么全用流式读取，要么全用getline再自行split，不要混用。

第三，边界数据没有处理。路灯只有一个、奖学金目标已经达成、洗牌次数为0，这类“极端但合法”的输入，最容易暴露出平时没考虑到的逻辑漏洞。平时练习时养成构造边界用例的习惯，笔试时就会条件反射地检查这些位置。

第四，浮点数比较的坑。路灯题如果用double计算再直接==或>比较，可能因为精度问题得到错误结果。避免它的最彻底的办法，就是我在2.3节里提到的整数化方案：把坐标乘以2，所有比较用整数完成，最后再转成小数输出。

5. 这套题放在今天还能怎么用

5.1 从2016到现在，笔试题型发生了什么变化

2016年的校招笔试，整体上还处在一个“考基本功”的阶段。题目范围窄、难度适中、很少出现特别偏的算法。到了2025年，大厂笔试的风格已经明显变化：题量增加、难度提升、动态规划和图论成为常客，有些公司甚至加入了“场景设计题”和“系统设计题”。看起来变化巨大，但有一个事实始终没变——简单题依然是筛选的第一道关卡。

现在的大厂笔试通常也是先把简单题放在前面，用来过滤连基本功都不扎实的候选人。如果你在模拟、排序、贪心、边界处理这些基础点上频繁翻车，后面的难题根本没机会展示。所以网易这套2016年的题，放在今天依然是最合适的“基本功体检工具”。花一个下午把它全部AC，并且确保自己能把每道题的边界情况讲清楚，比盲目刷几十道LeetCode难题更有价值。

5.2 三道题的现代变体与延伸训练

如果你把这套题吃透了，完全可以把它延伸到现代题目里，形成一套举一反三的练习路径。

洗牌题延伸出去，就是各类“数组重排”问题。LeetCode 1470（重新排列数组）几乎是洗牌题的简化版，直接给出交叉规则让你实现。再进阶一点，LeetCode 384（打乱数组）涉及随机洗牌，就必须用Fisher-Yates算法，那又是另一个层次的东西了。

奖学金题延伸出去，是典型的“贪心+排序”组合。类似题目包括LeetCode 455（分发饼干）、LeetCode 135（分发糖果）、以及各种“最小代价达到目标”的变体。做这类题时，重点练习的是“证明贪心正确性”的能力：为什么局部最优不会影响全局最优。

路灯题延伸出去，是区间覆盖和区间合并问题。LeetCode 56（合并区间）、LeetCode 452（用最少数量的箭引爆气球）、以及经典的路灯改造问题。这类题的共同点都是排序之后处理端点，边界情况永远是重心。

5.3 再来一次，我会怎么准备这套题

如果让我以现在的经验回到当年，重新准备这套题，我会做三件不一样的事。

第一，我会把每道题的“一句话考点”用白纸写下来。洗牌题是“模拟时先确定位置公式”，奖学金题是“按单价排序的贪心”，路灯题是“端点与间隔取最大”。别小看这一句话总结，它逼着你把整道题的逻辑压缩成可复用的模式，下次遇到类似题，能更快定位思路。

第二，我会在写代码之前，先在草稿纸上手动跑一遍输入样例，写出每一步的中间结果。这样可以尽早发现对题面理解的偏差，而不是等代码写完、提交报错了再回头改。手动跑样例还能帮你确认输出格式，尤其是在需要保留小数位时，提前知道答案长什么样。

第三，我会专门花20分钟做“输入输出专项训练”。网易这套题是ACM模式，和现在很多公司笔试一致，输入输出处理不好，算法再对也是零分。我会练习while(scanf(...) != EOF)、while(cin >> n >> k)、Python的sys.stdin.read().split()这三种不同风格的读取方式，确保自己不会在读数据上卡壳。

回过头看，这套题给我最大的启发不是某个算法，而是“基础题必须一遍过”这句话的含金量。笔试不是比谁会的最难，而是比谁在有限时间内犯的错最少。网易2016实习研发工程师编程题，就是检验你犯错频率的最好试金石。如果你愿意花一个下午认真做一遍，并且把这道题里每一个坑都填平，我相信你会在真正走进笔试考场时，比大多数人更从容。