2025 如何準備資深前端、全端工程師面試？

在把這次求職經驗寫成《2025 資深前端、全端工程師面試心得 — 日本求職經驗分享》一文的同時，也寫了這一篇來談資深工程師的面試準備。前一篇談的是具體面試時遇到的不同類問題。而這一篇則會進一步來談進到面試之前的準備。

因為筆者主要是面前端與全端的缺，沒有面純後端的缺，所以這篇的切入角度會是從前端與全端的角度來談。會先談「資深」是什麼，接著再基於這個資深的定義，分別來談不同類的面試準備方式。

與先前寫的文一樣，這篇僅是個人的經驗與觀點，讓讀者們有一個參考。每個人適合的面試準備方式可能不盡相同，推薦在讀這篇文時，要保有自己的獨立思考。

「資深」工程師的面試有什麼差別?

由於這篇是談資深工程師的面試準備，在最開頭想花一些篇幅聊，在職稱加上資深後，面試會有什麼不同。當理解這點後，就能更有效準備資深工程師的面試。

在《軟體工程師的職涯路徑概覽》一文有談到，資深跟初階工程師的核心差異在於，初階工程師的影響力侷限在個人層面，而資深工程師則需要展現出對團隊和組織層級的影響力。

如果要用表格簡單整理，大概會是像這樣

從上面的角度出發，即使同一個面試題目，面試官對於資深候選人回答層次的期待，也會跟初階工程師有所不同。

以技術問題來說，如果今天在面試中，面試官問到某個系統的設計，當今天能夠設計出如預期運作的功能，這很不錯，但只談這樣可能無法讓人感受到資深。同樣在談系統的設計，要能被認為資深，需要多去更完整考量不同面向，例如系統的複雜度 (多增加某個元件帶來的額外複雜度，是否真的值得?)、系統的可擴展性 (當今天這樣設計，未來要加東西或改東西是否容易)。

以行為問題來說，如果今天假如想再回答中強調自己的長處，如果談說自己擅長快速開發，這點很不錯，但是如果只停在這點，可能會讓面試官對於你是否已經達到資深程度，會有所遲疑。在同一個問題，如果去強調自己如何帶團隊、如何讓事情順利推動，如何因為自己的介入，不僅是自己動得快，而是能讓整個團隊都變快，這樣才可能被認為是資深。

回到這個段落拋出的問題「資深」的面試會有什麼不同，也因為更往團隊、高層次的角度，比起初階工程師的面試，在行為面試與系統設計面試的比重會提高許多。而如前面談到的，在技術知識點的面試，即使題目跟初階工程師的一樣，在回答的深度上也會被預期有所不同。

如何拿到資深工程師的面試門票?

在往下談各個不同面試的具體準備前，想再多聊一個可能不少讀者感到好奇的問題，那就是要如何拿到資深工程師面試的門票。特別在軟體工程求職市場高度競爭的時代脈絡下，很多人即使履歷上的年資已經累積數年，還是沒能拿到資深工程師的面試，這是為什麼呢?

回到上一個段落談的，能否被認定為資深，關鍵不在於年資多寡，假如一個人有十年的經驗，但是這十年都在做一樣的事，那麼這種有十個一年經驗的資歷，跟一個僅有一年經驗的人基本沒有差別。因此，在這種狀況下，即使有十年經驗，也很難拿到資深工程師。

那麼，要如何確保自己有逐步往資深邁進呢? 筆者認為最有效的方式，就是好好把握那些讓你覺得有挑戰性的事。

在工作中，假如一直是解決已經得心應手的事，能在過程中獲得的成長就會有限。反之，假如能去不斷挑戰那些自己還不擅長、可能沒有十足把握能做好的事，在過程中即使會有一些不舒適，往往在完成後獲得的經驗，就是能讓自己更上一層樓的經驗。

以筆者自己為例，過去一年在工作上遇到的不少任務，是有挑戰性到自己覺得沒把握的。舉例來說，有一個任務是要維持 CI 中的視覺回歸 (visual regression) 檢測，但同時要降低在這部分的成本。筆者在那之前只有用過視覺回歸測試的工具，但沒有做過減低系統成本的事情，對於能不能做好沒有把握。

