很多面試者希望能夠在 IDE 中（而不是白板上）編寫代碼，因為： >[info] 1. 主流 IDE 均帶有智能提示，從而大大提升了編碼速度 > 2. IDE 可以保證程序能夠編譯通過 > 3. 可以通過 IDE 運行/調試代碼，找到程序的 Bug 我承認第 1 點，白板編程要比 IDE 編程慢很多，但這并不能做為否認白板編程的理由——因為白板編程往往是 API 無關（因此并不需要你去背誦 API）的一小段（一般不超過 30 行）代碼，而且面試官也會允許面試者進行適當的縮寫（比如把`Iterable`類型縮寫為`Iter`），因此它并不能成為否認白板編程的理由。 至于第 2 點和第 3 點，它們更不能成為否認白板編程的借口——如果你使用 IDE 只是為了在其幫助下寫出能過編譯的代碼，或是為了調試改 Bug，那么我不認為你是一名合格的程序員——我認為程序員可以被分為兩種： >[info] 1. 先確認前條件/不變式/終止條件/邊界條件，然后寫出正確的代碼 > 2. 先編寫代碼，然后通過各種用例/測試/調試對程序進行調整，最后得到似乎正確的代碼 我個人保守估計前者開發效率至少是后者的**?10 倍**，因為前者不需要浪費大量時間在?**編碼-調試-編碼**?這個極其耗時的循環上。通過白板編程，面試官可以有效的判定出面試者屬于前者還是后者，從而招進合適的人才，并把老油條或是嘴遁者排除在外。 除了判定面試者的開發效率，白板編程還有助于展示面試者的編程思路，并便于面試者和面試官進行交流：  白板編程的目標并不是要求面試者一下子寫出完美無缺的代碼，而是： * 讓面試者在解題的過程中將他/他的思維過程和編碼習慣展現在面試官面前，以便面試官判定面試者是否具備清晰的邏輯思維和良好的編程素養 * 如果面試者陷入困境或是陷阱，面試官也可以為其提供適當的輔助，以免面試陷入無人發言的尷尬境地