最開始公司擴張需要招人讓我做面試官我是拒絕的，過了幾年，從開始用系統記錄的面試就有百來次，到現在依舊感覺自己不適合做一個面試官，並且不太合格。 這裡所談的都是業務開發的面試，自己也一直在做對應的工作，與其他的偏技術側的面試可能會有出入。

做面試官很難

從還未成為面試官到現在作為面試官，這個想法一直沒變過。 憑短時間的交流就要確認面試者能否勝任工作會存在很大的偏差，無論是判斷可以還是不可以。

就算是和自己工作了挺久的同事，感覺對方能力還不錯，合作也挺愉快，突然也會因為“無法勝任工作” "被優化"掉了。更何況與一個素不相識，就憑著一紙簡歷和1小時左右的問答就要確定 。

面試要考察技術能力，業務能力，溝通合作，主觀能動性等等等方面，又不能讀心，唯一的方式就只有溝通，而不同的面試官又有不同的衡量標準，我覺得不錯對方覺得差也遇到過很多次。每個人有不同的側重點，我覺得業務建模能力不錯相談甚歡，下一個面試官又嫌答不出來幾個設計模式基礎差，我覺得系統架構稍微有點弱，下一個面試官又讚賞技術視野，等等，屢見不鮮，其實這些都對又都錯，只是對這短短時間交談的一個感覺。

用統一的流程和題庫可以解決掉一些面試官標準不匹配的場景，但無法消除，畢竟就算有標準答案每個人心裡都有個隨著時間不斷變化的天平，學生時代同樣的題錯誤的解法不同老師會打出不同的分。

除了讓面試者自己表達，面試官也需要引導面試者更好表達自己。這個我連對自己都做不好，更別提對別人了。

面試提問的改變

順帶說說面試問題的一些改變。 下面說到是各個時期的方式，但不是整個面試過程的全部，只是說了那些時期比較象徵性的提問和側重點。

題庫. Yes or No

最開始的面試問題，感覺過於草率，在此向最開始1年裡我面試的人道個歉。就是題庫裡的題整合一下然後拿出來做，美其名曰考察技術能力和思維能力，倒不如是比題庫的豐富度。
看到的多記憶的多就能獲得我不錯的評價。
不過題庫的好處是一些基礎能力的缺失是可以一眼看出來的，壞處是可能會讓自己拘泥於答案而不是思路，一些題本身的答案是沒有太大意義的，what不重要主要是why和how，當然這不是題庫的錯，這是面試官的錯。 更糟糕的是如果題庫的答案是片面的，甚至就是錯的，且自己沒有識別出來，能在面試的時候被面試者教育還好，但一些面試官可能還會死不承認。之前群友討論自己面試面試官問TCP連線握手第三次能否攜帶應用資料，他回答可以結果被面試官懟，還讓他想想清楚回答。有意思嗎？

技術為主 步步深入

在捨棄了題庫地圖炮的方式後慢慢轉變成這種方式，當時大抵上覺得業務無關輕重，技術才是最重要的吧。 這種面試簡單來說就是看到簡歷上寫著這個技術元件，就問很多細節性的問題或者罕見case和特殊優化方式。 找人來造火箭的嗎？

這種形式沒有持續很久，因為實際上自己太菜，很多東西也沒法追問太深，換位思考後也就不再這麼做了，取而代之的是日常使用，以及基礎概念，比如問kafka就問問哪些業務用了，kafka的大體架構有哪些元件，元件之間怎麼協同工作之類。而換成之前可能就是如果設定client引數會導致訊息重複這類，說真的自己不去翻翻引數列表和筆記都記不清楚，這類偶爾也還會問一些，但能答出來是bouns，答不出也不影響評價。

之前工作內容為主 考察設計

也算是當前階段主要的方式了。
現在會更看重之前的專案，在和之前問完工作經歷之後更深入其中的細節，並給出一些擴充套件場景看看能否在原有基礎上實現。 要求畫出之前專案的整體架構圖，考察對於技術棧的熟悉度；要求給出完整的業務鏈路，各個業務元件的關係，考察對於業務的理解力。 不僅僅是你這個是怎麼做的，增加更多的你這個為什麼這麼做以及如果要滿足另一個場景要怎麼做。

---

總體感覺可能現在的方式更能看出面試者的一些能力，前兩個時期的側重著實有點扯淡。

但不得不說對於在技術深度上的考察的確是比之前更弱了，理由之一是自己也就那樣，平時做業務也沒有夠到多深，另外是很多問題是"偽深度"的，本質上是技術的廣度（但深度和廣度一定程度也相輔相成），知道就是知道，不知道就是不知道，無法推演。 “你知道XXX嗎”的問題價值可能不如“你知道XXX，那你為什麼要用XXX，那你怎麼去XXX”。

當然現在這種做法也有很多改善空間，但大體方向就是這樣了。

我不是一個合格的面試官

結合此前的面試和當下，這是我對自己作為一個面試官的評價，我也無法成為一個能讓自己覺得合格的面試官。

究其原因，我不覺得自己的技術能力和業務建模等能力有多強（甚至還有點菜），在深度和廣度上都有不少問題，並且隨著學習這種感覺愈發加強。 其次我也不覺得自己能較好考查面試者，和其他面試者的評價出入比較多，出現不少誤判。

最近有幾次面試感覺對方不錯，但後面的面試官又覺得對方差。這其實受到了不少打擊，感覺浪費了面試者不少時間，真的是深感抱歉 :(。