前言
本篇文章的作者是來自阿里淘系使用者增長前端團隊的“亦遜”，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 日誌的排查我發現最近出現大量類似 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 種方法？某種技術的實現原理？和什麼什麼相比有哪些優缺點？你對這項技術的思考是什麼？
面試者的「應對」
- 就實際情況做回答，提前準備的時候多發散，多思考，多總結。這一塊是可以自己準備的加分項。
- 發散性問題主要是看自己平時積累。首先基礎知識要牢固，同時也要了解最新技術動態。面對這類問題切記也不能答非所問而跑題了。
最後
建立了一個「前端校招面試衝刺互助群」，歡迎加「taoxiaozhao233」 入群~