技術面試(上):面試官篇

作爲一個技術團隊管理者,面試是一項必不可少的工作;作爲一個上班族,被面試也是必然會一而再再而三經歷的事情。

不過在我的經驗中,很多人(包括曾經的自己)不太會面試這件事,或者說不太重視這件事。面試官認爲搞幾道題給對方做做,做得出來就牛逼,做不出來就歇菜;受試者則認爲自己反正挺牛逼的,對方能慧眼識英雄的話必然會選中我,否則此處不留爺自有留爺處。很多人都認爲一旦談技巧就有種人爲造作的成分。

本文就自己作爲面試官和受試者的雙重經驗談談面試這檔子事(上篇從面試官角度,下篇從求職者角度),以及從面試官的角度分析作爲求職者在找工作面試時需要注意些什麼。

由於實際工作使用 PHP 作爲開發語言,後面的敘述以招聘中高級 PHP 工程師爲例。

面試官篇。

剛開始作爲技術經理招人時,完全不知道怎麼做,網上到處百度別人的經驗。一般流程是:打印一份筆試題,給受試者 1 小時的時間做題,然後根據結果大致判斷是否合適,真正的面試過程中也都是圍繞着筆試題目進行的。

隨着面試的人越來越多,逐漸總結出了自己的經驗。

簡歷篩選

招聘流程中有件很繁瑣(甚至是無聊)的事情:篩選簡歷。我們公司實際流程是人事進行初選,然後遞給技術經理,技術經理再在裏面選出一部分進行面試(當然技術經理也可以直接去招聘網站選人)。實際情況是,HR 一般是不懂技術的,HR 的篩選標準一般就是看對方的簡歷描述和公司的職位描述匹配度(這一步甚至是系統自動進行的),只要合適就會推薦給技術經理,因而一般都是整捆整捆的推。

面對大量的簡歷轟炸,技術經理一般都是通過“量子速讀”的方式篩選簡歷的。就我自己來說,第一遍快速瀏覽一遍簡歷,找關鍵詞和關鍵句子,看有無亮點(吸引我的),而不會逐字逐句去看簡歷,一份簡歷用時一般不超過 1 分鐘。

速覽的方式能過濾掉 80% 的“平庸的”簡歷,剩下 20% 再慢慢斟酌。

上面說了,速覽的目的是找亮點。如果一份簡歷即無亮點,又寫的“惜字如金”,會第一個被 pass 掉的。

就我們具體的招聘對象(中高級 PHP 工程師)來說,我會重點關注以下幾點:

自我簡介。

在冗長的簡歷中,自我簡介是簡歷的整體門面,裏面濃縮了這個人的方方面面,是最容易、最集中體現一個人整體面貌的地方。一份自我簡介寫得讓人覺得可有可無的簡歷不會給面試官留下深刻的印象。自我簡介的重要性絲毫不亞於項目介紹。

自我簡介一般包含兩部分:技術能力介紹與非技術能力介紹。技術方面要包括本專業技術能力(比如作爲 PHP 後端開發工程師必備的技能如 PHP、MySQL 等知識掌握情況)和本行業技術能力(語言無關的能力,如對 OOP、設計模式、算法、架構、管理等能力)。

非技術能力部分每份簡歷可能寫得都不一樣(很多簡歷壓根沒有這一塊),主要包括個人性格、團隊協作能力、個人愛好等。

在自我簡介中,我重點關注的是“高出平均”的那部分內容。舉個例子,每個 PHPer 都會在自我介紹裏面寫上對 PHP 這門語言的掌握,一般的寫法:

熟練掌握/精通 PHP、Laravel 框架;

另一種寫法:

精通 PHP,熟悉 PHP 底層運行機制,熟讀 Laravel 源碼,自己編寫過簡單的基於 MVC 的 Web 框架;

我的注意力肯定會被後者吸引,前者過於乾癟無味,後者則顯得飽滿、有血有肉,除了傳達出其技能掌握情況,還傳達出一種熱愛和自信。

大部分簡歷的自我介紹屬於流水賬,一句話概括了自己熟悉的所有編程語言、工具,對“行業能力”方面的介紹也是“輕描淡寫”,這種簡歷給人的感覺是草率、不夠自信、資歷平平。

