關於「面試」…

三個多月沒有寫文章了，這段時間都把專注於公司的專案開發上，雖然現在專案仍然持續開發中（還看不到結束的那條線），但持續將近一年維持高張力的開發，開始發覺到已經逐漸往崩潰邊緣前去，所以必須做一些調節，而以前調節情緒與壓力的方式就是寫文章。

先來寫一篇有關「面試」的主題，目前的工作內容除了在專案的開發之外，也會一起協同面試，主要是看前來面試者的技術，以及當面與面試者一起會談，藉這篇文章整理一下這段時間所看到的一些事情。

 

---

最近在 PTT 的 Soft_Job 板看到了一篇「對面試感到恐懼」的發文（這邊就不貼出連結，有興趣的朋友就自行尋找），後續也有很多人對於該文也有很多回覆，在這系列文章的討論和回應裡依然可以看到一些讓我覺得匪夷所思的狀況，例如還是有許多公司還是會以「問倒」應試者的方式進行面試，又或者是以筆試的方式讓應試者在紙上寫程式，也有的公司會直接讓面試者在一台有安裝基本開發環境的電腦裡去寫程式，好一點的是電腦有連對外網路，無法連對外網路的也是有，這就真的是在考驗應試者。

過去我也有許多的面試經驗，各式各樣的面試都有經歷過，例如：一場面試從早到晚歷經 9 個小時，電話對談、全英文面試、即席出題、筆試、上機考、直接被人拿一張試題從頭問到尾等等。雖然不敢說什麼各式各樣的面試都經歷過，但至少可以說有很多不同的面試經驗。

在這麼多的面試裡，最讓我反感的有兩種，一種是筆試，另一種就是要把應試者問倒的面試。

 

關於筆試

筆試，這有分了好幾種，比較常見的就像學校考試一般，給應試者一張考卷，上面列出一些題目例如選擇題、填充題、問答題，這主要是看應試者有沒有基礎與是否具備觀念，大部分會跟應試的工作職務有關。而除了上面所說的三種題形外，還有一種就是給一道題目，讓應試者直接在紙上寫程式 …

老實說，我真的很討厭在紙上寫程式，因為真的很彆扭，而且我也必須老實說，我就是那種沒有編輯器就不會寫程式的工程師，所以要我在紙上寫程式，我也就只能夠寫出個大概，所以也別指望這樣的程式碼會能夠正確，但以往面試的經驗裡，我就遇到好幾次拿著我寫在紙上的程式然後就開始在那邊指責我沒有觀念、不會寫程式等等，甚至於有一次遇到的筆試題目是連鎖題，第一題到第五題都是有相關的，第一題是設計資料表，並且要寫出 Create Script，第二題是寫出 CRUD SQL Script，第三題好像是在 C# 去寫連接資料庫與 CRUD 的操作程式，第四題是修改 Table 結構，一樣要在紙上寫出 Update Script，第五題好像是要寫 Stored Procedure，總之那一次我寫出來的結果就只有大概，想也知道是根本無法正確執行的內容，但主要的觀念和語法是對的，但面試我的人卻是在我所寫的內容裡去挑三揀四，那一次的面試結果讓我相當反感，也讓我之後遇到在面試過程裡要筆試的公司，我對於筆試內容就是隨便應付。

如果一家公司要以筆試的方式來面試，就不要去要求應試者所寫的內容必須百分百的正確，要去看應試者所寫的內容是否理解題目，以及是否具備題目所要求的觀念與知識，如果只是要一個正確答案，那麼應試者也只是個會死讀書而不會變通與應變的工程師，或許日後進來公司可以完成每次所交辦的需求，但也就只有這樣而已，你無法去期待他可以為公司去求新求變。

 

把應試者問倒

我不知道把應試者問倒有什麼好處？
讓面試的主管可以有優越感？還是只為了看到應試者被問倒之後的窘境呢？

我真的有遇過，但也只有一次，該面試主管拿著一張紙，上頭洋洋灑灑的列了四、五十個題目，題目內容包羅萬象，從基本的程式觀念、HTML、JavaScript、CSS、C#、IIS、Windows Server、Visual Studio 等等，什麼問題都有，甚至於有很多問題所提到的一些技術或名詞是第一次聽到，整場問下來大概是一個小時，那一個小時如坐針氈一般，當題目越來越進階，越來越多我所不懂的內容出現，我最後只有一個感覺就是我身為一個工作多年的網站程式開發人員竟然有這麼多不懂，我這些年都在做些什麼，我實在有夠廢物的，很多負面想法一直不斷地出現，那份工作最後還是有拿到，而最後我也瞭解到那是該公司的慣有手法，用一堆問題去把應試者問倒，讓應試者覺得自己一無是處，然後把應試者要求的薪資硬生生地直接打了八折，讓應試者覺得這公司還是願意給機會給他，讓他有機會可以學習，雖然拿著被打折的薪水，但還是會滿心感謝公司給他機會（但留得久不久就又是另外的故事了）。

 

