Re: [請益] 如何面試中認出優質的工程師？

[tomtang0406 (~~~)]

需要什麼樣的流程，愚以為要看公司規模，系統特性，人員組成來決定，大象不會跳舞。
打快攻有快攻的流程（搶市佔），禁區防守有防守的流程（鞏固現有勢力），看產業模式
而定，沒有一定標準做法。

原PO看起來想用「方便、快速做事」的流程，但想問怎麼找到適合這樣流程的夢幻人選。
無論後面爭論的內部管理與流程，但一開始如何面試合適的人，都是個值得思考。

最近剛好我也在煩惱這個招募問題，我想會用上機考的方式，給一個lab, 裡面只有一個
簡單的function，但是有bug，我會請面試者找出裡面的bug並修復。

實際上bug不只有一個，最粗淺的就是編譯失敗的語法問題，括號不對稱或是變數存取範
圍不一致這類，這個解不了，我就送他到門口鞠躬說聲謝謝請等待通知。

編譯失敗的問題解決了，如果面試人立即回報說這題完成了，那我就會知道他不是一個細
心的人，只看見眼前的問題，而沒有看到後面跟著的其他問題。

我應該會至少準備四種bug在裡面：
1. Runtime error：8元素的陣列，存取指標應該0-7，但迴圈卻用了1-8，或是迴圈條件
< 故意寫成 <= 來產生此錯誤。

2. 極值檢查錯誤，例如除法，我分母塞入0他有沒有想到這種可能，先檢查出來？

3. 邏輯錯誤：程式本身運行正常不會有error, 但是輸出的結果都是錯的，他找不找得出
原因？

4. 錯誤處理：在一定會有錯誤發生的地方他有沒有想到並處理掉？例如連資料庫或是api
但是面試的辦公室根本不可能連到。

後面這四個都會事前準備好單元測試，面試人交件後自動一跑，看幾個綠燈，就可以大概
知道這面試人的細心程度....

關於原PO的問題，這應該是我會嘗試的方法。


