這是一道關于符號調試器實現原理的討論題。目的不是考察調試經驗或者調試器設計，而是想借助這個話題來考察候選人的計算機基礎知識和工作性格。一般這樣開頭：

有用過調試器吧？都用過那些功能？接下來和候選人探討調試器背后的實現原理，比如如何實現查看變量，查看內存，查看調用棧，如何實現斷點等。

選擇這個話題的原因之一是有話可說，幾乎所有程序員都有使用調試器的經歷；其二是絕大多數人都沒有親自設計調試器的機會，反饋出來的信息能反映候選人的真實水平。

好處之一，識別沒有鉆研精神的候選人

我理解很多工程師在生產活動中并不使用調試器，但是調試器基本上是初學編程階段的必備工具。在初學者眼中，調試器就像一個上帝般的存在，他和我們自己編寫的程序有很大的不同–他能窺探和操縱別的程序。很難想象一個對計算機軟件真正感興趣的程序員從來沒有考慮過這家伙背后的原理。

如果一個工程師從來不思考調試器的原理，那么他及有可能也不會去思考數據庫的原理，不會去思考操作系統的原理，甚至也不會去思考經常使用的某個第三方庫的原理。這些沒有思考過的地方都是他的知識盲區，導致他永遠無法有把握的編程。而且這種候選人有個對工程師來說的致命傷–缺乏主動探索的好奇心。通常進來有什么技能，出去還是那些技能。

好處之二，識別基礎知識有瑕疵的候選人

當我們討論如何獲取調用棧，如何查看變量時，真實的意圖是考察候選人對程序運行時刻環境的理解；當我們討論斷點的設計時，其實也是在考察類似于中斷/信號這種體系結構/操作系統方面的基礎知識。

這些知識是編寫靠譜軟件最最基本的知識，比數據結構還要基礎。搞不清楚調用棧布局的工程師無法理解局部變量寫越界后程序為什么飛到一個莫名其妙的地方，因此他很難真正理解安全編程規范；而理解了對象運行時形態的工程師不會無意識寫出故意和垃圾回收做對的代碼；有些工程師在軟件不能正常工作時只能通過不斷回退版本分析代碼文本來定位，沒辦法拿著core dump直接了當的分析問題，原因就是他腦袋里只有源代碼，沒有程序的運行時模型。換句話說他其實就是一個邏輯編程者，沒錯，這就是有人認為數學過關就能編好程序的原因。

實戰中的反饋

以下是面試過程中收到的一些反饋：

如果是嵌入式工程師，他們會講到JTAG的原理

如果是c/c++程序員，他們會聊到編譯原理，操作系統，處理器

如果是java或者python程序員，他們會聊到虛擬機，聊到運行時對象模型

下次招人的時候，我推薦你不妨也試試這把錘子。它未必能幫你發現優秀的程序員，但是能幫你識別不靠譜的程序員。