最近刷面经刷得有点上头，发现一个很有意思的现象：不管是大厂还是中小厂，技术面试里“手撕代码”这一环几乎是标配。很多人在简历上写了“熟悉算法与数据结构”，结果面试官一道题甩过来，现场写不出、写不对、写出来但边界没考虑全，直接凉凉。这篇文章我想结合我看到的、听到的那些“别人面试遇到的手撕代码题目”，把背后的考察逻辑、常见题型、现场应对思路和避坑经验一次性聊透，希望给正在准备面试的朋友一些真正能落地的帮助。
手撕代码这件事，很多人把它理解为“背题”。其实背题只能帮你过最基础的一关，真正拉开差距的，是你面对一道没见过、甚至有点偏的题目时，能不能稳住心态、理清思路、写出可运行的干净代码。这不是玄学，是有方法论的。下面我就从面试官到底想看什么开始，一步步拆解。
1. 手撕代码到底在考察什么
1.1 面试官的真实意图
很多求职者把手撕代码当成“算法题考试”，认真刷了几百道 LeetCode，就觉得胜券在握。但面试官让你手撕代码，考察的绝不仅仅是“你会不会这道题”。
我在跟几位参与过校招和社招面试的朋友聊过之后，发现面试官在看手撕代码时，心里其实在过三个问题。
第一，你代码写得干不干净。变量命名是否语义化，函数划分是否合理，有没有多余的重复逻辑。这是在判断你日常工作里的代码质量。毕竟没有人会真的招一个写一手烂代码的工程师进来，哪怕他解题很厉害。
第二，你思考问题的方式对不对。接到题目后你是直接上手写，还是先花两分钟确认需求、理清边界条件？遇到卡壳时你是死磕一个方向，还是能换个思路重新来？这比“解出正确答案”重要得多，因为你工作中遇到的绝大多数问题都不是有标准答案的题。
第三，你跟队友沟通是否顺畅。面试官会故意不给你某个关键信息，或者在你写代码时打断你问“你这行是什么意思”，看看你能不能清晰地表达自己的想法。很多人写代码时一言不发，面试官全程看哑剧，这种就算代码对了，评价也会打折扣。
1.2 评判标准与评分维度
我综合了多份面经和面试官的反馈，把手撕代码的评判维度整理成了下面的表格。
| 维度 | 权重（参考） | 核心关注点 |
|---|---|---|
| 正确性 | 40% | 能否跑通所有正常用例和边界用例，逻辑是否严密 |
| 代码风格 | 15% | 命名是否规范、结构是否清晰、是否有注释意识 |
| 沟通表达 | 20% | 是否主动确认需求、讲清思路、解释关键决策 |
| 健壮性 | 15% | 是否考虑空输入、超大值、特殊字符等边界情况 |
| 时间效率 | 10% | 从拿到题目到动手写代码的思考节奏是否合理 |
这个权重分布不是我编的，是按多位面试官“如果让你给这场手撕打分，你主要看什么”的回答汇总的。可以明显看到，正确性不是唯一指标。很多时候面试者代码写出来了，但边界情况没考虑，面试官会补一句“如果输入是空数组呢”，直接暴露思维盲区，反而比坦承“我还没想到这一层”更减分。
提示：手撕代码不是“你出一道题我解一道题”的对决，而是“模拟一次微型的工作协作”。面试官在看你遇到问题时的真实反应，而不是看你背诵标准答案的熟练度。
2. 高频手撕题目类型与考点拆解
2.1 数组与字符串类：地基中的地基
在我收集到的“别人面试遇到的手撕代码题目”里，数组和字符串类的出现频率最高，大概能占到三成以上。原因很简单：它们是最基础的数据结构，几乎不依赖复杂的模板，能最真实地反映一个人的编程功底。
常考的代表性题目有这么几类。
双指针类，比如“判断一个字符串是否为回文串”的变体、“有序数组的两数之和”、“最大连续子段和”。这类题看着简单，但非常考验对指针移动条件的理解。我一个朋友面字节的时候遇到一道“移除数组中重复元素，要求原地修改，返回新长度”，其实就是双指针典型题，但他一紧张写成了创建新数组，直接被面试官追问“空间复杂度是多少”，当场尬住。
滑动窗口类，比如“无重复字符的最长子串”。这道题可以说是面试常青树，解法是维护一个窗口和哈希表，控制左右边界的移动。很多人能背出代码，但被问到“为什么右指针可以一直往右走不回退”时，答不上来底层逻辑，这就是典型的“背题没理解”。
前缀和与差分，比如“子数组和等于K的数量”“航班预订统计”。这类题不算特别高频，但一旦出现，很能区分是否真正理解“用空间换时间”的思维。核心是把多次区间求和降维成一次前缀和相减，时间复杂度从 O(n²) 优化到 O(n)。
字符串类还有一个常考方向是大数运算，比如“两个字符串表示的大整数相加”。这题朴素解法是按位相加再处理进位，代码量不大，但特别考验你对字符串下标、进位标记这些细节的处理。很多人在白板上写着写着，数组越界了都不知道。
我给这类题型的准备建议是：不要只刷“会做”的题，要刷“能讲清楚”的题。每做完一道，试着用两三句话跟空气讲一遍你的思路，讲不顺的地方就是你理解还不透的地方。
2.2 链表与栈队列类：细节决定成败
链表类题目在手撕中出现频率也相当高，因为它的指针操作特别容易出错，正好用来考察细心程度和基本功。
高频题目包括：“反转链表”（迭代和递归两种写法都要掌握）、“链表中环的检测”（快慢指针）、“合并两个有序链表”、“删除链表的倒数第N个节点”、“判断回文链表”。
说一个我在很多面经里都看到过的题目：“按K个一组反转链表”。这道题是字节、阿里、腾讯都爱出的，属于链表题里的中等偏上难度。它考察的点很综合：先要会基础的反转链表，还要会分组、衔接、处理最后一组不反转的边界情况。很多人前两步都写对了，最后“最后一组不反转”这个条件漏了，case 跑挂，功亏一篑。
链表题的几个共性坑，我列在下面，这些都是经验之谈。
- 哑节点（dummy node）一定要主动用。处理头节点可能被修改的情况，哑节点能避免大量“头节点特殊处理”的分支判断。
- 画图是必须的。不要省这一步。在白板上画两个节点、三条线，标注前驱和后继，比在脑子里空想要可靠十倍。
- 循环条件想清楚。
while (cur != null)和while (cur.next != null)差之毫厘谬以千里，很多人写挂了都是因为没想清楚循环结束时指针停在哪个位置。
栈和队列类经常跟“单调栈”结合来考，比如“每日温度”“柱状图中最大的矩形”“接雨水”。这类题的特点是：原理一听就懂，代码一写就错。原因在于单调栈维护的是下标还是值、出栈的时机、出栈之后如何计算结果，这些细节很容易乱。我的建议是，把单调栈的模板代码好好吃透，不要每次都现场推。
2.3 树与图类：递归思维的分水岭
树类题目在手撕题目中的地位很特殊，它不会特别多，但一旦出现了，往往是面试流程里的“压轴题”，用来区分“基础扎实”和“算法能力强”。
最常见的考察方向是二叉树的遍历：前序、中序、后序的递归写法要闭着眼睛能写出来，迭代写法也得掌握至少一种（推荐用栈模拟）。再往上就是“层序遍历”“之字形遍历”这类带变体的题目，考察点在于如何控制一层一层的边界。
更进阶一点的常考题包括：“最近公共祖先”“二叉树的最大路径和”“从前序与中序遍历序列构造二叉树”“验证二叉搜索树”。
以“最近公共祖先”为例，这道题解法其实很优雅：从根节点开始递归，如果在左子树找到了目标节点，在右子树也找到了目标节点，当前节点就是最近公共祖先。但很多人写递归时容易陷入“我要不要判断这个节点是左还是右”的纠结里，反而把简单问题复杂化。这题的核心逻辑只有一句：左右子树各返回一个节点时，当前节点就是答案。
二叉搜索树的题目也有自己的特点，比如“验证二叉搜索树”不能只比较当前节点和左右孩子，而是要用一个范围来约束。很多第一次写的人都挂在这里，认为只要root.left.val < root.val < root.right.val就行，结果遇到[5,4,6,null,null,3,7]这种用例就会判断错误。
图类题目在手撕中出现频率比树更低，但一旦出现就是偏难的。常考方向有拓扑排序、岛屿数量（DFS）、最短路径（BFS）。其中“岛屿数量”是最高频的，因为它一道题就同时考察了二维数组遍历、DFS 递归、visited 标记这三块基础能力，性价比非常高。
2.4 动态规划与数学思维类：区分度最高的题池
动态规划类题目是手撕代码的重灾区，也是很多人心里的阴影。它不像链表题，画个图就能理清；也不像遍历题，模板背熟就能套。DP 题的核心在于状态定义和转移方程的推导，这两步没有通用模板，考察的是真正的建模能力。
我在面经里看到的高频 DP 题有这么几道。
- 爬楼梯（斐波那契变体，入门级，但能衍生出“最小花费爬楼梯”“三步问题”等变体）。
- 打家劫舍（一维 DP，核心是“选或不选”的状态转移）。
- 最长递增子序列（朴素 O(n²) 解法要会，进阶的贪心加二分优化可以作为加分项）。
- 编辑距离（二维 DP 里的经典代表，状态转移有三个来源，很多人搞不清初始化）。
- 零钱兑换（完全背包问题，注意遍历顺序对结果的影响）。
以“编辑距离”为例，这道题考过无数次，但每次都能刷掉一批人。它的状态定义是dp[i][j]表示word1[0..i-1]变成word2[0..j-1]需要的最少操作数。初始化时dp[i][0] = i、dp[0][j] = j比较好理解，但转移方程里三个来源——插入、删除、替换——很多人会漏掉一个。这里的关键是：三个操作对应的是三个方向的转移，而不是一次只考虑一种操作。
数学思维类题目不算高频，但出现时很容易让人措手不及。比如“快速幂（Pow(x, n)）”“两数相除（不用乘除号）”“整数转罗马数字”等。这类题的特点是数学细节多、边界条件隐蔽，非常考验思维缜密度。以快速幂为例，核心思路是二分法把指数折半，但负数指数、整数溢出这些边界情况，很容易让人翻车。
3. 现场手撕的完整实操流程与进阶技巧
3.1 拿到题目后的五分钟该做什么
很多人在手撕代码时犯的最大错误是：拿到题目就动手写。好像写得越快就显得越厉害，其实恰恰相反，面试官更希望看到一个有条不紊的思考过程。
我建议拿到题目后，先花五分钟左右做好下面四件事。
第一步，复述题意。用自己的话把题目要求说一遍，尤其是输入输出、边界条件这些关键信息。这不仅是确认自己没理解偏，也是主动跟面试官建立沟通。比如面试官说“实现一个函数”，你要确认：输入是什么类型？数组的话能不能为空？字符串的话要不要考虑大小写？排序是稳定还是不稳定的？这些问题可以在后面帮你省掉大把调试时间。
第二步，想清楚暴力解。先不急着想最优解，先想最简单的暴力解法是什么。这样做有几个好处：一是确保你有一个保底方案，就算后面优化不出来也能写个暴力的先拿分；二是很多时候暴力思路是通向最优解的突破口，比如看到“最大子序和”，暴力是枚举所有区间求最大和，你会自然想到“能不能复用前面算过的区间和”，进而走向前缀和或动态规划。
第三步，设计复杂度可接受的最优解。这步不需要直接写代码，在白板或者纸上把思路梳理一下，算好时间复杂度和空间复杂度。这一步做得好，会给面试官留下“这人真的有算法思维”的深刻印象。
第四步，跟面试官对齐思路。把你准备采用的解法和复杂度告诉面试官，问一句“我这样写可以吗”。大部分面试官都会点头说“可以”，甚至还会给你一些关键提示。这是一个合法合规的“场外求助”，不用白不用。
注意：这五分钟不是死板的流程，顺序可以灵活调整。比如你一眼就看出最优解了，那可以直接跳过暴力解，但“复述题意”和“对齐思路”这两步建议永远不要省略，它们是对自己代码的有效保护。
3.2 写代码过程中的两个关键习惯
进入了实际写代码的阶段，有两个习惯是资深工程师和面试官反复强调的，但很多求职者做不到。
习惯一：边写边讲。每一行代码，或者每一个函数块，用一两句话说明一下“这段代码是在干什么”。比如你写了一个while循环，可以说“这个循环是让快指针先走K步，然后两个指针一起走，这样快指针到达末尾时，慢指针正好指向倒数第K个节点”。别小看这几句话，它能让你自己的思路更清晰，也给了面试官参与进来的机会。
习惯二：函数块拆分清晰。哪怕只是一道几十行的算法题，也值得写成两个小函数，而不是一个大函数一撸到底。比如“反转链表区间”这道题，可以写成reverseBetween(head, m, n)和reverseList(head)两个函数，代码结构一目了然。面试官看代码时会觉得你有工程意识，评分自然会上一个档。
还有一个很多人忽视的细节：写完不要立刻说“写完了”。先自己过一遍代码，从函数开头到结尾逐行走一遍，检查有没有明显的 bug、边界遗漏或笔误。我在模拟面试时见过很多人勇敢地把带 bug 的代码交给面试官，结果面试官一指点，自己恍然大悟地拍大腿。自己先检查这一遍，是免费的“自救机会”。
3.3 如何优雅地主动设计测试用例
手撕代码到后期，面试官经常会追加一环：“你能写几个测试用例吗？”有些人会当场愣住，有些人会写“输入 1，2，3 输出 5”这种没有营养的用例。
实际上，设计测试用例是你展示“工程质量意识”的最佳时机。一个合格的测试集至少应该覆盖下面几类情况。
- 正常用例：比如一个中等规模的常规输入，确认主路径正确。
- 边界用例：空数组、长度为 1 的数组、负数、极大值、字符串包含空格的输入等。
- 特殊情况：题目描述里的“特殊条件”，比如链表只有一个节点、删除的是头节点、数组中全是重复元素等。
拿“三数之和”这道题举例，一个好的测试集应该包含：普通用例[-1,0,1,2,-1,-4]，全零用例[0,0,0]，不足三个数的用例[1,2]，包含重复答案的用例[-2,-2,0,0,2,2]。这四组用例足够说明你考虑到了去重、边界长度和退化情况，面试官基本很难再挑出毛病。
还有一个小技巧：写测试用例时用口述的方式说一遍，比如“我用一个空数组用例来验证代码不会越界，再用一个全是重复元素的用例来验证去重逻辑正确”。你在“说”的过程中，面试官能看到你的思考路径，这会比默默写用例得分高很多。
3.4 最优解不是唯一答案
我知道很多人刷题时养成了一个习惯：看题就想要最优解，非要做到 O(n) 时间 O(1) 空间才觉得满意。这个习惯在面试里有时候反而不是优势。
举一个真实的例子。有个朋友面试的时候遇到“寻找两个有序数组的中位数”这道题，严格最优解是 O(log(min(n,m))) 的二分查找。他背过这个解法，但在白板上默写时卡壳了，逻辑太复杂，写着写着把自己绕进去了。面试官看他卡了十分钟，说“你先写个 O(n) 的归并解法吧”，他很快写出来了，但最后整体评价还是被扣了分。
正确的做法是分层次处理。
- 如果一上来就能想到最优解，并且能在 15 分钟内写干净，直接写最优解。
- 如果最优解比较复杂，自己把握不大，先写一个次优但正确的解法，再告诉面试官“这版是 O(n) 的，我能想到一个 O(log n) 的优化方向，但需要一点时间确认细节”。这种做法既保证了代码正确，又展示了优化意识，很多面试官会接受，甚至觉得你很有工程判断力。
- 如果最优解写到一半发现写不下去了，果断停止，说“这版边界情况太复杂，我换个思路”，然后退回暴力解。这不算认输，反而是成熟的表现。面试官最怕的不是你写不出最优解，而是你卡在一个错误方向上一意孤行。
手撕代码的本质是一道“工程题”，不是“竞赛题”。在有限时间内交付一个可运行、可维护、思路清晰的代码，远比死磕最优解有价值。
4. 那些让人捶胸顿足的翻车现场与复盘
4.1 边界条件：手撕翻车的第一杀手
我在整理面经的时候发现一个规律：大多数人代码写了一半、甚至写完都跑通正常用例了，最后翻车都是翻在边界条件上。边界条件才是真正的分水岭。
举几个高频翻车场景。
空输入翻车。面试官问你“如果输入是null怎么办”，你这才反应过来自己的代码一开头就对head.val做了访问。其实很多链表题、树题，第一行代码就应该判断空输入。正确做法是养成肌肉记忆：拿到数据结构类题目，先问自己“空的情况我处理了吗”。
单元素翻车。反转链表时链表只有 1 个节点，循环里next指针变成null，然后下一行又去访问next.next，直接空指针。这也是高频翻车点。解决方法是：写完代码后手动拿 1 个节点的输入在脑子里过一遍。
负数/零/极值翻车。二分查找里left + right直接相加可能整数溢出，应该写成left + (right - left) / 2。最大子数组和初始值是 0 还是负无穷？如果数组全是负数，初始化为 0 就直接错。这些细节看似小，但面试官都是人精，一眼就能看出你有没有受过“算法严谨性”的训练。
下标越界翻车。滑动窗口类题目最容易出现right < n还是right <= n这种临界条件搞错的错误。我自己的经验是：拿到这种题，先在白板上写下数组长度和下标最大合法值，再动手写循环，真的能有效减少越界。
4.2 时间管理：在一道题上耗还是放弃
手撕代码的时间一般是 20 到 40 分钟不等。很多人遇到一道有点难的题，卡了 15 分钟后陷入一个尴尬的境地：继续硬磕，可能最后也写不完；放弃重来，又觉得有点可惜。
我自己的经验是设置一个“15 分钟原则”：如果一道题在 15 分钟内没有形成清晰的思路，或者代码写到一半发现自己对整个方案的可行性已经没底，就果断停手，跟面试官说“我目前想到的最优方案是这样，但它在某个边界条件下处理起来很复杂，我换个思路再试一次”。这个话术给面试官传达的信息是：你有时效意识，有决策能力，不是那种死磕到底的“倔驴”。
另一个相关技巧是：无论如何都要在最后留下一个可运行的版本。如果时间不够，宁可放弃最优解，把暴力解写好。面试官考察的是“你能否在真实工作压力下交付可用的代码”，而不是“你能否在算法竞赛里拿满分”。一个能跑通的 O(n²) 解法，永远强过一个没写完的 O(n) 解法。
4.3 心态崩了怎么办
手撕代码时心态崩掉的情况非常多。尤其当你觉得“这题明明见过，怎么现场写不对”的时候，焦虑感会瞬间拉满，然后越急越写不对。
我分享三个亲测有效的“急救方法”。
急救方法一：回到暴力解。当你脑子里一片混乱时，别管什么最优解了，先写一个最简单的暴力解法。暴力解的思路相对固定，能很快让你回到“写代码”的节奏里，缓解紧张感。哪怕是两层 for 循环，至少你在输出东西，这种“掌控感”比卡在那里无所事事强得多。
急救方法二：把“我不会”转成“我目前想到的是”。直接跟面试官说“我不会”等于自我放弃，但“我目前想到的是用哈希表来优化查找，不过对于冲突处理还没想好，您觉得这个方向对吗”就完全不一样。前者是宣告失败，后者是把面试官拉进你的思考过程，变成一次“合作解题”。面试官很吃这一套，毕竟他们也是从求职阶段过来的。
急救方法三：用具体例子跑思路。如果你不知道怎么推导转移方程，直接拿一个小例子手动跑一遍。比如动态规划题拿一个长度为 3 的数组，手动填表格，填着填着你就会发现规律。我在模拟面试里用过这个方法，确实能从“大脑空白”里自救出来。
注意：心态崩了不是问题，问题是崩了之后什么都不做。哪怕是写出一个半成品，也比交白卷强。面试官见过很多紧张到写不出代码的人，他们更看重你如何处理“我不会”这个真实的工作场景。
4.4 面的题没刷过怎么办
手撕代码嘛，总有遇到没刷过的题的时候。哪怕你把剑指 Offer、LeetCode Hot 100 都刷透了，面试官依然可能从某个犄角旮旯掏出一道你没见过的题来。
遇到这种情况，最忌讳的是沉默。正确姿势是：把“我没刷过”换成“我对这类问题有一些了解”。比如你没刷过“天际线问题”，但你可以从“这道题涉及多个区间的合并和高度维护”开始讲起；你没刷过“自由之路”，但你至少可以说“这道题的暴力解法应该是枚举所有可能的状态”。
然后就是顺着这个思路硬推。很多时候你以为自己没刷过，其实你刷过类似的原型题。比如面试官考你“寻找旋转排序数组中的最小值”，你虽然没刷过原题，但只要刷过“搜索旋转排序数组”，思路是完全通用的。体会到这层关系之后，你就能明白为什么常刷题的人“什么题都会”，不是因为他们见得多，而是他们擅长“包装原型”。
还有一个隐藏技巧：主动向面试官要提示。有些平台、有些公司是允许面试官给提示的，面试官给提示不扣分，反而会因为“你懂得在恰当的时候求助”而给你加沟通分。但前提是你先表达了你已经思考过，比如“我考虑过用双指针，但不确定移动哪个指针会比较高效，你能给我一点提示吗”，而不是一上来就说“这题我不会”。
5. 手撕代码的准备计划与资源搭配
5.1 从零开始的刷题路线
说实话，手撕代码如果没有系统的准备，光靠面试当天的临场发挥，成功率非常低。这里我给出一条亲测有效的刷题路线，大家可以按下面的阶段来规划时间（以下时间按每天 2–3 小时的刷题时间估算）。
阶段一：基础补全（约2–3周）。先刷数组、字符串、链表、栈、队列、哈希表这些基础数据结构，题目难度以 Easy 和 Medium 开头为主。这个阶段的目标是“建立手感”，不追求数量，每道题都要把暴力解和至少一种优化解法写出来。
阶段二：核心算法（约3–4周）。系统性地刷树、图、二分查找、滑动窗口、双指针、动态规划、回溯。这一阶段要注意分类，每类先做 10–15 道入门题，再做 5 道综合应用。做动态规划时，建议把状态定义、转移方程、初始化和遍历顺序写成一个“四件套”，复盘时一目了然。
阶段三：综合模拟（约2周）。以 25–40 分钟为限，做整套的模拟面试题，使用在线白板工具或干脆用纸笔。把每一道做过的题用“讲一遍”的方式复盘，最好能对着镜子或者用录音功能录下来，检查自己的口头表达是否流畅。
阶段四：冲刺加固（面试前1周）。把高频题和错题本过一遍，把最近面经里出现的新题看一遍，重点练习“时间压力下的快速思路构建”。
这个路线图适用于校招和社招候选人。社招的话，可以压缩阶段一的时间，把重点放在阶段二和三上，因为社招手撕代码的难度定位通常与你的职级正相关，算法题的考察会更注重工程场景而非纯算法技巧。
5.2 要不要纠结“最优解”
很多人在准备期间的困惑是：“我要不要把 LeetCode 每道题的最优解都背下来？”我的答案是：不用，也不建议。
正确的目标应当是：做到“看到题目能快速判断题型和大致解法”。举例来说，看到“子数组”，你会想到滑动窗口、前缀和、动态规划；看到“树”，你会想到递归、层序遍历、迭代栈。有了这个判断能力，就算遇到没见过的题，你也能在五分钟内找出一个方向。
刷题数量方面，我的建议是把“剑指 Offer”里的题全部吃透，再把 LeetCode Hot 100 刷掉 60%。这两部分的覆盖范围已经能应对九成的手撕场景。剩下的，靠“归纳”而不是“背诵”来补充。
另外，要推荐一个具体操作方法：做过的题至少隔三天重做一遍。这里说的“重做”不是重看一遍答案，而是重新在白板上从头写一遍。你会发现很多你以为掌握了的题，过三天根本默写不出来，这种“抓漏”方式比你多刷三倍新题都有用。
5.3 项目实战与算法题目的平衡
有些求职者，特别是社招的，会陷入一个误区：把准备手撕代码的时间拉到极致，结果项目部分反而没时间准备了。这里要泼一盆冷水：手撕代码只是面试一关，项目讲解、系统设计、行为面试同样重要。
平衡的建议是这样：面试前两个月，每天 60% 的时间刷题，40% 的时间整理项目经历；面试前一个月，调整到 50% 刷题、30% 系统设计、20% 行为面试准备；面试前一周，每天只固定 1–2 小时做手撕模拟，把剩余精力放到“讲项目”和“讲设计”上。
很多人在面试环节被刷，不是手撕代码挂了，而是因为“项目经历讲得毫无亮点”——没有数据支撑、没有难点复盘、没有技术选型对比。码农的职业竞争力是综合的，千万不要因为死磕手撕代码，把项目的武器给丢了。
5.4 我常用的刷题复盘模板
最后分享一个我一直在用的刷题复盘模板。每做完一道题，我会按下面五个字段做记录。
- 题目链接与难度：方便后续回刷。
- 核心考点：用 2–3 个词概括，比如“双指针、去重、排序”。
- 最优解思路：用自己语言描述，不要复制题解。
- 我踩的坑：记录当时的错误认知和错误写法，复盘价值最高。
- 举一反三方向：记录这道题可以迁移到哪些题目上，形成知识网络。
这个模板看起来很简单，但坚持用它做，效果非常明显。我认识的几个拿到大厂 offer 的朋友，都有类似的复盘习惯。它本质上是在帮你构建“遇到新题能想起老题”的迁移能力，而迁移能力，恰恰是手撕代码考察的核心能力之一。
写在最后
我个人在实际准备手撕代码的过程中，最深刻的体会是：刷题数量是下限，复盘习惯和沟通能力才是上限。很多人以为手撕只是写代码，实际上它是一场“有代码参与的综合面试”。代码之外的沟通、思路拆解、现场决策，往往才是面试官真正在意的。
再分享一个小技巧：模拟面试时，我习惯把面试官当成一个“代码评审同事”，而不是一个“考官”。这个心理切换很微妙但很有效，它会让你更放松、更愿意表达思考过程，而不是全程追着标准答案跑。手撕代码是一个可以训练的技能，找对方向，踏实练上两个月，大多数人都会有肉眼可见的提升。
