如何應(yīng)對web開發(fā)面試中項目經(jīng)驗這一難關(guān)

這篇文章給大家介紹如何應(yīng)對web開發(fā)面試中項目經(jīng)驗這一難關(guān)，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

說起面試

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

STAR法則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 等等等等。

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

面試場景還原

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

面試官：

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

我：

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

面試官：

那問題解決了么？

我：

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

面試官：

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

我：

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

面試官：

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

我：

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

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

面試官：

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

我：

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

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

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

面試官：

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

我：

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

總結(jié)一下

面試官的「套路」

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

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

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

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

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

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

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

關(guān)于如何應(yīng)對web開發(fā)面試中項目經(jīng)驗這一難關(guān)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。