徵才與面試

我現在的工作環境也是一直在徵才中，因為有欠缺太多的開發工程師，但也不會因為缺很大而隨意地招聘，但各單位的徵才狀況又讓我有些瞋目結舌，有的單位會用筆試、口試的方式來進行面試，也有很多是在「閒聊」的過程完成，連應試者的程式都沒有看過，甚至於是不是真的有具備應徵職務該有的技術能力都不是相當瞭解的狀況就決定聘用，這些狀況所找來的工程師水準都參差不齊，真的上了戰場之後才能夠知道當初那份履歷上所寫的技術與經歷是不是經過灌水。

面試一個人，從電話聯繫、詢問是否有意願、接洽面試時間、面試會談、複試、送文件到人資單位、上級審查、核薪、通知任用、確認報到時間，一直到最後的職務報到，最快的情況約兩個星期，而一般都會耗費一個月或一個月以上的時間，要花費這麼多時間與人力，所以面試者與應試者都應該要認真的面對這件事情。

 

程式

面試一位開發工程師比較快的做法就是看他以往所寫的程式，但這也是最容易引發爭議，因為絕大部分的工程師所開發的都是公司的專案或是業主的系統，程式原始碼不可能也不可以私自帶出來，所以不可能叫應試者直接將之前工作所開發的程式拿出來看（其實專案原始碼什麼的，都是有辦法拿到的，但這就關係到程式開發人員的職業道德，如果應試者就這麼直接的把前公司的專案原始碼拿出來而且攤出來給別人看，那麼這位應試者假如也真的成了員工，若干年後也變成了前員工，那麼是不是他也會把公司的程式原始碼給私自帶出然後給別人看呢？），如果應試者有自己的部落格或是有個人 Github，而且有將這些訊息登載在履歷上，我們在看履歷的時候就可以第一時間就能夠瞭解應試者的技術水準與能力，就可以減少雙方的時間，在面試的時候就可以讓公司捨去「探底」的過程而直接進入更進階的階段。

作業

如果沒有部落格、也沒有 Github 的應試者呢？所以在去年的時候，我們單位就出了一個作業題目，向公司其他開發團隊建議在面試之前，要讓應試者完成這一份作業，並且在面試前回覆給面試單位，作業內容如下：

• 資料庫可以使用 Northwind 或 AdventureWorks，或是可以自行設計
• 使用 C# 與 ASP.NET MVC 或 WebAPI 進行作業的專案開發
• 針對其中的部分資料（不限定）完成 C.R.U.D 的操作
• 沒有限定資料存取的方式，可以使用 Entity Framework 或 ADO.NET 或 Dapper
• 可以在專案裡使用 DI Framework，或加入單元測試
• 開發工具需使用 Visual Studio 2013 以上 ( 提供 Visual Studio Community 版本的下載網址 )
• 程式開發過程必須使用 Git 版本控管
• 最後開發結果必須簽入到 Github 上，如果沒有 Github 帳號就自行前往申請
• 於面試前一天將作業的 repository 位址回覆給面試單位

 

這一份作業內容對於很多人來說是有如一塊小蛋糕一般，但這份在許多人看來是相單簡單的作業卻真的可以反應出許多應試者的心態與技術能力。

完全沒做

這情況還沒常見的，而且理由不外乎就是那幾種，最常聽到的就是不會用 Github 或者是沒有 Github 帳號，這…… 我覺得用這種理由而沒有交作業就相當不負責任，沒有帳號，那就去申請一個，而且又不需要花費任何的費用，至於不會用的，那就去學呀，連簡單使用 Git 將程式原始碼簽入到 Github 裡，這種已經是現在程式開發人員必備的技能都不願去學，卻會在履歷中寫上自己的特色是「認真主動學習、喜歡嘗試新技術」，這就讓我覺得這個人就會是表裡不一，日後如果進來公司，專案要使用新技術或新方法的時候，就會讓專案陷入危機。

