前言本文作者为阿里淘系用户增长前端团队“易寻”。校招入阿里。今天作为一个有经验的人，跟大家分享一下面试官问项目经验的时候怎么回答。说到面试和校招面试，大家总会感到手忙脚乱。可能是你不自信，或者你可能觉得自己准备不足。没关系，既然投了简历，通过了筛选，就不要胆怯了。首先你要知道，面试官都是想着招你，只是想多了解一下你的具体情况。既然面试官愿意花时间和你聊天，那就证明你还是有能力的，还有被看好的闪光点，有什么愧疚的，勇敢自信的去面对就好了。STAR规则需要在简历撰写和面试过程中描述工作经历或个人经历。优秀的面试官往往会用STAR法则来建立个人事件，让面试官通过你过去的经历更好地判断你的个人能力和潜力。重温一下STAR法则的四大要素：Situation：事情是在什么情况下发生的，基于什么样的背景；任务：你是如何明确你的任务的；Action：针对这样的情况分析，你采取了什么行动，做了哪些具体的工作内容；Result：结果是什么，带来了什么价值，整个过程中你学到了什么，有什么新的体会。往往大部分同学一上来就直接介绍自己做了什么以及实现的过程，结构比较清晰，内容也比较有技术含量。但是很多同学容易忽略SituationandResult这一部分，即背景和结果。或者当面试官了解更多的询问细节时，很容易恐慌。这些原因往往是由于面试前没有把自己经历的来龙去脉说清楚，总结的不够全面和深入。举个例子：比如有同学提到在XXX项目的时候实现了一个Webpack插件XXX。这个插件的功能是XXXX，在Github上是开源的。整个实现过程和思路都比较清晰，面试官听得津津有味，甚至还回忆起小时候一天晚上加班研究Webpack插件的青春时光。即便如此，面试官也很想知道当时的项目背景，是什么原因让你想到做一个Webpack插件而不是使用其他工具来解决的，这个插件给项目带来了什么价值（是构建性能还是其他？）。背景和结果是面试官非常看重的部分。你必须拿出足够的理由和价值观来说服面试官。否则，虽然你在这个项目上投入了足够的精力，但最终不会给你的面试评价加分。这个非常重要。遗憾。这时候，也有同学会想：**我的project只是一个个人/学校的实践项目，觉得项目成果不是很亮眼。**所以这个时候，你不妨说说你在项目中学到的东西。比如在这个Webpack插件的例子中，大家可以谈谈：Compiler和Compilation以及它们的区别；Webpack如何实现插件之间的关系并保证它们的有序性；在开发插件的时候，需要根据当前配置是否使用了一些其他的插件来做下一步的决定，如何判断Webpack当前使用了哪些插件；我在开发插件的过程中借鉴了其他插件的思路。对本插件源码的了解；等等等等。在实际开发Webpack插件的过程中，大部分都会遇到以上问题。如果你有记录和总结，这些问题也可以作为Result。还原面试场景下面笔者通过面试过程还原项目场景，简单介绍一下借助STAR规则做一个浏览器API兼容性检查器的过程（把一件事描述清楚也很重要）interviewthroughdictation),以下都是口语，所以没有图片)。面试官：我看到你在简历中提到你实现了一个检查浏览器API兼容性的工具，可以介绍一下吗？我：（情况）好的，当时的情况其实是一个网友舆论反馈页面空白/打不开。通过排查JSError日志，发现最近出现了大量类似IntersectionObserverisnotdefined的日志。同时与我上次发布的模块暴露需求时间线几乎重合，所以很快定位到当时使用浏览器IntersectionObserverAPI做DOM暴露时没有考虑兼容性问题。面试官：问题解决了吗？我：是的，当时定位到问题后，通过添加polyfill很快解决了问题。**(Task)**后来用这道题自己想了一下。事实上，随着操作系统和浏览器的更新，越来越多的JS/浏览器新特性开始被支持。在给前端开发带来方便的同时，也会带来一些不可避免的兼容性问题。忽略兼容代码（polyfill）很容易造成不可预知的问题。但是，仅靠开发人员手动检查兼容性问题并不是最优雅的解决方案。毕竟人工难免会出现疏漏。所以我想知道是否有可能开发一个工具来集成现有的兼容性检查规则来自动化这个过程。面试官：对，我详细介绍一下具体过程。我：（行动）嗯，这个想法萌生后，我去了解一下常用的前端兼容性检查网站：Caniuse和MDN是我比较常用的两个。后来发现这两个网站的检查数据其实在Github上维护了一个静态检查规则（caniuse-db和mdn-browser-compat-data）。这些数据是具有特定结构的JSON文件，虽然两者描述浏览器支持的方式不同，但已经可以满足获取兼容性数据的基本要求。下一步是分析代码并将代码与这些规则进行比较。这个过程需要对代码进行语法逻辑分析，于是想到了使用Babel将代码转为AST语法树进行具体遍历。同时整理了一下常规的API调用方式，发现也就那么几种，比如：NewExpression（构造表达式）和CallExpression（调用表达式）。当所有这些信息都清楚的时候，我认为这件事在技术上是可行的。面试官：那么在这个实施过程中有没有遇到什么问题？你是怎么解决的？我：（行动）是的，我刚刚提到了Caniuse和MDN维护的静态JSON数据。在实现过程中，我统一了这两个数据的格式。目的是为了补充两个数据，方便后续检查。比较。最终，实际得到了近九万条数据。如果直接比较的话会影响效率，所以这时候可以通过浏览器列表配置指定目标检查的浏览器范围，比如iOSSafari9以上，通过这一层在这个范围内进行过滤没有兼容性问题的数据，从而减少对比，提高效率，同时也为开发者提供了灵活的配置能力。第二个问题也是check的性能优化，就是用isReferencedIdentifier来检测identifier是否真的被引用了。最后就是这个工具的控制，以及如何接入发布过程。由于公司发布流程采用云构建方式，所以我在发布前必须经过这个工具的验证，并打开消息通知和邮件系统查看检查结果。,**(Result)**帮助他人在发布前拿到项目代码的浏览器API兼容性检测报告，避免此类问题的再次发生。这段经历帮助我加深了对Babel和AST的理解。面试官：你了解Babel解析AST的过程吗？我：解析成AST有两个阶段：词法分析和句法分析。词法分析阶段：将字符串形式的代码转化为令牌（tokens）流，令牌类似于AST中的节点；语法分析阶段：将一个token流转化为AST的形式，同时将token中的信息转化为AST的表达结构。面试官：能详细说说你项目中提到的AST遍历过程吗？我：Babel在处理节点时，以访问者的形式获取节点信息，并进行相关操作。这个方法是通过Visitor对象来实现的，Visitor对象定义了各个节点的访问函数，这样就可以针对不同的节点做不同的处理。比如我在项目过程中主要处理NewExpression和CallExpression，通过路径参数balabala判断过滤节点及其父子节点。总结面试官的“套路”面试时问的问题基本上分为两种：具体问题和开放性问题。具体问题基本会参考工作经验，遵循STAR规则，主要了解基本素养、技术深度和潜力。开放题基本是考察发散思维的能力，考察某一领域的深度和广度，基本是结合技术问题，或者结合工作内容提出的。例如：n种实现某项技术的方法？某项技术的实现原理？和什么相比有什么优缺点？您对这项技术有何看法？面试官的“回应”是根据实际情况回答。提前准备的时候，多发散，多思考，多总结。这件作品是您可以自己准备的奖励项目。发散问题主要看你平时的积累。首先，基础知识要扎实，同时要了解最新的技术动向。面对此类问题，切记不要回答无关紧要的问题和跑题。