比如:

熟悉 PHP、MySQL、HTML、CSS、JavaScript、Laravel 框架、ThinkPHP 框架、Swoole 框架等;
熟悉常見設計模式、數據結構和算法;
熟悉分佈式架構、微服務架構;

是不是似曾相識?是不是乍一看感覺很牛逼?

看了太多的這種寫法,我就產生審美疲勞了,我想其他人肯定也是。

之前我看到這種流水賬不以爲意,覺得應該是對方不知道怎麼樣寫簡歷?叫過來一聊,發現大部分人對其羅列的技術都是蜻蜓點水、一知半解。

於是我得出一個結論:這種流水賬式的自我介紹源自簡歷作者的內心矛盾:一方面自己對這些知識並未熟練掌握,有些只聽過名字而已,內心不夠自信;而另一方面他覺得這些流行的、“高大上”的技術寫上去能給自己添幾分光彩,如果不寫,倒是反映自己“孤陋寡聞”。

於是後面的簡歷篩查中,我會重點關注那些具體的、能反映作者真正水平的內容(我稱之爲“高出平均”的東西。當然這裏說的“反映真正水平”是假設簡歷本身內容是真實的)

項目經驗。

項目經驗這塊,我最感興趣的是“求職者對項目的貢獻”。

很多簡歷花了大量篇幅去寫每個項目本身是個什麼東西,有哪些模塊,至於自己在項目中的角色、貢獻則是輕描淡寫。比如“維護公司 CRM 系統”,然後花了大量篇幅介紹這個 CRM 系統有哪些模塊,每個模塊都是幹什麼的。

就算這個系統是公司最核心、最複雜的系統,而你僅僅是維護了幾行代碼,又如何?

如果求職者在所有的項目中扮演的角色都是“維護者”,這份簡歷基本就會被 pass 掉,因爲從他的介紹中我看不到激情、思考,看到的僅僅是一個會寫代碼的機器。

好的簡歷在每個項目介紹中會簡明扼要地描述項目本身,然後重點提出項目中遇到的問題以及自己是如何解決的,以及自己對項目的其他方面的貢獻(如主導系統設計、重構)。

其它加分項。

如果簡歷中有求職者的博客、開源項目,我會很感興趣地去看看,這部分很可能直接讓簡歷通過海選(所謂物以稀爲貴,絕大部分人都沒有自己的博客)。

學歷、學校。

這部分會引起我的好奇,但不會作爲篩選簡歷的標準(因爲實際工作中遇到過很多學歷和學校都挺不錯的,但由於各方面原因,在團隊中永遠只能做配角的那種)。

綜上,我一般根據簡歷的自我介紹項目經驗中“高出平均”的東西去速選簡歷,進行第一輪面試。

筆試

實際中,我們有時候會有筆試環節,有時候(項目緊急缺人,面臨大量面試的時候)沒有筆試。

對於筆試題目,我的原則是:

  1. 不考很偏、但實際沒有什麼技術含量的題目(比如 goto、with);
  2. 不考需要大量記憶、實際工作中基本都是要問度孃的題目;
  3. 考題中會包含一定比例的專業基礎知識考查(如 PHP7 相比 PHP5 有哪些優化、PHP 數組相關、PSR 規範等這些幾乎每個稱職的 PHPer 都需要掌握的知識);
  4. 包含一定比例的數據結構、算法、設計模式的考查,這部分的考查一般具有一定自由度(比如讓求職者自己選定幾種設計模式並說明其作用、應用場景,而不是考某個特定的設計模式);
  5. 大部分的題目具有一定的靈活度,求職者有自己發揮的空間;
  6. 允許當場問度娘。這符合實際工作場景,而且這些筆試題目在面試環節還會拿出來聊,如果求職者的答案完全是搜出來的,自己卻沒有理解,面試環節一樣通不過的。

筆試題有兩個考查目的:

  1. 受試者專業基本功——專業素質;
  2. 受試者的態度——爲人素質。有些受試者有種自負心裏,覺得這些題目太簡單了,不屑於回答,每道題都是草草一兩句了事,有些甚至會寫“結果見百度”這樣的話。自負者往往較自我,對於團隊尤其是初創公司的團隊並不合適。

