前言
本篇文章的作者是來自阿里淘系用戶增長前端團隊的“亦遜”，18年作爲雙非本科生通過層層面試，校招進入阿里，今天以過來人的身份給大家分享在面試官問起項目經驗時，該如何回答。
“我自己是一名從事了6年web前端開發的老程序員（我的微信：web-xxq），今年年初我花了一個月整理了一份最適合2019年自學的web前端全套培訓教程（視頻+源碼+筆記+項目實戰），從最基礎的HTML+CSS+JS到移動端HTML5以及各種框架和新技術都有整理，打包給每一位前端小夥伴，這裏是前端學習者聚集地，歡迎初學和進階中的小夥伴（所有前端教程關注我的微信公衆號：web前端學習圈，關注後回覆“2020”即可領取）。
說起面試
說起校招面試，大家總會感覺心慌慌。可能是不自信，可能是感覺好多沒準備好。沒關係，既然投遞了簡歷，又通過了篩選，就不要膽怯。首先要知道面試官都是抱着想把你招進來的想法的，只是想多瞭解你的具體情況。既然面試官願意花時間和你聊，那麼證明自己還是有實力的，有被看中的閃光點，那麼有什麼好心虛的呢，勇敢自信的面對就好了。
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 種方法？某種技術的實現原理？和什麼什麼相比有哪些優缺點？你對這項技術的思考是什麼？
面試者的「應對」
- 就實際情況做回答，提前準備的時候多發散，多思考，多總結。這一塊是可以自己準備的加分項。
- 發散性問題主要是看自己平時積累。首先基礎知識要牢固，同時也要了解最新技術動態。面對這類問題切記也不能答非所問而跑題了。