2017 年前端面試心得

前言

終於有時間整理最近的面試歷程了。先總結一些看到的事情：

1. 通常公司面試只考 Javascript 的熟悉度，多數關於演算法或是解釋原型鍊等等，很少考 DOM 或是 Event 的操作。
2. 幾乎不考 CSS，就算有也只是簡單判斷 class、ID 優先度這種基本題目而已。
3. 沒有面試考 HTML，例如 semantic tag、accessilbility、input type 使用等等。
4. React、Redux、ES6 語法幾乎成為前端必備技能，Angular 比較少公司採用。
5. 普遍的獵頭都不夠專業，也有可能是太菜了還沒被專業的獵頭找上

以下是這次面試的公司：

1. Accupass
2. Codementor
3. Linker Network Inc.
4. 樂天市場
5. 17 media

背景

國立科大資管系，目前已經有兩年工作經驗。平時專注在前端開發，接觸 React、Redux 開發約兩年的時間。除了一般的前端「工程」之外，自己也很喜歡畫面的實作與互動，同時也有在自己的小專案當中練習後端的知識，像是 AWS、Lambda、nodejs、資料庫、機器學習等等，不過最熟悉的還是前端相關。

期待的工作環境

1. 能夠和前端團隊一起合作。之前的工作經驗因為前端開發都只有自己一人，所以比較難討論特定的前端技術
2. 不會有太多突發狀況。像是突然就改需求、砍掉開發中的產品、因為人情而被迫開發的案子等等
3. 有主產品以及明確的服務
4. 技術含量高，可以和優秀的團隊一起共事

找工作的管道

• inside jobboard
• yourator
• 104 人力銀行
• f2e jobs
• PTT Soft_Job 版

1. Accupass 活動通

應徵職位：Frontend Developer

一個活動票券的網站，最近正在將架構從 Angular 改寫為 React，原因是原本的 Angular 較難維護，而且很容易產生牽一髮動全身的情形。

面試前

在 104 上被邀約面試，是由 PM 邀約面試的。

面試中

團隊正在擴編。面試主要聊一些自己的工作經驗以及一些小項目。當天面試我的前端工程師是一位日本人 XD，但是中文講得很好（全程都是中文面試）。

聊了關於 Accupass 的開發狀況、如何開發功能、管理時程等等，也和前端工程師聊技術，從 CSSModules、RxJS 聊到 CycleJS，感覺是個對前端技術很有熱忱的工程師。

面試結果

婉拒 offer。

PM 相當希望我能夠加入 Accupass 團隊，婉拒後也撥了通電話詢問原因，並提及如果以後有機會希望能夠一起合作。不過由於其他職位更吸引我，所以拒絕了 Accupass 的 offer。

2. Linker Network Inc. 美商寶蘊凌科網路科技有限公司

應徵職位：Frontend Developer

專門做 IOT、AI、機器學習的雲端運算平台，因為這些 platform 需要 UI 的支持，所以需要前端開發協助。官網還蠻簡陋的，看不出個所以然，不過做的事情技術含量很高。

面試前

在 104 上主動投遞履歷，被電話邀請面試。這間公司做的技術含量很深，也有在線下辦一些社群。

面試中

感覺得出來是個蠻技術含量很紮實的公司。自我介紹談了一下過去的工作經驗，以及用 React, Redux。

我之後才知道原來當初面試我的是 c9s ，想說怎麼那麼眼熟。感覺得出來是位大大，技術的掌握度很深。（不過本人看起來比較憔悴）

面試時考了些偏優化的題目，像是：

1. js 如何做 minify？ 這題是要你大概解釋一下 js minify 的過程，最後簡化到如何消除程式碼中不必要的空白。這題的想法很簡單，不過實作起來有一些細節要注意，當時沒有想很多，被提示很多次才寫出來
2. 前端效能優化可以怎麼做？ 提了一些常見的方式，不過感覺沒有很合面試官的胃口。像是 base64 編碼減少請求數、快取、ServiceWorker 等等。
3. 如果要你做一個 SPA 的 framework，你會怎麼做？ 如果要我做，首先要考慮的是 router 的處理方式，畢竟 SPA 需要依靠前端做 router。後來被提醒了還要考慮 lifecycle 的問題
4. 一些 Javascript 的問題
5. 原形鍊的原理
6. new 背後發生了什麼事？
7. 如何實作繼承
8. this 指向誰

最後由一位看起來是主管的人跟我談一些公司現況、未來發展等等。

面試結果

無聲卡（到現在已經三週），大概是太菜了吧 QQ

3. 台灣樂天市場

應徵職位：Frontend Developer

之前有參加過一次面試，不過因為沒辦法提供全職的上班時間（也不確定是不是）。所以重新又投了一次。辦公室的氣氛跟一般大公司差不多，要有員工證才能進辦公室。

面試前

HR 聯絡，寄給我一張身家調查表以及程式考題。上頭的格式大概跟 104 履歷差不多。這邊我想特別講一下他們的面試邀約信。

