一道题识别不靠谱的程序员

　这些年招聘软件工程师，和所有面试官一样，工具箱里也积累了几把锤子，帮助尽快鉴别候选人。

　　其中一道是关于符号调试器的讨论题。一般这样开头：有用过调试器吧?都用过那些功能?接下来和候选人探讨调试器背后的实现原理，比如查看变量，查看内存，查看调用栈，打断点等，在此过程中根据应聘者的程度高低给予或多或少的提示和支持。选择这个话题的原因之一是有话可说，几乎所有程序员都有使用调试器的经历;其二是绝大多数人都没有亲自设计调试器的机会，通过讨论反馈出来的信息相对真实。

　　好处之一，识别没有钻研精神的候选人

　　我理解很多人在生产活动中不用调试器，但是调试器基本上是初学编程阶段的必备工具。在初学者眼中，调试器就像一个上帝般的存在，他和我们自己编写的程序有很大的不同--他能窥探和操纵别的程序。很难想象一个对计算机软件真正感兴趣的程序员从来没有考虑过这家伙背后的原理。

　　如果一个工程师从来不思考调试器的原理，那么他及有可能也不会去思考数据库的原理，不会去思考操作系统的原理，甚至也不会去思考经常使用的某个第三方库的原理。这些没有思考过的地方都是他的知识盲区，导致他永远无法有把握的编程。而且这种候选人有个对工程师来说的致命伤--缺乏主动探索的好奇心。通常进来有什么技能，出去还是那些技能。

　　好处之二，识别基础知识有瑕疵的候选人

　　当我们讨论调用栈，讨论调试器如何查看变量时，真实的意图是考察编译原理这方面的基础知识;当我们讨论断点的设计时，其实也是在考察类似于中断/信号这种体系结构/操作系统方面的基础知识。

　　这些知识基本上是编写靠谱软件最最基本的知识了。是的，比数据结构还要基础。比如你不能指望一个搞不清楚调用栈的工程师能避免堆栈溢出，也不能指望一个对程序内存布局没有概念的工程师能定位内存问题。他们只知道内存写越界会把程序搞崩溃，但是不知道是怎么崩溃的。有些工程师在软件不能正常工作时只能通过不断回退版本来定位，没办法拿着core dump直接了当的分析问题，根本原因就是脑袋里只有源代码，没有计算机的运行时模型。换句话说他其实就是一个逻辑编程者，没错，这就是有人认为数学过关就能编程序的原因。

 

　　下次招人的时候，我推荐你不妨也试试这把锤子。它未必能帮你发现优秀的程序员，但是能帮你识别不靠谱的程序员。