[[395455]]

前言

本篇文章的作者是來自阿里淘系用戶增長(zhǎng)前端團(tuán)隊(duì)的“亦遜”，18年作為雙非本科生通過層層面試，校招進(jìn)入阿里，今天以過來人的身份給大家分享在面試官問起項(xiàng)目經(jīng)驗(yàn)時(shí)，該如何回答。

說起面試

說起校招面試，大家總會(huì)感覺心慌慌?？赡苁遣蛔孕牛赡苁歉杏X好多沒準(zhǔn)備好。沒關(guān)系，既然投遞了簡(jiǎn)歷，又通過了篩選，就不要膽怯。首先要知道面試官都是抱著想把你招進(jìn)來的想法的，只是想多了解你的具體情況。既然面試官愿意花時(shí)間和你聊，那么證明自己還是有實(shí)力的，有被看中的閃光點(diǎn)，那么有什么好心虛的呢，勇敢自信的面對(duì)就好了。

STAR法則

在寫簡(jiǎn)歷和面試過程中，都需要描述工作經(jīng)驗(yàn)或個(gè)人經(jīng)歷。優(yōu)秀的面試者往往會(huì)用 STAR 法則來建立個(gè)人事件，讓面試官可以更好地通過你過去的經(jīng)歷來判斷你的個(gè)人能力和潛質(zhì)。

重新回顧一下 STAR 法則四要素：

• Situation：事情是在什么情況下發(fā)生，基于一個(gè)怎樣的背景；

• Task：你是如何明確你的任務(wù)的；

• Action：針對(duì)這樣的情況分析，你采用了什么行動(dòng)方式，具體做了哪些工作內(nèi)容；

• Result：結(jié)果怎樣，帶來了什么價(jià)值，在整個(gè)過程中你學(xué)到了什么，有什么新的體會(huì)。

往往大部分同學(xué)一上來就直接介紹做了什么以及實(shí)現(xiàn)的過程，條理也比較清晰，內(nèi)容也頗具技術(shù)含量。但很多同學(xué)很容易忽略了 Situation 和 Result 的部分也就是背景和結(jié)果?；蛘呤窃诿嬖嚬龠M(jìn)一步了解追問細(xì)節(jié)的時(shí)候容易驚慌失措。這些原因往往都是由于面試前對(duì)自己的經(jīng)歷沒有將來龍去脈講清楚以及總結(jié)不夠全面和深入。

舉個(gè)例子：比如有的同學(xué)提到了在 XXX 項(xiàng)目過程中實(shí)現(xiàn)了一個(gè) Webpack 插件 XXX，這個(gè)插件的功能是 XXXX 并且在 Github 上開源了。整個(gè)實(shí)現(xiàn)過程和思路都比較清晰，面試官聽的也是饒有興致，甚至回想起年輕時(shí)某個(gè)夜晚加班研究 Webpack 插件的青澀時(shí)光。

盡管這樣面試官也同樣希望了解當(dāng)時(shí)項(xiàng)目的背景，是什么原因?qū)е履阋氲酵ㄟ^做 Webpack 插件來解決而不是通過其他工具，以及這個(gè)插件給項(xiàng)目帶來了怎樣的價(jià)值（是構(gòu)建性能還是其他？）。背景和結(jié)果是面試官非?？粗氐囊徊糠?，必須拿出足夠的理由和價(jià)值來說服面試官，否則盡管你在這個(gè)項(xiàng)目投入了足夠的精力但最終并沒有為你的面試評(píng)價(jià)加分，這是十分可惜的。

這時(shí)候有的同學(xué)也會(huì)想：**我的項(xiàng)目只是個(gè)人/學(xué)校的練手項(xiàng)目，對(duì)于項(xiàng)目結(jié)果我想不到非常有吸引眼球的價(jià)值。**那么這個(gè)時(shí)候你不妨說一下你在項(xiàng)目中學(xué)到內(nèi)容，比如在這個(gè) Webpack 插件例子中，就可以說一下：

• Compiler 和 Compilation 以及它們的區(qū)別；

• Webpack 是通過什么方式實(shí)現(xiàn)了插件之間的關(guān)系以及保證它們的有序性；

