2020 軟體工程實習求職見聞錄

2020/10/31閱讀時間約 11 分鐘

自春季末開始求職以來，大約也經過了半年，期間陸續接觸了近十間軟體企業，拓展了不少眼界。依循著前人「取之於社群，回饋於社群」的精神，我也希望能為產業貢獻一己之力，以一個求職者的視角，分享我親身體驗的軟體企業面試現況。

在進入正文之前先粗略描述筆者的技術背景，希望讀者能理解觀察與描繪面試流程的視角，也提供背景相似的讀者一些參考。目前我有五年多的程式撰寫經驗，軟體工程師相關實習經驗約一年半，在 SITCON、COSCUP 等等會議給過幾次 Talk，技術算是上的了檯面。

這次接觸的企業都是中小型的軟體新創或是外商，比如 iCHEF、UI.com、PicCollage、17 Media，可能會有誤差無法代表整個軟體產業，但如果你嚮往的企業性質相似的話，這篇文章具有足夠的代表性。

接觸企業的方式我主要依靠 LinkedIn 接收人資或獵頭的邀約，以及請朋友協助內推，整體感受相較於陌生投遞來得更有效率許多。而工作性質是希望能長期合作並被視為產品團隊的一員，接受嚴格的 Code Review 與效能及品質檢驗、跟隨產品版本推進，因此由 mentor 帶著做業外 project 或是寫自動化測試腳本的就沒考慮了。

接著就來談談我這半年所觀察到的面試風格和趨勢吧！

知識儲備與成長背景

對於一個 Software Engineer 而言，如果除去 Coding 之後還會剩下什麼？

軟體工程的技術深度和複雜度不斷的突破上界，使得近代軟體工程師更多時候投入在釐清軟體需求、建立交付流程、溝通技術採用與架構設計等等，把 Code 寫好已經是基本能力之一。這讓團隊溝通的重要程度向上提升了多個檔次，一人單幹撐起一個產品可說是越來越不可能了。

也許你曾經有那種和對方辯論許久仍未得出結論的經驗，就如同雙方是在不同的世界一樣，這樣子的溝通在時間以及精神上都是十分大的耗損。除了對於熟悉知識與技術無法對齊外，長時間受環境影響而養成的價值觀也是值得關注的點，以軟體工程團隊的角度來說，理所當然的希望邀請溝通更為順暢的夥伴加入。

以筆者面試的感受來說，企業為了推測日後與候選人在技術與價值觀上溝通的成本，往往會在詢問過往經驗與背景上費些苦心。相較於直接詢問「你可不可以解釋這工具的用途？」以及「你為什麼想當工程師？」之類粗淺又容易應付的問題，不少企業是採取更抽象的間接驗證來了解候選人真實的內在想法。

學習環境

我們所能擁有的知識與技術，可說是幾乎取決於學習環境與獲取管道。中國辯論翹楚詹青雲在一次演講中有提到：

這個世界上很無奈的，有一種東西，你無論怎麼靠自身努力改變不了，而需要一個人點醒。這個東西叫眼界。

井底待久了，也就慣了。沒受過真實市場的考驗，沒見過尖端技術的登峰造極，又哪能有所突破呢？井底的千錘百鍊，終究止於枯枝、落葉、礫石與水罷了。把心思用於勾勒候選人學習環境，比直接透過技術問題檢驗能具有可靠度、也能獲得更全面的資訊。

許多具有面試他人經驗的前輩皆有和我提到，在社群中學習、參與開源專案貢獻的候選人，普遍比在校內穩定發展的族群對技術生態系有更全面的了解。一些企業已把「樂於參與技術社群」列為加分項目之一，可見其對學習成長環境的重視。

眼界與格局

「如何看待一門技術未來的發展方向？」、「如何看待這個技術問題？」、「如何進行選擇用哪種技術？」從這些開放性問題的回答方式都能看出一個候選人的思考格局和眼界的。

若大半時間都僅在 Code 如何分檔案上兜圈子，無法更往上一層討論整體服務架構設計，那便會給人一種只會獨立開發小專案的感覺。若僅因為一門技術的一兩個亮點而堅持使用，而沒把服務遷移風險、導入時程納入考慮的話，則容易形成沒經歷過上線產品及團隊運作的形象。

以實習職缺面試來說，這部分是個再多類問題通用性高，也能有效創造巨大差異化，讓其餘競爭者由完全無法跟上的技巧。筆者在多次面試後都又收到這方面正向的評價，若你有足夠的技術經驗，不妨試試從這方面彰顯優勢。

申請動機與企業文化

為什麼想加入我們公司？

幾乎是每次面試必被問到的問題，候選人往往會先行了解公司理念與文化，並在面試時表達認同與共鳴，不過這類東西非常容易在言語上假冒。既使面試後順利錄取了，少了真實的動機和認同感，職業倦怠期就會迅速到來，這對團隊來說完全是不必要的損害。

更具體的問題

幾乎每次 on-site 的 HR 面試環節筆者都有被問到「還有投遞哪些企業呢？」這個問題，除了了解潛在人才市場的競爭對手外，也能見識候選人求職方向的一致性。有些候選人面試了許多間文化和理念完全不同甚至背道而馳的公司，但每一次面試時都充滿熱忱的說享受這間公司的文化。

很多時候當對方想要知道候選人對 A 問題的答案的時候，並不會直接提問 A 問題，而是提出另一個需要用的 A 問題答案的 B 問題。像是上述的求職方向，另外筆者也有被問到「有哪些持續關注或嚮往的公司呢？」也是異曲同工之妙，若心中沒有一個 consistent 的自我實現方向一昧地迎合當前公司的話，是難以回覆具有連貫性的答案的。