但那時看到這個需求時，還是主動跳出來說要解決，而事後也因為解決這個問題，累積到在履歷上能夠展現資深的經驗。具體來說，不只透過調整 CI 設置降低自己團隊在視覺回歸快照的運算成本，還進一步把該解決方案分享給公司其他團隊，讓影響力擴展到公司層級。

另一個沒把握但後來有做出影響力的例子，是協助團隊導入 AI 工具提升開發生產力。一來筆者本身不是 AI 專家，也不是生產力專家，二來很多工程師對於自己使用的工具，都有很強烈的觀點，要有效讓大家換工具，不是那麼容易。

雖然不是專家，且推動這種工具轉換本身有難度，但因為筆者自己對於透過 AI 提升生產力這個主題很感興趣，所以那時得知有這個任務時，也是主動說要去做。在經過一陣子的努力，也順利在團隊建立起 AI 輔助的工作流，讓至少 30% 的繁瑣事務被自動化，讓團隊整體產出提升不少。而這個經驗也成為筆者履歷中的亮點之一。

透過上面兩個例子，想談的是如果在工作上，主動去爭取那些有挑戰性的事，自然能累積出能拿到資深工程師面試門票的資歷。當然，最理想的狀況，是做的事情對你來說不僅是有挑戰性，還是你自然而然想投入而不自覺的 (以筆者來說，上面推動 AI 工具導入的就是)。當能夠找到這樣的事情來解決，就能在愉快的狀況下，逐步累積出資深的經驗。

希望讀到這裡，讀者們對於如何累積出「讓自己能拿到資深工程師面試門票」的經驗，有更具體的理解。往下讓我們具體來談，當今天通過了履歷關卡的審核，實際進到面試階段，可以如何做準備。

如何準備知識點面試

在準備知識點相關的面試時，有個核心的點需要注意，就是「即使題目一樣，資深的回答會不一樣」。具體來說，比起初階工程師的面試，要能展現自己是資深工程師，會需要回答更深入。

以前端的知識點題目來說，當被問到「事件迴圈（Event Loop）」時，不要只解釋基本的非同步概念，而是要進一步解釋 setTimeout、requestAnimationFrame 等 API 在事件迴圈的運作中扮演的角色，以及在實作中可以如何運用這些 API 解決特定問題。

以全端的題目來說，筆者在這次面試就有被問到跟 RESTful API 有關的問題，如果在講自己對 RESTful 的理解，是這樣介紹

「RESTful API 是一種設計風格，用來建立可靠、可擴展的網路應用程式。它主要基於 HTTP 協議，使用 GET、POST、PUT、DELETE 和 PATCH 等方法來執行不同的操作。RESTful API 還有一些限制，比如無狀態、客戶端—伺服器架構等。

此外，API 的回應中的 HTTP 狀態碼也是很重要的，2xx 表示成功，3xx 表示重新導向，4xx 表示客戶端錯誤，5xx 表示伺服器錯誤。在設計 RESTful APIs 時，我們需要遵循一些設計原則，比如使用單一資源路徑來表示資源，使用合適的 HTTP 方法，以及使用適當的 HTTP 狀態碼來回應請求。」

基本上沒有什麼問題，但是可能無法被認為是資深的回答。如果要能被認為是資深，會需要談到更深入的點。

舉例來說，可以談：

「RESTful API 是一種設計風格，可用於 CRUD 操作。對於複雜事務，RESTful API 可能會變得過於複雜和難以使用。這時候需要考慮使用其他設計模式，比如 GraphQL ，以滿足不同的需求。

為了優化效能和安全性，我們可已透過快取提高 RESTful API 的效能，通過將常用的資料存在快取中來做到。另外，壓縮可以減少 RESTful API 的流量，這可以通過將資料壓縮為更小的格式來做到。另外可以加上安全認證，來保護 RESTful API 免受未經授權的訪問。」

又或者，可以從冪等與向後兼容的角度來談 RESTful API 的設計。以冪等來說，可以談：

