前陣子剛換完工作，默默地深耕前端已經 7.8 年第五份工作，由於自己也是一直有在擔任面試官（默默地又要開始擔任了，有人想跟我當同事嗎哈），對於面試方式心有戚戚焉，來做個心得分享。
理想的前端面試應該要包含“基礎知識“，”應用能力“，”深入實作能力“。
我理想的面試流程大概是這樣：
今天履歷過人資這關後，履歷到我們 RD 面試官手中開始進行第一關 phone interview，接著發作業，最後是 onsite interview（人資再做進一步確認）。大部分流程都是先作業最後 onsite，不過考量到一些因素我個人認為也可以先 onsite interview 最後再作業，這取決於整個面試環節與這是一個什麼樣的作業。
phone interview ->作業->實作 或者 phone interview ->實作->作業
Phone iterview：
Phone interview 主要分成兩個階段，自我介紹與基礎技術問答。第一時間拿到履歷時，我會先花一點時間去看這個人有提供的 online 資訊(github/medium..etc. github 為主) 把他看過一遍，然後著重在有興趣或者與自家有相關的部分記錄下來（從最近的動態開始），聽對方到時怎麼描述邊紀錄。
1. 自我介紹階段：
- 了解對方的職涯：例如現在 2–3 年經驗的前端可能沒寫過 es5，可以先簡單問答並記錄下來，之後可能就不會聊到像是 var let const 怎麼出現解決什麼問題的演進，假如只寫過 vue，之後可能就會多問一些 es6, 甚至 typescript 的能力，可能本來是做 backend 在 2.3 年前轉來前端跳進 react 世界可能從 class component 寫到 function component with hook 等等之類。
- 了解對方的工作範疇：例如在提到前一份工作時，產品可能是 0–1 開發起來或是大改版或是進去維護舊專案，團隊可能是 2 個前端互相 cover 跑 sprint，或是專職於 team 內某部分專門做活動頁面等等，去了解對方近期的狀態。在對應其技術部分，例如專案上使用 graphql，typescript..等等記錄下來，做基本的瞭解，想深聊的可以 onsite 的時候再多聊一點。
2. 基礎技術問答：
一開始 phone interview 的基礎技術問答，我個人認為是只需要問一些很基礎且描述性可以回答的問題，簡單列一些，例如：
- “== 跟 === 的差異”
- “簡單描述 cookie 跟 localStorage 跟 sessionStorage 差異“
- “react 中 state 跟 prop 是什麼”
- stopPropagation 跟 preventDefault 是做什麼用，可以延伸描述 event bubbling 跟 event capturing
- ”git rebase 跟 merge 有什麼不同”
也不用問太多，這部分只是要確認我們的面試者不是來亂的 XD，並不需要問到太深的問題，電話上的問答有一個重點是，盡量問可以描述性回答的問題！有一些問題如
- “什麼是 BFC”
- ”box-sizing 有幾種”
- ”this 是什麼”
- “closure 是什麼”
- “callback 是什麼”
個人認為這類問題更好的方式是安排情境題讓對方解決，例如想考 box-sizing 就給一段錯誤的 code 告訴對方 ui spec 寬度要 300x100 請對方修正或是直接請對方直接寫，想考 let bind this 就把經典的 setTimeout + var with for loop 拿出來，甚至給錯誤的 react onClick function code without bind/arrow function 請對方修正並瞭解為什麼看對方了解多少，這樣的問題會比用問的請對方描述來得好！每個人的描述力不同，不太會形容或描述不清楚不代表他不會或是他不懂。想考這些部分可以直接視訊開 codeSandbox 這類工具或是請對方直接打 console 也可或是在後面的階段考。至於要考多還是考少視情況而定，一般而言只要時間夠我會希望能夠盡量多問些，這個階段的題目會比較偏基礎知識，確認對方前端的基礎能力。而重要的是雙向的來回！
有的公司可能會用一些線上考題來當作前測，我覺得也沒有不好，但很重要的一點是，考完事後的階段一起來檢視！有交流有來回深入了解才是測驗的目的，也能讓 candidate 感受到面試的用心。
建議費時：半小時~一小時
作業：
作業是個兩面刃，由於大部分人都是還在職時就開始找下一份（其實我個人覺得先離開再找也沒什麼不好，能夠有充分的準備時間也好安排，重點是密集面試會比較容易進入狀況）有的作業可能動輒需要一個下午的時間有的可能需要 6–8 小時，很少作業是 2 個小時內可以完成，我個人覺得不錯的作業如
- “實作 google timer 倒數/碼表”
- “實作 calculator 計算機”
- “實作 github search 相關”
- “實作 reuse calendar component“
上述的實作再加上一些些 ui spec，這部分主要是確認對方的應用能力，有的人可能沒有在經營 github，就很需要讓對方真的實作來看到對方的 code（也能辨識該人選 github 上的東西差異是否會太大），讓對方寫出他目前熟悉＆最滿意的 code 。除了團隊中特定想考得部分外（例如要求使用 state management，custom hook，可以明確設定一些得分與加分條件。甚至表示希望對方當作開發一個完整的專案去做（像是包含了 unit test / e2e test / storybook 等等），希望能夠在這階段真的看到對方的 code 與架構來評估。（補充說明一下得分與加分條件部分，有的工程師常常會自己覺得什麼需要什麼不需要，有明確的標準可以知道 candidate 對 spec 的要求是否會一一遵循，細心程度等等，沒做到的部分可以詢問原因來回，而完整程度也能看出 candidate 是否對我們有興趣）最後是希望能讓 candidate 公開作業放到 gihub，好處是對方也能增加自己 github 內容。（怕洩題可以平時準備好題目庫定期更換）
至於為什麼我會說先 onsite 在作業也可以呢？這是我個人看法參考看看，先寫作業有時可能好的 candidate 有很多好公司搶著要，而好公司通常面試也都不會太容易，想當然就會面臨作業海，這時候常常就會有取捨考量而被過濾。如果是先 onsite 覺得彼此契合，確認雙方都對彼此有興趣，onsite 後再做作業我覺得也是可行的，這樣如果 candidate 真的也對我們很有興趣的話，他一定也會努力去提高完整度完成作業！當然這樣反過的話，就要在多一步最後的核薪 onsite （或是電話）後續動作，會比較繁瑣一點。這次面試中有一間即是這種做法，有好有壞，提供另一種思維給大家參考。
建議費時：一個下午的時間約 4 小時~ 6小時
Onsite interview：
onsite 面試時我覺得也是要循序漸進，可以先考一些前端相關的知識看看使用者了解多少如：
- map 跟 forEach 的差異
- splice 跟 slice 的差異
- string 跟 number 相加減的行為
- shallow copy, deep copy 問題
- react 非同步修改 state 問題
- css reflow repaint
- typescript Omit, Partial, 擴充 type 相關
搭配白板能讓使用者慢慢進入狀況後再考深入的實作能力，而 Onsite 是最重要的階段，從對於前測的互相來回與確認到探查對方深入實作能力與最後的 match 確認，主要分為兩個部分：
- 確認對方的深入實作能力
這個階段許多公司會考許多深入實作的能力像是：
- denounce throttle 相關實作
- promise 相關實作
- compose pipe curry add 相關實作
- add(1)(2)(3) 長度固定 or 不固定問題
準備好一系列 test case 看你能深入完成到什麼程度。我覺得這個作法沒有不好，只是上述的東西基本上平時我們都有 lib 能用會去用，實際自己造輪子的情況我覺得比較少也比較不熱見，變成說好像前端面試必需要特別去準備這樣的問題（而這似乎是很熱門的考法，也許這算必備能力吧），如果真的要考這方面題目我覺得考到基本 case 就好。我個人更傾向考一些實際開發會遇到的問題，像是：
- 解釋一份舊系統 nodejs 中 存在者 callback 的寫法，請其將 code 轉成 promise 轉成 async/await 甚至搭配 promise all 一起考，甚至加上一些條件等等
- 給一份無拆分 component rerender 的 code 請對方修改（React.memo, useCallback）甚至是一份殘缺的 code 請對方完善到他覺得最理想的狀態
- resursive function 實作如設計長度不固定的 ul li tree，url 處理..等等
就算要考些經典題目如費氏數列也可以換個方式問（強者我前同事用白板畫樓梯去考讓 candidate 自己去找出邏輯最後發現是費氏數列）我覺得都是蠻好的考法。整個過程希望是雙向溝通來回的，就算對方解不出來也給予適時的幫助，即使沒完成也能對其講解交流（許多公司都會說希望可以當作雙向溝通來進行，有問題隨時可以發問，然而實際上進行時都還是會變成上對下一問一答，這部分真的很難做到很好，我覺得只要秉持一個原則，想像你們彼此是未來的 cowork 對象，應該不會用上對下的模式去做雙向溝通吧！隨便亂舉例例如說”當看到對方寫出“編成式的 code 時詢問對方有沒有用過 map filter reduce 之類，沒有的話提示參數是 callback function，在不會的話就直接寫出一些 code 請對方繼續往下或是讓對方 google 都行，如果還是不行..那就整個寫出來然後跳過吧！有時可能真的是暫時性失憶ＸＤ面試是雙向的，就當交個朋友吧！）
2. . candidate 與團隊 match 程度
既然是未來的 cowork 對象，彼此還是要去熟悉彼此吧（即使你只是擔任面試官，也為你的公司挑選適合 cowork 的對象吧）！我覺得好的 team 文化也是在這時候慢慢產生，每一個 candidate 都會為團隊帶來改變，長時間就會形成一個團隊文化，至於要形成什麼樣的文化，掌握在彼此手中。工程師百百種，不是說什麼樣特性的人是好或是不好，只能說合適或不合適，一間還在衝刺的 startup 可能想要找也有同樣熱情的人，而一間公司與組織已穩定的可能想要找心態已趨穩定的人，即使人資有做確認實際上合作的對象還是在彼此。相遇就是有緣，有緣一起工作就當交個朋友，理想的團隊氛圍是一種”大家一起“的狀態，一起為團隊著想朝同樣的目標前進。 形成一個好的團隊氛圍與文化，從面試開始！
建議費時：約 2–3 小時
作為面試官的角度：
當你面試的人一多，這些筆記都是能在事後比較或是一個記憶點！
- 隨時筆記超重要，而且先列好一些我們團隊會在意的部分不論是技術還是其他甚至定標準，題目可以團隊一起去討論出來（當然有的公司是有人專職面試官跟團隊無關，那就自己決定與衡量）主要是當面試的人一多，每個人的每個部分都列清楚才比較好做客觀比較，而不僅是感受上的比較。
- 掌握好面試節奏，很多時候超容易聊一聊就聊遠，例如當發現對方 react hoc render props hooks 一路玩或者更早期一點 state management 到 redux 到現在新的（現在不知道還有幾個人聽過 flux ?) vue2 propType 賭錯 vue3 typescript 改寫等等之類，搭配當時公司情況一聊遠很容易聊太多（最好設定每個主題每個環節的大約時間）或者說一個題目卡太久等等，還是要做好一個全面性的掌控與全面性的考量。
（其實現代前端已趨於穩定，隨著時代與長江前後浪推進，能這樣或會這樣聊的只會越來越少，不過這邊想補充的點是若一個 candidate 能在過去持續掌握自己領域上的大小事，相信未來也能持續掌握！這點絕對是加分。） - 若要找人的時候，建議密集一點安排面試吧！（但也不要排太緊，時間到只能強制說掰掰會給人一種面試制式化感受）盡量讓 candidate 之間的面試時序不要差太遠，否則非常容易造成用印象分去比較（筆記之重要）時間拉長前面的 candidate 可能也早已找到工作，持續的比較排出新的 priority ，而若沒有到很喜歡也不要硬要做選擇，減少妥協。
- 額外想提的部分是，面試官們從 HR 那邊收到履歷時，HR 應該要把對方的期待薪資隱藏起來，我認為公司對於職缺的 range 應該先訂好，而剩下的則是 match 程度決定核薪。如果面試官能看到 candidate 的期待，很容易會有一種先入為主的心態或是比較，薪資這部分我個人是傾向保密的，大家假如職等一樣在一定的 range ，那薪酬就是你與公司之間的事，避免一些新舊人的比較問題或造成更多人的問題。
總結：
其實打到這我有點不太記得自己當初想打這篇主要是想講什麼哈哈，這篇文章也是有空就編輯一下搞得有點沒重點頗為發散，主要是對目前的前端領域做一個整理與一些心得分享。其實前端的東西也蠻收斂，再硬的題目有心都找得到＆準備（我是比較懶的那一個, leetcode 大概 easy 20題..）整體來看，前端領域的薪資還是有持續在提升，每間公司願意或能給的上下限不同，端看你能夠達到 match 程度多少，希望在這塊領域上的一切都能繼續更好！
