面试被问项目经验不用慌，按这个步骤回答绝对惊艳

大家好，我是若川。常有小伙伴问，面试时项目经验怎么回答，经常会分享这篇文章给TA。本文经授权转载。面试、学习源码系列、年度总结、JS基础系列

前言

本篇文章的作者是来自阿里淘系用户增长前端团队的“亦逊”，18年作为双非本科生通过层层面试，校招进入阿里，今天以过来人的身份给大家分享在面试官问起项目经验时，该如何回答。

说起面试

说起校招面试，大家总会感觉心慌慌。可能是不自信，可能是感觉好多没准备好。没关系，既然投递了简历，又通过了筛选，就不要胆怯。首先要知道面试官都是抱着想把你招进来的想法的，只是想多了解你的具体情况。既然面试官愿意花时间和你聊，那么证明自己还是有实力的，有被看中的闪光点，那么有什么好心虚的呢，勇敢自信的面对就好了。

STAR法则

在写简历和面试过程中，都需要描述工作经验或个人经历。优秀的面试者往往会用 STAR 法则来建立个人事件，让面试官可以更好地通过你过去的经历来判断你的个人能力和潜质。

重新回顾一下 STAR 法则四要素：

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

往往大部分同学一上来就直接介绍做了什么以及实现的过程，条理也比较清晰，内容也颇具技术含量。但很多同学很容易忽略了 Situation 和 Result 的部分也就是背景和结果。或者是在面试官进一步了解追问细节的时候容易惊慌失措。这些原因往往都是由于面试前对自己的经历没有将来龙去脉讲清楚以及总结不够全面和深入。

举个例子：比如有的同学提到了在 XXX 项目过程中实现了一个 Webpack 插件 XXX，这个插件的功能是 XXXX 并且在 Github 上开源了。整个实现过程和思路都比较清晰，面试官听的也是饶有兴致，甚至回想起年轻时某个夜晚加班研究 Webpack 插件的青涩时光。

尽管这样面试官也同样希望了解当时项目的背景，是什么原因导致你要想到通过做 Webpack 插件来解决而不是通过其他工具，以及这个插件给项目带来了怎样的价值（是构建性能还是其他？）。背景和结果是面试官非常看重的一部分，必须拿出足够的理由和价值来说服面试官，否则尽管你在这个项目投入了足够的精力但最终并没有为你的面试评价加分，这是十分可惜的。

这时候有的同学也会想：我的项目只是个人/学校的练手项目，对于项目结果我想不到非常有吸引眼球的价值。那么这个时候你不妨说一下你在项目中学到内容，比如在这个 Webpack 插件例子中，就可以说一下：

Compiler 和 Compilation 以及它们的区别；
Webpack 是通过什么方式实现了插件之间的关系以及保证它们的有序性；
开发插件时需要依据当前配置是否使用了某个其他的插件而做下一步决定，如何判断 Webpack 当前使用了哪些插件；
开发插件过程中借鉴了其他插件的思路，我对这个插件源码的理解；
等等等等。

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

面试场景还原

下面笔者场景还原一下项目经历面试的过程，借助 STAR 法则来简单介绍一下自己之前在做浏览器API兼容性检查器的过程（通过口述将一件事情清楚描述在面试中也是非常重要的，以下均为口述方式，所以没有图）。

面试官：

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

我：

（Situation）好的，当时的情况实际上是一次线上的用户的舆情反馈说页面白屏/打不开，通过 JSError 日志的排查我发现最近出现大量类似 InterpObserver is not defined 的日志，同时和我最近一次发布的模块曝光需求时间线是差不多吻合的，所以很快定位到了是当时使用浏览器 InterpObserver API 做 DOM 曝光时没有考虑到兼容性的问题。

面试官：

那问题解决了么？

我：

是的，当时定位到问题后通过增加 polyfill 的方式很快解决了这个问题。（Task）后来我借着这个问题我自己也进行了思考，其实随着操作系统和浏览器的更新，越来越多的 JS/浏览器的新特性开始被支持。为前端开发带来便利的同时，也会带来一些不可避免的兼容性问题。兼容代码（polyfill）的忽视很容易造成不可预估的问题。但如果只依赖开发人员人工检查兼容性问题并不是最优雅的解决方案，毕竟人工的难免会有遗漏。所以我想是不是能够开发一个集成现有的兼容性检查规则的工具将这个过程自动化。

面试官：

不错，详细介绍一下具体过程吧。

我：

（Action）恩，这个想法诞生之后我就去了解了一下常用的前端兼容性检查网站：Caniuse 和 MDN 这两个是我比较常用的。后来发现这两个网站的检查数据实际上在 Github 上都对应维护了一份静态的检查规则（caniuse-db 和 mdn-browser-compat-data），这些数据都是具有特定结构的 JSON 文件，尽管这两者对浏览器支持程度描述的方式不太一样，但已经能满足得到兼容性数据的基本要求。接下来就是对代码的分析检查，将代码和这些规则进行比较。这个过程需要对代码进行语法逻辑分析，所以我想到了用 Babel 将代码转化成 AST 语法树进行特定遍历。同时我整理常规的 API 的调用方式我发现不外乎几种，比如：NewExpression（构造表达式）和 CallExpression（调用表达式）。当这些信息都掌握清楚后我觉得这件事情是具备技术可行性的。

面试官：

恩，这个实现过程有没有遇到哪些问题？你是怎么解决的？

我：

（Action）恩有的，刚刚提到 Caniuse 和 MDN 维护的静态 JSON 数据，我在实现过程中将这两份数据进行了格式的统一，目的是将两块数据进行互补同时方便后续进行检查比较。最终事实上得到了接近 9w 条数据，如果直接拿来对比是很影响效率的，所以当时利用 browserlist 可以配置指定目标检查的浏览器范围，比如 iOS Safari 9 以上，通过这一层去过滤在该范围内没有兼容性问题的数据，从而减少对比提升效率，也为开发者提供灵活的配置能力。第二个问题同样也是检查的性能优化，是通过 isReferencedIdentifier 去检测标识符是否有被真正引用到。

最后是这个工具与如何接入发布流程的管控，由于公司的发布流程采用的是云构建的方式，所以我在发布之前先经过这个工具的校验，并且将检查的结果打通消息通知和邮件系统，（Result）帮助其他人在发布前得到项目代码的浏览器 API 兼容性检查报告，避免了这类问题的再次出现。这次的经验帮助我加深了对 Babel 和 AST 的理解。

面试官：

那你了解 Babel parse AST 的过程么？

我：

在解析成 AST 过程中有两个阶段：词法分析和语法分析。

词法分析阶段：字符串形式的代码转换为令牌（tokens）流，令牌类似于AST中的节点；语法分析阶段：把一个令牌流转化为 AST 的形式，同时把令牌中的信息转化为 AST 的表述结构。

面试官：

你项目中说的 AST 遍历的过程能再详细说说么？

我：

Babel 在处理一个节点时，是以访问者的形式获取节点信息并进行相关操作。这种方式是通过 Visitor 对象来完成的，Visitor 对象中定义了对于各种节点的访问函数，这样就可以针对不同的节点做出不同的处理。比如我在项目过程中主要针对 NewExpression 和 CallExpression 进行处理，通过 path 参数对节点以及节点的父子节点以及进行判断筛选，balabala。