: 推 strlen: 哪有什麼不能左右？智力測驗都立法不準考了 鬧一鬧以後白 10/05 11:28
: → strlen: 板題也是智力測驗的一種 也立法除非職務有需求不然不準考 10/05 11:28
: → strlen: 也是很合理的啊？我跟你說喇99.99%的程式職缺根本就都用不 10/05 11:29
: → strlen: 到那些拉機白板題 在現實中一點用處都沒有 10/05 11:29
: → strlen: 沒用的東西大家拼命刷 用力刷 這他X的跟古代考八股文有87% 10/05 11:29
: → strlen: 像 這不就是智力測驗的變形而已？腦殘公司才會在那邊通通 10/05 11:30
: → strlen: 考白板 就只是便宜行事而已 10/05 11:30
現實生活中也不少人用不到微積分，你看
看有多少大專院校科系把它列為基礎必修
科目？
我也同意絕大多數的白板面試考題，你在
現實開發場景中幾乎遇不到一模一樣的題
目。但不代表他背後考核的東西，沒有測
驗的價值，也不代表他背後考核的東西，
在現實開發場景中沒有用處。這個我想之
前有版友分享過了：
Re: [討論] 軟體工作真的有需要刷題嗎?
https://hhp.li/BDCnO
所以舉「99.99%的程式職缺根本就用不到
那些拉基白板題」做為反對白板面試的篩
選機制，說真的有點好笑；我想這可能也
是很多反對刷題仔的一些誤區：
(1) 題目要刷夠多？
實際上不是，題目可能背後考的是同一個
思想，有些人練習的題目數量是別人的十
分之一，但卻花心思從中看出了「套路」
可以取一反三寫出其他題。在 Educative
上面有一門很知名的課程有總結這些所謂
的刷題套路（pattern）：
Grokking the Coding Interview
: Patterns for Coding Questions
https://hhp.li/8cucv
(2) 面試上遇到題目就是要給出最佳解?
實際上可以說是，也可以說不是。有些題
目考核的是你的熟悉度，這種可能就是面
試官希望你能夠一上來就拿出一個複雜度
低的解法；但有些題目考核的是你的溝通
能力與思考過程，這種不用一上來就端出
最佳解，而是一步步在互動過程中完善解
答，甚至有時候你即使這題沒有 AC 也能
拿到比那些背誦給出 AC 的人更高的分數
。
（所以即使你刷過一題，可以直接給出最
佳解，有時候藏拙裝笨會比直接端出最佳
解更好。）
大廠的不同關卡通常會有給定的時間限制
，可能會預設說這關要出幾題 easy、幾
題 medium、幾題 hard。如果今天預設這
一關要測 2 easy, 1 medium 結果你的時
間只答出 1 easy 那就掰了；如果今天預
設要測 2 hard，結果你直接給最佳解，
省略那些溝通過程，只能出更多 hard。
有些東西是要有一些「感覺」的，要能夠
猜出對方想要測驗什麼，這其實不論刷不
刷題都很重要。
(3) 白板面試測驗到底好不好？
說真的就是「見仁見智」，如同上一篇說
的，他可能只是面試多個關卡中的其中一
個環節；有些大廠還是會考，有些大廠則
有其他選才機制。
我認為他有存在的必要，而且的確是滿適
合作為篩選機制，其中：
> 如果給出對方沒見過的題目，能夠考察
對方對於文義的理解，還有能不能在題目
敘述完畢後，額外再來問我一些沒提到的
限制條件或是資料狀況？
舉個比較淺顯易懂的例子，今天題目中有
個操作是需要排序，對方會不會注意原始
資料是不是已經基本有序？會不會問有沒
有記憶體的限制要做額外處理？
> 能不能適當地把題目要實作的內容，選
擇適當的資料結構，把問題「抽象化」，
有了適當的資料結構再來設計演算法？
最簡單的就是同樣都是線性結構，可以使
用 Linked List 儲存也可以用 Array 儲
存，為什麼要選其中一個？是根據哪個考
量？為什麼？
> 實作過程中有沒有考慮邊界條件，提前
不符合就返回，避免冗贅的計算或是處理
了本身題目就不會進來的條件。
有位教師經常舉因為程式錯誤導致飛機失
事的例子，來說明工程師的重要性。練習
的過程中，會不由自主地去想到這些，當
然這也包含在前面兩點中，有沒有空值？
有沒有負數？有沒有重複值？是不是整數
值？
> 有沒有良好的開發習慣？命名習慣？單
元測試？
會不會出現神奇的 a, aa, b, dd 變數名
稱？會不會適當地將操作封裝成函數？
後者的習慣讓我在實際開發上有不小的收
穫，一來是除錯時方便定位，二來是會對
程式更有一種掌控感。中國大陸有一名臉
書離職的員工跑去開了所謂的刷題課，雖
然課程內容我不覺得有多好，但他最一開
始有個導論介紹他怎麼寫題目，收穫算是
頗豐。
他提到他曾經的主管，會在釐清問題之後
先寫下過程中要實作的函數，而不是全部
都寫完邏輯之後再拆分成函數。這種「自
頂向下」的開發方式，會有一種提綱挈領
的用處。
（而且這種習慣，搭配 GitHub Copilot
面對實務中那種常見的 CRUD 寫起來根本
超級無腦……）