「RESTful API 來說，有些請求相對不用擔心冪等性問題。舉例來說，GET  請求就是，因為假如某個資料存在伺服器，不論請求幾次，資料沒變的狀況下，就會都拿到一樣的資料。

PUT  也是，因為  PUT  是一次修改整個資源，假如有多個請求送來，就以最後送到的請求即可。同樣地  DELETE  刪除某個資源後，就沒有該資源，多發幾個過來的結果都是該資源被刪除，所以也是冪等。

然而，我們很常用的  POST  請求會是相對需要特別處理的。就像電商下訂單時的支付，通常會是用  POST  請求。而最常見的冪等處理方式會是加上冪等鑰 (idempotent key)。所謂的冪等鑰，是一個獨特的  id，讓伺服器端知道這個請求已經被處理過了。所以如果有網路中斷，或者使用者快速連擊，當同一個請求帶著相同的冪等鑰，伺服器端就知道不用再處理該請求。」

可以看到，同樣是 RESTful 的回答，可以很粗淺地介紹，也可以針對實務上要注意點的深入談。而要能夠展現資深，深入談是不可或缺的。因此推薦想準備資深面試的讀者，在準備回答不同的點時，務必要問自己「這樣的回答有足夠的深度嗎?」

除了深度外，完整準備各類常見問題也很重要。在題目準備的部分，推薦可以參考 ExplainThis 先前寫過的前後端面試題庫，以及前後端面試題詳解。想要看更深入的技術知識內容，可以參考 E+ 成長計畫的主題文。

如何準備程式面試

程式面試基本上是不論前端或全端的缺，一定會出現的面試類型。前端程式題通常會要求候選人手寫 JavaScript 函式。在練習時，推薦務必練習常見的 JavaScript 方法：例如 map、filter、reduce 等陣列方法，以及 debounce、throttle 等效用函式。而後端的程式題基本上是以資料結構與演算法

想要多練習不同類的題目，可以參考一些前端題庫，例如 ExplainThis 前端 50 題或 GreatFrontEnd 前端題庫 ，這些題庫提供了大量的練習題和詳細解答。至於資料結構與演算法的練習，首推 LeetCode 上多做題目，要聽講解的話則是推薦 NeetCode 的頻道解說。

程式面試在檢驗什麼？

在準備程式面試時，一個關鍵是要先釐清「程式面試的核心不僅僅是檢驗你是否會寫程式」。軟體工程不僅僅等於寫程式，程式面試本身也在檢驗你作為軟體工程師的其他能力。根據 Meta 公開的面試準備手冊，程式面試會特別檢驗四個主要點，其中只有一個是程式能力，其他三個點則是軟體工程中非常重要的能力。

程式以外的能力包括：

1. 溝通能力 (communication)：是否針對需求進一步釐清? 是否持續保持溝通對話，還是只是埋頭寫程式碼？
2. 問題解決能力 (problem solving)：如何理解和解釋複雜的概念? 能否解釋思路 (而不是背誦答案)? 能否提供多種解法、是否有討論不同解法的時間和空間的複雜度? 是否能對的解法進行優化?
3. 驗證能力 (verificaiton)：是否充分考慮了測試案例? 能否提出充分論據證明程式碼的正確性? 當解法有錯時，能否梳理自己的邏輯、找出錯誤？

這些能力都體現了軟體工程師在團隊合作中的重要品質，因為軟體工程往往需要多人團隊的合作，且需要持續的溝通與協作。以下分別講可以如何展現如何展現這些要點。

如何展現溝通、問題解決、驗證能力?

要能展現溝通能力，最直觀的方式就是在過程中保持與面試官的溝通，非常推薦在整個面試的過程中，可以透過一些框架句型，作為銜接讓自己能夠有效溝通自己的思考。

舉例來說，當你準備要寫某段程式時，不要只是低著頭寫、什麼話都不講，可以說 I'm considering using a XXX here because… 讓面試官知道你接下來打算做什麼。又或者假如你寫到一半卡住了，也不要沈默不語，可以說 I'm encountering a bit of a roadblock here. Let me take a moment to gather my thoughts and see if I can figure it out。

