刷了几百道LeetCode，面试时还是卡壳？有人把问题归结为"题量不够"，但真正的卡点可能不在算法本身，而在你写代码之前的那几分钟。
一位开发者记录了自己准备算法面试的完整过程。他没有一上来就扎进题库，而是从简单的AI生成练习题开始，每天2到3道，根据难度调整节奏。这个选择背后的逻辑很直接：直接刷难题会击碎信心，而带着不安全感走进面试，结果通常不会好。
先找到自己的"摩擦点"
每做完一道题，他会回头定位那些让自己卡住的具体环节。这些摩擦点被逐一记录下来：
- 还没完全理解问题就开始写代码
- 一口气写太多代码，中间不做测试
- 写到一半开始自我怀疑
- 出现bug时感到尴尬，不知道如何体面地恢复
他甚至录下了自己练习的过程，回看录像来评估自己的节奏、讲解方式和整体状态。这个做法把"感觉哪里不对"变成了可以观察和调整的具体问题。
找到摩擦点之后，他逐渐摸索出一套固定的工作节奏，用来在面试中保持稳定。
一套可以复用的解题节奏
这套节奏从写代码之前就开始了。第一步是澄清假设，把所有假设写下来。接着验证环境，先写一个空函数打印测试输出，确认一切正常运行。
然后是最关键的一步：手动追踪算法。用示例输入一步步走，找出每一轮迭代中需要的所有变量。这个过程不写代码，只在纸上或屏幕上推演。
如果中途卡住，就把自己正在试图解决的问题说出来。比如："这里需要一个标志位吗？一个累计值？这个变量是按组追踪还是跨所有组追踪？"把困惑讲出来，本身就是推进思路的方式。
逻辑验证通过后，再用示例输入走一遍，确认变量被正确设置、重置或累加。一直追踪到手动步骤能产出预期结果为止。
只有逻辑被证明可行之后，才开始写代码。这个顺序的意义在于：避免在还没想清楚的时候就被语法细节拖住。
到这一步，面试官已经能清楚看到你的思考过程，因为伪代码和变量状态追踪都已经在屏幕上了。
调试不是丢人的事
写代码之后，他建议尽早、频繁地打印调试信息，实时监控关键数据结构。不要犹豫使用简单的print语句——早点抓到bug，就能避免后面出现意外输出打乱自己的节奏。
如果意外输出还是出现了，把它当成工作日里处理的一个普通工单。这个心理框架的作用是让情绪保持稳定。面试中的bug不是能力证明，只是一个待修复的问题。
回头看这套方法，它解决的其实不是"会不会做这道题"，而是"能不能在压力下把已经会的东西稳定输出"。前者靠刷题量，后者靠节奏感。而节奏感，是可以被拆解、被练习、被录像回看一点点打磨出来的。
如果你也在准备面试，不妨从记录自己的摩擦点开始。你卡住的到底是算法，还是写代码之前的那几分钟？
热门跟贴