※ 引述《Masakiad (Masaki)》之銘言：
: 其實制度流程沒分兩種，開發團隊講好規則；約定好軟體開發的品質、驗證基準並自動
化
: 、約定時間code review的時程，正是加速品質保證及驗證軟體的速度。這個作法並沒
有
: 什麼多餘跟lock的問題，除非品質跟驗證軟體本身就是多餘。
: 另外有很多方法論來指導上述的實作原則外、也很多公司有進行也持續運轉這機制，若
你
: 還沒有嘗試就趕快試試，不用臆想跟推論這麼多。
: 閣下言談之間我的感覺是不熟這方面的運作，所以另外再建議你找一個熟這方面流程的
人
: 來協助你，這樣才可以解決問題。
: 至於怕優秀人才會因為這樣感到不被信任的問題也不用擔心，優秀人才只會因為沒有這
些
: 機制而離去，原因在於他們嚴格要求自己驗證跟品質，團隊有這些機制對他們來說已經
很
: 習慣，倒是沒有這些機制還要擔心我完美的架構混入其他沒被驗證的糞code，什麼叫委
屈
: ？這才叫委屈。
: ※ 引述《accessdenied (存取違規)》之銘言：
: : 唉唉唉，當初我不用「態度」這個字眼就是知道大家會各自解讀，到底什麼是好的態
度
: ..
: : ...
: : 所以我講白了就是「細心」和「紀律」，還舉了很多實際例子來說明這兩個元素的概
念
: ，
: : 結果有人又簡化回態度兩字，果然底下有開始亂戰了...
: : 拉回主題，前陣子忙著賺錢沒時間好好回應一些想法。有人說制度和流程可以解決，
還
: 提
: : 到權限控管，為什麼我不太認同。
: : 制度流程分兩種，一種是協同合作必要的方式，你負責的範圍是哪裡？東西做好會放
在
: 哪
: : 裡？這是讓大家做事彼此方便快速的約定，是增加效率的。這類似交通規則的訂定，
大
: 家
: : 照著做就流暢。
: : 另一種制度流程，是防弊的，稽核、放行、權限控管，是保持著一種不信任的心態在
做
: 管
: : 理。這就好像除了紅綠燈外，又另外安排了一個交通警察指揮交通（權限、審核放行
）
: ，
: : 並看管所有駕駛人。
: : 後者會產生效率瓶頸，因為每台車都要經過檢查並放行，交通就堵塞了，開發人員再
多
: 、
: : 效率再高都沒用，就是會lock。
: : 每個change都要approve的下場，就是「人皮圖章」開始產生的時候。
: : 再來，有些 team 趕專案加班到半夜怎麼辦？負責approve的人難道發呆配到半夜只
為
: 了
: : 最後幫他開權限和approve？這些都是無謂的人力損耗。
: : 而且優秀的人才，一直在不被信任的環境下做事，心委屈了，流失也只是遲早的事情
！
: : 想想看，你有10個工程師，只為了其中1個心態隨便的人員，就把剩下9個優秀的人才
一
: 起
: : 拖下水被綁手綁腳不再信任？
: : 為了那一個人，與其設計各種稽核制度防止他做錯，不如一開始九排除他，讓剩下九
個
: 人
: : 順順利利做事，這才是正解吧！？
: : 讓不對的人一開始就不要溜進來，團隊也不會被污染，好的人才更不會覺得被牽累！
: : 這才是我為什麼要跟大家請益的出發點。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.215.225
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1530928002.A.258.html
※ 編輯: tomtang0406 (223.136.215.225), 07/07/2018 09:47:58
※ 編輯: tomtang0406 (223.136.215.225), 07/07/2018 09:49:05
推 MacPerson: 我的建議是... 告訴面試者,這個Lab有幾項設計缺失
→ MacPerson: 請你修正....    而不單單只說 裡面有bug請你修正
→ MacPerson: 對於腦筋簡單 直來直往的工程師  很容易就中招
→ MacPerson: 有時候不是能力不足, 而是心還太嫩....
→ MacPerson: 單純建議 無意引戰   我老了......
→ tomtang0406: 樓上說的有理謝謝指教
※ 編輯: tomtang0406 (223.136.215.225), 07/07/2018 10:00:43
→ SmallpTsai: 原Po的問題在於標題下了"優質",然後講了一堆為什麼
→ SmallpTsai: 細心和紀律很重要,好像那就===優質
推 Sex5F: 有點像是找日本人的奴工
→ SmallpTsai: 不過這一串下來可能只有你真正的給了建議 :)
→ Sex5F: 有些comoiler就會找出來的真的考試是浪費時間
→ Sex5F: 考點oop和演算法吧
推 Sex5F: 你的工作內容看起來比較像維護
→ Sex5F: 不像是找真正的神人
推 dophin332: 他破題不就說看產業內容 沒有標準做法
→ dophin332: 然後試著舉了一個case
→ tomtang0406: 我沒有要找神人，這個面試設想只是要找能安心做事的
→ tomtang0406: 一般員工
→ tomtang0406: 神人的重點不會在細心和紀律這兩個條件吧？
→ tomtang0406: 另外其實軟體業的工作，維護大概占據了89成的工作量
→ tomtang0406: ，除了接案公司，沒有天天都有全新專案可以開發的公
→ tomtang0406: 司
→ MOONY135: 你只是找一個可用的人力而已 不覺得可以叫優質
推 winken2004: 推原po跟一樓
推 accessdenied: 哈哈，現在連優質的定義都要各自解讀了，真無聊你
→ accessdenied: 們。我認為態度細心有紀律的人就已經鳳毛麟角，所以
→ accessdenied: 對我來說是優質
推 abccbaandy: 考這種總比寫白板好啦，至少比較實際，工作上也可能碰
→ abccbaandy: 到
→ accessdenied: 你們玻璃心有你們自己的定義，乾我屁事？我就是要
→ accessdenied: 細心、有紀律的人，而且我覺得這種人難找很優質，這
→ accessdenied: 麼簡單聽不懂嗎？
噓 fish0112: linkedin不是很多HR討論區嗎？
推 x246libra: 感覺這篇的建議 挺具體的阿
推 bakedgrass: 這篇很具體，但我覺得一樓的想法我更認同
推 stupid0319: 原po找的是碼農吧
→ codehard: 看別人的code修到好太痛苦了 比自己重寫還累
→ codehard: 誰知道他埋了多少bug在裡面
推 sayya2311: 能有優秀成果的,便是優秀工程師.
推 sayya2311: 一個優秀成果的細節,豈是短短的一些面試問題就能包含
→ sayya2311: 的了的...
推 zhuzii: 推這篇建議 學起來 謝謝^^
推 peanut97: 推
推 Morphee: 乾脆請他找亨利或是拼拼圖不是更好
→ Morphee: 感覺考察面還是不夠全面　頂多看基本知識跟細心度
→ abccbaandy: 樓上要不要建議一個2個小時能全面了解的面試法？
→ Masakiad: 這篇提供的方法很實際，但老實說我覺得原Po（指禁止存
→ Masakiad: 取）想在面試階段過濾的應該不是這種程度的不細心面試
→ Masakiad: 者（甚至我認為這根本不專業）應該是在架構複雜的狀況下
→ Masakiad: 產生的邏輯錯誤等bug，而不是能不能build過這樣的狀況。
→ Masakiad: 實際上就是工程師怎麼撰寫他的測試案例已經決定他的態
→ Masakiad: 度跟細心度了。
→ SmallpTsai: 本來優質就是各自解讀, 也才因此而有前面一堆討論
→ SmallpTsai: 直到現在才有一篇算是真正的建議
→ SmallpTsai: 問題問精準一點會比較快得到有用的回覆
推 keyut2433: 感覺你連function都不用幫，讓面試者寫出來再讓他寫單
→ keyut2433: 元測試測就好.
推 ckp4131025: 我個人認為考這個會比要面試者背sort的時間複雜度實
→ ckp4131025: 際
→ sorryla: sort的複雜度不是演算法常識嗎? 不需要特別背吧
→ sorryla: 現在G家人資還會直接問你sort複雜度來決定你夠不夠格電面
推 art1: 就陷阱題
→ tinlans: C++ 的 STL algo 都有時間複雜度保證，和資結當初上的
→ tinlans: 差不多，我遇到履歷寫會 C++ 的也會去問這問題。
→ tinlans: 遇到寫擅長物件導向的我會給一個爛架構叫他重構給我看
推 zonppp: 說實在...能找到可用的人已經很不錯了~神人那是另一個境界
推 shallmay: 推原 PO 跟一樓
推 superjeff: 在找打雜的吧無聊
→ vi000246: 1.2是基本的 但是3.4有點搞人了
→ y3k: 曾經我有想過 找個大型的Opensource專案開題目讓新人加功能
推 APTON: 真的是好建議耶
推 mathrew: 推這篇  也推一樓
噓 love95023: 後面考細心在搞人吧...面試時間短短，當然迅速解重點
→ love95023: 刻意埋邏輯錯誤不講
→ love95023: 更何況要短時間適應、爬完別人的code，抓出所有坑
推 zased: ...真不會找人捏  面試心法完全是靠聊天  但大多工程師主
→ clamperni: 他如果在高手環境待久了 看到這種程式搞不好反應不來
→ KanoLoa: 真的，traceCode找bug是沒用過ide嗎?
→ KanoLoa: 是只想找到喜歡用筆記本寫code的高手嗎
→ KanoLoa: 尤其無限上綱錯誤，難道他硬加了七八個防呆你反而大喜?
→ KanoLoa: 這種怕死的面試法是以前測試不流行的年代，可以改進的