面試

第一印象很重要。

第一印象包括對方的精神面貌、禮數。雖然 IT 界不太講究禮數這玩意,但起碼的見面問候語和微笑是要有的。當然,有些面試官不太在意禮數,但大部分都會比較在意對方的精神面貌(陽光、自信還是萎靡、茫然?)

第一部分是求職者的自我介紹環節。

很多人的自我介紹和其簡歷上一樣是乾癟的流水賬,從第一家公司開始,到最後一家公司,將做過的項目幾乎一個不漏地說一遍,從中聽不出哪個項目是是他重點負責的,也不知道哪個項目給公司帶來了巨大收益。從這種流水賬式的介紹中,你能感受到一個毫無激情、毫無擁有感的人的漫長職業生涯是多麼地無聊,這些事情一件一件地發生着,對於他而言卻幾乎毫無意義——或者說他幾乎從來不去思考其存在的意義。

我期望從這些自我介紹中聽到陳述者的價值存在感。哪些事情是你主導的?你爲什麼做這樣那樣的設計決策?這些項目給公司以及給你自己帶來了什麼樣的收穫?

求職者沒有必要把生平所有的項目都陳述一遍,管中窺豹,一葉知秋即可。

第二部分是項目問答環節。

接着求職者的介紹,我會從中挑出一些問題點提問。如果剛纔的介紹過於流水而抓不到問題點,我會讓求職者再從中挑選一個做詳細介紹。

一般我問得比較多的是就某個項目中的某些設計決策的理由,比如如果對方提到做過秒殺系統,而做秒殺的基本繞不開高併發和庫存超賣問題,每個人的解決方案可能都不同,比如有人將所有的商品庫存放到消息隊列中,有人將庫存做成原子計數器,也有人將用戶請求放到隊列中。這裏沒有所謂標準方案,我更關注的是你的方案是否能滿足你們的目標,因爲方案長什麼樣完全取決於要實現什麼目標,如果你們的目標很小很簡單,而你的方案確實一個非常複雜的耗時耗力的“大廠”、億級的解決方案,我倒認爲這不是一個好方案,這種人做出來的設計往往需要仔細掂量。

另外,我會就項目中用到的一些技術進行漸進式追問。比如大部分人都會提到用 Redis 做緩存來解決數據庫壓力,那麼你對 redis 本身瞭解多少?它和 MemCached 在對請求的處理、數據存儲、內存管理上有何不同?PHPer 有個普遍現象是底子太薄,限於工作實際,絕大部分人的工作都是做些業務開發,涉及不到底層,很多人連什麼是 TCP 三握手都不知道,也照樣開發了十幾年。在這種“刁難式”追問上走得越遠,給我的印象越好。不過當我問這些問題時,還有另一個潛藏的目的:我想看看對方在答不上問題後的表現。有些人心態不好,一個問題答不上來,整個人就蔫了。

回答問題需要聚焦。這涉及到今後團隊溝通問題,也側面反映一個人的思考力、辦事效率。沒人喜歡聽別人囉嗦,特別是聽了半天還聽不出對方想要表達什麼的時候,基本就是面試結束的節奏了。有些人囉嗦是因爲習慣使然,平時說話就囉裏囉嗦,有些人是覺得說多點能給面試官更深刻的印象。殊不知,如果你能三言兩語就切中要害,入木三分,面試官定會對你刮目相看——因爲只有思考足夠深入、理解足夠透徹才能一句話抓住問題本質。

第三部分是專業問答環節。

這部分不再涉及具體的項目(這不是說對方不能就問題關聯到某個項目,而是說我不再就具體的項目發問),而是“純專業知識”問答互動。