• 開發(fā)插件時(shí)需要依據(jù)當(dāng)前配置是否使用了某個(gè)其他的插件而做下一步?jīng)Q定，如何判斷 Webpack 當(dāng)前使用了哪些插件；

• 開發(fā)插件過程中借鑒了其他插件的思路，我對(duì)這個(gè)插件源碼的理解；

• 等等等等。

以上的在實(shí)際開發(fā) Webpack 插件過程中大部分都會(huì)遇到，這些問題如果你有記錄和總結(jié)也能作為 Result。

面試場(chǎng)景還原

下面筆者場(chǎng)景還原一下項(xiàng)目經(jīng)歷面試的過程，借助 STAR 法則來簡(jiǎn)單介紹一下自己之前在做瀏覽器API兼容性檢查器的過程（通過口述將一件事情清楚描述在面試中也是非常重要的，以下均為口述方式，所以沒有圖）。

面試官：

我看到你在簡(jiǎn)歷中提到實(shí)現(xiàn)了一個(gè)檢查瀏覽器 API 兼容性的工具，可以介紹一下么？

我：

（Situation）好的，當(dāng)時(shí)的情況實(shí)際上是一次線上的用戶的輿情反饋說頁面白屏/打不開，通過 JSError 日志的排查我發(fā)現(xiàn)最近出現(xiàn)大量類似 IntersectionObserver is not defined 的日志，同時(shí)和我最近一次發(fā)布的模塊曝光需求時(shí)間線是差不多吻合的，所以很快定位到了是當(dāng)時(shí)使用瀏覽器 IntersectionObserver API 做 DOM 曝光時(shí)沒有考慮到兼容性的問題。

面試官：

那問題解決了么？

我：

是的，當(dāng)時(shí)定位到問題后通過增加 polyfill 的方式很快解決了這個(gè)問題。**（Task）**后來我借著這個(gè)問題我自己也進(jìn)行了思考，其實(shí)隨著操作系統(tǒng)和瀏覽器的更新，越來越多的 JS/瀏覽器的新特性開始被支持。為前端開發(fā)帶來便利的同時(shí)，也會(huì)帶來一些不可避免的兼容性問題。兼容代碼（polyfill）的忽視很容易造成不可預(yù)估的問題。但如果只依賴開發(fā)人員人工檢查兼容性問題并不是最優(yōu)雅的解決方案，畢竟人工的難免會(huì)有遺漏。所以我想是不是能夠開發(fā)一個(gè)集成現(xiàn)有的兼容性檢查規(guī)則的工具將這個(gè)過程自動(dòng)化。

面試官：

不錯(cuò)，詳細(xì)介紹一下具體過程吧。

我：

（Action）恩，這個(gè)想法誕生之后我就去了解了一下常用的前端兼容性檢查網(wǎng)站：Caniuse 和 MDN 這兩個(gè)是我比較常用的。后來發(fā)現(xiàn)這兩個(gè)網(wǎng)站的檢查數(shù)據(jù)實(shí)際上在 Github 上都對(duì)應(yīng)維護(hù)了一份靜態(tài)的檢查規(guī)則（caniuse-db 和 mdn-browser-compat-data），這些數(shù)據(jù)都是具有特定結(jié)構(gòu)的 JSON 文件，盡管這兩者對(duì)瀏覽器支持程度描述的方式不太一樣，但已經(jīng)能滿足得到兼容性數(shù)據(jù)的基本要求。接下來就是對(duì)代碼的分析檢查，將代碼和這些規(guī)則進(jìn)行比較。這個(gè)過程需要對(duì)代碼進(jìn)行語法邏輯分析，所以我想到了用 Babel 將代碼轉(zhuǎn)化成 AST 語法樹進(jìn)行特定遍歷。同時(shí)我整理常規(guī)的 API 的調(diào)用方式我發(fā)現(xiàn)不外乎幾種，比如：NewExpression（構(gòu)造表達(dá)式） 和 CallExpression（調(diào)用表達(dá)式）。當(dāng)這些信息都掌握清楚后我覺得這件事情是具備技術(shù)可行性的。

面試官：

恩，這個(gè)實(shí)現(xiàn)過程有沒有遇到哪些問題？你是怎么解決的？

我：