一般的公司通常在信上附上地址，不過樂天市場會把一些重要的地標標示出來，例如 XX 號出口、在 XX 銀行上面、出電梯右轉等等，雖然這是一個微不足道的提醒，但對面試者來說很有用，畢竟誰都不想在大太陽底下看 google map 還不小心走反方向。

面試中

這次的面試比起以前好像又更制式一些，還要寫智力測驗跟人格測驗的考卷，考一些類似加減乘除之類的題目，我好像還錯了幾題 XD。整個面試流程又因為這樣拉長了一些時間。

跟工程師面試的過程蠻愉快的，主要也是聊一些工作經驗以及對技術的了解，兩位工程師感覺也是技術很強的大大。有一位工程師之前已經面試過我，跟我說「我對你的技術能力沒有太大問題」，但是因為卡兵役的關係還是被 reject 掉，整個很感動 QQ。

後來我還發現原來有一位就是 react-bootstrap-table 的 creator。

面試主要考了一些 Javascript 的東西，像是：

1. 遞迴以及實際應用 例如有一題反轉字串，主考官叫我用遞迴實現，並問我好處是什麼。我想破頭也想不出來，網路也找不到答案。
2. 閉包與實際開發應用
3. IIFE（立即執行函式） 的好處 我舉了幾個例子，不過後來一位工程師跟我分享 jQuery 的原始碼，說用 IIFE 的方式也可以有效幫助 minify（因為把 window 參數化了），這招倒是我以前從來沒想過的。
4. React、Redux 的開發場景應用 考一些 Redux 常見開發情景、管理 store 的方式、react lifecycle 的應用
5. （更新）如何不用 + 實作加法功能 這題考對 bit operator 了解。透過 XOR 可以做到，高中的加法器有教 XD，不過還是要畫一下真值表。
6. （更新）台灣樂天市場有一句令我印象深刻的標語：複雜的東西簡單化、簡單的東西流程化、流程的東西標準化、標準化的東西自動化。（不確定原文是不是這樣）

之後問了一些比較工程化的問題，像是 CI/CD、如何跑開發流程等等，樂天市場的技術線蠻多的，Angular、React、RoR、GraphQL 都有。

面試結果

因為還是資格不符，所以基本上應該是被淘汰。不過前端 team 感覺得出來相當紮實，兩位工程師除了前端外都有其他領域的開發經驗，而且相當友善，面試結束時還請我喝了一杯飲料（雖然是公司的販賣機啦 XD），也給了我很多關於職涯上的建議。

4. Codementor

應徵職位：Frontend Developer

做一對一的線上 mentor 的服務。衍伸出來許多服務，像是線上 code review、debug、pair programming 等等。

面試前

因為技術含量高，而且面對的對象又是工程師，想說是個很好練功的地方，在 104 上投遞履歷，隔天收到 HR 線上面試邀請。我還蠻喜歡線上面試的，不用額外跑到公司一趟對工程師來說實在是一大福音啊！

面試中

第一階段  —  工程師面試

跟 team lead 面試，聊一些過去的工作經驗，問了一些開發上的問題。口頭考了一些 javascript 跟 react 的理解

1. 閉包
2. flux v.s MVC 解決了什麼問題：老實說我沒有實際用過 flux，只有看過架構圖跟 code，所以只能靠自己的理解來回答
3. javascript 是如何做到非同步的？談對 call stack 跟 event loop 的理解

第二階段  —  與 co-founder 面試

一樣在線上跟 co-founder 聊天。這個階段比較少提技術的部分，自我介紹完了之後，他對我的一個 side project 好像很有興趣 XD，問我當初成立的動機以及為什麼沒有把它變成完整的服務。有好一段時間都在談這個小專案，也有談到 code mentor 也有在做類似內容平台的服務。

後來問了一些 code mentor 的歷史以及一些團隊文化。總共約 30–40 分鐘左右

第三階段  —  與 CEO 面試

CEO 人在 California，一樣在線上面試。主要也是聊一些自己的工作內容跟開發經驗以及一些關於人格特質的問題。應該是希望從對談當中聊聊彼此之間的契合程度吧！總共約 30–40 分鐘左右。

因為 code mentor 的 co-founder 以及 CEO 都是工程師出身，聊起來相當愉快，不會有種從上往下看你的感覺。

他後來問了一題「你覺得你自己是個聰明人嗎？」。我回答不是，看過越多的程式碼與演算法後更是如此覺得。

自己可能一輩子都沒辦法設計出像 React 那麼龐大的架構，或是各種排序演算法等等，怎麼想都不覺得自己很聰明。

面試後

約五天後被婉拒，好像是找到更 senior 的前端。code mentor 給我的感覺相當愉快，不管是 CEO 或是 team lead 都給我一種對自己產品相當有熱忱的感覺。希望未來還可以跟他們一起合作。

5. 17 media

應徵職位：Frontend Developer

這應該是我目前面試過最愉快的一間公司。從 f2e jobs 上看到徵才資訊，一直猶豫要不要投履歷，後來是朋友推薦後獲得面試邀約。

面試中

因為 team lead 是用下班時間面試 18:30。我很準時到達辦公室，team lead 也很準時出現在辦公室。這點讓我很欣賞。