更多關於在程式面試溝通過程可以用的框架句，推薦可以讀《技術面試白板題如何溝通？常用框架句型總整理》一文。

要能夠展現問題解決能力，一個核心要點是，在面試中看到題目時，不要馬上跳下去解題，而是要先釐清問題。釐清問題可以讓面試官看到你有問題解決能力，因為你會先確保自己理解正確的問題，而不是直接開始解題。

以下是一些可以問的問題：

• 確認題目理解：將面試官講的題目重述一遍，問是否理解正確，這樣可以避免因為理解錯誤而浪費時間解錯的問題。
• 輸入與輸出：確認對輸入與輸出的理解是否正確。
• 特殊情況：問及題目是否有特殊限制，例如時間複雓度或空間複雓度的要求。
• 極端案例：確認是否有需要處理的極端情況，例如正負無限、NaN 等。
• 輸出形式：確認輸出的形式，例如是否需要回傳多個解，或者是否只需要回傳其中一個解。

至於如何展現驗證能力呢? 最簡單的方式就是寫完程式碼後要驗證，dry run 是在這時可以用的技巧。所謂的 dry run 是指在寫完程式後，先用手動的方式，一步一步地執行程式碼，藉此模擬程式的執行流程和驗證程式的邏輯。

具體如何 dry run?

• 從簡單的輸入與輸出開始：先用基本輸入值，走過程式碼
• 逐步增加複雜性：接著引入更複雜或極端案例，來確認程式都能處理這些狀況
• 邊想邊說 (think out loud)：在逐步執行程式碼時，口頭說明您的推理和計算。
• 及時調整：如果在 dry run 過程中，發現程式碼有錯，或者有沒考慮到的情境，遇到錯誤，當下及時調整；如果在 dry run 時有想到更好的解法，也要馬上與面試官溝通

不要從第一題練到最後一題

雖然在這段落的開頭有談到「多練習題目」，但是練習技術面試題目時，勁量避免從第一題開始刷，一路刷到第 100 題、第 200 題，因為這種做法是非常沒有效率的。畢竟很多時候，某個類型的題目你已經很熟悉了，這時候如果你再花時間去做更多這種類型的題目，效益是非常低的。即使你沒有多做這些題目，可能你在面試時遇到這種類型的題目還是能順利過關。

因此，比起從第一題刷到最後一題，更好的做法是針對自己不擅長的題型去特別練習。舉例來說，可能有些人特別擅長處理陣列相關的問題，但不擅長處理圖或其他資料結構類型的問題。那麼當你在面試時發現自己遇到圖或樹相關的問題時總是卡住，導致無法通過面試，這時候你就應該花時間去針對這些不擅長的題型加強練習。

如何準備系統設計面試

要準備這塊，系統設計面試推薦可以參考 GreatFrontEnd 的系統設計內容。而行為面試就是參考上面提到的那篇。

系統設計面試通常會要求你設計一個系統，例如短網址系統、聊天系統或金流系統。這類面試多半不需要寫程式，而是要求你根據需求提出宏觀的架構，並針對技術細節進行深入討論。

以 Meta 官方準備指南提到的，面試官在系統設計面試主要檢驗以下四個方面：

1. 面對模糊需求的能力：能否在模糊的情境下釐清需求。
2. 提出解決方案的能力：能否根據需求提出對應的架構。
3. 深入探究的能力：能否針對提出的架構進行深入的技術討論。
4. 技術溝通能力：能否在整個過程中與面試官保持良好的溝通。

如何在面試中做到核心要點？

在了解完系統設計面試的要點後，在準備時就可以針對這些要點來準備，以下談分別可以怎麼做。

面對模糊需求，釐清需求

在系統設計面試中，面試官通常會故意保持題目的模糊性，以檢驗你是否能主動釐清需求。這包括功能需求和非功能需求。

功能與非功能需求的區別如下：

• 功能需求：系統最基本的功能，例如社群媒體的發文、瀏覽動態等。
• 非功能需求：系統在極端情況下的表現，例如高流量下的穩定性、一致性等。舉例來說，社群媒體的非功能需求可能包括在名人發文時，如何處理瞬間的高流量推送。這類需求雖然不影響系統的基本功能，但在實際應用中非常重要，也是能展現技術深度的地方。

