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 公开的面试准备手册，程式面试会特别检验四个主要点，其中只有一个是程式能力，其他三个点则是软体工程中非常重要的能力。

程式以外的能力包括：

沟通能力 (communication)：是否针对需求进一步厘清? 是否持续保持沟通对话，还是只是埋头写程式码？
问题解决能力 (problem solving)：如何理解和解释复杂的概念? 能否解释思路 (而不是背诵答案)? 能否提供多种解法、是否有讨论不同解法的时间和空间的复杂度? 是否能对的解法进行优化?
验证能力 (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 官方准备指南提到的，面试官在系统设计面试主要检验以下四个方面：

面对模糊需求的能力：能否在模糊的情境下厘清需求。
提出解决方案的能力：能否根据需求提出对应的架构。
深入探究的能力：能否针对提出的架构进行深入的技术讨论。
技术沟通能力：能否在整个过程中与面试官保持良好的沟通。

如何在面试中做到核心要点？

在了解完系统设计面试的要点后，在准备时就可以针对这些要点来准备，以下谈分别可以怎么做。

面对模糊需求，厘清需求

在系统设计面试中，面试官通常会故意保持题目的模糊性，以检验你是否能主动厘清需求。这包括功能需求和非功能需求。

功能与非功能需求的区别如下：

功能需求：系统最基本的功能，例如社群媒体的发文、浏览动态等。
非功能需求：系统在极端情况下的表现，例如高流量下的稳定性、一致性等。举例来说，社群媒体的非功能需求可能包括在名人发文时，如何处理瞬间的高流量推送。这类需求虽然不影响系统的基本功能，但在实际应用中非常重要，也是能展现技术深度的地方。

在厘清阶段，确认没有解决错误题会很关键，推荐可以看 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）的问题，觉得非常精辟。推荐在准备面试新创公司的人一读。