有些公司因為不確定面試者什麼時候來，所以多數都是工程師還在工作的狀態下突然被通知要面試才匆匆忙忙準備相關資料，或者臨時看一下履歷表。問了一下目前到現在面試幾個人了，他還特地秀出 slack 的訊息，還順便註記了幾個人遲到。是個相當重視時間的人。

剛開始先由 HR 帶領晃過公司一圈。辦公室挺大的，零食櫃跟冰箱很猛，還有咖啡機、咖啡豆、微波爐等器具，聽說 RD team 還有另外一間辦公室，不過當天去的情況看來還是有點擠。

再來是 team lead 面試，首先先自我介紹跟講一些工作經驗。

一邊聊一邊帶到目前公司、團隊的狀況。感覺起來是個蠻保護團隊的人。之後就是 live coding 了，為了模擬真實的情況，所以不會斷網路，主要考一些 javascript 常見開發應用跟 built-in function 的實作。

寫出來之後，team lead 就會從你寫的 code 當中開始討論技術。像是這邊為什麼要這樣寫，有沒有更好的寫法等等，他花了很多時間在討論、問問題以及提出自己對這段 code 的意見，感覺就像實際在 code review 一樣。這邊也花了最久時間，大概也有 1.5hr 左右吧。

最後會給你一段髒髒的程式碼要你做 code review 跟解 bug，一起討論完之後，面試就結束了。

出辦公室的時候大概已經 21:50 幾分了吧，他很有耐心都一直在旁邊做事。比較讓我印象深刻的是我們一起討論 \B 的用法，這是很少人會去理解的正規表達式，所以討論完原本的答案後，我就請教他 \``B的用法。

他很有耐心地從 \b、\w 到 \B 一個一個解釋，直接解開了我長久以來的疑問。（網路上很少把 \b 解釋的很清楚）

他給我幾個感覺：

1. 真實：不會隱瞞公司的狀況，讓你進來後覺得被騙，而且過程中不經意會講一些工作上遇到的無奈與感嘆，感覺已經看過不少風雨。
2. 真誠：不會用很奇怪的考題來電人，還會跟你一起討論 code quality、這段 code 要如何改進。這在面試當中是一件相當難得的事情。再來我跟他提到因為辦公室太大讓我不知道一進門要找誰時，他說會再反映給 HR。原本我以為他只是說說而已（畢竟大部分的公司也都是聽聽而已），沒想到他真的有跟 HR 反應，讓我非常感動。

面試結果

offer get。HR 打電話來說明 on board 相關流程。

面試心得

面試真的好累 QQ，如果可以的話實在不想到處奔波，全部採用線上面試，非常符合 lazy engineer 啊！

這次面試除了「找工作」之外，也見識到許多開發者，他們或許不常出現在各大社群當中，但是論實力跟涵養，都遠比某些在社群上膨風的開發者來得深厚。並不是說參與社群是一件不好的事，還是有很多人為社群貢獻許多，不過線下也有許多人在默默奉獻，不應該用活躍與否來判斷一個人的實力。

這一次的面試除了「找工作」這件事之外，我學到的是  —  謙遜。在軟體開發的領域中有太多聰明人了，不斷在提醒著自己有多麽無知。

1. 履歷準備

因為我平常就有寫 medium 跟部落格的習慣，履歷表就能順便放進去。而且因為履歷表是放在 github 上，所以很容易更新。

2. 工作經驗

工作經驗並不是把公司名稱、職稱、年資寫進去而已，你負責哪些工作內容、在公司做了什麼事情，盡量寫得具體一些，例如：

• 用 React、Redux 管理複雜頁面開發
• 優化首頁 Loading 效能

就比擔任前端開發來得好許多。

3. Side Project

除了工作以外，如果有自己的 side project 就更好了，身為工程師一定會有自己想要動手解決的問題。

可以讓面試官知道你喜歡的領域以及技術線，每個專案當中一定會有一些特定的問題是困擾你很久或是花了許多時間解決的。

4. 多問問題

面試應該是個你來我往的雙向溝通，而不是一場你問我答的標準流程而已，知道如何反問對方，也能夠增加對公司的了解程度。

通常我都會問一些公司內部的問題，主要會針對這幾個方面問：

1. 有沒有自動化？ 很多公司都還是土炮手動 SSH 登入部署。這種開發方式很可能間接一步反映到公司文化上，例如：申請預算流程繁瑣、對能夠自動化的東西視若無睹。
2. 如何解決 bug？ 解決 bug 的方式可以看出公司如何排程。例如 bug 怎麼被回報的、誰來決定 bug 的優先度等等，通常從對方的回答就能判斷他們是否有一套規範來決定如何排程的
3. 需求是否常常變動？ 從需求變動這個問題來看可以從很多角度切入，什麼是常常變動？在什麼時候變動？怎樣才叫做變動？這時候就能看出這間公司是否會出現明明開發時說 A，結果交差卻說 B 的情形了。

接下來就是從這上面延伸出來的回答繼續追問了，通常看面試官的回答程度大概就知道這間公司的內部情形了。