1. 先说说360笔试的题量布局和时间分配
2023年春招笔试（第二批）我实际参加下来，整体感觉和互联网大厂常见的"两道编程题搞定一场笔试"的路子不太一样。360的笔试系统里，编程题占大头但不是全部，前面还有一块在线评测的选择/填空类题目，考查范围涵盖了操作系统、网络、数据结构这些计算机基础，后面才是2到3道完整的编程题。这个结构意味着你没法靠"背题"应付，基础不扎实的人在第一阶段就会开始掉血。
从题目类型来看，第二轮批次的题比第一批更偏向"把算法落到工程场景"的考法。第一批里有一些纯模板题，比如直接给一个数组让你排序、让你写个链表反转，属于热身性质；第二批则明显加了业务背景的包装，题干会故意写得很长，铺陈一个产品场景，然后让你抽象出数学模型。这和360的安全、搜索、IoT硬件这些业务方向是挂钩的——它在考察你"能不能从混乱的需求里提取出清晰的算法问题"。
时间上，整套题给的时间大约是90分钟，选择题和编程题共用。我的建议很直白：前面基础题控制在25分钟以内，不要恋战。基础题分值虽然单题不高，但数量多、覆盖面广，做太快容易粗心，做太慢会挤压后面编程题的时间。编程题里，最简单的第一题要在15分钟内搞定，第二题控制在25到30分钟，最后一道如果思路卡了超过15分钟，别死磕，先把能过的样例拿到手。
这里有一个很多人容易忽略的点：360的笔试系统用的是类LeetCode的提交方式，但它的本地IDE默认不会帮你做语法检查，编译报错直接显示一大段英文日志，心态不好的当场就慌了。我建议在进笔试之前，先熟悉一下你常用语言在命令行里编译运行的报错格式，至少能快速定位是缺头文件、名称写错还是类型不匹配。
再说分值结构。第二批的编程题总分在整张卷子里占比大约60%，剩下40%分散在基础题里，这意味着哪怕编程题全都AC，基础题拿个两三成，总分依然不保险。反过来，如果编程题只写出一道半，基础题好好做，也能稳过简历关。所以我的策略一直是：编程题保证前两道的高正确率，第三道当作冲刺题；基础题不允许空题，不会的也要按常识排除掉明显错误选项。
2. 字符串与模拟题：这批题目里最不能丢的分
360笔试编程题第一题，几乎所有批次都喜欢出字符串处理或者状态模拟类题目，2023年第二批也不例外。这类题的特点是：算法思想不深，但逻辑分支很多，题干里会塞进一堆限制条件，考察的是你"稳不稳"。
我印象里有一道题是给出一段经过规则处理的字符串，要求还原出原始内容。题目给的规则不算复杂，但存在嵌套情况，比如某个标记可以嵌套在另一段标记内部，而且处理顺序是从左到右。第一次读题时很容易主观认为用正则替换就行，仔细想才发现正则处理嵌套是行不通的。
这类题的正解是用栈来维护嵌套层级。具体思路是：遍历字符串，遇到左标记时把当前状态压栈，进入新的层级；遇到右标记时弹出栈顶，恢复上一层状态。这里有一个关键细节：弹出的时机不是遇到右标记的当下，而是要在把当前层级的缓冲区处理完之后再弹栈，否则嵌套内容的顺序会乱掉。
我当时写代码时踩了一个很典型的坑：字符串拼接的性能。第一版实现里，我在每层用一个String对象做累加，测试数据量小的时候看不出问题，但数据量一旦到10万级别，字符串拼接的时间复杂度会退化到O(n²)，直接超时。换成StringBuilder或者用数组模拟字符缓冲区之后，时间瞬间降到个位数毫秒。
模拟题的另一个坑在边界条件。题目里往往会出现"空串""只有标记没有内容""标记嵌套深度为1"这类边缘输入，很多人的代码在常规用例上全过，一遇到空串就直接抛异常。我写完后会特意构造几个极端的输入跑一遍，比如全空字符串、只有一对空标记、标记内部只有空格。这些小习惯，考场上是能实实在在救命的。
还有一点值得单独说：输出格式。360的判题系统对输出要求非常严格，多一个空格、少一个换行都会判错。字符串还原类的题，如果结果本身包含前后空格，直接Trim掉会导致答案错误。我通常的做法是，严格按照题目给的输出示例来检查，不确定时宁可不做额外处理，只做最保守的格式化。
3. 贪心和二分：春招笔试里的高频核心
第二批编程题的第二题，风格上明显比第一题"有算法含量"，但也没有直接出动态规划这种重型题目，而是集中在贪心和二分这两个方向上。这其实反映了笔试出题的一个潜规则：校招笔试不是ACM，它不指望你45分钟手撕一个网络流，而是考察你在常见算法模型里能不能快速找到正确的切入路径。
贪心题在这一批里出现了一道让我印象很深的：一系列任务，每个任务有开始时间和结束时间，同一个资源只能同时处理一个任务，问最多能完成多少个任务。这个题目本质是经典的活动选择问题，解法是按结束时间排序，然后贪心地选择结束时间最早且与前一个已选任务不冲突的任务。
难点不在于排序本身，而在于题目套了一个"资源预热时间"的壳。每个任务结束之后，资源需要一段冷却时间才能处理下一个任务，冷却时间可能是固定的，也可能随任务不同而变化。如果是固定冷却时间，只需要在判断冲突时把"下一个任务的开始时间大于等于当前任务结束时间"改成"大于等于当前任务结束时间加冷却时间"；如果冷却时间不固定，就需要对每个任务额外维护一个属性，排序时按"结束时间加自身冷却时间"来排。
二分题则更典型，几乎可以确定是"二分答案"类。题目大致是给一组工位和一组员工，要求分配员工到工位，希望最大化"所有工位里员工数量最多的那个值"，但这里的特殊之处在于某些工位有容量上限，某些员工有位置依赖，求最小化最大负载。这类题的套路非常固定：判断函数里，用贪心或者模拟验证"如果最大负载限制为x，是否能分配完成"，然后对x做二分查找。
写二分的时候，我推荐一个几乎不会出错的写法：左边界取可能的最小值，右边界取一个绝对足够大的值，循环条件是"左边界小于右边界"，每次取中值mid=left+(right-left)/2。判断函数返回"可行"时，把右边界收缩到mid；否则把左边界移到mid+1。最后循环结束时，左边界就是答案。有人在二分查找里纠结用mid还是mid+1，其实只要记住"可行就收右边，不可行就收左边"这个原则，就不会死循环。
贪心和二分结合起来还有一个隐藏考点：证明贪心策略的正确性。虽然笔试不要求写证明文本，但如果你在写代码之前想清楚了"为什么按结束时间排序是最优的"，代码写起来会顺畅很多。想不清楚的时候，可以先写个暴力回溯跑小规模数据，和贪心结果对拍一下，确认无误再提交。我私底下刷题时经常这么做，考场虽然没时间写完整对拍，但这个习惯会逼着你想清楚边界条件。
4. 安全与系统向题目：结合360业务背景的考查方向
360的笔试比起其他互联网公司，有一个非常鲜明的特点：会出少量和安全、系统底层相关的题，哪怕是编程题，也偶尔会披着"日志分析""数据校验"的外衣。2023年第二批的编程题里，至少有一道题在题意上涉及了数据完整性校验，如果你完全没接触过校验和、哈希这类概念，读题就会卡住。
这道题的场景是：系统产生了一串日志记录，每条记录包含时间戳、级别、内容三部分，要求把满足特定条件的记录抽取出来并按时间排序输出。表面上是字符串处理加排序，排序的key是时间戳。但题目里埋了一个小陷阱：时间戳的单位是毫秒级，而且是字符串形式，直接用字典序排序在位数不一致时会出错。比如"20230210120001"和"2023021012001"，前者是13位，后者是12位，字典序排序会把后者排到前面，但实际时间顺序应该是前者靠前。
正确做法是先把时间戳字符串解析成整数或者标准时间对象，再排序。这里我推荐转成整数，因为标准时间对象的解析在部分语言里会牵扯时区问题，而纯数字解析是最稳妥的。解析过程里要注意前导零，时间戳虽然是数字，但可能以0开头，转成int的时候不要丢掉前导零——虽然排序用int没问题，但输出时如果需要原样输出，就得保留原始字符串。
另一道和系统底层沾边的题，涉及二进制位的操作。题目给出一组分片数据和一个校验值，要求判断哪些分片损坏了。实际解法是把每个分片转成一个整数，用异或运算逐片累积，最后和校验值比较。异或在这里的价值很直观：如果有某一片的数据被篡改，累积结果和校验值必然不一致，而且可以通过分组的方式定位到具体是哪一块。
这类题目背后其实映射了360业务里真实在用的技术：数据完整性校验、日志结构化、异常检测。你能感觉到出题人不是单纯想考你算法套路，而是希望招进来的工程师在写业务代码时，能对数据流有一种"敏感度"——知道数据从哪来、经过什么处理、到哪里去、中间可能发生什么异常。
给准备这类题的同学一个建议：不必专门去啃安全工程的书，但要把位运算、字符串编码、哈希这些基础概念理解透。笔试考的永远是概念和代码的映射，不会考"如何破解某个加密算法"。把异或、与、或、位移运算的优先级和结合性背清楚，考场上能少掉很多头发。
5. 边界条件、复杂度与代码风格的考场实战细节
编程题真正拉开差距的，往往不是算法思路本身，而是边界条件和复杂度控制。360的判题系统比较严格，有几个数据点专门卡边界，我身边不少人看到"通过率90%"后卡在那里半天，就是因为循环变量差了一个等号。
先说说复杂度估算的实战方法。笔试时你没法写代码验证超时不超时，只能在写之前心里算一笔账。常规的经验值是：1秒大概能跑10的8次方次简单操作，2秒能跑2到3倍的量。如果题目给的数据范围是n≤10^5，那么O(n²)的算法就是10^10次操作，必然超时；O(n log n)是大约1.7×10^6次，稳定没问题。所以拿到题先看数据范围，再定算法，这是铁律。
具体到实现层面，有几种常见的低效写法要警觉：字符串拼接（前面已经说过）、数组的无序删除、频繁的容器拷贝、在循环里重复计算长度属性。以数组删除为例，如果你在一个长度10^5的数组里反复删除元素，每次删除都是O(n)的，总体就是O(n²)。正确做法是改用标记数组延迟删除，或者用双指针从后往前覆盖。
边界条件的检查，我有一套固定的自查流程，每次提交前都会过一遍：
- 数组或字符串为空的情况
- 数组或字符串长度为1的情况
- 所有元素相同时的表现
- 数值达到题目给定上限时是否有溢出
- 输入中有重复值时是否影响结果
- 排序后第一个和最后一个元素的特殊逻辑
这套流程在实际笔试里帮我排查出过不少bug。比如有一道题需要求"子数组的最大平均值"，我最初写的代码在数组长度恰好等于子数组长度时，循环条件少判断了一次，导致结果差了一截。后来养成了这个自查习惯，这类问题基本能在提交前发现。
另外，代码风格在笔试里看起来不重要，其实很影响发挥。变量命名要有意义，函数拆成小块，关键步骤写注释，不是为了给判题系统看，而是为了让自己在40分钟之后还能看懂自己的代码。我见过很多人在最后一道题上写了一大坨逻辑，结果跑出错误后找不到bug位置，就是因为变量名全是a、b、c，函数没有拆分，改一处崩三处。
我自己的习惯是：主函数只做输入解析和调用，每个算法步骤单独抽成一个函数，函数名直接说明它的用途，比如findMinLoad、canDistribute。这样即使最后时间不够，打个日志也能很快定位问题。还有一个考场小技巧：对输入规模较大的题目，别用Scanner逐行读，用缓冲流按块读入，速度能提升好几倍，数据量上百万时体验尤其明显。
6. 复盘这套题之后，我对春招笔试的几点观察
整套题做下来，我最大的感受是360笔试的出题风格在"工程化"和"基础扎实"之间找平衡。它不是那种纯考智力的题，也不是纯考背书的题，更像是一个信号：我们希望候选人既能快速建模，也能写出健壮的代码，还能对业务场景有基本认知。
观察之一，字符串和模拟题几乎必然出现在第一道编程题。这类题不区分竞赛选手和普通科班生，所有人处在同一起跑线，拼的就是细心和代码基本功。在准备春招时，不要只刷动态规划和图论，把字符串处理、栈、队列、哈希表的经典题型每种刷上20道，基础分就能稳稳抓住。
观察之二，贪心和二分是"性价比最高"的复习方向。它们不像动态规划那样需要大量思路训练，核心套路就那么多，掌握判断函数的写法、边界调整的逻辑，就能应对大多数变体。我建议把"二分答案"的通用模板背下来，现场会省下大量思考时间。这个模板在360笔试里反复出现，我甚至怀疑它的题库里有多道同源变形题。
观察之三，笔试前一定要做一次全真模拟。完整空出90分钟，打开牛客或者360自己的在线练习系统，按真实考试的时间压缩来做题，卡着表不延时不暂停。我在第一次模拟时发现，前25分钟做基础题时贪了几道，导致编程题时间紧张，第二题草草提交只过了一半测试用例。后来调整了时间分配，第二题压到25分钟内完成，正确率明显提升。考场上最大的敌人不是题目难，而是节奏乱。
还有一点对2023届的同学尤其适用：春招第二批的竞争比第一批更激烈，因为很多人的简历还在流程里，池子越滚越大。笔试分数成了筛人的硬指标，这就更要保证简单题不丢分、中档题多拿分、难题尽力写。我在这一轮笔试之后进入面试，面试官其实没有太抠笔试细节，更多是问项目经历和基础八股，但笔试通过是这一切的前提。
回顾整场笔试，我觉得最值得带走的不是哪道题的解法，而是一个认知：校招笔试不是竞赛，它在考核的是"在有限时间内稳定交付可用代码"的能力。三道编程题，你能完整做出两道，剩下那道写出一半的暴力解法并注释清楚思路，再加上基础题拿个中等偏上的分数，就已经赢过多数人了。剩下的，就让平时的积累去回答。