另一種不交作業的情況，就是不會我們所指定的技術（ASP.NET MVC / WebAPI），這我也不能說什麼，的確就真的是有人之前專案開發就是只會 ASP.NET WebForm 或是 WinForm，完全沒有接觸過 ASP.NET MVC / WebAPI，其實這個因為不會而不交作業，我是覺得有點可惜，因為連嘗試的機會也不願意，至少試著完全依照 ASP.NET 官網上的教學課程做一遍也可以，連一點機會給自己都不願意，那之後公司要開始導入 ASP.NET Core 開發的時候，怎麼辦呢？

隨便應付

作業真的很簡單，所以稍有能力的工程師可能拿到作業題目就會先嘲笑一番，可能是在笑說出這什麼題目，是瞧不起他們嗎？所以有的人就會直接用專案範本將作業給完成，最後也簽入到 github 上，但也真的是完全用專案範本來完成，所以全部的內容從自動產生之後都沒有做更改。

認真面對

會認真面對這份作業並且將內容做了一些變化，也加入自己專案經歷所會的東西在作業裡面，例如做簡單的軟體分層、使用 DI，在專案加入單元測試專案等。多半會相當認真寫這份作業的應試者都是屬於對於 ASP.NET MVC / WebAPI 沒有多少專案開發經驗或毫無經驗的人，而真的會 ASP.NET MVC / WebAPI 而且認真面對作業的應試者還真的不多（屈指可數）。

 

作業的說明

這份作業要反映的是應試者有沒有具備我們公司所要求的基本能力與技術，也可以看出我們公司開發單位裡每個工程師都要具備的基本條件。
例如我們主要是使用 Microsoft .NET Framework 技術進行開發，使用 C# 語言，主要是以 ASP.NET MVC / WebAPI 開發專案，開發時所使用的工具為 Visual Studio，版本已經使用 2013 以上，有要求使用版本控管，而且使用的是 Git，在專案上會要求做到軟體分層，並且會使用到 DI Framework，而且專案有導入單元測試的實做。
另外沒有明確講出來的，但是從細節裡可以看出，因為是使用 ASP.NET MVC . WebAPI 又有提到 DI Framework 與單元測試，所以對於物件導向程式開發的觀念是有要求的。

有些單位主管在收到應試者所完成的作業後，會將完成的作業 Github repository 位址給我，讓我去看看程式的內容，我會去詳細的看過一遍後再提供一些我的分析與意見。

我這邊會看的第一個就是看 Commit 記錄，如果是熟悉或已經有在使用 Git 的開發者，專案的簽入是會有很多次的，不會是一次或是只有幾次而已，而且可以也可以從 Commit 的訊息裡看到每個開發階段的歷程。

接著是看專案的結構，如果是使用 MVC / WebAPI 專案範本建立的網站，而且沒有做任何的變化，那麼專案的目錄結構就不會有什麼變化，我就不會期待程式會有什麼樣的進階變化，如果有試著做簡單的軟體分層，就會在專案裡去建立不同的資料夾，例如 Repository, Service 等。

再來是看專案裡的 packages.config 內容，看看專案除了範本一開始建立時所使用的 Nuget Packages 外，還會用到哪些套件，如果有看到 Unity, Autofac 等名稱，就會知道專案有使用 DI Framework，在下一階段的程式就會留意這一個部分。

下個階段就會看 Controller 的程式，如果只是用專案範本而沒有做任何的修改，檔案開起來之後從上到下檢視過一遍之後，甚至連 View 都可以不用看，但如果有對程式做些變化，就會讓我再去細看內容，如果有做軟體分層，就會去看類別的設計、有無使用介面、怎麼切分職責，接著再去看類別及成員與變數的命名、程式碼的格式，由這些去觀察工程師的習慣和物件導向觀念。

ASP.NET WebAPI 專案的話，就會去看各個方法的動詞與 Route 使用。ASP.NET MVC 專案的話，最後要看的就是 View，去觀察是否瞭解 Razor 語法的使用，另外是否知道使用 ViewModel，以及是否正確設計與使用 ViewModel。

如果有做單元測試的話，就會去看專案如何去做到可測試性，以及去看單元測試程式的內容，可以從測試程式的內容去看出對於單元測試的熟悉程度，是否以前工作有使用過，還是自己摸索而還沒有應用在工作上。

 