（Action）恩有的，剛剛提到 Caniuse 和 MDN 維護(hù)的靜態(tài) JSON 數(shù)據(jù)，我在實(shí)現(xiàn)過程中將這兩份數(shù)據(jù)進(jìn)行了格式的統(tǒng)一，目的是將兩塊數(shù)據(jù)進(jìn)行互補(bǔ)同時(shí)方便后續(xù)進(jìn)行檢查比較。最終事實(shí)上得到了接近 9w 條數(shù)據(jù)，如果直接拿來對(duì)比是很影響效率的，所以當(dāng)時(shí)利用 browserlist 可以配置指定目標(biāo)檢查的瀏覽器范圍，比如 iOS Safari 9 以上，通過這一層去過濾在該范圍內(nèi)沒有兼容性問題的數(shù)據(jù)，從而減少對(duì)比提升效率，也為開發(fā)者提供靈活的配置能力。第二個(gè)問題同樣也是檢查的性能優(yōu)化，是通過 isReferencedIdentifier 去檢測(cè)標(biāo)識(shí)符是否有被真正引用到。

最后是這個(gè)工具與如何接入發(fā)布流程的管控，由于公司的發(fā)布流程采用的是云構(gòu)建的方式，所以我在發(fā)布之前先經(jīng)過這個(gè)工具的校驗(yàn)，并且將檢查的結(jié)果打通消息通知和郵件系統(tǒng)，**（ Result ）**幫助其他人在發(fā)布前得到項(xiàng)目代碼的瀏覽器 API 兼容性檢查報(bào)告，避免了這類問題的再次出現(xiàn)。這次的經(jīng)驗(yàn)幫助我加深了對(duì) Babel 和 AST 的理解。

面試官：

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

我：

在解析成 AST 過程中有兩個(gè)階段：詞法分析和語法分析。

• 詞法分析階段：字符串形式的代碼轉(zhuǎn)換為令牌（tokens）流，令牌類似于AST中的節(jié)點(diǎn)；

• 語法分析階段：把一個(gè)令牌流轉(zhuǎn)化為 AST 的形式，同時(shí)把令牌中的信息轉(zhuǎn)化為AST的表述結(jié)構(gòu)。

面試官：

你項(xiàng)目中說的 AST 遍歷的過程能再詳細(xì)說說么？

我：

Babel 在處理一個(gè)節(jié)點(diǎn)時(shí)，是以訪問者的形式獲取節(jié)點(diǎn)信息并進(jìn)行相關(guān)操作。這種方式是通過 Visitor 對(duì)象來完成的，Visitor 對(duì)象中定義了對(duì)于各種節(jié)點(diǎn)的訪問函數(shù)，這樣就可以針對(duì)不同的節(jié)點(diǎn)做出不同的處理。比如我在項(xiàng)目過程中主要針對(duì) NewExpression 和 CallExpression 進(jìn)行處理，通過 path 參數(shù)對(duì)節(jié)點(diǎn)以及節(jié)點(diǎn)的父子節(jié)點(diǎn)以及進(jìn)行判斷篩選，balabala。

總結(jié)一下

面試官的「套路」

面試時(shí)所問的問題基本分為兩種：具象的問題和開放性的問題。

具象的問題基本都會(huì)參考工作經(jīng)驗(yàn)按照 STAR 法則來進(jìn)行，主要是了解基本的素養(yǎng)，技術(shù)深度和潛力。

開放性的問題基本是考察思維發(fā)散能力，考察在某個(gè)領(lǐng)域的深度和廣度，基本上會(huì)結(jié)合技術(shù)問題來問，或者是結(jié)合工作內(nèi)容來問。

比如：實(shí)現(xiàn)某種技術(shù)的 n 種方法？某種技術(shù)的實(shí)現(xiàn)原理？和什么什么相比有哪些優(yōu)缺點(diǎn)？你對(duì)這項(xiàng)技術(shù)的思考是什么？

面試者的「應(yīng)對(duì)」

1. 就實(shí)際情況做回答，提前準(zhǔn)備的時(shí)候多發(fā)散，多思考，多總結(jié)。這一塊是可以自己準(zhǔn)備的加分項(xiàng)。

2. 發(fā)散性問題主要是看自己平時(shí)積累。首先基礎(chǔ)知識(shí)要牢固，同時(shí)也要了解最新技術(shù)動(dòng)態(tài)。面對(duì)這類問題切記也不能答非所問而跑題了。