在釐清階段，確認沒有解決錯誤題會很關鍵，推薦可以看 ExplainThis 寫過的《系統設計時要避免的 3 個誤區》一文。

根據需求提出架構

在釐清需求後，需要根據需求提出對應的架構。在討論整體架構時，可以先著重在確保功能都有被照顧到；非功能需求的部分，可以在深入設計的部分討論。換句話說，在架構設計的階段，盡可能用全局觀來看，先不要在某個細節深入，因為那會是後面深入優化該做的事。

你可能會問，要如何展開整體架構呢? 假如你沒有方向的話，推薦可以從核心要件開始，所謂的核心要件，是指能夠滿足功能需求的要件。以動態牆系統來說，要構成一個動態牆，使用者會需要追蹤其他人，然後才能在動態牆上看到其他人的貼文；因此最基本的核心要件會包含使用者、追蹤、貼文。

當然你可以說，現在的動態牆會有廣告、或者有自己追蹤的粉絲專頁，要不要在架構中放入這些，端看在前一步驟的需求釐清，是否這些有被算在範圍中。

在理清楚核心要件後，可以往下討論如何設計 API 來完成這些核心的要件。以動態牆來說，會需要有獲得貼文的接口、張貼新貼文的接口、去追蹤其他人的接口。同樣地，在這邊要不要細到討論各種接口，也是需要先釐清。例如新增貼文與獲取貼文是基本一定要有的，但修改與刪除可能不一定是。

有了核心要件、以及針對核心要件設計完 API 後，就可以開始架構。一般來說，推薦用圖像方式表達架構，會比較清楚好懂。

針對關鍵點深入研究

在提出架構後，需要針對關鍵點進行深入研究。這包括技術上的取捨，這是因為在現實世界中，基本上沒有一種技術可以完美解決所有問題。多數情況是需要面對權衡取捨 (trade-offs)。因此在深入設計的討論中，很大一部分是要面對取捨。而要能有效做好取捨，就會需要知道什麼重要 (要取)、什麼相對沒那麼重要 (要捨)。

想要做好取捨就需要有切入角度，舉例來說，CAP 理論就是一種切入角度。以 CAP 理論來說，在系統設計時，推薦第一個可以去思考該系統的需求下，一致性 (C) 與可用性 (A) 之間要如何取捨。當有了取捨後，就有向下深入優化的方向。

舉例來說，在一個搶票系統中 (例如設計一個搶票系統的題目)，針對票券販售的特性，我們可以推得一致性比較重要，因為如果沒有顧好一致性，可能導致一張票被兩個人買到，這會造成後續營運處理的麻煩。當有了這層思考後，就能往下去討論如何設計一致性高的系統。

相反地，在一個動態牆系統，可用性會比較重要，因為動態牆的商業模式是展示廣告，高可用意味著能時時展示廣告。先前 Facebook 全球大當機時，就有人去估算在當機期間 (不可用的期間) Facebook 的廣告收益損失有多慘重。

而在動態牆中，一致性就相對沒那麼重要，你按了某個貼文的讚，其他人隔十秒二十秒後才看到，對於使用體驗影響不會到太大。所以在這種狀況下，要優化自然就可以往高可用去思考。

如何準備行為面試

如前面的段落談到，資深跟初階工程師的核心差異在於，初階工程師的影響力侷限在個人層面，而資深工程師則需要展現出對團隊和組織層級的影響力；在行為面試上，這點是特別關鍵的。

更進一步說，行為面試是許多公司會用來判斷一個候選人是否為資深的關鍵。換句話說，同樣通過了技術面試，一個候選人能拿到中階或是資深的工作邀約，會是由行為面試來決定。

先前在 ExplainThis 有《如何在行為面試讓人覺得你像資深工程師？》以及《面試時如何讓面試官覺得你有洞見？》在談如何可以在面試時展現資深，推薦讀者可以一讀。

