半年前，我第一次成为了二面面试官。这段经历不仅让我，一个曾经的候选人，对许多问题有了更新的理解，也逐渐澄清了我之前在面试过程中的那些困惑。高频次的面试，也使得我对于自己，对于面试这一行为本身，有了深刻的反思和新的认识。我也希望通过分享这些体会，能为那些即将踏上这段旅程的人提供一些启示和帮助。
明明聊的很开心，算法题也做出来了，却没有后续了？
这应该是很多同学在二面的时候遇到的问题。一般来讲，一面完成了基础知识的考察，二面就是你将来的直属上级。
也正是由于二面会是你入职之后的直属上级，这种情况才更容易发生，明明聊的很开心，算法题也做出来了，却没有后续。
从我担任二面面试官的经验来言，因为考虑到候选人入职之后，将是我的直接下属，所以，考察的关键点并不仅仅在于技术层面，性格是否匹配，处事风格如何，过往经历是否匹配，学习能力如何，也是决定是否通过的重点。
除此之外，聊的开心，也并不等于技术过关。
由于工作经验和年限不同，候选人和面试官，往往在技术视野上存在一定的 gap。而项目经验的不同，也会导致候选人和面试官在技术的了解上存在偏差，双方熟悉的领域并不相同。
碰到有类似的项目经验的面试官，那么在深度上，往往会深挖，这一过程中，候选人可能会感觉良好，觉得问对了，觉得聊的比较开心。
而在面试官的角度，可能并不会认同，由于技术视野和技术深度的偏差，一旦候选人达不到预期的深度或方案上没有自己的思考，可能会认为候选人在技术方案和深度上，都有待加强。
当然，除此之外，还有很多原因会导致没有后续(不过 hc 不足，有更好的候选人等，这些其实一般不会发生在二面，往往会发生在 hr 面之后)，上述也仅仅只是我个人作为面试官的一些想法。
这面试官问的问题怎么这么奇怪？这问题有答案吗？
不知道有没有同学遇到过，面试官在聊了项目之后，会抛出一个非常开放的问题，有可能是项目的延伸，有可能是项目的未来规划，也有可能是一个不好实现的问题。
比如：如何在 vue 里面使用 react 组件，react 能够使用 vuex 吗这种天马行空的问题 (当然，这个问题纯属示例，一般都会和项目相关，比如如果重构，你会多出哪些考虑，能不能用另一种方案实现它)。
这里的背后，作为面试官一般是这样的心理活动，和候选人这个项目聊的还不错，深度也还 ok，姑且问个开放性的问题，看看随机应变的能力和创新性吧。
遇到这样的情况，其实也很简单了，面试官要的并不是一个准确的答案，甚至有可能问题本身就有问题。
此时，就大开脑洞，也别管能不能实现，正确与否，按照你的想法，天马行空也好，讨论问题也罢，聊就对了。
你有遇到过什么困难或者有技术难度的问题吗？
我自己作为候选人被面试的时候，有时候会被问到这个问题。
当时的内心 os 真的是，你问这么虚的问题，真不靠谱，敢不敢问点实在的。
当我成为面试官之后，我才明白，这个问题背后的意思（当然，这仅仅代表部分情况并非全部）。
往往会在聊了一会项目之后，问出这个问题。
这里其实要注意了，问出这个问题，大概率意味着，前面的项目咱们都聊过了，在我的视角下，可能不是太有挑战性，技术上复杂度一般，当然，也可能是因为咱们项目经验的差别，导致我看不出你做的项目的复杂度。
此时，问出这个问题，让候选人自己把困难或者项目的复杂度抛出来，来避免由于我自己的判断导致错误估计了候选人的技术实力。
一般一到两年经验的同学，被问到这个问题还算正常，因为一般来讲，这个年限的同学做的事情都比较基础。而如果是三到五年的同学，那么就需要看看是否自己简历上的项目描述是否有突出复杂性和难度。
要应对这个问题，就必须上点技术复杂度了。如果业务复杂，可以讲述业务的情况和场景，如果技术复杂，那么可以看看有哪些你认为复杂的点没有聊到，可以再聊聊。
如果业务确实不复杂，那么可以聊聊看过的源码，或者自己平时钻研的一些问题或者当下热门的话题，比如之前 react18 的 renderToPipeableStream 和传统 ssr 的区别，或者前一段时间 vue 作者认为 react 文档存在让开发者自行 pua 的情况的讨论。
这里的核心，就在于突出自己的技术深度以及对各种方案背后的思考。
那到底什么算深度呢？
提到深度，如果是以前的我，必然会反驳，前端，就是画画页面，有什么深度可以说呢？
但是实际上，大家还是低估了自己工作的复杂度，画页面的简单，仅仅只是因为那些复杂的东西，其他同学在底层都处理掉了。
在一个成熟的前端团队中，工具层面的复杂度基本都在底层被一些同学或者一些组进行了解决。
比如：资源文件的缓存处理，html 文件一般进行协商缓存或者不缓存，而 js、css 文件一般使用强缓存。这些在部署平台就进行了处理，从我面试的候选人来讲，知道协商缓存强缓存的很多，涉及的几个头背的滚瓜烂熟，但是他们的具体用途，往往会含糊不清有所犹豫。
再比如组件库，基本上大家都在用，那么组件库是如何实现按需加载的？或者你的项目中，组件库是否是正常按需加载的吗？组件库的组件，应该提供哪些打包产物呢？你的项目中又是什么样的产物呢？对于样式文件，有哪些处理方案呢？各自的优劣如何？
再比如，项目的打包产物，是否还需要对 promise, async/await 这些语法进行 polyfill，2024 年了，我们的 babel 还有必要把 es6 语法转为 es5 吗？
而更底层的复杂度，从 Jquery, 到 react, vue，再到 svelte, solid 等声明式框架，被这些更底层的框架所掩盖。
那么回到深度，对于做业务的同学，确实不太会对构建打包，组件库、脚手架建设有那么多的了解。但是业务同学，是需要对整个项目的技术选型，性能优化，代码可维护性负一定的责任的。
这里我也只能结合我自己的经验聊一聊深度，并不具有代表性。
比如常见的 react 中的多次渲染如何优化，为什么需要全局状态管理，context 如何避免不必要的渲染，对于 redux 有多少了解，它的中间件思想可以拿出来用到项目中吗？这是我在给组内设计一款合适的状态管理时做的思考，在后来准备面试的时候就做了更多相关的了解。
再比如一些项目本身，就有一定的复杂度，比如我之前做的可视化埋点平台，涉及到一些生僻 api 使用，iframe 通信的设计，以及 babel 插件、webpack 插件等来稳定 xpath 的开发。而这个技术项目，本身也是在我们运营活动的场景下所演化出来的一个平台。
这里建议候选者，对自己的项目一定要进行深挖，涉及到的相关知识点，务必要吃透。比如写了在用 redux，那么势必就需要对其原理有比较多的了解。
本身面试双方信息就是不对等的，面试官一旦在你的优势项目中，发现深入度和思考还不如自己初看这个项目时的思考，将会是非常大的一个减分项。
结语
以上，便是我的一些感悟和思考。
其实这半年的时间，于我而言，也可以说是一场对面试去魅的过程。
站在面试官的角度去实际同候选人交流，有时候就像遇到过去的自己。也很快就理解了以前的我，单纯作为候选人的时候的诸多困惑。
希望本文的一些解答，能够帮助大家对与面试有更好的理解。也祝大家在新的一年里，都有更好的 offer！