面试不是在考你知道多少
很多人把面试当成一场考试，备考策略就是"把这个领域的知识点都过一遍"。这种思路对于校招可能还管用，但对于中高级岗位的社招面试，很快就暴露出问题：你复习了二十个 React 知识点，面试官可能只问了三个，但每个都往深了挖，问到你答不上来为止。
这不是面试官故意刁难，而是中高级岗位的筛选逻辑和校招完全不同。
校招是在茫茫人海里找"潜力股"，主要看基础是否扎实、学习能力是否强、能不能培养。中高级社招是在有一定经验的人里找"能直接上手解决问题"的，看的是你能不能在现有基础上立刻产生价值。
这个本质区别，决定了面试的考察重点。
高级前端面试的四个维度
大多数中高级前端面试，技术面会围绕这四个维度来考察：
维度一：能不能干活
这是底线。不是因为它最重要，而是因为它是一个门槛。
能不能干活看的是：给定一个具体问题，能不能写出能跑的代码；遇到一个 bug，有没有办法排查和解决；接手一个需求，能不能独立设计实现方案。
这个维度通常由笔试或者现场写代码来考察。题目不会太难，链表反转、字符串处理、数组操作这类基础题就够了。真正卡住的往往不是思路，而是实现细节——边界条件没考虑、变量命名乱七八糟、写出来的代码自己都看不懂。
面试官在这个维度看的不是"会不会"，而是"写出来的代码质量怎么样"。
维度二：理解有多深
到了三年以上，候选人之间的差距主要体现在这个维度。
同样用 React 三年，有人只能说出"state 变了组件就重新渲染"，有人能画出完整的更新链路：从 setState 调用开始，经过 React 的批处理机制，进入 Fiber 的调度循环，根据 lane 优先级决定同步还是异步执行，最后经过 render phase 和 commit phase 完成 DOM 更新。
这两类人写出来的代码差距会在实际项目中逐渐拉开。第一类人遇到复杂的交互状态管理会很头疼，第二类人能快速判断应该在哪个层级处理状态、什么时候该用 useTransition、什么时候该用 useDeferredValue。
理解深度不只是"知道答案"，而是"能用自己话把机制讲清楚"。面试官通常会这样问："能说说你对 React Fiber 架构的理解吗？"或者"useEffect 的依赖数组到底该怎么决定，什么时候会死循环？"
能答出来的和不能答出来的，差距一眼就能看出来。
维度三：能不能做技术判断
这个维度经常被低估，但它其实是高级岗位最核心的能力。
技术判断指的是：遇到一个问题，知道该用哪种方案，而不是哪种方案都能实现但不知道优劣在哪里。比如：
- 什么时候该用 Redux，什么时候该用 Context，什么时候该用
useState - 什么时候该引入 TypeScript，引入之后如何做类型设计
- 性能优化该从哪里入手，如何判断瓶颈在哪里
这类问题没有标准答案，考察的是候选人在真实项目中积累的工程经验和对技术方案的权衡能力。
面试官通常会这样问："如果让你做一个后台管理系统，你会怎么设计状态管理方案？""你们项目现在有什么性能问题，你打算怎么优化？"
维度四：能不能把技术讲清楚
这是很多人忽视但实际上非常重要的能力。
很多工程师代码写得好，技术理解也不差，但一到口头表达就垮掉。讲东西抓不住重点，一个简单概念绕了三分钟还没说清楚，问一个延伸问题就慌了。
口头表达能力的本质是把脑子里那张知识网组织成一条清晰的线。在面试这种时间有限的压力环境下，能不能快速组织语言、能不能在被追问时稳住、能不能举一反三，比"知道多少"更能体现一个人的真实水平。
三轮技术面通常分别看什么
标准的中高级前端面试通常是三轮技术面，每一轮的侧重点不同。
第一轮技术面通常由级别相近的工程师来面，侧重考察基础能力和编程能力。会让你写代码，题目不会太复杂，但会看你代码写的质量怎么样、有没有考虑边界情况、写出来的代码是否可读可维护。
第二轮技术面通常由高级工程师或者 tech lead 来面，侧重考察技术深度和工程判断。会问你很多"为什么"——为什么用这个方案而不是那个方案，为什么这样设计，这个技术在你们项目里是怎么落地的。也会问一些系统设计相关的问题，比如"如果让你设计一个 XX 系统你会怎么做"。
第三轮技术面通常由架构师或者技术总监来面，侧重考察架构能力、技术视野和软技能。可能会问你在做技术选型时遇到过什么挑战、在团队里怎么推动技术改进、如何看待某个技术趋势。这类问题没有标准答案，看的是你的思考深度和全局视野。
了解这个结构很重要，因为它帮你明白每一轮该展示什么、不该在错误的地方花太多时间。第一轮拼命展示架构见解而代码写得很烂，和第三轮只聊技术细节而讲不出技术视野，同样糟糕。
什么是"能直接上手解决问题"
很多 JD 上会写"能直接上手解决问题"，这句话的真正含义值得拆解一下。
它不是说招来一个人立刻就能做所有事情——那不现实。它指的是：这个人进来之后，给他一个具体问题，他能独立设计方案、能推动落地、能对结果负责，不需要手把手带。
具体来说，能直接上手解决的人通常具备这几个特征：
问题还没完全搞清楚的时候，不会停在原地等指令。 会先自己分析，主动和业务方或者后端对齐，然后给出方案。
方案有多个选项的时候，能说出每个选项的优劣。 而不是"我觉得这个好"然后说不出原因。
落地过程中遇到阻碍，不会轻易放弃。 会想办法绕过去，或者找到替代方案，实在不行才升级。
做完了会复盘。 知道这次哪里做得好，哪里可以改进，下次怎么避免同样的问题。
这些特征很难通过背题来伪装。面试官通常会通过追问细节来判断你是真正做过的人，还是只是背过答案的人。比如问"你们这个项目在性能优化上具体做了什么"，背答案的人会说"我们做了很多优化"，真正做过的人会讲出具体的数值、具体的问题、具体的方案和具体的效果。
面试中的两类常见失败
第一类：什么都答得上，但什么都答不深
这类候选人给人一种"很稳"的感觉，但面完面试官会觉得"这个人可能经验掺水"。
问题出在哪？在于只知道概念，不知道原理；能说出名词，但经不起追问。
比如问 React 的更新机制，能说出"有 render 和 commit 两个阶段"，再问"render 阶段具体做了什么"，答不上来。再问"Fiber 节点里面有哪些属性"，还是答不上来。
这种状态通常是因为学习方式不对——看源码解析文章是"看"懂了，但没有动手验证、没有画过图、没有用自己的话复述过，所以知识还是浮在表面。
第二类：技术很强，但表达混乱
这类候选人可能代码写得很好，对技术的理解也很深，但口头表达是弱项。
面试官问一个问题，回答了三分钟还没到重点。中间讲了很多细节，但主线不清，面试官已经跟不上了。问一个延伸问题，整个人就乱了，因为脑子里那张网没有一条清晰的主线来牵引。
这类问题其实比第一类好解决，因为技术底子在，只需要训练表达。可以对着镜子练、录下来回放、找人模拟面试，都是有效的方法。
这一章想说的
高级前端面试看的不是"知道多少"，而是"理解多深"、"能不能做判断"、"能不能讲清楚"。
知道自己被考察的维度，比盲目刷题重要得多。对着每个维度检查自己的状态：基础编程能力是否过关、技术深度是否够、对常见的技术判断有没有积累、口头表达是否清晰。哪个维度弱，就在哪个维度上多投入时间。
接下来的章节会具体讲怎么诊断自己的弱项、怎么建立知识骨架、怎么训练表达。