軟體工程師應該是現下最熱門的行業之一，面試時有一個魔王關卡，那就是技術廣度 (Technical Breath) ，面試時可能會產生這樣的對話內容：
面試官：請問什麼是CDN?
你/妳: （恩…）Content-Delivery-Network? 我只知道這個。
面試官：（OK，看來他只知道名詞解釋，below the bar） OK，下一題，什麼是CAP理論？
公司的Technical Breath這關是在幹嘛？
公司想要評估求職者本身在這份崗位上的background knowledge，包含對會需要設略的領域（e.g: storage, compute, networking, monitoring, database…），以及有無特別感興趣或是見解的地方。而綜合起來的結果就可以想像成申請人的戰鬥力指數。
通常會用Wh類的問題作為開場：
- What is CAP therom?
- What is the difference between relational database and non-relational database?
- What is OSI?
根據Galssdoor和blind等網站，Amazon再進行技術廣度評估的時候，會將面試者回答的答案分成三種等級(Above / Meet / Below the bar)並有對應的分數，待面試官面試結束後會得到總分並評估是否有超過Hiring manager和公司的要求水平，例如：
- 該崗位所需要專注的領域是否有達標？(e.g: database, security要合格)
- 整體而言此level所需要的標準是否達到水平(e.g: 至少要有2個領域 above the bar並且大部分都是meet the bar)
綜合上述的標準才會決定是否要往下一關前進。
為什麼我很常在這關就被刷下來？
通常這關就被拒絕的原因有很多種，但大原則是不要不懂裝懂或是直接拒絕。
其餘的部分，大致上也分成三大因素：
1. 只會字面翻譯但是不知道用來解決什麼問題
例如文章最一開始被問到什麼是CDN，若求職者只能回答出字面意思，但卻不清楚此技術能帶來什麼效果，通常都是拿到below the bar的分數。
- 面試不是一個背多分的考試，詳細講出自己的know how 跟 experience才是最重要的。
2. 並不是自己的經驗
面試最重要的原則就是據實以告，並且用STAR方式去描述自己解決問題的方法。
Ｓ- 情境（Situation）事情是在什麼情況發生的? 什麼樣的因素導致這樣的情境？
Ｔ- 任務（Task）你當時的期望工作和挑戰是什麼？
Ａ- 行動（Action)過程中你扮演什麼角色？你怎麼做？怎麼想？
Ｒ- 結果（Result）最後的結果是什麼？後續有什麼影響？
3. 對於專業知識不夠深入
既使所有的問題求職者都可以回答得出來並且有中等水平，但是無法進入更深入的技術比較與實務經驗的分享，會讓面試官感受不到申請人的強項而，從而認為不一定能為團隊帶來價值。
- 建議大家擁有一個自己的專業能力，並非單純只有CS，團隊溝通、系統分析也是很重要的一環。
怎麼樣擴增技術廣度且同時理解本質？
首先，這並非速成可以解決的問題，必須要靠時間積累來逐步打底各種領域的知識。
但也有高效的方式快速打底，讓你從0到入門並將身邊能掌握的事物進行透徹理解。
實務上在進行重點式的吸收時，建議將所有的知識點彙整在同一份筆記上，每次都不斷修正這份筆記讓它趨近於更好吸收與複習。以下是求職者可以運用的方式：
1. 打好基本功，了解基礎名詞分類以及彼此之間的關係。
軟體工程領域裡面有很多的縮寫，稍微不注意就會迷失在這些縮寫當中，所以可以先釐清每個名詞的類別作為開始，以IaC這個名詞為例子，其全寫是Infrastructure as Code的縮寫，也可以翻譯成架構即代碼，屬於“領域類”的名詞。
在IaC領域中，常見的技術工具為 Cloudformation, Terraform，分別是不同公司在IaC中所提供的工具，屬於"工具/技術類"的名詞。透過明確分類名詞之間的性質，求職者會更有系統的歸納不熟悉名詞之間的關係。
另一個例子是database領域，有關聯式資料庫(Relational Database)跟非關聯式資料庫(non-relational database)等等，而在關連式資料庫裡頭，MySQL是一種資料庫引擎(database engine)，而SQL是一種資料庫檢索的語言(query syntax)，不是資料庫引擎。
- 試圖先從同一個主題內的名詞，將其之間的從屬關係釐清，才不會陷入用蘋果跟橘子在比較的情況。
2. 從CV上的專案進行地毯式的整理。
首先掌握自己的作品集、專案上所使用的技術，是讓面試立於不敗的基礎。準備階段可以按照下列框架整理CV上列的產品或專案：
- **背景介紹：**研究主題、合作對象、應用(Application)的介紹、原本產品的tech stack
- **專案挑戰：**過去的舊技術哪方面無法滿足？使用的情境上出現了什麼變化導致的？
- **解決方案：**採用什麼樣新的技術？為什麼選擇這個技術？預期有什麼效果？
- **實際成果：**預期與實際的成果有什麼樣的差距？你的客戶認為此專案成功嗎？如果還有更多時間，你會在哪方面改進此產品？
3. 暸解其他類似產品的架構並嘗試暸解為什麼這樣設計(nice to have)
閱讀科技公司的engineering blog可以學習到更多。在面試公司前，求職者也可以去找找其他國家/市場上類似領域的佼佼者，看看他們在處理更大scale的時候，怎麼去調整產品的架構以因應更大的流量。當求職者很明確掌握技術的概念、範疇後，詳加熟悉自己做過的案子，閱讀別家公司的案例將為你節省大量時間，加速成長與學習的速度。另外，同樣性質的產品在面對不同規模(scale)的狀態下，有不同的技術因應方式，求職者也可以利用這個機會瞭解面試公司目前處在什麼階段，以及加入後如何協助公司往下一個更大規模階段做好準備，這將是重要的價值輸出。
結論
透過技術廣度的面試官，公司能衡量知道求職者在此份工作目前的的戰鬥力是否都有達到平均水平。雖然不可能每個技術都有使用過甚至是鑽研過，但至少可以先廣泛地涉略，並知道其扮演的角色和解決了什麼樣的問題作為開始。
Writer: Jeff Fan
(NEX Foundation Europe Moderator)
Editor: Mia Lin
( NEX Foundation Engineering Product Manager )