在準備面試時，因為題目很多，所以更推薦練習一個故事多個切入角度。舉例來說，下面這些變化，完全可以同一個故事回答：

• 請分享一個你做過最有挑戰的專案
• 請分享一個你感到最引以為傲的專案
• 請分享一個你做過技術上最困難的專案
• 請分享一個你過去印象最深刻的專案
• 請方想一個你過去做過最喜歡的專案

除此之外，針對不同的公司，也推薦有不同的回答策略。舉例來說，同樣是問到「過去工作上碰到的問題與挑戰」，面對大公司，可以多分享遇到要解決不同極端情境的挑戰，因為大公司通常做的產品是全球化，即使極端的狀況也可能很多使用者會遇到。但是，如果是面對新創公司，可以多分享如何快速解決某個問題，因為在新創的領域，速度快很重要。

如何準備「你有沒有什麼想問的問題?」

在多數的面試中，最後面試官多半會問「你有沒有什麼想問的問題?」，推薦務必要把握這個問題，因此好好準備這問題很重要。

這個問題之所重要，主要有兩個原因

• 展示對公司和職位的興趣：當你提出問題時，可以展現你對公司和職位的興趣與熱情。如果你說「我沒有問題」，可能會讓面試官覺得你對這份工作缺乏興趣，進而影響你的面試結果。因此，至少要準備兩到三個問題，展現你對公司的了解與思考的高度。
• 收集資訊，反向篩選公司：面試是雙向的，不僅是公司在評估你，你也在評估公司。特別是在你有多個工作機會時，如何選擇最適合的公司非常重要。透過提問，你可以收集關於公司文化、團隊運作、未來發展等關鍵資訊，幫助你做出更好的決定。

在準備這問題時，有些問題推薦問，有些則不推薦問。

推薦的問題會是在了解完該公司的相關資訊後，針對相關資訊的點提問。前 Amazon 的工程總監 Dave Anderson 寫過一篇《Questions to Ask at the End of an Interview》，非常推薦一讀，有很詳盡完整的解說。

而以筆者自己的經驗來說，特別推薦在面比較高階的技術主管時 (例如 Director 或 VP)，可以問 「目前團隊有遇到什麼技術挑戰? 如果我有幸加入，期望我能協助解決什麼問題? 帶來什麼面向的貢獻?」以及「最近公司發布了 XXX，這個產品的願景與五年規劃是什麼?」，

問這個問題，不僅僅是讓你能展現對公司的興趣 (畢竟有興趣才會好奇)，也能展現你已經開始站在公司的角度幫忙想解決問題。這兩點都會在面試官心中留下好印象。筆者實際面某一間上市公司的 Director 這問題時，對方聽到後很開心說，因為本來就期待候選人問這問題。而也因為問這問題，後來跟該 Director 有針對這點多聊，可說是相談甚歡。

不推薦問的問題則是「能輕易找到資訊的問題」，容易能夠找到的資訊，也都推薦不要問。例如公司有多少人、規模多大，這種除非是在新創公司，不然一般大公司都輕易在網路上查到，就推薦不要問。這種顯而易見的問題，問了反而會讓人覺得沒有做功課。

除了上面提到的問題外，先前讀過 PostHog 創辦人寫的《The really important job interview questions engineers should ask (but don't)》一文，談了針對新創公司面試時應該問的問題，特別是關於市場與產品契合點（PMF）的問題，覺得非常精闢。推薦在準備面試新創公司的人一讀。

閱讀更多

以上分享了準備資深前端、全端工程師的心得，如果有興趣閱讀更多內容，或者觀看線上課程。我參與的 E+ 成長計畫中，有一門長達 8 小時 57 分鐘的《軟體工程師求職全攻略》課程，推薦感興趣的讀者可以加入觀看。

課程中會涵蓋找職缺、投履歷、面試準備，再到談薪水等內容。此外，如果觀看線上課程時有任何問題，也都可以在 E+ 的專屬 Discord 社群中提問。另外 E+ 也有專門的履歷健檢頻道，讓讀者們可以問到飽、改到好。

感興趣的讀者，可以點此了解 E+ 的詳細介紹