面试这事真的很看缘分但也真的很看准备。我在写这篇文章的时候特意回看了自己当初一年半经验时投 Shopee 那段时间的记录和聊天截图一边看一边冒冷汗。不是因为表现多差而是因为我发现自己对面经这两个字的理解和真正拿到 Offer 之后的复盘结论几乎完全不一样。市面上太多面经在告诉你考了什么题、怎么答但很少有人在讲为什么要这样答、答完之后面试官到底在评估什么、你简历上哪句话会被追着问十分钟。这篇内容不打算写成标准答案汇总而是想把我这一年半前端经验去面 Shopee 的真实路径、踩过的坑、以及后来复盘时才想明白的细节完整剥开给你看。无论你是刚满一年想试试水还是两年左右准备冲一波外企都值得花十分钟把这篇文章看完尤其是里面关于项目深挖和算法轮的部分可能和你预想的不太一样。1. 为什么在一年半经验的时候动了跳槽念头很多人会觉得一年半这个时间点很尴尬。你说自己是应届生吧已经不是了说自己是资深前端吧又明显不够格。但恰恰是这个阶段是跳槽性价比最高的时候之一。因为你有完整的项目经验能独立负责模块又还没有被某个公司的固定技术栈和业务逻辑完全同质化面试官对你的预期其实没有你想象的那么高。1.1 一年半的经验到底处在什么阶段在我自己看来一年半的前端核心任务不是证明自己什么都会而是证明三件事。第一你能不能在没人盯着的情况下把一个需求从设计稿变成线上功能。这包括技术方案选型、组件拆分、接口联调、自测上线以及处理线上问题。很多一年左右的同学在这个环节是缺位的因为公司里往往有更资深的人兜底需求拆解和排期都不用自己操心。但面试官不知道你有没有人兜底他只能通过你的描述来判断。第二你有没有形成自己的技术判断力。举个例子同样是做一个表格页面你会不会在技术方案里写明为什么用虚拟滚动而不用分页你会不会主动提出这里用 useMemo 其实没有意义因为数据来源是全局状态每次都会变这种细节是区分一年经验和三年经验的关键分水岭也是我在面试前集中补课的地方。第三你能不能吃亏。这话听起来有点虚但放到面试场景里就非常具体面试官抛出一个你没做过的场景题你的第一反应是这个我没做过不知道还是我没直接做过但基于我对 XX 的理解我会从这几个维度去拆后者就是吃亏之后练出来的表达能力。1.2 Shopee 为什么值得在这个阶段投我在决定投递之前其实纠结了很久。一方面听说 Shopee 的面试流程比较规范技术面至少两轮到三轮每一轮都会有明确的考察侧重点另一方面也听一些朋友说外企对英语有一定要求对算法和基础的要求也不低。作为一个平时不刷题的选手我心里是有点打鼓的。但我后来想明白了一个问题你不可能等自己完全准备好了再去面试。所谓准备好了在面试这个场景里是永远不会到来的。更务实的做法是定一个周期比如三周用三周时间集中补齐最核心的知识盲区然后直接投用真实面试来检验自己的水平再根据反馈做第二轮补充。我就是用这种方式推进的前两轮面试确实暴露了不少问题但也因此拿到了非常具体的复习方向比自己闷头刷题高效得多。如果你也是一年半左右的前端我建议你认真评估一下自己目前负责的业务复杂度。如果每天的工作内容已经很难让你在技术上有新的积累那现在就是你启动面试计划的最佳时机。跳槽不是否定当前的公司而是主动给自己换一个成长速率更高的环境。2. 简历筛选阶段把一年半的资历写出辨识度简历这件事我吃过很大的亏。第一次投递的时候我几乎是照着网上的模板把自己的经历填进去的。比如负责 XX 后台管理系统开发、使用 Vue 3 和 Element Plus 实现页面交互、对接后端接口完成数据展示。听起来好像很完整但实际上每一句话都像白说。HR 每天看几百份简历这一版描述和隔壁应届生的描述几乎没有区别凭什么约你面试2.1 我踩过的最大的简历坑最大的坑是把项目描述写成了工作日志。工作日志记录的是我做了哪些事而面试官想看到的是我解决了什么问题、带来了什么结果、体现了我什么能力。这两个视角的差别非常大。举一个具体的例子。我做过一个内部运营平台的数据报表模块。刚开始简历上写的是负责数据报表模块的开发使用 ECharts 实现多种图表展示支持按日期、按渠道筛选提升运营人员的数据查看效率。这版描述的问题在于它只是罗列了功能没有解释任何决策。为什么用 ECharts 不用其他图表库图表数据量大了之后卡顿怎么解决筛选条件联动时有没有遇到性能问题运营同学的真实使用场景是什么样的这些内容一概没有面试官想追问题都无从追起他只能按自己的经验问一些通用问题然后把你当成普通开发对待。后来我重写这版的时候改成了主导运营后台数据报表模块重构对接日均百万级埋点数据。针对图表渲染卡顿问题调研并落地 ECharts 大数据模式 按需更新方案将首屏渲染时间从 3.8s 降至 1.2s。负责筛选条件组件化设计抽象出通用 QueryBar 组件支撑三个业务线复用。前后对比你会发现后者天然地埋了三个可以被追问的点百万级数据是怎么处理的3.8s 是怎么测出来的QueryBar 抽象的时候是怎么设计 API 的这三个点每一个都能引出一次有深度的对话而对话的主动权在你手里因为你才是做过这件事的人。2.2 项目描述的具体写法我在重写简历的时候给自己定了一个规则每个项目只保留两到三个最有辨识度的点其余全部砍掉。不要贪多不要指望面试官通过你的简历读完整个项目他能记住的只有那么两三个亮点。具体写法上我总结了三个要素按顺序排列背景和问题。一句话说清楚这个项目为什么要做或者你为什么要改它。比如原有报表页加载超过 5 秒运营反馈无法接受。你的动作和决策。你做了什么你的方案是什么为什么选这个方案而不是另一个。这是整个描述里最重要的一块能体现你的技术判断力。结果和量化指标。性能提升了多少业务方效率提升了多少复用了多少条业务线最好有数字没有数字就用对比比如从无法使用到可流畅查看。我当时整理完这三个要素以后删掉了简历里一半的废话整体篇幅也短了但信息密度反而高了。后来约面率明显提升应该是和这个有直接关系的。2.3 技能清单应该怎么列如果你经验不到三年技能清单这块建议不要写熟练使用 XXX这种话。熟练这个词在面试官眼里等于没写。更合适的写法是标出你实际使用过的场景和深度比如Vue 3组合式 API 开发中后台项目封装过表格/表单/弹窗等 10 通用组件、TypeScript封装过带泛型的请求层处理过类型收敛和接口对齐问题。还有一点心得是不会的东西不要硬写。简历上写的每一项都有可能被追问。与其赌面试官不问不如只列自己真正能把前因后果讲清楚的内容。我在第一版简历里写过了解 Webpack 原理结果面试官问我 loader 和 plugin 的区别、写过自定义 plugin 没有我回答得支支吾吾那一轮印象分就掉了不少。如果你准备时间充裕这一步值得静下心来慢慢改。我的建议是简历改完之后自己先对着每一行问三个问题这段描述背后的技术难点是什么当时的可选方案有哪些为什么做了这个选择如果三个问题里任何一个答不上来就说明这个描述要么不该写要么你还没理解透。3. 一面基础题怎么答出非应届感Shopee 的一面通常以基础为主考察范围集中在 JavaScript、浏览器、网络、框架原理这几个方向。说实话这些内容的八股文版本网上到处都是但很多人背得很熟一问到具体场景就露馅。原因很简单死记硬背的答案没有上下文。面试官想看到的不是你一字不差地背出事件循环分为宏任务和微任务而是你能不能把这个概念放到一个真实问题里讲清楚。3.1 事件循环、闭包、this 这类题的高分回答逻辑先说我真实遇到的一道题可能很多人也见过setTimeout 的延时是准确的么为什么如果我想精确测量一段代码的执行时间应该怎么做这道题表面在考 setTimeout实际上考的是事件循环、宏任务微任务、性能计时这三个层次。低分回答是setTimeout 不准确因为它是宏任务会被前面的任务阻塞可以用 performance.now() 测时间。这个回答不能算错但只停留在第一层。高分逻辑是这样展开的先给结论setTimeout 的延时不是精确的最小延时受浏览器实现影响Chrome 里嵌套调用还会有限制。解释为什么不准。JS 是单线程的setTimeout 只是把回调放进宏任务队列要等当前执行栈清空、微任务队列清空之后才轮到它。所以实际执行时间 设定延时 当前任务队列的剩余执行时间。如果真到面试官问怎么测代码执行时间一定要提到 performance.now() 的高精度特性以及为什么不用 Date.now()——因为 Date.now() 受系统时间调整影响而 performance.now() 是单调递增的不会被时钟回拨干扰。更进阶的一点是如果你在 React 场景里还要能扯到 requestIdleCallback 或者调度比如 React 的 Scheduler 底层就是基于 MessageChannel 来模拟 requestIdleCallback 的这能体现你对框架原理的理解不是停留在 API 层。同样是背过八股文这个回答思路明显更能体现非应届感。我准备的技巧是每当复习一个概念都强迫自己回答三个问题——它解决什么问题它的机制是什么如果让我设计一个方案替代它我会怎么做这比单纯刷题有效得多。3.2 React 原理和 Hooks 陷阱Shopee 的岗位如果用的是 React 技术栈一面基本都会追 React。我当时准备了几个高频问题Hooks 为什么不能写在条件语句里、useEffect 的依赖数组到底怎么比较、useCallback 和 useMemo 的适用场景。这里面最容易答偏的是 useEffect。很多人只会说依赖数组里的值变了就会重新执行但面试官追问一句如果我传了一个空数组是不是只在挂载时执行一次很多人就开始犹豫了。正确答案是不一定。关键在于你的 effect 里有没有访问外部变量以及这些变量是不是 React 每次 render 都会重新创建的。如果依赖是空数组但 effect 里用了一个在组件内定义的函数那这个函数每次 render 都是新引用但由于依赖数组是空的React 不会在更新时重新执行 effect——这看起来是安全的实际上如果你用了函数内的状态且没有正确注册依赖就相当于闭包捕获了旧值这就是经典的 stale closure 问题。如果你在项目里用过 React 函数的闭包导致过 bug比如定时器里拿不到最新 props这块一定要准备好。最简单也最不易出错的解法是把依赖项写全或者用 ref 去保存最新的值。面试里能主动讲出我在项目里遇到过这种问题最终的解法是 xxx比单纯背概念要加分非常多。3.3 浏览器和网络从背概念到讲场景这一部分我强烈建议你不要只看协议原理一定要结合一个真实页面从输入 URL 到展示的完整链路去理解。缓存、DNS、TCP、渲染、JS 执行、重排重绘这些本来就不是孤立的知识点它们共享一条完整的请求生命周期。比如常见的面试题浏览器缓存机制低分回答是背一遍强缓存和协商缓存的状态码。我后来学到的加分答法是先说浏览器在请求资源时会先查强缓存也就是 Cache-Control 和 Expires命中的话直接用本地副本发 200 from cache没命中才发请求服务端通过 ETag 或 Last-Modified 返回 304让浏览器继续用旧资源。然后补一句实际开发里我一般会结合打包工具给静态资源加 hash这样文件名变了缓存自然会失效同时保证没有变化的资源可以继续命中强缓存。这样既展示了原理又展示了工程实践。如果你能再进一步提到 HTTP/2 多路复用、队头阻塞问题以及为什么还需要 HTTP/3 的 QUIC 协议来解决传输层的队头阻塞面试官对你的印象会再上一个台阶。虽然这些问题不一定会被问到但它们之间是有逻辑链条的理解了这条链路哪怕换一种问法你也能接住。4. 二面项目深挖和技术方案设计的真正分水岭一面是考你会不会二面是考你有多会。这个问题是我面试完最大的感受。Shopee 的二面通常不再围绕通用八股文而是会花大量时间问你自己做过的项目。你简历上写的每一个亮点都可能被拿来精细解剖。面试官会问你这个方案是你自己决定的还是别人帮你定的当时还有哪些备选方案你了解它们各自的优缺点吗上线以后有没有出过问题如果让你重做一次你会有什么改动这些问题没有标准答案但非常考验你有没有真正思考过自己的工程实践。4.1 项目复盘的正确打开方式很多人在准备项目深挖的时候会犯一个错误把项目准备成一份做成 PPT 的成功案例只讲做了什么、结果多好完全不讲踩过的坑、走过的弯路。但实际上面试官愿意听到的恰恰是失败和反思因为那更能体现一个人的思考深度。我二面讲的一个项目是前端性能优化专项一开始我是打算只讲成功部分的发现页面慢、做了性能分析、改进了哪些点、LCP 从 4.5s 降到 1.8s。但后来我复盘的时候发现真正让我对性能优化有深刻理解的不是那些成功的点而是整个过程中我曾经做过一个无效优化把图片全部转成 WebP结果发现数据上几乎没变化后来查了才发现线上大部分图片已经通过 CDN 的压缩参数处理过了我转换的图片总量只占页面的很小一部分。这个失败故事反而比我罗列一堆优化手段更能展示我的判断力因为它说明我在优化的时候不是无脑堆方案而是会验证方案的有效性并且在无效之后能重新定位问题。面试官对这段追问了很多比如那你后来怎么定位到真正的瓶颈用的是什么工具Performance 面板里的什么数据给了你线索这些问题我可以答得非常细节因为它是真实经历不是背出来的。4.2 场景设计题如何拆解一个前端需求二面还会出现一类题就是给你一个业务场景让你现场做技术方案。我遇到的一个问题是如果我们要做一个支持多人实时协作的文档编辑器你会怎么设计前端架构这类问题听起来很大面试官并不期待你完整地把整个系统设计出来他更在意的是你在拿到一个模糊需求的时候有没有一套自己的拆解方法。我当时没有直接说用什么技术而是先问了一连串澄清问题并发冲突怎么解决是服务端权威还是客户端乐观更新要不要支持离线编辑协作人数规模大概是多少历史版本保留多久这些问题本身就向面试官传递了一个信号我不是一个只会写代码的人我会先定义问题再想解决方案。澄清完之后我再给出一个分层设计。前端层面要把编辑器核心文档模型、操作转换、UI 层工具栏、状态同步、网络层WebSocket 消息收发、重连恢复分开操作冲突解决最简单的是服务端用 CRDT 或者 OT 算法前端只需要把用户的每个操作转换成原子化的指令发给服务端状态管理上本地状态和远端状态的同步需要有一个明确的中间层避免直接把 WebSocket 消息散落到各个组件里。如果对 CRDT 和 OT 的区别不了解至少也应该能讲清楚CRDT 是无中心、合并友好的方案Google Docs 用的就是类 OT 方案需要中心服务端做转换。能讲到这一层面试官已经会认为你是认真思考过的。4.3 遇到我不会的正确表达方式这一点是我最想说、也最想让所有准备面试的人记住的。面试中一定会遇到你不会的题区别只在于你用什么样的方式处理。最常见的错误是沉默然后挤出一句这个我不会。这会把对话瞬间冰住面试官想帮你都无从帮起。另一种错误是强行编造被追问两轮之后就露馅反而让人质疑你的诚信。正确的处理方式是把你已知的部分拆出来然后表达你未知的部分并给出你的猜测方向。比如面试官问你有没有用过 WebAssembly你可以说我没有在实际项目里用过 WebAssembly但我知道它适合计算密集型的场景比如音视频处理、图像处理。如果要我现在设计一个方案我可能会考虑把复杂的编解码逻辑用 Rust 或 C 打包成 wasm然后通过 JS 调用。具体到集成细节——比如内存管理和与 JS 的通信开销——我还没有实践经验需要去查一下文档。这段话既表明你没有经验也证明你知道它该用在什么地方、有哪些知识点需要补足而不是一个完全空白的大脑。这个方法在我身上屡试不爽我甚至有一次面试官听完之后主动说你没做过也很正常这个领域用的人确实少。然后他就开始给我讲他们团队是怎么做的了——面试变成了技术交流。5. 算法轮和手写题一年半前端最容易被击穿的地方我承认算法是我整个面试过程中准备得最痛苦、也是最花时间的部分。因为平时工作根本用不到那些复杂的算法大学里学的那点东西也早还给老师了。但实际上Shopee 的算法考察并没有想象中那么可怕难度基本保持在 LeetCode 中等题以下而且很多题目都是可以通过针对性准备拿到分数的。5.1 算法到底要刷到什么程度作为一个不刷题的人我给自己定的目标是先把最常见的题型刷熟而不是追求刷题数量。我当时集中刷了大概 100 道题分成几个固定的模块数组和字符串、哈希表、链表、二叉树、动态规划入门、栈和队列、双指针、排序和二分。每类题刷够 10 道左右基本就能开始看到一些规律了。我的感觉是面试里的算法题和刷题网站不完全一样。面试官更看重你的思考过程他会观察你拿到题之后是直接开始写还是先和面试官交流清楚题目里的细节。我个人的体会是哪怕会让你显得慢一点也一定要先口头分析一遍题目的输入规模有多大边界条件是什么有没有可能有负数能不能改变原数组这些问题问出来既帮你避免编码中大量出错也让面试官看到你是一个有工程思维的人。我实际遇到过的题目里印象比较深的一道是给一个字符串求最长无重复字符子串的长度。这道题在 LeetCode 上是第三题非常经典。准备过的同学可能直接就会写滑动窗口但我当时先口头分析了窗口的扩展和收缩条件确认了重复字符处理的方式再写代码整个流程反而非常顺畅。如果你的目标是外企刷题的时候建议一定要养成英文读题的习惯很多题目翻译成中文之后意思会有微妙变化直接读英文更准确。5.2 高频考点和手写题清单除了纯粹的算法题大厂面试还非常喜欢手写一些 JS 题这类题更像是对语言基础和工程能力的综合考察。我把当时重点准备的一些题列在这里手写 Promise.all、Promise.race并解释 Promise 的 microtask 机制手写防抖和节流并说清楚它们的核心区别和使用场景手写深拷贝处理循环引用和特殊类型Date、RegExp 等手写 instanceof 原理并说明它和 typeof 的区别实现一个简单的发布订阅 EventEmitter实现一个 LRU 缓存用二分查找实现一个版本号排序手写数组 flat 以及去重注意 NaN 和对象实现虚拟列表的基本逻辑数据量大时只渲染可视区域我的建议是不要只背代码一定要会讲思路。比如手写防抖你要能说清楚最后一次触发之后延迟执行和第一次触发立即执行的两种模式并且能根据业务场景讲出你实际用过哪一种。我当时还主动提到在一些场景里防抖会导致操作无响应感太重所以会改用节流来保证一定频率的执行这种实际权衡比单纯默写代码更能加分。5.3 在线 coding 时的心态和节奏控制在线 coding 最怕的不是写不出而是写的过程中内心慌乱越急越出 bug然后开始怀疑自己。我之前在别的公司面试时就经历过一次写一个很简单的快排因为紧张把 while 条件写错了调了五分钟才看出来整场面试的节奏都被打乱了。后来我总结了一套自己的节奏控制方法分享给你。拿到题之后强制自己先看两分钟题不要急着写想清楚边界条件再动手开始写的时候注释先行把思路用注释写出来再填充代码写完之后不要马上说写完了主动检查一遍边界情况。这一套流程下来哪怕中间有小 bug面试官也会觉得你的思路是清晰的。还有一个小技巧是在写代码的时候保持和面试官的交流。不用每行代码都解释但在关键节点说一句这里我用双指针是为了把时间复杂度从 O(n²) 降到 O(n)会让面试官知道你不是在背题而是真的在思考。我曾经在一次手写题中写完之后主动提了一句这里还有一个小边界情况当指针相遇的时候要再加一个判断面试官笑着说 fine那场面试的氛围明显轻松了很多。6. 反问环节和 HR 面容易被忽略的隐性加分项很多人觉得面试到最后一问你有什么想问我的时候面试已经基本结束了随便问一两个问题客套一下就行。但我的经验是反问环节真的是可以影响面试结果的一个独立环节。它不像技术上那样有硬性的评分标准但它能影响面试官在写评价时那种微妙的、对你个人的印象。6.1 技术面反问什么才显专业我当时整理过一套反问问题按效果从好到差排下来大概是这样如果我有幸入职前三个月团队对我最大的期望是什么——这个问题直接说明你已经在设想入职后的工作计划显得非常真诚。团队现在的技术栈里你觉得最大的历史包袱是什么——这个问题能问出很多真实信息也会让面试官觉得你对技术有好奇心。前端团队在公司的组织架构里和产品、后端是怎么协作的——适合想了解工作方式的同学。你们有没有什么正在调研或者试点的新技术方向——适合展示你在技术视野上的兴趣。尽量避免只问一些公司福利怎么样、加班多不多之类的问题不是说不能问而是这些问题最好留到 HR 面不要浪费技术面宝贵的交流机会。如果面试官在技术面里给你讲过某个复杂的系统设计或者某个技术方案选型你在反问环节可以顺着他的思路再问一句你刚才提到的那套方案上线之后有没有踩过什么坑这会是一个非常漂亮的收尾因为它证明了你刚才真的有在认真听并且对技术本身感兴趣而不是把面试当成一场拷问。6.2 HR 面谈薪和离职原因的话术HR 面通常会问离职原因和期望薪资这两个问题没聊好前面技术面积累的优势可能会被抵消掉一部分。离职原因的核心原则是不吐槽前公司、不抱怨前领导把所有原因都归因到个人成长诉求上。哪怕你真实原因就是工资太低、感觉没前途也要包装成我希望能在业务复杂度更高、技术挑战更大的环境里继续成长。这句话听起来很官方但它安全、不出错HR 也知道大多数人的真实原因是什么ta 要的只是你处理敏感话题时能不能保持体面。谈薪的时候我的体会是不要直接报一个具体数字而是给一个有理有据的范围。比如我目前的总包是 xx考虑到 Shopee 的职级体系和我对标的能力水平我希望整体涨幅能在 30% 左右。如果你有多个 Offer 在谈也可以含蓄地提一句我目前正在流程中的其他机会给的预期也在这个范围这会让 HR 更认真对待你的数字。7. 复盘我踩过的坑、挂过的地方和最终建议文章写到后半段我想把最真实的那部分经历放出来。不是因为我面试全过了才有资格说这些话恰恰相反我在整个面试周期里也挂过不少包括一些我自认为准备得很充分的环节。7.1 挂掉的那场面试问题出在哪我印象最深刻的一次是在二面项目深挖环节被问到一个我完全没有准备好的角度。面试官问我你项目里用了一个自定义的请求 hook它内部是怎么处理取消请求的如果用户快速切换路由你怎么保证不会把上一个页面的响应 setState 到已经卸载的组件上这个问题其实不算刁钻正常用 AbortController 或者 axios 的 cancel token 就能处理。但因为我简历里只写了封装了 useRequest 请求 hook没有深入准备这个 hook 的内部细节所以当时只是简单说我用了 mounted 标志位来避免已卸载组件的 setState面试官追问那如果请求已经发出去了服务端还在处理你怎么取消它我就卡住了。复盘下来问题不在于我不会 AbortController而在于我简历上放了一个我没有真正从底层思考过的技术点。如果我在写简历的时候先把自己封装过的每个工具函数、每个组件都重新审视一遍问问自己最底层它是怎么工作的这场面试就不会挂。这也是我个人最想提醒你的一点不要因为某个项目是你做的就觉得你天然能讲清楚它。你能不能讲清楚和你做的时候有没有深入思考过是完全两回事。7.2 我对一年半经验前端的一些实用建议如果让我重新走一遍这段路我会给自己三条建议。第一准备时间最好拉长到三周以上不要压缩到一周。因为基础知识、算法手感、项目深挖这三个模块需要不同的复习节奏。基础知识和项目可以用碎片时间反复过算法需要连续的大块时间刷题一周的话很难平衡。第二找一个朋友或者同事做两到三场模拟面试。我在真正面试前做了一场模拟朋友模拟面试官把我简历上的项目逐条追问了一遍。那场模拟让我发现自己讲故事的能力很差讲到一半就开始细节发散完全没有主次。后来我调整了话术刻意训练自己在每个项目上用三分钟讲完背景——难点——方案——收益这个框架真实面试时发挥稳定了很多。模拟面试这件事真的不是浪费时间。第三把心态从通过面试调整为技术交流。我在二面的时候因为抱着这是一次交流的心态整个人松弛了很多反而答出了不少自己都没预料到的亮点。如果你只是想着答对每一道题脑子里就全是标准答案稍微遇到一个不一样的问题就开始慌。但如果你想着分享我自己做过的项目聊聊我对某个技术的理解你的表达会自然得多而且对方听着也会舒服得多。7.3 这个内容后续还能怎么用如果你正处在准备投递或者已经进入流程的阶段这篇文章里的很多东西可以直接复用。比如简历那段的写法你可以直接拿自己的项目套一下看看针对一面基础题的回答逻辑你可以挑几个高频知识点用它解决什么问题、它的机制、我的工程实践这个框架重新组织一遍项目深挖的部分至少要想清楚我提到的那些问题——方案是为什么做的、有没有备选方案、上线之后有没有出过问题、如果重做一次会怎么改。另外像 Shopee 这样以英文沟通和外企文化为特点的公司如果你英语口语还行面试中尽量用中英文混合的方式表达专业术语比如直接说component、hydration、race condition会比刻意全部中文翻译更自然也会让对方觉得你在国际化环境里能顺利沟通。如果你的英语面试是全英文的至少把简历上的项目介绍准备一个英文版本特别是项目描述里的那个背景——难点——方案——收益框架提前用英文讲顺一两遍会非常有帮助。最后真心建议每一位准备跳槽的前端同学把面试当作一个周期性的事情来对待而不是一次性的冲刺。你不需要等最好的时机也不需要等自己变成完全体再行动。一年半也好三年也好只要你手上有一个值得讲的项目、有一颗愿意复盘的心、加上一套有节奏的复习计划就已经足够开始了。