因為這份作業沒有嚴格要求什麼，要做什麼以即要做到什麼樣的程度、使用什麼樣的技術，這都讓應試者自己去決定，我甚至於也沒有要求專案可以被執行（但必須要可以被編譯完成），看應試者對於這份工作的面試是抱持什麼樣的態度。這份作業一般是在與應試者決定什麼時候來面試的時候告知的，應該都會是在面試日期的前一週就會提供，所以不會讓應試者做得太倉促，一來也是不希望佔用應試者太多時間，另一方面也讓想做更多一些的應試者可以在一週裡用一些時間去做調整，而且這些的調整都是我事後可以在 Commit 記錄裡去看出來的。

當應試者來公司進行面試時，面試主管可以在面試前或面試後給我看作業，然後我提供我的觀察給面試主管，提供給他們做為參考。如果是我與其他同事一起協同面試的話，就會在面試前就看過作業，然後就會在面試過程裡針對作業與應試者做交流，去瞭解應試者的程度。

 

我們不希望只是閒聊或用不著邊際的方式去對應試者旁敲側擊，看過應試者的履歷和專案經歷後，再以作業的內容做第一步的瞭解和認識，接著在實際面對面的對談去瞭解應試者是否真如履歷上的資料一般，是否真有那些專案經歷，而且技術能力是否如實與符合我們的期待，最後就是整個人的調性是否適合開發團隊。

這一年多下來，看過的應試者和作業雖然不多，但普遍存在一個現象，那就是很多人在履歷上的技術能力與專案經歷都洋洋灑灑寫了很多，交出的作業內容多半無法反映出相對的實力，然後在實際的對談也沒有看到履歷上應有的內容。最後就會覺得很多人的履歷與專案經歷寫得真的很好，有些人的實際對談也可以口若懸河、應答如流，但實際所看到的程式就又是另外一回事了。

 

最後，我想說的是……

現在有些開發人員都喜歡去看 leetcode，去練技術、練程式，但我覺得因人而異，如果是想多練程式好讓之後工作面試的測驗可以好過關，我覺得這個出發點就很怪，因為公司找人，要找的是日後在公司有產出，能夠消化需求，能夠解決問題、能夠改善流程，能夠有所貢獻的人，要面對的是實際的需求與變化。

面試的時候，不只是公司去面試應試者，也是應試者去面試公司的過程，不是單方面的公司去挑人，也是應試者去挑公司，應試者要去看面試的公司是否能夠滿足你的期待，是否滿足你未來的職涯發展，是否能滿足你在技術的追求和施展能力。

這些年幾乎沒有看過有完整規劃與想法的工程師，大部分的工程師都沒有想法、沒有規劃，也沒有學習的方向和目標，但卻會要求公司是否有完整的培訓計畫或資源，對於未來想要朝什麼方向發展也沒有提出明確的內容。程式開發人員沒有想法、沒有規劃、沒有學習目標，到最後也只能算是個「程式碼打字作業員」而已，真的不要成為這樣的開發者呀~

最後再補充一下，很多人都在履歷上或是面試的對談裡會講到學習資源與教育訓練，基本上除了一些電信、金融、公營機構、大型企業外，很少有公司會編列所謂的個人教育訓練的預算或額度，一般的公司其實也願意給予學習補助，但就會希望是以對價的方式，例如要取得多少預算額度，可能需要跟公司簽約，至少在上完課之後要留在公司裡多少時間，我想這是最常見的，對於這樣的方式是否每個人可以接受，我是沒有任何意見，畢竟你要公司去投資你去學習，公司也勢必需要你之後有所回饋（這邊說一下我看到很多人拿公司預算去上課的情況，因為不是花自己的錢，就不會痛，不會痛的情況就是沒也強烈的學習動機與慾望，最後就是什麼都學不到，拿到結業證明，卻無法證明你真的已經學習到課程所教的技術）。

另外很多人在履歷上都會寫主動學習、願意學習公司指派的新技術，但如果公司沒有主動要求你做任何的學習呢？公司的確是有義務在適當時候對員工進行教育訓練與技術提昇，但員工本身呢？沒有人在背後推或要求就不會主動學習嗎？

 

延伸閱讀

造就優良的軟體開發團隊文化的要素有哪些？ | Soft & Share

白板上的演算法 | iThome | 程式人｜林信良

IT职业技能图谱 | Emily StuQ

开发者技能修炼的五个等级 - ThoughtWorks洞见 - 宋琦

有什麼做什麼，其實是職場上最可怕的事 | gipi的學習筆記-專案管理、商務簡報技巧部落格 - 點部落

 

以上