需要什麼樣的流程,愚以為要看公司規模,系統特性,人員組成來決定,大象不會跳舞。
打快攻有快攻的流程(搶市佔),禁區防守有防守的流程(鞏固現有勢力),看產業模式
而定,沒有一定標準做法。
原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個優秀的人才
一
: 起
: : 拖下水被綁手綁腳不再信任?
: : 為了那一個人,與其設計各種稽核制度防止他做錯,不如一開始九排除他,讓剩下九
個
: 人
: : 順順利利做事,這才是正解吧!?
: : 讓不對的人一開始就不要溜進來,團隊也不會被污染,好的人才更不會覺得被牽累!
: : 這才是我為什麼要跟大家請益的出發點。
我的建議是... 告訴面試者,這個Lab有幾項設計缺失請你修正.... 而不單單只說 裡面有bug請你修正對於腦筋簡單 直來直往的工程師 很容易就中招有時候不是能力不足, 而是心還太嫩....單純建議 無意引戰 我老了......
作者: tomtang0406 (自砍D文之王) 2018-07-07 10:00:00
樓上說的有理謝謝指教
原Po的問題在於標題下了"優質",然後講了一堆為什麼細心和紀律很重要,好像那就===優質
作者:
Sex5F (HTC)
2018-07-07 10:13:00有點像是找日本人的奴工
他破題不就說看產業內容 沒有標準做法然後試著舉了一個case
作者: tomtang0406 (自砍D文之王) 2018-07-07 10:27:00
我沒有要找神人,這個面試設想只是要找能安心做事的一般員工神人的重點不會在細心和紀律這兩個條件吧?另外其實軟體業的工作,維護大概占據了89成的工作量,除了接案公司,沒有天天都有全新專案可以開發的公司
哈哈,現在連優質的定義都要各自解讀了,真無聊你們。我認為態度細心有紀律的人就已經鳳毛麟角,所以對我來說是優質
考這種總比寫白板好啦,至少比較實際,工作上也可能碰到
你們玻璃心有你們自己的定義,乾我屁事?我就是要細心、有紀律的人,而且我覺得這種人難找很優質,這麼簡單聽不懂嗎?
作者: codehard 2018-07-07 11:45:00
看別人的code修到好太痛苦了 比自己重寫還累誰知道他埋了多少bug在裡面
作者: sayya2311 (ya) 2018-07-07 12:00:00
能有優秀成果的,便是優秀工程師.一個優秀成果的細節,豈是短短的一些面試問題就能包含的了的...
作者:
zhuzii (UsualMan)
2018-07-07 12:03:00推這篇建議 學起來 謝謝^^
作者:
Morphee (千磨萬擊還堅勁)
2018-07-07 13:15:00乾脆請他找亨利或是拼拼圖不是更好感覺考察面還是不夠全面 頂多看基本知識跟細心度
作者:
Masakiad (Masaki)
2018-07-07 14:02:00這篇提供的方法很實際,但老實說我覺得原Po(指禁止存取)想在面試階段過濾的應該不是這種程度的不細心面試者(甚至我認為這根本不專業)應該是在架構複雜的狀況下產生的邏輯錯誤等bug,而不是能不能build過這樣的狀況。實際上就是工程師怎麼撰寫他的測試案例已經決定他的態度跟細心度了。
本來優質就是各自解讀, 也才因此而有前面一堆討論直到現在才有一篇算是真正的建議問題問精準一點會比較快得到有用的回覆
作者:
keyut2433 (keyut2433)
2018-07-07 15:12:00感覺你連function都不用幫,讓面試者寫出來再讓他寫單元測試測就好.
我個人認為考這個會比要面試者背sort的時間複雜度實際
作者:
sorryla (Mr.東)
2018-07-07 16:33:00sort的複雜度不是演算法常識嗎? 不需要特別背吧現在G家人資還會直接問你sort複雜度來決定你夠不夠格電面
作者:
art1 (人,原來不是人)
2018-07-07 16:45:00就陷阱題
作者:
tinlans ( )
2018-07-07 19:25:00C++ 的 STL algo 都有時間複雜度保證,和資結當初上的差不多,我遇到履歷寫會 C++ 的也會去問這問題。遇到寫擅長物件導向的我會給一個爛架構叫他重構給我看
作者: zonppp (冷涼卡好) 2018-07-07 20:00:00
說實在...能找到可用的人已經很不錯了~神人那是另一個境界
作者: superjeff 2018-07-07 22:53:00
在找打雜的吧無聊
作者:
y3k (激流を制するは静水)
2018-07-08 01:24:00曾經我有想過 找個大型的Opensource專案開題目讓新人加功能
作者:
APTON (瑋瑋)
2018-07-08 03:32:00真的是好建議耶
作者:
mathrew (Joey)
2018-07-08 09:44:00推這篇 也推一樓
後面考細心在搞人吧...面試時間短短,當然迅速解重點刻意埋邏輯錯誤不講更何況要短時間適應、爬完別人的code,抓出所有坑
作者:
zased (我只是上PTT查資料)
2018-07-08 13:57:00...真不會找人捏 面試心法完全是靠聊天 但大多工程師主
他如果在高手環境待久了 看到這種程式搞不好反應不來
作者:
KanoLoa (卡)
2018-07-08 17:42:00真的,traceCode找bug是沒用過ide嗎?是只想找到喜歡用筆記本寫code的高手嗎尤其無限上綱錯誤,難道他硬加了七八個防呆你反而大喜?這種怕死的面試法是以前測試不流行的年代,可以改進的