程序员面试实用技巧总结

面试过程往往充满微妙的考量。许多面试官在让你现场编写代码之前，都会先与你交流背景经历。他们着重考察的通常是以下几个维度：

• 你对优秀代码的理解深度——是否真正掌握高质量代码的标准？
• 个人能力与领导力——你是否有过完整的项目流程经验？是否曾主动修复那些“虽可忽略但确实存在”的潜在问题？
• 沟通能力——与你进行技术交流是愉悦还是费力？

针对这类背景调查，建议从以下几个角度切入——至少深入探讨其中一项：

• 你曾攻克的一个技术难题
• 你成功化解的一次团队分歧
• 展现领导力或个人能力的真实案例
• 你在项目中做出的具体贡献
• 对常用编程语言的吐槽与深度见解——你用它完成了什么，对其有何改进想法
• 针对目标公司产品或业务的提问
• 对其工程方法的探讨（例如测试流程、Scrum实践）

事实上，对技术的热爱无法掩饰。你应当自然流露出自信与自豪——对自己的成果充满成就感，对技术选择有明确的判断力。这些特质远比标准答案更有说服力。

沟通

进入编码环节后，沟通能力便成为关键分水岭。值得注意的是，遇到困难时懂得如何求助与沟通的候选人，往往比能独立解决所有问题的候选人更受欢迎。因为在真实工作中，极少有人能够独自完成所有任务。

首先，需要判断当前问题的类型。通常分为两类：

• 编码题。面试官期望你写出简洁高效的代码。
• 开放式问题。面试官希望与你深入探讨，例如高级系统设计（“如何克隆一个Twitter？”），或者某些技术细节（“如何理解JavaScript的变量提升？”）。有时，这类讨论会自然演变为一个实际编码题，比如“如何对整数列表进行快速排序？如果是其他类型呢……”

如果你一开始就动手写代码，而面试官并不想听你解释，最好直接询问：“需要我为这个问题编写代码吗？”——这样可以避免浪费时间。

另外，体现团队合作意识很重要。面试官本质上在评估“与你共事的感受”。多使用“我们”，少用“我”。例如：“如果我们采用广度优先搜索，就能及时得到那个解决方案。”如果可以选择在纸上还是白板上写，优先选择白板——这样你可以站到面试官旁边，直接面对问题，而不是隔着桌子。

还有一个常被忽略的技巧：说出你的思考过程。 像“我不知道这样是否可行，但让我试试”这样的话，完全可以表达。遇到卡壳，就描述你当前的思路——什么可能有效，什么可能无效，以及原因。即使面对JavaScript闭包这类问题，能说出“与作用域有关，尝试放到函数中”这样的答案，也能获得大部分分数。

当然，遇到不确定的内容，不要假装明白。直接说：“我不确定，但我猜测是$thing，因为……”。然后继续分析，排除其他可能性，或者用其他语言进行类比。这比强行装懂要明智得多。

但有一点需要注意：不要抢答。 这不是速度竞赛。过于匆忙给出答案，反而显得鲁莽。如果答错，场面会很尴尬。给自己留出思考时间，同时也给面试官留出提问机会。

摆脱困境

遇到卡壳是难免的。放松，这并不表示你失败了。许多面试官真正关注的不是最终正确答案，而是你是否能从不同角度分析问题，灵活地寻找解决路径。

画图示意。 不要只在脑中思考，动手画出来。画出几个不同的测试输入；画出你手动操作如何得到期望的输出；然后再想办法将这些步骤转化为代码。

从简单版本开始。 不知道如何找出集合中第4大的元素？先考虑如何找第1大的，然后看是否能用同样的思路。

先写出低效但正确的版本，再逐步优化。 即便只是勉强写出一个能运行的答案，也比一片空白要好。

阐述你的思路。 说出你知道的内容，你认为什么可能有效，什么可能无效。这个过程可能帮助你突然发现某个方案实际上可行，或者得到一个稍加修改就能奏效的方法。有时，面试官正在等待这个时机给你提示。

主动考虑时间与空间复杂度。 例如：“我至少需要遍历所有元素，不可能比O(n)更快”，或者“暴力方法才能枚举所有可能”，又或者“结果集包含n²个数据项，所以至少需要n²的时间。” 说出来，能让面试官看到你有清晰的分析能力。

写下你的思路

仅靠脑中思考容易产生矛盾。将思路写下来，细节可以后续补充。

调用辅助函数，继续推进。 如果某个功能实现一时难以想出，不要卡住。写一个名称清晰的函数调用，例如“this will do X”，然后继续向前推进。如果这个辅助函数很简单，甚至可以稍后补充。

不必纠结语法细节。 一笑了之即可。如果忘记某种语言的特定写法，直接用英语描述思路，并告知面试官后续再完善。

预留空白区域。 从白板顶部开始书写，行与行之间保持间距——你很可能会在后面添加笔记或代码。

最后添加检查标记。 不要纠结于for循环的条件是“<”还是“<=”——在代码末尾画个勾，提醒自己最后再回头处理细节。先确保主流程正确。

使用描述性变量名。 命名虽花时间，但能帮助你记住每段代码的用途。例如使用names_to_phone_nums_map而非nums。返回布尔值的函数以is_*开头，保存列表的变量以s结尾。这种编码习惯非常有价值。

完成之后的整理

完成编写后不要急于提交。将解决方案再检查一遍，大声讲解，并模拟运行一个例子。记录变量每一步的值——仅靠脑记不会加分。这不仅能帮助你发现bug，也能消除面试官的疑虑。

检查差一错误。 你的for循环是否应该使用“<=”而不是“<”？

测试边界情况。 空集合、单元素集合、负数……都是潜在的陷阱。主动提及单元测试，将为你加分。

但不要过度。有些面试官可能不关心这些细节。如果不确定，可以询问：“我通常会在这种情况下进行边界测试——我们需要检查一遍吗？”

实践

最后，最朴素的真理是——没有捷径可走。

好记性不如烂笔头。一开始在纸上写代码可能会不适应，但只要现在克服这种不适，真正面试时就能从容应对。

本文所总结的要点，只是面试过程中的一些线索与思路。没有放之四海而皆准的规则，实战中仍需灵活应变。最后，祝你面试顺利。