忍不住回應下，有在使用 Homebrew 應該知道這套件管理軟體超級強大
作者 Max Howell 去 Google 面試被問如何反轉 binary tree
這位大神當場掛掉，面試失敗
這種反轉二元樹題目po上ptt還會被鄉民笑，
但影響全世界軟體界的大神就是沒在刷這種東西
不只 Homebrew, 連 Python 創始作者 Guido van Rossum 當初面試Google也差點被刷掉
後來Google內部有檢討為什麼現在機制會刷掉這種大神
他們也承認要寫出頂級軟體產品其實這些東西並非必要
後來G社面試委員會找了篇論文，
該論文指出很會刷code的面試者進公司數年後，
平均產出比同公司沒在刷code的人還高
所以他們根據此研究就繼續保持這項「傳統」
另外我當面試官時，
會盡可能用系統設計的角度去判斷此人是否有足夠的軟體經驗
1.版本控制
不是考他指令，而是問他情境
開發中的功能是否放在主線branch還是獨立拉出來，兩者優劣差異
如何管理binary file 如何做Review機制
可從版控問到CI/CD甚至自動化測試的經驗 (對方答出一個套件也沒差，至少他有經驗)
也面過完全沒在做版控的，用資料夾跟檔案命名版控，
這樣你就知道他進來的話需要學什麼
重點是: 有版控清楚的觀念
2.API
遇過工作好幾年的軟體工程師完全分不清楚API是什麼 該怎麼設計
為什麼需要RESTful? 什麼時候不需要RESTful
REST跟SOAP差異
然後可以從API追問到microservice的經驗、異質API的介接
跨單位或跨司合做這項技能很重要，代表公司跟對方技術人員談時比較能進入狀況
3.Service
剛畢業大概傻傻分不清楚server跟service差在哪
可以問寫過/用過什麼service
若對方有雲端經驗，可以聊SaaS/PaaS/IaaS
然後聊聊企業在資源不足情況該如何選擇
有經驗的可以多聊聊上面提過的microservice, load balance, inverse proxy...
4.安全性
遇過把產品私鑰發佈給客人的工程師
簡述公私鑰機制
什麼應用情境是由server產生公私鑰 / 什麼情境是由client產生
憑證是什麼 SSO是什麼
這可以聊很多，看應徵職務。但最基本觀念還是需要有
(曾經還有工程師把連線到雲端資料庫的connection string寫在客人電腦client端,吐血)
5.資料庫
關聯性資料庫跟NoSQL優劣，什麼情境需要用到前者/後者
正規化的意義是什麼? 為什麼我們偶爾需要反正規化?
資料庫加密機制 封存機制 同步設計 auto-scaling
6.法規
歐盟 GDPR 如何做內控及如何因應歐盟/競爭對手的檢舉
什麼情況的產品,客人會受到 GDPR 的保護? 如何讓產品合規
同理, 美國CCPA也可以聊 看他經驗有多少
這塊台廠RD大概比較弱，想說這是PM的事
但設計系統時 (特別是資料庫)，若開發人員搞不清楚亂寫一通
後面只是等著被競爭對手弄而已
7.開源軟體授權
常見可商用授權有哪些? 如何做才能商用?
過去有無寫過軟體第三方授權宣告
二流的真的沒在管，網路抓抓就套用然後做成產品了
這也是等著被競爭對手弄而已
8.其他
什麼情境使用long polling 為何使用web socket
docker 的應用
OS相關
軟體/韌體/driver
...族繁不及備載...
多跟面試者聊這些就知道他過去的經驗及接觸多少東西
有經驗的工程師，至少都能說出些東西，馬上就知道這人值不值這個價
最後我想說...軟體不是只有刷題 (很重要沒錯，但那只是冰山一角)
不要面試者一坐下就問那些什麼紅黑樹考白板，我真覺得那太狹隘了
明明軟體有那麼多面向可以聊
供參考囉
: 也因為刷題滿辛苦的,所以代表這個人可能是個努力的人
: 像做embedded system相關,跟刷題相關性不大
: 但是至少有一定水準的coding能力在設計架構跟實作比較不會犯基本錯誤
: 曾經面過一個說的一嘴的好經驗~ 但是寫個LinkedList都寫不出來
: 也面過一個直接跟我說刷題用處不大~要我不要問他coding
: 可以把刷題當成基本門檻跟英文一樣
: 擁有這些基本能力再繼續談其他的這樣
: ※ 引述《dickjas (夏天的航海記)》之銘言：
: : 小弟不才, LeetCode只刷了幾題. 但小弟已經工作了快18年
: : 也做了很多的大型Project, 真心認為刷題跟寫程式其實沒有很大的關西
: : 所以想請問各位300萬大大, 真的有需要刷題嗎?還是純粹就為了面試?
: : 在下工作比較邊向機台開發和嵌入式系統
--