我的問題清單包括 PHP 基礎知識、數據庫、緩存、網絡基礎、面向對象、設計原則、設計模式、算法,類似下面:

  • PHP7 相對 PHP5 做了哪些改進?
  • 如何求兩個數組的交併差集?(以及類似的問題。因爲數組是 PHP 中最常用、最強大的功能,但不是每個人都能熟練掌握這些功能,因而在實際項目中經常充斥着各種蹩腳的實現,各種嵌套循環滿天飛,其實就是一個原生函數調用的事情)
  • 你都瞭解哪些 PSR 規範?(考察對方對編程規範的關注,大部分人只能回答出編碼規範、命名空間規範,有些甚至連 PSR 是什麼都不知道)
  • 一次 Web 請求的執行步驟?(屬於網絡基礎知識,不同人的理解深度不同,此處能看出對方處於那個級別,如果能說出 局域網 ARP、HTTP 協議解析、TCP/IP 封包、DNS 分層解析的,定能讓人刮目相看)
  • MySQL 中一條 SQL 語句的執行過程大致是怎樣的?(考察對 MySQL稍底層的瞭解)
  • 什麼是聚簇索引?什麼是索引覆蓋?什麼是回表?InnoDB 如何保證數據正確性?(考察對 MySQL 較深層次的理解)
  • Redis 是單線程還是多線程的?採用單線程的原因有哪些?單線程如何處理高併發問題(考察對 Redis 稍底層的瞭解以及 I/O 多路複用的瞭解)
  • 你是如何理解面向對象和麪向過程的區別的?面向對象編程都有哪些特性?(大部分人被問到這個問題時會同時有兩種截然相反的內心活動:操,問這麼低級的問題;咦,我好像回答不上來)
  • 你都知道 OOP 的哪些設計原則?(實際中大部分人一個都不知道,每當我給予提示後,對方會表現得恍然大悟,不過再加以追問時,又是一臉懵逼。對設計原則的理解本是仁者見仁的事情,而真要說出個所以然,沒有實際的面向對象經驗與思考是答不上來的。所以,如果這個問題回答得讓我印象深刻,我對其的定位一般都是“高級”)
  • 你都瞭解哪些設計模式?在哪裏用過或者見過?(這個問題的“平均水平”回答一般有兩種:一種是隻知道單例、工廠;另一種是能說出一大串,但真從中抽一個細問時又是一臉懵逼)
  • 你都瞭解哪些排序或者查找或者其他算法?挑一個說說其大致實現方式?(由於各種原因,PHPer 普遍算法較弱,能說出個快排實現方式的都能讓人刮目相看)
  • PHP 數組底層的實現機制是怎樣的?(這是一個較底層的問題,需要了解其 C 代碼實現。問這個問題的目的是探測對方技術深度,問的前提是對方其他問題都回答得較好)

上面的問題有幾個特點:

  • 偏原理,追根問底,回答者平時須有思考、探究的習慣才能答得出來;
  • 貌似平時用不到,跟實際開發沒什麼關係;
  • 大部分問題的答案並不固定,可以有不同的回答深度;

那麼,針對不同級別的工程師招聘,我都是用同一套問題嗎?

答案是肯定的。我的目的不是要對方都能回答得很完美,而是要通過問題甄別出對方的真實水平。不同水平的人的回答會截然不同,比如對設計模式、設計原則的理解,初級工程師可能只會背出來,卻說不出所以然,更別提在實際項目中應用,高級工程師則能結合自己的實際項目談他的理解。

很多人會抱怨面試官總是問些實際項目中用不到的知識,我以前也是這樣認爲的,覺得他們這樣做無非是爲了顯示自己知道得比別人多而已。直到我自己去面試別人。如果面試官問的都是所謂“工作中用得到的”東西,那絕大多數人都能答得上來,你讓面試官去選哪個?

另外,我個人會給那些對面向對象、設計原則和設計模式理解得比較好的人更高的權重。這些看似很虛的東西在實際項目中卻真真切切起着重大作用。很多人的代碼寫出來只有機器能看得懂,可讀性、可維護性、可擴展性一塌糊塗。這些人拿着面嚮對象語言做着全是面向過程的開發,心裏根本沒有設計原則、設計模式那回事,開發中也談不上設計,覺得開發這檔子事完全是個人的事情,怎麼樂意怎麼搞。

第四部分是技術無關的互動環節。

這部分的前提是前面部分進行的比較順利。

這部分我會問些諸如平時都看些什麼書啊,有沒有寫過博客啊,都有什麼興趣愛好啊,上一家公司離職都原因啊,從更多維的、立體的角度接觸下這個未來可能的同事。

