本篇分享筆者於 2022 春季期間軟體工程新鮮人正職的求職心得。由於網路上理工留學生的求職分享大多以北美地區為主，而歐洲這邊的分享又以商管領域居多，因此希望本篇能夠為相似狀況的讀者提供一些準備方向 。
Disclaimer
雖然標題打著軟體工程，但其實筆者的目標職位是更偏近於嵌入式軟體（Embedded software）的部分，通常是針對較底層的驅動程式、軟硬體協作、即時系統等等。不少公司也將稱之為韌體 （Firmware），但又有另一派公司把韌體工程狹義上視為使用 Verilog 或 VHDL 為主的工作 ，而把使用 C 和 assembly 歸納在軟體工程。總而言之，在業界稱呼的分類上相當混亂，毫無統一用法，所以建議相似背景的讀者在求職時不論是 software engineer, firmware engineer, embedded software engineer 的職銜都點進去看看 JD 會比較清楚。
背景
M.S. Embedded Systems @ TU Eindhoven, Netherlands （當時碩二下）。在開始找工作前有在荷蘭上市公司實習過半年，內容是開發封包解析軟體。更早之前 （大學）則有在台灣做過軟體實習。
申請結果
如 Figure 1 所示無聲卡比例仍然超過一半。而拿到一面的機會差不多 10% 多一點。投遞國家範圍則包含西歐（含英國）、北歐、伊比利半島。另外在求職期間筆者完全沒有投任何荷蘭工作，主要是因為實習結束時主管有口頭 return offer，所以打從開始就將荷蘭視為保底。因此這份統計粗略可視為保守結果（如果投荷蘭工作則會有學歷的地利優勢）。
就如先前提過嵌入式工程的職位在命名上相當不一致，下圖 Figure 2 筆者將所有投遞過的職稱以頻率加以視覺化（大字體＝高頻率）。即使職位不同，當比較過這些職位的 JD 後發現其實性質都大同小異。
面試
以下筆者挑選一部分印象較深刻的面試過程：
- Amazon (UK)
分成兩場面試，一小時電面和一整天的四或五輪面試。前後大約間隔了一個多月。由於事前要簽 NDA 因此在這就不方便討論題目了。至於難度的部分 HR 有說因為是 embedded software 的職位所以 coding questions 不會刁鑽在很深的演算法，筆者面試下來也是這個感覺。基本上大學的資結演算法好好念就夠用了。除了技術題之外 Amazon 也很重視 Leadership Principles， 基本上就是 behavioral questions。這部分非常重要因為每一輪都會問而且占的比重都不低 ( 一輪的 40–50% 時間左右）。照官方的說法 LP 是用來判定面試者的價值觀是否符合公司文化，但筆者覺得這更像是在考驗面試者遵循著核心主題 (LP) 來敘述事件 (通常會要求以學校或過往工作的 projects 作為舉例）的能力。一般會建議照著 STAR (Situation, Task, Action, Results) 模板來回答。最後決定錄取與否的依據是根據二面時的四或五輪考官投票決定，如果過半就通過。通常其中一個考官會是組外的 bar raiser， 問的問題比較深入，而且投票時具有 veto 的權利。筆者最後投票沒過半被刷掉覺得有點可惜，因為整個流程看下來其實不算難。只是一整天的二面倒是真的蠻累，從上午第一輪開始，到結束時已經接近傍晚。建議最好多補充體力，不要像筆者低估了時程的消磨到最後兩輪基本上已經頭昏腦脹。
- HP (Spain)
HP 在 Valencia 的據點主要負責的是印刷產品的開發而不是筆電或桌電，面試官也都來自同個 team。全程只有一場面試分為四輪，每輪各半小時。前三輪是 technical questions，題目圍繞資結、C coding、和 real-time systems，筆者覺得難度都偏基本。最後一輪是 behavioral，由用人主管面試，基本上都是在喇賽，氣氛很輕鬆。有一點讓筆者不太滿意的部分是前三輪技術題中的有的面試官們似乎都只是照著公司題庫的解答比對而並沒有真的關注於面試者的思路，因為不只一次當筆者提出不同的方法或理論時，有些面試官就直接愣住並說他沒聽過，且不斷試圖將回答內容導回他們手上解答的方向，而非讓面試者有繼續解釋的機會 。這樣的作法筆者覺得非常的不專業，而且給人一種匆匆應付的感覺。總而言之，這讓筆者體認到面試中最重要的不是說出你懂什麼，而是說出對方想要聽什麼。
- Nordic Semiconductor (Norway)
這家北歐公司的應徵流程跟其他的明星公司相較之下精簡了很多。從投遞到安排面試只花了兩周。Coding questions 感覺上只是確認面試者有程式背景，所以 pseudo codes 寫出個大概就不繼續追問了。其他的技術問題主要是圍繞在筆者的碩論（兩位面試官會問得很細），而不是一般針對教科書知識的一問一答，因此整體的氣氛更像在深度討論而不是考試。最後在一面結束當下就安排二（最終）面，將會是用人主管提問 behavioral questions 和系統設計。雖然筆者最後拿到其他 offer 後便婉拒二面了，但直覺猜測應該也會是喇賽的成分比較多。整體而言這家公司給筆者的印象很好。面試官態度友善不囉嗦，也不會刻意刁難。可說是近年來科技業面試趨勢下少有的清流 XD
- Apple (Ireland)
蘋果的面試算是筆者遇過最奇葩的經驗。首先 HR 會在某一天突然寄信通知面試者準備隔天面試，沒有錯，是通知而不是喬時間。同時也不會告知面試者需要準備什麼或是面試長度。筆者自己是抓個大概 90 分鐘排開。因為一切都發生的很突然，會有種走在路上忽然間被蓋布袋綁上車的感覺。然而這還不是最神奇的，面試過程中考官會連環問一系列不相干的問題，範圍非常廣，從電路學、程式設計、統計學、甚至是文字邏輯推理都有。共同點是都不會太艱深，但面試者也起碼要有稍微涉獵才回答得出來。整體上給人感覺有種想要找出 Jack of all trades 的意味。在面試結束之際，筆者忍不住問面試官這一系列的弔詭安排 （突然約隔日、不提示準備方向、神奇題目等等）到底是怎麼一回事。結果不意外的面試官答覆是：蘋果故意要整面試者的… 至於背後原因筆者就沒有繼續追問了。一面結束後一周左右二面通知就到了。套路基本上也差不多不會詳細交代要準備什麼，因此筆者這次乾脆就不準備了。幸好的是二面相較下步調悠哉很多，多是 behavioral questions 跟閒聊筆者碩論的進度。
準備
筆者認為 embedded software 面試的準備方式跟大家熟悉的 SWE 差異甚大。首先 LeetCode 真的不用刷太多或太難，主要原因在於 embedded software 職位更加集中於特定題型，例如 bit manipulation, data structure 等等。 而什麼 Dijkstra’s algorithm, red-black tree 這種演算法類的題目出現的機率則極低。再者，比起 LeetCode，筆者覺得把 C 語言徹底的弄清楚更為重要 （不單是 coding，而是把整個語言的特性認識過一遍，例如 preprocessor, memory allocation 等等），畢竟對於嵌入式或系統軟體工程而言，C 在某種程度上就是母語。筆者幾乎所有的面試中都曾被問到關於 C 的問題。
第二個準備重點則是 domain knowledge 的部分，因為嵌入式系統本質上就是指嵌入在電機系統中負責軟硬體協作的介面，因此應用層面非常廣大，從物聯網、機器人、到更上層的使用者軟體都是常見的應用。以下筆者整理了一些重要的主題並按照面試中遭遇的頻率排序：
- OS, RTOS (interrupts, semaphore, schedulability…etc)
- Digital Communication (serial link, source coding, channel coding…etc)
- Computer Network (OSI, IoT, security…etc)
- Computer Architecture (ISA, assembly, parallelism..etc)
總結
筆者一直以來堅信著找工作這種事就是一場 number game ，不斷的海投讓結果順其自然得均值回歸。有些人可能傾向善用人脈內推，但就筆者個人經驗覺得工作錄取的決定因素之複雜，牽涉到公司的 head counts、 其他應徵者的表現、甚至是用人主管的心情，整體上內推的實質效益應該有限。況且，看到不少新鮮人過度的重視內推反而讓筆者覺得某種程度上限縮了視野跟選擇，倒不如多嘗試不同公司的面試和聽聽對方員工的介紹，都會對於了解當下勞動市場更有幫助。與其相信人情不如相信統計學，這一直都是筆者的求職方針。
最後鼓勵正在找工作的讀者，大部分時候沒有錄取真的都不是應徵者本人的能力問題。就像上段提到的，找到工作其實就是一連串天時地利人和下的結果。只要不停的嘗試並從每次經驗中修正，剩下的就交給大數法則！
如有其他問題歡迎來信詢問 :))