筆者非常喜歡重視使用者體驗、刻畫未來更方便的生活方式，且願意積極與目標市場互動的 B2C、B2B2C 產品，我一路以來面試的企業都有這些特點，在 LinkedIn 上的關注議題與企業也都是如此。透過這種技巧來側寫候選人的真實動機會更加可靠許多，也突顯出對於動機和自我實現方向的重視。

不是有沒有動機的問題，而是夠不夠強烈

少數一兩次面試有遇上了「你曾經為了你的理想付出什麼？」這類型的問題，使我有更深一層的思考與對談。如果真的希望對於環境帶來一些改變，那應該要有實際採去行動，而面試就如同兩個理念相同的知音相遇，彼此分享著過往的經驗並期待未來彼此的合作一樣。

面試後的反思

我很早就已經發現我是個渴望外界衝擊的人，半年來許多鋒利的面試問題不斷使我的理念更加清澈。在企業嘗試了解候選人的同時，也使得候選人更加了解自己，這有賴於整體產業的招募風氣進步與精心設計的面試流程。即使面試當下未能妥善回答，那也可能會是值得思考多個夜晚的難得議題。

從量化指標走向集體共識

在面試之前我也曾上網搜尋過前人的經驗分享，有不少中小企業以及傳統大公司都還是用學歷、證照等等指標在評斷候選人，老實說筆者某些親戚所經營的企業也是如此。值得慶幸的是，本次筆者在軟體新創與外商的面試並未遇到如此檢核方式，若讀者的目標企業與我相似的話可以不用過度擔心。

取而代之的就是來自 HR 以外，包含工程、產品、設計及營運團隊中所有可能在未來與候選人共事的成員，所形成的集體共識。這對於企業來說可說是提高了不少招募成本，光是安排會議徵求足夠的成員在面試時段與候選人對談就是一大難題，但也顯示了對文化融入與互動過程的重視。

筆者所參與的 on-site 中一對一的面試與多對一面試比例大概各半，有遇過和六、七個成員一起用餐交流，也遇過和輪流和各個面試官對談一小時的。不過話題多半圍繞在以面試者的視角來了解候選人上，變化之豐富似沒有什麼標準的套路，網路上所查到的「面經」實用度感覺不是非常大。

用高大上的問題判斷實際實力深度

除了變化性相當高之外，許多問題方式也更偏向抽象的軟體工程問題，在確認候選人在特定領域的知識外，也顯示了企業軟體工程團隊目前重視的問題與希望招攬的人才特質，比如：

如何設計聊天應用程式的 Server API？
如果服務 crash 了你會如何進行偵錯？
如何設計 AWS 架構使服務承載更高的流量？
如何規劃 Issue Tracking 的流程？
如何決定 Log 要存下哪些資訊？
如何管理 Docker image 之類的 artifacts？

這些問題提其實都沒有標準答案，重點會在於候選人思考的深度與廣度、以及與面試者互動討論如何產出解決方案的過程。這些問題也讓我每次面試時都像在拆驚喜包一樣，相較於面經上的必考題更來得有趣許多。

其中有個筆者貌似在每次面試都會被問的問題：

分享經歷過最困難的技術問題

這問法相當精妙，因為給了候選人幾乎無限的回答自由，使得上下限差距非常大，如同筆者在上文中所描述的「眼界」有所呼應。筆者認為要這問題確實可以先行準備，但要回得好就不應該急於回覆，要以尋求有效互動的角度要求面試者給出更詳細的描述：

我有許多值得分享的經驗，包含資料庫遷移、CI CD Pipeline 設計、Load Balancing 負載異常等等。不知道你們目前較專注哪一方面的技術，我可以分享相關的主題。

透過一些談判上的技巧把開放性問題調整一下，會使得問題更好回答，也能讓面試者收到他直覺上更想聽到的答案類型。這個方法在實戰中屢試不爽，面試者都會提出兩三個方向讓我參考，或是直接在我提到的幾個主題中選一個請我分享，降低了許多不必要的風險。

職位等級垂直偏移

我在搜尋目標實習職缺時，有發現到軟體工程相關的實習薪水比其餘社群營運、行銷相關的還要高。如果是以時薪計價的話，可能會高出 40~90 塊不等，也有遇到一些是以月薪開三至四萬的，貌似已和某些低階正職缺的薪資待遇看齊。

如此直接地在職缺類別上製造差異化，以及很給面子的待遇，也顯示出企業更積極投入在軟體工程人才的招募上，也將人才市場的競爭向下扎根至學生實習階段就開始佈局。

不過如此細緻的面試方式以及遠高於業界水平的給薪也給招募團隊帶來不少時程與心理壓力，因此幾乎在 on-site 面試前都會有一兩關前測。可能是一些時限一至三小時的線上作答，也可能是三天至一週的 take home project，目的就是為了快速剔除思考和開發能力低於要求應徵者，讓團隊能把心思聚焦在剩餘的理想候選人身上。

目前寫起來的前測水準其實都不低，演算法題目大概有 Leetcode Medium 等級，take home project 的時間壓力也有給的足夠，我偶爾會需要在截止日前每天投入 6~8 小時才能完工。筆者有幾次算法題有些小失誤，但仍順利進入 on-site 階段了，感覺通過前測的門並不會太窄，但得花些心思用程式碼讓對方了解自己的水準。