第五部分是受試者提問環節。

我最不喜歡被問到的問題是:”你們公司是幹什麼的?“

我的天!幾乎所有招聘網站都有公司簡介項,大部分公司也有官網和百度詞條,你來公司參加面試前都不瞭解下?

這簡直就是無理與傲慢。

求職者的提問如果表現出對公司業務的些許瞭解,並在此基礎上提出一些他自己關心的針對性的問題,或者就團隊的現狀、負責的業務、團隊以及成員的管理、發展等提問,我個人感覺都是比較中肯的問題。

態度

面試態度很重要。

整個面試過程中,我都一直在考察對方的態度,有時爲了該考察目的,我會特意問一些刁鑽的、甚至是稍帶刺激性的問題。

面對回答不上的問題,受試者一般有這麼幾種反應:

  • 拐彎抹角型。這類人爲了掩飾自己對該問題的無知,會拐彎抹角、旁敲側擊,讓人感覺驢頭不對馬嘴,卻自認爲能夠瞞天過海。

  • 自我感覺良好型。這類人一般對問題略知一二,因而不願直接承認自己對該問題的無知,而是添油加醋、“旁徵博引”,以表現得很是在行;

  • 長時沉默型。這類人可能以前曾經瞭解過相關知識,但現在忘了,於是費勁心思在心裏琢磨,給人的感覺就是長時間的沉默。

  • 誠實型。這類人會對問題稍作思考,確認自己答不上來時,直接跟面試官說出實情。

我個人喜歡最後一種類型的,我想大部分面試官也是。

莊子說“吾生也有涯,而知也無涯”,一個人不可能對所有問題都知道,很大概率上面試官的問題清單中的一部分他是不知道的,而對於這一點,有經驗的面試官也是心裏有數的。有時候,面試官爲了考察對方的性格品質,會故意問一些認爲對方不知道的問題。當受試者回答不上問題時,態度至關重要。這裏的關鍵是:保持誠實。

誠實這一品質在團隊協作中非常重要,它的同義詞是謙虛。相反,和不誠實相關的特質是自負。

自負者往往過於自我,在團隊中過於執守己見,很難聽進別人的意見,難於溝通。

在面試互動中,受試者往往會就某些問題的解決方案或意見和面試官產生分歧,面試官會關注這種情況下對方的表現。有些人無論是處於對面試官的尊重還是處於對分歧本身的認可,他會主動承認自己方案的缺陷,以及認可存在更優的解決方案。而有些人則會一路堅持自己是最優的,哪怕經過分析發現其方案存在明顯的缺陷。

自負的另一種表現是在面對自己不熟悉的問題時。自負者一般不願意顯露自己的無知,會竭盡各種手段來讓自己表現得好像知道答案。

自負者往往有一定的底氣(能力),但其能力還不足以將“自負”轉換成“自信”。

作爲面試官,我們(以及我們的團隊)青睞自信而謙虛的人。

面試評價模板

我會從技術功底、項目經驗、溝通能力、態度四個維度對面試結果打分。
每個維度都有 0 - 10 的評分,梯度:0 - 4 不及格,5 - 6 分及格,7 - 8 分良好,9 - 10 分優秀。
每個維度有權重,總權重100%。就實際來說,我給予的權重排序是:技術功底 > 態度 > 溝通能力 > 項目經驗。

  • 技術功底:
    技術功底要細分本專業技術能力和本行業技術能力。對於做 Web 開發的 PHP 工程師來說,專業技術能力是指 PHP Web 開發棧所必須具備的能力,本行業則是指作爲程序員所需具備的基本通識技能(如面向對象、設計原則、設計模式、系統架構、數據結構與算法等)。
  • 項目經驗:
    重點考察受試者主要做過哪些項目,如何解決項目中的問題,考察其思考及解決問題的能力。受試者對項目的貢獻程度大於參與了多少項目。
  • 溝通能力:
    表達明晰、主題聚焦。考察受試者的溝通技巧、思考力,並從側面反應受試者處理問題的效率。
  • 態度:
    誠信、積極、陽光、抗壓、正向思維。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章