序言

第一集该文的译者是源自穆萨Niederbronn使用者快速增长后端工程项目组的亦逊,18年做为莱齐研究生透过一层层复试,校招步入穆萨,那时以占卜师的身分给我们撷取在辩手问道工程项目实战经验时,该什么样提问。

讲起复试

讲起校招复试,我们协进会觉得Nagaur。可能将是不自信心,可能将是觉得好些没准备好。说实话,难道递送了对个人简历,又透过了甄选,就千万别优柔寡断。具体来说要知道辩手都是抱着想把你新来的设想的,而已想多介绍你的详细情况。难道辩手愿花天数和你聊,所以断定自己还是有整体实力的,有被看上的布齐,所以有甚么好优柔寡断的呢,坚忍自信心的直面就好了。

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 日志的排查我发现最近出现大量类似 IntersectionObserver is not defined 的日志,同时和我最近一次发布的模块曝光需求天数线是差不多吻合的,所以很快定位到了是当时使用浏览器 IntersectionObserver 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。

总结呵呵

辩手的「套路」

复试时所问的问题基本分为两种:具象的问题和开放性的问题。

具象的问题基本都会参考组织工作实战经验按照 STAR 自然法则来进行,主要是介绍基本的素养,技术深度和潜力。

开放性的问题基本是考察思维发散潜能,考察在某个领域的深度和广度,基本上会结合技术问题来问,或者是结合组织工作内容来问。

比如:实现某种技术的 n 种方法?某种技术的实现原理?和甚么甚么相比有哪些优缺点?你对这项技术的思考是甚么?

复试者的「应对」

  • 就实际情况做提问,提前准备的时候多发散,多思考,多总结。这一块是可以自己准备的加分项。
  • 发散性问题主要是看自己平时积累。具体来说基础知识要牢固,同时也要介绍最新技术动态。直面这类问题切记也不能答非所问而跑题了。
star法则(star法则成功故事例文)-第1张