前言
本篇文章的作者是來自阿裡淘系用戶增長前端團隊的“亦遜”，18年作為雙非本科生通過層層面試，校招進入阿裡，今天以過來人的身份給大家分享在面試官問起項目經驗時，該如何回答。
說起面試
說起校招面試，大家總會感覺心慌慌。可能是不自信，可能是感覺好多沒準備好。沒關系，既然投遞了簡曆，又通過了篩選，就不要膽怯。首先要知道面試官都是抱着想把你招進來的想法的，隻是想多了解你的具體情況。既然面試官願意花時間和你聊，那麼證明自己還是有實力的，有被看中的閃光點，那麼有什麼好心虛的呢，勇敢自信的面對就好了。
STAR法則
在寫簡曆和面試過程中，都需要描述工作經驗或個人經曆。優秀的面試者往往會用 STAR 法則來建立個人事件，讓面試官可以更好地通過你過去的經曆來判斷你的個人能力和潛質。
重新回顧一下 STAR 法則四要素：
往往大部分同學一上來就直接介紹做了什麼以及實現的過程，條理也比較清晰，内容也頗具技術含量。但很多同學很容易忽略了 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 種方法？某種技術的實現原理？和什麼什麼相比有哪些優缺點？你對這項技術的思考是什麼？
面試者的「應對」
更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
