又是一年秋招季不少准备投递vivo 2023届秋季校招的同学来问我在线编程环节到底怎么准备。说实话每年都有基本功很扎实的同学挂在笔试上不是不会做而是不熟悉在线编程的节奏和审题方式。这篇就把我这些年参与校招命题、也带过不少学弟学妹备战的经验一次性说透从题型分布到真实环境注意事项再到排错思路全部按实际场景来拆。在线编程早就不是简单的“写代码”了它本质上是一场限时、限环境、限评测标准的算法基本功检测。vivo这类公司的校招笔试通常是在牛客网、赛码网这类平台上完成题目的切入点非常贴近业务场景比如字符串处理、状态转移、资源调度背后考的全是数据结构与算法的基础功。你能不能在45分钟内把一道中等偏上的题写对、跑通、过边界基本就决定了你能不能进入下一轮面试。1. 校招在线编程笔试到底在考什么——先从出题人的视角看问题1.1 笔试筛人的核心逻辑不是考倒你而是考你的下限很多同学有个误区觉得校招笔试就是要做难题、怪题谁做出压轴题谁就稳了。实际上从出题人的角度来看校招在线编程的目的非常朴素在最短时间内用最少的人力成本筛掉“基本功不扎实”的候选人。大厂的笔试系统每天要处理成千上万份试卷没有办法像面试那样逐个人去聊。算法题是最客观的筛选工具——会就是会不会就是不会编译报错就是报错超时就是超时。vivo的校招笔试通常控制在90分钟到120分钟3到4道编程题难度梯度从“签到题”到“思维题”递进。前一两道题基本是给大部分认真准备过的人送分的真正的区分度在后面。这里要特别提醒一下不要小看签到题。每年都有人因为第一道题为了秀操作用了复杂的写法结果边界条件考虑不全反倒丢了分。在线编程的判题系统只会告诉你“通过率百分比”不会告诉你具体哪个用例挂了。你AC不了就是AC不了写再漂亮的代码也没用。1.2 在线编程和平时本地写代码的根本区别在线编程最坑的地方在于它和你平时在IDE里写代码是两套玩法。本地写代码你可以随意调试打日志一步步看变量变化。在线编程不行你只能通过“提交-反馈”来获取有限的信息。在线编程的几个典型限制你要提前适应第一输入输出格式由系统严格定义多一个空格、少一个换行都可能导致格式错误。第二系统有运行时间和内存限制比如C通常是1秒或2秒超出就报TLE但不会告诉你具体哪个用例超时。第三测试用例是分多个文件跑的你本地跑过了第一个样例不代表能过所有隐藏样例。我见过太多同学本地IDE里怎么跑怎么对一提交就是0%整个人直接懵掉。原因往往出在最基础的地方——没有处理多组输入或者输入格式解析错了。这些坑提前踩一遍真正笔试的时候就能避开了。2. 从vivo历年校招真题反推高频考点与备战路线2.1 高频考点分布这些知识点一定要烂熟于心我梳理了近几年vivo校招在线编程的题目特点虽然每年的具体题目不同但考点分布有非常明显的规律。这里整理了一张高频考点表方便你对照着自己的复习进度查漏补缺。考点方向出现频率典型题型推荐复习深度字符串处理极高子串匹配、字符统计、字符串压缩熟练掌握常用API和双指针技巧动态规划极高背包问题、路径规划、状态机DP能独立推导状态转移方程数组与双指针高滑动窗口、两数之和变体、区间合并能识别题目背后的双指针模型贪心算法中高区间调度、任务分配、资源最优解理解“贪心选择性”的证明思路排序与查找中自定义排序、二分查找边界熟悉各种排序的适用场景图论基础中最短路、拓扑排序、连通分量掌握BFS/DFS和Dijkstra模板数学思维中低最大公约数、快速幂、排列组合掌握推导型题目的切入方式从这张表能看出一个重要信号vivo的笔试并不是追求算法竞赛的高难度而是更看重你能否用常见算法解决实际业务中的问题。比如字符串处理的大量出现就和手机系统、应用层开发中的文本解析场景直接相关动态规划频繁出现则是因为它在资源分配、路径优化等领域有广泛应用。2.2 按目标岗位调整复习优先级不同岗位的笔试侧重点是有差异的这一点很多同学会忽略。我建议你在投递前先看清楚岗位要求再有针对性地调整复习计划。以vivo校招来说软件开发岗客户端方向会更侧重操作系统、网络编程相关场景下的算法题比如并发任务的资源调度容易用贪心或优先级队列来考后端开发岗则更重视数据结构的设计能力和大数据量下的处理思路比如海量日志的时间段统计这种题看起来是算法题实际上考的是你对哈希表、排序、归并这些基本功的综合运用。算法工程师岗的笔试就比较硬核了动态规划属于标配有时候还会出现需要你推导数学公式的题目这种题在准备时不能只背模板一定要理解推导过程。测试开发岗的题目通常难度偏低但会考一些边界条件非常刁钻的题本质上就是看你能不能想到别人想不到的测试用例——这本身就是测试思维的一部分。我个人的建议是不论投递哪个岗位动态规划和字符串处理都是必须吃透的因为这两个考点覆盖面太广几乎是所有技术岗笔试的共同科目。3. 真题思路拆解三道典型在线编程题的完整推导3.1 签到题实战字符串压缩与展开vivo校招笔试里经常出现一类看着简单、但非常考验细节的字符串题。为了说明这类题的完整思路这里以一道典型的字符串压缩题为例要求统计连续相同字符的个数将字符串压缩成“字符数量”的形式如果压缩后的长度不小于原字符串则返回原字符串。这道题的解题关键有两个一个是遍历时的连续字符计数另一个是最后别忘了处理末尾那一组连续字符。很多同学写到最后一组时就漏掉了导致结果差一位。#include string using namespace std; string compressString(string S) { if (S.empty()) return S; string res; int cnt 1; for (int i 1; i S.size(); i) { if (i S.size() S[i] S[i - 1]) { cnt; } else { res S[i - 1]; res to_string(cnt); cnt 1; } } return res.size() S.size() ? res : S; }注意上述代码里i S.size()这个细节很多第一版代码会写i S.size()然后在循环外面再补一次字符串拼接。那样写虽然也可以但容易漏变量重置的逻辑不如这样在循环内统一收尾更简洁。从这道题能看出来签到题并不是白送分的。它考查的是你对边界条件的敏感度、对代码结构的组织能力以及能不能一次性写出没有语法错误的代码。在线编程环境下你没有编译器帮你反复试错所以平时就要养成“一次写对”的习惯。3.2 中等题实战动态规划解决最小路径代价动态规划是vivo这类公司笔试中的绝对主力考点。以典型的“矩阵最小路径和”为例给定一个包含非负整数的m×n网格每次只能向下或向右移动一步找出一条从左上角到右下角的路径使得路径上的数字总和最小。动态规划的核心就三步定义状态、确定状态转移方程、处理初始化和边界。这个题的状态定义非常直观dp[i][j]表示从起点走到(i,j)的最小路径和。因为只能从上方或左方到达(i,j)所以转移方程就是取这两个方向中的较小值再加上当前格子的值。def minPathSum(grid): if not grid or not grid[0]: return 0 m, n len(grid), len(grid[0]) dp [[0] * n for _ in range(m)] dp[0][0] grid[0][0] for i in range(1, m): dp[i][0] dp[i-1][0] grid[i][0] for j in range(1, n): dp[0][j] dp[0][j-1] grid[0][j] for i in range(1, m): for j in range(1, n): dp[i][j] min(dp[i-1][j], dp[i][j-1]) grid[i][j] return dp[m-1][n-1]这类题在笔试中属于“中规中矩”的难度命题人喜欢拿它当第二或第三道题。它本身不难但需要你快速识别出这是一道动态规划题并且能准确处理第一行和第一列的初始化。我在辅导同学时发现一个共性问题很多人DP状态定义没问题转移方程也能推出来但就是死在初始化上。第一行只能从左边来第一列只能从上边来这两个特殊情况往往被忽略一提交就是答案错误。所以准备DP题时一定要养成画表推演的习惯哪怕很简单的题也把dp数组自己在草稿纸上填一遍。3.3 拉开差距的压轴题二分答案与贪心的结合笔试的最后一道题通常用来拉开差距难度接近竞赛的入门题。vivo的压轴题风格很典型表面上看是一个普通的资源分配问题实际上要用二分答案配合贪心检验。假设有n个任务每个任务有耗时time[i]要求将任务分给k个工人每个工人的负载是分配给它的任务耗时之和目标是最小化所有工人负载的最大值。这种“让最大值最小”的描述方式就是二分答案的经典信号。解题思路是对最终答案最大负载进行二分对于每个猜测值mid用贪心法检验能不能在不超过mid的前提下用k个工人完成所有任务。贪心策略非常直观按顺序分配任务当前工人放不下就换下一个工人最后看所需工人数是否小于等于k。bool canFinish(vectorint tasks, int workers, long long limit) { long long cur 0; int cnt 1; for (int t : tasks) { if (t limit) return false; if (cur t limit) { cnt; cur t; } else { cur t; } } return cnt workers; } int minimizeMaxLoad(vectorint tasks, int k) { long long left 0, right 0; for (int t : tasks) right t; while (left right) { long long mid left (right - left) / 2; if (canFinish(tasks, k, mid)) { right mid; } else { left mid 1; } } return (int)left; }这道题能在笔试中区分出两类人一类是看到“最大值最小化”就能联想到二分答案的老手另一类是看到题目后直接尝试用贪心硬解结果解不出来或者写了一个完全没有正确性证明的DFS碰运气。这里给一个实操建议在线编程的压轴题不要求你一定做出来但要保证前面所有题AC。如果时间只剩15分钟最后一题还没有思路果断放弃把时间用来检查前面的题是否有边界遗漏。这个策略虽然不是最优解但一定是期望分数最高的选择。4. 在线编程实战从环境适应到一次通过的关键细节4.1 养成本地环境与在线环境一致的写码习惯在线编程最大的敌人不是算法而是环境差异。很多同学在本地IDE里开着自动补全、自动纠错代码写得飞起一到在线编辑器就各种不适应。函数名记不全、括号不匹配、大小写拼错这些低级错误在紧张状态下尤其容易爆发。我的建议是从准备校招的第一天起就有意识地练习“裸写代码”。什么叫裸写就是打开一个最简单的文本编辑器或者白板不借助任何智能提示把代码从零写完。你不需要长期这样但每周至少要有2到3次这样的训练。这个习惯能让你在笔试时做到心里有底不会因为编译器提示变少而乱了阵脚。另外一个很多人不注意的点提前熟悉你选定的主语言在在线平台的输入读取方式。C的cin、Java的Scanner、Python的input()这些在本地你可能用得不频繁但在笔试中是唯一的输入途径。我见过不止一个同学在笔试中途卡在“怎么读多组数据”这种问题上非常可惜。4.2 复杂度的估算技巧不要等TLE了才后悔每道题提交后最怕看到的不是WA答案错误而是TLE超时。TLE意味着你的算法思路可能没问题但实现方式不够高效或者选错了算法。这里分享一套我常用的复杂度快速估算法如果题目给的数据范围是n ≤ 10^4那么O(n²)级别大约是一亿次操作在1秒的限制下很危险应该优先考虑O(n log n)或O(n)的算法如果n ≤ 10^5O(n²)大概率超时必须用O(n log n)以内的算法如果n ≤ 10^9级别基本就是在暗示你O(√n)或者数学公式直接计算了。还有一个容易TLE的细节频繁使用输入输出也可能拖慢速度。C里默认的cin/cout在大量数据下会明显慢于scanf/printf但你可以通过在main函数开头加一行ios::sync_with_stdio(false); cin.tie(nullptr);来加速。Python则可以用sys.stdin.buffer.read()做更高效的输入处理。这些细节看起来不起眼但关键时刻可能决定你是AC还是TLE。4.3 在线OJ判题机制详解通过率百分比说明了什么很多在线编程平台给你看的是通过率百分比而不是“对还是错”。比如你的代码显示通过了60%的用例说明你已经踩中了大部分常规情况但在某些隐藏用例上出了问题。这60%到100%之间的差距排查起来非常磨人。我建议按以下优先级来检查第一是否漏了极端输入比如空数组、数组长度为1、全是同一个数字等第二是否出现整数溢出C里int最大值约21亿很多中间计算超过这个数就要用long long第三是否有多余的输出比如你调试时打印了中间变量但忘了删第四是否有数组越界这是C/C最常见的问题本地不一定报错但OJ会直接判RE。这里分享一个我自己的小技巧每次提交前在脑子里把样例输入手动模拟一遍从读入数据到输出结果步骤越详细越好。这个过程会逼你发现很多自己代码里的逻辑漏洞比反复盲提交有效得多。5. 高频报错排查指南从WA到AC的完整心法5.1 常见报错类型速查与应对策略在线编程平台的报错信息通常只有几个英文缩写但每个缩写背后的排查思路完全不同。我整理了一张速查表可以直接对照排查。OJ反馈含义排查方向AC完全通过无需处理WA答案错误检查算法逻辑重点看边界条件和特殊输入TLE超时优化算法复杂度检查输入输出是否过慢RE运行时错误检查数组越界、除零、空指针、栈溢出MLE超内存检查是否开了过大的数组或递归层数过深CE编译错误检查语法、头文件、编译环境差异WA是排查成本最高的错误因为系统不会告诉你哪个用例错了。我的做法是先构造几个极端用例在本地跑一遍输入为空、输入为最大边界、所有元素相同、已经有序、完全逆序。这些用例一旦覆盖到很多隐藏bug就会浮出水面。RE在本地可能完全复现不出来因为它很依赖内存布局。C里最常见的原因是数组越界尤其是二维数组的索引写反了或者循环边界差一。建议在编写循环时始终问自己一句当索引等于最大值时数组下标会不会越界这句话能帮你避免一大半的RE。5.2 关于“本地能跑OJ就是0%”的深度剖析这应该是所有在线编程玩家最崩溃的时刻没有之一。代码在本地跑得丝滑样例输入输出完美匹配一提交显示0%。我遇到过的原因集中在以下几个方面按出现频率排序第一个是多组输入没有处理。有些题目明确写了“输入包含多组测试数据”但只给了单组样例。如果你的代码只处理了一组就return 0OJ就会在你的程序读取第二组数据时直接得到EOF整个程序提前结束全部用例都挂。解决方法是把核心逻辑包在一个while(cin n)或者while True: try: ... except EOFError: break的循环里。第二个是输入格式解析错误。比如一行里有多个整数但数据里可能有多个空格或者换行符不规律比如字符串包含空格你用cin str只读到了空格前的部分。这些都是很小的问题但足以让所有用例出错。第三个是输出格式问题。题目要求每组结果换行你多打了一个空格或者少打了一个换行OJ就会判格式错误。在线编程的评测系统对格式非常严格不能多也不能少。建议每题提交前反复核对题目描述中的输出格式示例。5.3 草稿纸与心算在线编程笔试中最被低估的工具在线编程笔试是在电脑上答题但草稿纸依然是绝对刚需。我参与过的笔试监考里桌面干干净净的同学和草稿纸写满一页的同学AC率完全不在一个水平线上。草稿纸的正确用法不是让你抄代码而是画状态图、推转移方程、模拟小规模用例。面对一道动态规划题你在纸上画一个3×3的表格手动填一遍状态转移关系就一目了然了。这个过程中你会发现很多写代码时不容易察觉的坑比如某个状态依赖的是dp[i-1][j-1]不是dp[i][j-1]这种错误靠肉眼看代码很难发现但一画表就暴露了。另外草稿纸也是你的备用大脑。笔试时时间紧、情绪紧张靠脑子记住所有细节不现实。你在草稿纸上写下每个变量的含义、每个函数的作用、每一步的思路即使在写代码过程中临时中断也能很快接上。这个方法在写比较长、逻辑复杂的题时尤为有效。6. 最后的实战心态把在线编程当成一次技术沟通在线编程笔试本质上是一次你和出题人之间的“无声沟通”。出题人用题目告诉你他希望考察什么能力你通过代码告诉他你是否具备这个能力。理解这一点你的心态会稳很多。我发现一个规律平时准备越充分的人笔试时越容易进入一种“心流状态”。整个过程就像一个闯关游戏你不再害怕报错因为你知道每一次错误都在帮你更接近正确答案。相反准备不充分的人会把精力浪费在焦虑上越急越写不出来越写不出来越急最后陷入恶性循环。这里分享一个缓解紧张的小技巧笔试开始后的前5分钟不要急着动笔。先花3分钟通读所有题目把每道题的题型和大致难度标记出来然后从最顺手的题目开始做。这个“先易后难”的顺序能让你在短时间内建立信心为后续的硬仗储备心态。另外一个我反复强调的经验是不要因为一次笔试失利就否定自己。在线编程的随机性比很多人想象的大你的状态、题目的方向、平台的环境都会影响最终结果。挂掉一场笔试不代表你的真实水平不行可能只是这场的题目风格不适合你。保持稳定的刷题节奏坚持到各家校招的最后一轮最终拿到满意的offer才是最重要的。