這是一道關於符號偵錯程式實現原理的討論題。目的不是考察除錯經驗或者偵錯程式設計，而是想借助這個話題來考察候選人的計算機基礎知識和工作性格。一般這樣開頭：
有用過偵錯程式吧？都用過那些功能？接下來和候選人探討偵錯程式背後的實現原理，比如如何實現檢視變數，檢視記憶體，檢視呼叫棧，如何實現斷點等。
選擇這個話題的原因之一是有話可說，幾乎所有程式設計師都有使用偵錯程式的經歷；其二是絕大多數人都沒有親自設計偵錯程式的機會，反饋出來的資訊能反映候選人的真實水平。
好處之一，識別沒有鑽研精神的候選人
我理解很多工程師在生產活動中並不使用偵錯程式，但是偵錯程式基本上是初學程式設計階段的必備工具。在初學者眼中，偵錯程式就像一個上帝般的存在，他和我們自己編寫的程式有很大的不同–他能窺探和操縱別的程式。很難想象一個對計算機軟體真正感興趣的程式設計師從來沒有考慮過這傢伙背後的原理。
如果一個工程師從來不思考偵錯程式的原理，那麼他及有可能也不會去思考資料庫的原理，不會去思考作業系統的原理，甚至也不會去思考經常使用的某個第三方庫的原理。這些沒有思考過的地方都是他的知識盲區，導致他永遠無法有把握的程式設計。而且這種候選人有個對工程師來說的致命傷–缺乏主動探索的好奇心。通常進來有什麼技能，出去還是那些技能。
好處之二，識別基礎知識有瑕疵的候選人
當我們討論如何獲取呼叫棧，如何檢視變數時，真實的意圖是考察候選人對程式執行時刻環境的理解；當我們討論斷點的設計時，其實也是在考察類似於中斷/訊號這種體系結構/作業系統方面的基礎知識。
這些知識是編寫靠譜軟體最最基本的知識，比資料結構還要基礎。搞不清楚呼叫棧佈局的工程師無法理解區域性變數寫越界後程式為什麼飛到一個莫名其妙的地方，因此他很難真正理解安全程式設計規範；而理解了物件執行時形態的工程師不會無意識寫出故意和垃圾回收做對的程式碼；有些工程師在軟體不能正常工作時只能通過不斷回退版本分析程式碼文字來定位，沒辦法拿著core dump直接了當的分析問題，原因就是他腦袋裡只有原始碼，沒有程式的執行時模型。換句話說他其實就是一個邏輯程式設計者，沒錯，這就是有人認為數學過關就能編好程式的原因。
實戰中的反饋
以下是面試過程中收到的一些反饋：
- 如果是嵌入式工程師，他們會講到JTAG的原理
- 如果是c/c++程式設計師，他們會聊到編譯原理，作業系統，處理器
- 如果是java或者python程式設計師，他們會聊到虛擬機器，聊到執行時物件模型
下次招人的時候，我推薦你不妨也試試這把錘子。它未必能幫你發現優秀的程式設計師，但是能幫你識別不靠譜的程式設計師。