1. 2019秋招笔试全景：题型分布与考察逻辑
先交代一下背景。2019年那会儿，B站的秋招笔试还远没有现在这么卷，但已经能看出这家公司的出题口味和一般互联网大厂不太一样。我当时完整刷过那一批题目，也帮学弟学妹做过复盘，一个很直观的感受是：B站笔试不考偏题怪题，几乎全部落在“基础算法 + 数据结构 + 简单思维题”这个范围内，但它的基础题并不是白给，很多题表面一看就会，真正动手写才发现边界条件非常容易漏。
先说笔试的整体结构。B站2019秋招技术岗笔试一般分成两部分：第一部分是选择题，涵盖计算机网络、操作系统、数据库、C++/Java基础等常规八股；第二部分就是编程题，通常是3到4道，难度从简单到中等递进。从当时牛客网上的投票和讨论帖来看，编程题的通过率并不高，很多同学挂在第二题和第三题上，原因并不是题目本身有多难，而是对输入输出格式、题目隐含条件、以及时间复杂度的把控不到位。
我梳理了一下那批题目的类型分布，大概是这样的：
| 题型 | 出现频率 | 典型考察点 |
|---|---|---|
| 字符串处理 | 高 | 翻转、压缩、括号匹配、子串统计 |
| 动态规划 | 高 | 一维DP、二维DP、背包类变体 |
| 贪心与排序 | 中高 | 区间调度、任务安排、排序策略 |
| 数学规律 | 中 | 找规律、位运算、幂运算 |
| 模拟题 | 中低 | 按题意一步步模拟，考察编码细节 |
这里有个很有意思的现象：B站笔试很少出现纯粹的“模板题”，比如裸的LIS、裸的最短路径。它更习惯把算法包装在一个具体的业务场景里，比如“视频播放器缓冲区的调度”“弹幕字符串的过滤规则”“评论区的敏感词替换”等等。这其实是B站出题的一个显著特征，也是这个题集和其他公司题集最大的区别。
所以如果你现在准备B站的技术岗笔试，我给你的第一个建议是：不要把大量精力放在背模板上，而是要训练自己“把场景翻译成算法模型”的能力。这道题到底在考什么，比这道题怎么解更重要。
另外还有一个细节值得注意：那年的笔试环境支持的语言比较广，C++、Java、Python都可以用，但判题机的输入输出是标准的牛客风格，也就是多组测试样例、每组用逗号或空格分隔、需要在循环里读取输入。很多人平时在LeetCode上刷惯了，函数签名直接给好，一到牛客这种“自己写完整程序”的笔试环境就懵了，这是另一个隐形的失分点。后面我会专门讲这个。
2. 字符串处理题：笔试里最“友好”也最阴险的高频题型
字符串题几乎成了2019秋招各厂笔试的标配，B站也不例外。它的特点非常鲜明：入口浅、上手快，但边界条件极其琐碎，稍不留神就漏掉一两个特殊输入，导致整道题AC不了。我选了三个当时比较有代表性的题目展开讲。
2.1 字符串循环右移的三种写法与边界陷阱
这是一个非常经典的题目：给定一个字符串和一个非负整数K，将字符串循环右移K位。比如abcdefg右移2位得到fgabcde。
很多人第一反应是“把末尾的K个字符剪切到开头”，但真动手时问题就来了——K可能比字符串长度还大。比如字符串长度是7，K是10，你如果直接切末尾10个字符，那直接越界崩溃；就算你做了取模，还要考虑“K等于0”和“字符串为空”这两个特殊输入。
我当时写这道题采用的是“三步反转法”，代码很短，但每一步的索引必须算清楚。以abcdefg右移2位为例，先反转整个字符串得到gfedcba，再反转前2个字符得到fg，最后反转剩余部分得到abcde，拼起来正好是fgabcde。这个方案的时间复杂度是O(n)，空间复杂度是O(1)，不需要额外数组。
实际做题时有一个非常容易踩的坑：输入格式。牛客网的判题系统里，字符串和K可能是用空格分隔在同一行，也可能分两行输入，更坑的是有的样例里K用负数表示“左移”，你需要提前读清楚题目要求。我建议不管题目怎么说，统一写成循环读取输入的模板，避免遗漏样例。
import sys def reverse(s, left, right): # 左闭右闭区间反转 while left < right: s[left], s[right] = s[right], s[left] left += 1 right -= 1 for line in sys.stdin: line = line.strip() if not line: continue parts = line.split() if len(parts) < 2: continue s = list(parts[0]) k = int(parts[1]) n = len(s) if n == 0: print("") continue k = k % n # 先整体反转，再局部反转 reverse(s, 0, n - 1) reverse(s, 0, k - 1) reverse(s, k, n - 1) print("".join(s))这段代码我建议大家按“零长度字符串”“K为0”“K大于n”三个用例分别测一遍，只要这三个用例都能通过，这道题基本就稳了。
2.2 括号匹配的进阶：最长有效括号长度
普通括号匹配是栈的入门题，B站2019秋招没有止步于此，它考了一个进阶版本：给定一个只包含(和)的字符串，找出其中最长的有效括号子串长度。比如(()的最长有效子串长度是2，)()())的最大长度是4。
这道题如果只用栈，写法上有一点讲究。大多数人会想到用栈存字符，但那只能判断“整个字符串是否匹配”，无法求出“最长连续匹配子串”。正确的做法是栈内存下标，而不是字符。栈底始终保持一个“最后一个未匹配的右括号的下标”，作为计算长度的基准。
我贴一下我当时提交的版本，容易理解也容易记：
def longest_valid_parentheses(s): stack = [-1] max_len = 0 for i, ch in enumerate(s): if ch == '(': stack.append(i) else: stack.pop() if not stack: stack.append(i) else: max_len = max(max_len, i - stack[-1]) return max_len核心逻辑只有一句话：遇到右括号就出栈，出栈后如果栈空，说明这个右括号无法匹配，把它本身入栈作为新的基准；如果栈不空，那么当前下标减去栈顶下标就是一段有效括号子串的长度。
笔试时我见过不少同学在这道题上TLE，原因是用了replace("()", "")循环删除这种写法，最坏情况时间复杂度是O(n²)，字符串一长就超时。笔试环境的时间和空间限制通常比LeetCode更紧，所以一定要用O(n)的解法。
2.3 从B站弹幕场景出发的字符串压缩变体
还有一道题我印象很深，它模拟的是弹幕文本的压缩规则：给定一个字符串，将连续出现的相同字符压缩成“字符+出现次数”的形式，比如aaabbc压缩成a3b2c1，但如果压缩后的长度不小于原串长度，则保留原串。
这道题的陷阱在于“如果压缩后更长就保留原串”这个条件。很多人按部就班压缩完就输出了，完全忘了比较长度，导致一道简单题直接0分。还有一层坑是：题目里的“压缩后长度”包含数字占位，如果某个字符出现了超过9次，需要用两位数表示，这个细节很多考生都没注意到。
我的建议是：字符串类题目一定先把特殊条件圈出来，然后用“原串为空”“单字符重复”“字符连续出现超过9次”这三个用例自测一遍。这种题不考智商，考的就是细心程度，而笔试考场上最缺的就是细心。
3. 动态规划：把“状态定义”想清楚，你已经赢了一半
动态规划在B站2019秋招编程题里的出镜率非常高，但它的难度曲线比LeetCode上的同类题目要柔和一些，基本不出现“插头DP”“树形DP”这种竞赛级别的难点，更多集中在最基础的线性DP和区间DP上。
3.1 一维DP的经典模型：跳石板问题
有一道题让我记忆很深，它用的是“跳石板”这个场景：小B从编号为N的石板出发，每次可以跳的步数是当前编号的一个约数（且不能等于当前编号本身），目标是跳到编号为M的石板，问最少需要跳几次。
这道题本质上是“最短路径”或“BFS/DP”模型，但很多人的第一反应是递归暴力搜索，导致超时。正确做法是从N到M正向递推：对于每个位置i，枚举i的所有约数d，然后更新dp[i + d] = min(dp[i + d], dp[i] + 1)。
这里有两个关键细节。第一，约数不包括1吗？题目说的是“一个约数且不能等于当前编号本身”，1是合法约数，也就是说可以从i跳到i+1，这一点特别容易漏。第二，需要跳到的位置可能远超M，因为一次跳跃可能越过M然后再回头？仔细读题会发现题目隐含“只能向右跳”，所以一旦位置超过M就不再考虑，直接剪枝。
我当时写的版本是这样的：
def jump_stone(n, m): INF = float('inf') dp = [INF] * (m + 1) dp[n] = 0 for i in range(n, m + 1): if dp[i] == INF: continue # 求出i的所有约数（除数） for d in range(2, int(i ** 0.5) + 1): if i % d == 0: if i + d <= m: dp[i + d] = min(dp[i + d], dp[i] + 1) other = i // d if other != d and i + other <= m: dp[i + other] = min(dp[i + other], dp[i] + 1) return dp[m] if dp[m] != INF else -1注意我在枚举约数时从2开始，因为从i跳到i+1虽然合法，但它属于基础情况，你可以选择在循环外单独处理，或者干脆把1也加进去。笔试时这个细节并不会影响最终求得最小值，因为跳1步本质上只是增加了搜索范围，不会让答案变小，但如果M比较大而N比较小，不处理跳1步会导致大量无效状态。我在代码里从2开始枚举，实际上是为了减少不必要的更新，同时需要把i+1单列出来处理，否则可能出现“本该跳1步到达的路径没被更新”的问题。
建议读者在动手前先在草稿纸上推演几个小例子，比如N=4,M=24，看看最少跳几次，再对照代码结果，这样印象更深。
3.2 二维DP的区间模型：合并回文子串
还有一道题是典型的二维DP，它要求判断一个字符串能否通过“插入最少字符”变成回文串。换句话说，给定一个字符串s，最少插入多少个字符能让它变成回文串。
这道题的标准解法是求原串和逆序串的最长公共子序列（LCS），答案就是n - LCS长度。但如果是笔试时第一次见到，这个转换并不好想。还有一种更直观的区间DP做法：dp[i][j]表示子串s[i..j]变成回文串所需的最少插入字符数，转移方程是：
- 如果
s[i] == s[j]，那么dp[i][j] = dp[i+1][j-1] - 否则
dp[i][j] = min(dp[i+1][j], dp[i][j-1]) + 1
这个方程的直觉是：左右两端字符相等，那就不用动它们，只需处理中间部分；不相等，就选择在左端补一个和右端相同的字符，或者在右端补一个和左端相同的字符，取代价更小的方案。
区间DP的遍历顺序要特别注意，不能简单地按i从0到n、j从0到n遍历，因为dp[i][j]依赖dp[i+1][j]，也就是说i要从大到小遍历，j要从小到大遍历。这个遍历顺序错误是初学者最常见的错误，笔试时一旦状态更新顺序错了，结果会完全不对，而且很难排查。
我当时提交了一个记忆化搜索版本，避免遍历顺序的坑：
def min_insertions(s): n = len(s) memo = {} def dfs(i, j): if i >= j: return 0 if (i, j) in memo: return memo[(i, j)] if s[i] == s[j]: res = dfs(i + 1, j - 1) else: res = min(dfs(i + 1, j), dfs(i, j - 1)) + 1 memo[(i, j)] = res return res return dfs(0, n - 1)记忆化搜索的好处是免去了思考遍历顺序的负担，坏处是递归深度可能比较大，笔试环境如果限制递归深度，长字符串会爆栈。所以稳妥起见还是建议掌握迭代写法，并且把遍历顺序当成一个固定的套路来记：外层循环枚举“区间长度”，内层循环枚举“区间起点”。这个套路适用90%的区间DP题。
3.3 动态规划题笔试中的通用检查清单
结合那年的题目，我总结了一套动态规划题的笔试检查流程，每次做题都按这个来，能大幅减少漏判：
- 状态定义是否覆盖了题目所有维度的信息？如果题目有两个变量，比如“前i个数字中选j个”，那么状态大概率是二维的。
- 初始状态是否合理？
dp[0]、dp[i][i]这类边界值一定要手工验证，很多错解就是初始状态设错。 - 转移方程是否有遗漏？比如“每个元素最多选一次”和“可以重复选”对应的转移完全不同。
- 最终答案从哪里取？并不是所有题目都输出
dp[n]，有的要输出max(dp[0..n])，有的要输出dp[m][n]，看清楚再下手。 - 空间能否优化？如果只需要上一行的状态，滚动数组能把O(n²)降到O(n)，这在内存限制比较紧的笔试里非常关键。
我见过太多同学一上来就写dp = [[0] * n for _ in range(n)]，写到一半发现状态定义错了，整段代码作废重来。在纸上先把状态和转移方程写清楚，再动键盘，是在给后面的自己省时间。
4. 贪心与排序：看似朴素，实则全是细节
贪心算法在2019秋招笔试中出现频率不低，但它的特点是：解法往往只有几行，证明却要花一堆时间。很多人做贪心题靠“感觉”，感觉对了AC，感觉错了WA，复盘时根本不知道自己错在哪。我来拆两个当年出现的典型场景。
4.1 区间调度问题的排序策略：按左边界还是右边界？
题目大致是这样：给定若干个区间，每个区间表示一个任务的开始时间和结束时间，同一时间只能做一个任务，问最多能完成多少个任务。
这是经典的“区间调度问题”，标准解法是按结束时间从小到大排序，然后贪心地选“最早结束的且与已选区间不重叠”的区间。为什么按结束时间排序而不是按开始时间？因为一个任务越早结束，它给后面留下的时间越多，局部最优能推出全局最优。
但笔试时有一种变体很坑：题目要求你输出“最少需要多少个教室/多少个资源才能容纳所有任务”，这就变成了“最多同时重叠的区间个数”问题，解法是完全不同的。前者是“选最多的互不重叠区间”，后者是“找最大重叠次数”，两者都叫区间调度，但一个是贪心，一个是扫描线。
我见过大量考生在这道题上栽跟头，就是因为把这两种变体搞混了。看清题目问的是“最多完成几个”还是“需要几个资源”，是你拿到题后第一件要做的事。
如果按结束时间排序，核心代码大概是这样的：
intervals.sort(key=lambda x: x[1]) count = 0 last_end = -float('inf') for start, end in intervals: if start >= last_end: count += 1 last_end = end注意边界条件：start >= last_end表示前后两个区间可以背靠背衔接，如果题目要求“结束时间和开始时间不能相同”，就改成>。
4.2 带权重的贪心：如何验证“看起来对”的贪心策略
有一道题涉及“带权任务调度”：每个任务有一个截止时间di和一个收益wi，每个任务耗时1个单位，问如何安排任务顺序使得总收益最大。
常规做法是按收益从大到小排序，然后用并查集或一个布尔数组来维护“每个时间片是否被占用”，尽量把收益高的任务安排在截止时间之前。这个解法本质上是贪心，但它的正确性并不像区间调度那么直观，笔试时你很难在短时间内严格证明。
我的建议是：先用小规模数据暴力枚举验证你的贪心策略，如果贪心结果和暴力结果在大样本下都一致，再放心提交。笔试环境里可以多写一个暴力函数作为对拍器，生成随机小数据，两边结果对比。这个操作看起来多花了几分钟，但能让你避开大量“玄学WA”。
再补充一个细节：这类题通常需要对时间从后往前安排任务，也就是“尽量占用截止时间越晚的时间片”，这样可以给截止早的任务留出更多空间。从后往前填时间片是这个贪心策略的关键，很多人写成从前往后填，结果收益损失很严重。
4.3 排序题里容易被忽略的“稳定性”要求
B站2019秋招有一道题要求对多个结构体按某个字段排序，如果字段相同则按输入顺序排列。很多考生直接用Python的sorted()，但它默认是稳定排序，这个没问题；可如果用了C++的sort()，它是不稳定排序，就需要在比较函数里加入下标作为第二关键字。
还有一个更隐蔽的坑：题目要求排序后输出“原始下标”，也就是说你不能只对值排序，还要保留每个元素在原数组中的位置。这种题考察的是“排序 + 下标映射”，如果你只对值排序，后面想找原始下标就只能用index()方法在数组里逐个找，时间复杂度瞬间变成O(n²)，碰到大样例必TLE。
我建议遇到这种题，一开始就把元素封装成(value, index)的形式，排序后再拆包。多写一个元组，能帮你省掉后面一整串麻烦。
5. 手写代码的应试细节：从编译环境到边界条件
很多人刷了很多题，但一到笔试环境就发挥失常。我这里把当年踩过的坑和后来总结出的经验集中说一遍，这些都是“不刷题根本发现不了”的东西。
5.1 牛客/赛码笔试环境的隐藏坑
B站那几年用的笔试系统主要是牛客网，偶尔用赛码网。这两个平台都有一个共同点：需要你自己处理输入输出，而且main函数拿到的输入可能是多组测试数据。
常见的输入坑包括：
- 第一行是“测试组数T”，后面每一行是一组测试数据，你需要先读T，再循环T次。
- 有的题不告诉你有几组数据，你需要用
while True不断读，读到EOF为止。 - 数组的输入可能带方括号和逗号，也可能用空格分隔，你要么用
split()切分，要么用正则提取数字，不要想当然。 - 输出格式多了空格或者少了一个换行，会被判格式错误，这种错误有时候比WA更冤。
我的习惯是准备一个统一的“读入模板”放在编辑器里，不管什么题，先搭好骨架：
import sys def solve(): data = sys.stdin.read().strip().split() # 解析逻辑写在这里 pass if __name__ == "__main__": solve()这样至少不会在输入解析上浪费大量时间。如果你用的是C++，建议读题后用cin >>配合while(cin >> n)，一样能处理未知组数的情况。
5.2 边界条件自查清单
每一道编程题，在提交前都应该过一遍下面的自查清单：
- 空输入：字符串为空、数组长度为0，你的代码会崩溃吗？
- 单元素输入：只有一个字符/一个数字，逻辑还成立吗？
- 极值输入：数字是INT_MAX或INT_MIN，有没有溢出风险？Python不用考虑，但C++/Java必须考虑。
- 重复输入：所有元素都相同，排序/去重/计数逻辑还对吗？
- 不合法输入：题目规定了输入范围，但你的代码会不会因为用户输入非法值而抛出异常？
我统计过自己在笔试中的WA原因，至少有40%出在边界条件上，而不是核心算法上。也就是说，如果你能严格走一遍自查清单，正确率至少能提升四成。
5.3 时间复杂度：提前判断能不能过
笔试判题机一般给的时间限制是1到2秒。Python本身跑得慢，如果你写的是O(n²)的算法，n超过10^4就可能超时。快速估算方式是这样的：
- n <= 10^3：O(n²)没问题
- n <= 10^5：需要O(n log n)或更优
- n <= 10^7：必须是O(n)或近似O(n)
- n > 10^8：基本只能靠O(log n)或O(1)
拿到题目先看一眼数据范围，再决定算法，这是最基本的应试素养。很多人不是因为不会做而超时，而是因为“觉得暴力能过”就懒得优化，结果被大样例打脸。
5.4 多留一个“暴力对拍”的保险
前面提到过对拍器，我再细说一次操作方式。笔试时如果没有额外时间限制，你可以写一个非常暴力的解法，专门用来验证贪心/DP解法的正确性。比如暴力枚举所有排列，或者暴力DFS搜索所有状态，数据规模小的时候，暴力解和你的优化解应该输出一致。
这一技巧在LeetCode上用处不大，但在牛客笔试里非常有价值，因为判题系统不会告诉你具体哪个样例错了，你只能自己猜。对拍能帮你在提交前几秒内发现低级错误，避免白白丢分。
6. 备考复盘：从真题反推复习重点
最后我想聊一聊，从这批2019秋招题集里，我们能反推出哪些对现在仍有价值的复习方向。
6.1 刷题优先级建议
如果你现在时间有限，比如只有两周就要笔试，我建议按照下面的优先级来安排：
- 字符串操作与处理：翻转、截取、替换、括号匹配、子串统计，这些题代码量不大但边界极多，性价比最高。
- 一维动态规划：爬楼梯、跳石板、打家劫舍这类线性DP，状态定义清晰，容易举一反三。
- 排序 + 贪心：至少要把“区间调度”及其变体吃透，这一块思路一旦通了，很多题都能套。
- 数据结构模板：栈、队列、哈希表、堆的基本操作要能默写，尤其是手写堆排序和手写单调栈。
- 图论基础：如果时间充裕，复习一下BFS/DFS和最短路径，B站偶尔会出一两道中等难度的图论题。
优先级最低的是竞赛级高级数据结构，比如线段树、平衡树、后缀数组，这些在B站2019秋招里几乎没有出现，在后续年份也不常见，不建议投入过多时间。
6.2 我自己的复盘心得
我复盘那批题目有一个很强烈的感受：B站笔试的筛选目标不是“找出算法竞赛选手”，而是“找出代码功底扎实、思维缜密、能把业务场景抽象成算法模型的候选人”。所以它的题总是带一点业务色彩，比如弹幕、播放器、评论区、推荐流，本质上是在模拟你入职后要做的事情。
那我个人的建议就是：刷题时不要只看AC率，每做一道题，多问自己一句“如果这个字符串换成用户昵称，这个数组换成视频观看时长，这道题在真实业务里对应什么场景？”这种思维方式，在笔试后的面试环节也非常有用，因为面试官会追问“你还有没有优化空间”“如果数据分布变化了，你的解法还成立吗”，这些问题本质上考察的就是抽象能力和边界意识。
从备考策略上讲，我觉得最有效的提升方式是“限时训练 + 错题复盘”。每次给自己分配90分钟，严格按照笔试时间做一整套题，做完后无论分数多少，逐题检查是“思路错了”还是“边界漏了”还是“输入输出格式不对”，分类记录下来。坚持做五套以上，你的实战稳定性会明显好于那些只刷题不模拟的人。
还有一个小技巧：提交之前，养成把代码里的调试输出全部删掉的习惯。我自己就栽过好几次，写代码时用print输出中间变量，结果提交前忘删，白白拿了几个“格式错误”。这个低级错误只要养成本能反应就能完全避免。
那次的题集放在现在看，难度不算高，但它的出题思路和考察维度，对准备任何一家互联网公司的秋招笔试都有参考价值。做一遍真题，比刷十道同类题库里的题更能让你摸清楚笔试的真实脉搏。
