star法则(star法则举例子)

序

本文作者为阿里淘系用户增长前端团队“易迅”。18年，作为一名双非本科生，通过层层面试，被招入阿里。今天作为一个有经验的人，和大家分享一下当面试官问到项目经历的时候该如何回答。

说到采访

说到校招面试，大家总觉得心慌。可能是我不自信，可能是我觉得很多没有准备。没关系，既然投了简历，通过了筛选，就不要胆怯。首先你要知道面试官都是想招你，只是想多了解你的具体情况。既然面试官愿意花时间和你聊，那就证明自己还是很强的，有被人看到的闪光点，那有什么好心虚的呢？勇敢自信的面对就好。

星形规则

在你写简历和面试的过程中，你需要描述你的工作经历或者个人经历。好的面试官经常用明星法则来设置个人事件，让面试官通过你过去的经历更好的判断你的个人能力和潜力。

再次回顾明星法则的四个要素:

Situation：事情是在什么情况下发生，基于一个怎样的背景；Task：你是如何明确你的任务的；Action：针对这样的情况分析，你采用了什么行动方式，具体做了哪些工作内容；Result：结果怎样，带来了什么价值，在整个过程中你学到了什么，有什么新的体会。

往往大部分同学会直接介绍自己做过的事情和实现的过程，组织清晰，内容也颇具技术性。但是很多学生容易忽略情境和结果，也就是背景和结果。或者面试官了解更多细节的时候很容易慌。这些原因往往是因为面试前没有把事情的始末讲清楚，总结的不够全面深入。

举个例子:比如有同学提到在XXX项目期间实现了一个Webpack插件XXX。这个插件的功能是XXXX，在Github上是开源的。整个实现过程和思路都很清晰，面试官听得很有兴趣，甚至回想起年轻时有一天晚上加班研究Webpack插件的日子。

虽然面试官也想知道当时的项目背景，但是是什么原因让你想到制作Webpack插件而不是其他工具，这个插件给项目带来了什么样的价值(构建性能还是其他？)。背景和成绩是面试官很重要的一部分。你必须给出足够的理由和价值观来说服面试官。否则，虽然你在这个项目上投入了足够的精力，但最后还是没有给你的面试测评加分，很可惜。

这时候有些同学也会想:我的项目只是一个个人/学校的实践项目，想不到项目成果有非常抢眼的价值。那么这个时候，你不妨说说你在项目中学到了什么。例如，在这个Webpack插件的例子中，您可以说:

编译器和编译及其区别；

Webpack如何实现插件之间的关系并保证其有序性；

在开发插件时，需要根据当前配置是否使用了其他一些插件来做下一步的决策，如何判断Webpack当前使用了哪些插件；

在开发插件的过程中，我借鉴了其他插件的思想，以及我对这个插件源代码的理解；

等等等等。

以上大部分问题在Webpack插件的实际开发中都会遇到，如果你有记录和总结，这些问题也可以作为结果。

采访场景还原

下面的场景还原了项目的面试过程，简单介绍了借助STAR rule做浏览器API兼容性检查者的过程(通过听写把面试中的一件事描述清楚也很重要，以下都是听写方法，没有图片)。

面试官:

我看到你在简历中提到你实现了一个检查浏览器API兼容性的工具。能介绍一下吗？

我:

(情况)好吧，当时的情况其实是一个在线用户的舆情反馈页面空白/打不开。通过对JSError日志的调查，我发现最近有大量类似于交集观察者的日志没有定义，同时也和我上次公布的模块暴露需求的时间线几乎一致。所以很快发现在使用浏览器IntersectionObserver API进行DOM曝光时没有考虑兼容性问题。

面试官:

问题解决了吗？

我:

是的，当时定位问题后，通过添加polyfill很快解决了。(任务)后来我自己也思考过这个问题。事实上，随着操作系统和浏览器的更新，越来越多的JS/ browser新特性开始得到支持。在给前端开发带来便利的同时，也会带来一些不可避免的兼容性问题。忽略兼容代码(polyfill)很容易导致不可预知的问题。但是，仅仅依靠开发人员手动检查兼容性问题并不是最优雅的解决方案。毕竟手动难免会有疏漏。所以我想知道是否有可能开发一个集成现有兼容性检查规则的工具来自动化这个过程。

面试官:

很好。详细说说具体流程。

我:

(行动)嗯，想法产生后，我去了解了常用的前端兼容性检查网站:我常用的Caniuse和MDN。后来发现这两个网站的校验数据其实在Github上维护了一个静态的校验规则(caniuse-db和mdn-browser-compat-data)。这些数据是具有特定结构的JSON文件。虽然这两种方法对浏览器支持的描述不同，但它们已经可以满足获取兼容数据的基本要求。下一步是分析和检查代码，并与这些规则进行比较。这个过程需要对代码进行语法逻辑分析，所以我想到了用Babel把代码转换成AST语法树进行具体的遍历。同时我整理了一下常规API的调用方式，发现只有几种，比如:NewExpression(构造表达式)和CallExpression(调用表达式)。当所有的信息都清晰后，我认为技术上是可行的。

面试官:

那么，这个实施过程中有什么问题吗？你是怎么解决的？

我:

(动作)对，我刚才提到了Caniuse和MDN维护的静态JSON数据。在实现的过程中，我统一了这两个数据的格式，以便对两个数据进行补充，方便后续的核对和比较。事实上，最终获得了近9w条数据。如果直接比较，会影响效率。所以，这时候我们可以用browserlist来配置指定目标检查的浏览器范围，比如iOS Safari 9以上。通过这一层，我们可以筛选出这个范围内没有兼容性问题的数据，从而减少比较，提高效率，也为开发者提供了灵活的配置能力。第二个问题也是checking的性能优化，就是检查标识符是否被isReferencedIdentifier实际引用。最后是这个工具的控制，以及如何访问发布过程。因为公司的发布流程是建立在云端的，所以我在发布前检查了这个工具，并将结果传达给了消息通知和邮件系统。(结果)帮助他人在发布前拿到了项目代码的浏览器API兼容性检查报告，避免了此类问题的再次发生。这段经历帮助我加深了对巴别塔和AST的理解。

面试官:

你知道巴别塔解析AST的过程吗？

我:

解析成AST的过程分为两个阶段:词法分析和语法分析。词法分析阶段:将字符串形式的代码转换成令牌，类似于AST中的节点；语法分析阶段:将一个令牌流转换成AST的形式，将令牌中的信息转换成AST的表达式结构。

面试官:

你能详细说明一下你的项目中提到的AST遍历过程吗？

我:

Babel在处理一个节点时，以访问者的形式获取节点信息，并执行相关操作。这是通过Visitor对象完成的，该对象为各种节点定义了访问函数，因此可以对不同的节点进行不同的处理。比如在项目的过程中，我主要处理NewExpression和CallExpression，通过路径参数balabala判断和过滤节点及其父子节点和节点。

总结

面试官的“套路”

面试问的问题基本分为两种:具体问题和开放性问题。

具体问题基本都是参照工作经验按照明星法则进行，主要是了解基础素养，技术深度，潜力。

开放式问题基本上是关于思维发散的能力，以及某个领域的深度和广度。基本都是结合技术问题或者工作内容来问的。

比如:实现某项技术的N种方式？某项技术的实现原理？与什么相比有什么优缺点？你对这项技术有什么想法？

面试官的“回应”

就实际情况做回答，提前准备的时候多发散，多思考，多总结。这一块是可以自己准备的加分项。发散性问题主要是看自己平时积累。首先基础知识要牢固，同时也要了解最新技术动态。面对这类问题切记也不能答非所问而跑题了。