聊聊前端面試

? ?大家好，我是若川。今天分享一篇面試相關的文章。

點擊下方卡片關注我、加個星標，或者查看源碼等系列文章。學習源碼整體架構系列、年度總結、JS基礎系列

最近 Zoom 國內又開放招聘了，我們組有了前端的 HC，所以我也參加了幾場面試。合肥整體的前端氛圍很一般，厲害的人比較少，來參加面試的偏初階的比較多，不過我們面試也不卷，很少出一些復雜的算法題，面試難度并不高。我們對候選人的要求也沒有那么高，基本上你能達到 p6 的水平，就能通過我的面試。當然，如果你是工作年限較久（六年以上）的老玩家，我對你的期望和要求也會相應的提高。

在面試的過程中我也發現了很多問題，因此作為一個 9 年工作經驗和 7 年面試經驗的老兵，我想分享一些經驗給你，希望看完后對你有所幫助。

面試的目的

先想想看，為啥要面試？

首先，面試是一個雙向選擇的過程，在這個過程中，面試官通過一些提問和交流來判斷候選人是否合適這個工作崗位，他是一個怎樣的人，你未來想不想和他一同共事；那么候選人也可以通過面試的過程來感受到面試官是否專業，是否是自己心儀的公司或者是團隊。

其次，對于候選人來說，面試的過程也可以發現自己的不足之處，通過一些專業性的技術交流可以了解自己對于某些知識點的理解和掌握的情況，以便之后查漏補缺。此外，通過對自己經歷和項目的描述，也可以鍛煉自己的表達和溝通的能力，如果在面試中發現自己并沒有發揮好，那么則可以加強這方面的練習。

最后，對于用人單位來說，面試除了幫助自己招到合適靠譜的人才之外，也是豎立自己公司形象的機會，對于整個面試流程安排夠不夠專業，面試官的資歷夠不夠深，能不能讓候選人有個不錯的面試體驗，都多多少少會影響公司在業內的口碑。因此，很多大廠都會對面試官的級別要求比較高，并會給予一定的面試培訓（我在百度的時候就有幸被培訓過）。

寫給候選人

對于候選人，我主要想從簡歷和面試準備這兩個方面給你一些指導。

簡歷

寫簡歷的目的，就是讓面試官和 HR 能從幾頁紙中對你的過往經歷有個大致的認識。首先，你得保證簡歷的真實性，不能有半點造假，因為這涉及到一個人的誠信問題。有些人為了讓自己簡歷能被篩選通過，在學歷和工作經歷上作假，有些人為了讓自己能多談一點薪資在流水上作假。對于知名企業，對這些造假行為是零容忍的，因為很多企業都會對候選人做專業的背調，一旦查出來有作假行為，不僅 offer 沒了，也可能會有永不錄用的風險。

那么有些人可能會問：我學歷不行，又沒啥工作經驗，不造假，簡歷都通不過呀。

不好意思，如果你的資歷不夠，那么你暫時就是進不了一些名企，可以先進一些小公司鍛煉，然后有一定工作經驗，且技術能力提升后，再考慮進大廠。你可以想想看，為啥一些優秀的本科生和碩士生一畢業就進入了名企，那是別人寒窗數十年努力學習換來的，所以后面路自然就好走一些。如果你年輕時候因為不懂事或者一些不可抗力因素而荒廢了學業，那么起點低也是正常的，但是這樣并不影響你未來通過努力學習和奮斗改變命運。

名企的 HR 對候選人的背景要求高，也是從一個概率學的角度來考慮的，畢竟，好的學校和工作背景意味著更好的學習能力和工作能力，這樣的候選人符合崗位要求的概率自然就更高。

對于在小公司工作的人，進入大廠也并不是不可能，但是你可能要花費比一般人更多的努力去學習，那些學歷背景不好最后也成為大佬的人，付出的努力，背后的辛酸，可能只有他們自己知道。

另外，通過大廠外包轉正，或者結識圈內好友內推大廠，都會多一份成功的機會。

回到簡歷本身，除了真實性，第二個要點就是要突出重點。簡歷并不是記流水賬，你不需要把之前所有過往的工作經歷都寫在簡歷上，面試官也沒時間看。建議你給每段工作經歷中挑出一兩個重點的項目，詳細去寫項目的技術重點和難點，以及你在其中負責的角色，做的事情。

對于技能這塊，也是要突出你擅長的技術棧，弱化甚至不用去寫一些你不熟悉的技術棧。有些人在技能方面就是在羅列一些技術名詞，這樣毫無意義，一旦面試官去問其中一些技術點，而你又不能很好的回答，是非常減分的。

讀到這里，可能有些人會說，我之前待的都是一些小公司，業務簡單，項目都不難，沒啥可寫的。但你有沒有想過，你每天的開發工作，有沒有痛點或者不爽的地方？比如經常通過 CV 大法拷貝代碼，你有想過抽離和復用這些模塊嗎？公共 JS 模塊的共享，你是通過拷貝代碼，還是自己搭一個 NPM 私服？所有項目都放在一個 repo 下，編譯打包速度慢，有沒有想過拆成 multiple repo 或者是 mono repo？開發上線流程不規范，有沒有想過參考一些業內成熟的方案搭建一套 CI/CD 方案呢？使用一些開源庫遇到問題，你是去百度或者等著別人去解決，還是自己研究源碼然后去提個 PR 呢？

再舉一個正面的例子，多年前在知乎上，我看到一個在小公司做小程序的哥們，因為小程序的審核特別慢，而且也不允許動態加載和通過 new Function 或者 eval 的方式運行 JS 腳本，他就想到一個法子，大致就是通過把 JS 腳本當做數據來下載，然后通過 JS 實現的 JavaScript 解釋器去動態跑這些代碼。雖然這種方式對開發來說可能不夠優雅，但也解決了他大部分的需求，另外這種愛折騰技術的精神，大廠能不愛嗎？

除了突出重點之外，簡歷還需要有亮點。近幾年選擇做程序員的人越來越多，競爭越來越激烈，那么如何讓你的簡歷脫穎而出，就需要你在簡歷中有一些亮點了。

那么什么算亮點呢，對于應屆生來說，比如優秀的學歷背景、名企實習經歷、競賽獲獎，知名期刊發表過論文等等。對于有工作經驗的人來說，比如名企的工作經歷，有技術博客（有一定高質量的博文），做過知名的開源項目或者參與知名開源項目的共建，寫過書等等。

當然，亮點只是加分項，它不能決定你是否能通過面試，但至少從簡歷上看，面試官會對你多一分興趣。

不過你要記住，如果沒有亮點，那就不要寫了，比如我看過一些候選人的博客，內容簡單，而且從時間上來看都是近期的寫作，有非常大的專門為面試而準備的嫌疑；還有一部分的候選人貼的 GitHub 地址，點進去后空空如也，這些反而是減分項。

最后，簡歷上不要寫一些偏主觀的話，比如“我對技術感興趣”，你對技術感不感興趣，從你有沒有寫過技術博客，有沒有參與過開源項目，或者翻譯過一些國外技術文章等等一些事情就可以看出來。

面試準備

那么，一旦你的簡歷通過了篩選，進入到面試階段，你需要做哪些準備呢？

首先，技術面主要是考察的就是技術能力，面試官對候選人的技術評價，通常會從基礎知識、知識深度、知識廣度三個方面來考察。在我看來，知識點主要是靠平時工作和學習的積累，你需要構建自己的知識體系，把這些知識點都牢記在自己的腦海中，那么面試的時候自然就可以和面試官談笑風生。

前端的知識點多而雜，有些人會在面試前幾天找一些常見的面試題來看，但是前端知識點那么多，短時間想搞透是很難的。所以我的建議是要把學習融入到平時，如果是你工作中遇到的技術，那么你必須要深刻理解其背后的本質，并做一些延伸學習。除工作之外，你也可以找一些和工作相關但可能暫時沒有用到的技術學習，我公眾號里推過很多課程，大部分課程都是非常值得學習的，我自己也做了幾門 Vue.js 的課程，如果有條件，跟著名師學習要比自己踩坑效率高的多，一旦學進去了，投入產出比也是非常高的。

不要跟我說平時工作太忙沒時間學習，那都是借口，即使你晚上加班到 12 點，你有沒有想過你的有效工作時間是多少，中間有沒有聊天、刷抖音、頭條、微博，你的工作效率是怎樣的，多少時間是在開發，多少時間是在改 bug，多少時間在開低效會議。

如果有心學習，每天抽兩個小時不成問題，如果你真的每天 12 小時滿負荷工作，那么你應該換個工作了，注意自己的身體吧。

我是反對刷面試題的，即使你在刷題，那你也不應該去背他們，而是查漏補缺，前端知識點很多，有些你沒接觸過的，不會也沒有關系，但是你會的，你一定要把它們很好地表述出來。

為什么背題沒有用，舉個例子，“從輸入 URL 到頁面渲染中間發生什么” 這是一個老生常談的問題，有些候選人回答這個問題感覺一看就是準備過的，但是一細問都會露餡，比如 TCP 的三次握手，每次發了回了什么樣的包？瀏覽器解析文檔過程中，遇到外鏈的 JS，會不會阻塞渲染，遇到外鏈的 CSS，會不會阻塞渲染，如果阻塞了，原因是什么，如果沒阻塞，原因又是什么？一道題的背后，往往蘊含著非常多的知識點，如果你知識走馬觀花似地只背大致流程，意義并不是很大。

有些人可能會說，這道題細節太多了，我不可能都會啊。確實是很多，我也并不要求你全部掌握，我想表達的是，你可以從這道題背后，延伸學習很多基礎知識。如果你不了解其背后深層次的原理，你去做性能優化基本都是無從下手。但是，如果你掌握的細節越多，就能說明你的知識儲備很豐富，有些時候會讓面試官眼前一亮。

其次，面試過程中面試官通常會問你簡歷中的項目的技術難點，技術挑戰，你在其中的角色，以及怎么去解決其中遇到的問題的。這塊是可以好好準備一下的，因為這里面不僅能體現出你的技術能力和思考能力，還能體現出你的表達能力。因此，平時多做技術分享，有機會參與一些述職演講都能很好地幫助你提升這方面的能力。

另外，聽說現在很多大廠內卷嚴重，面試喜歡問算法題，那么要不要突擊刷算法題呢？

在我看來，算法題的學習也是平時工作積累下來的，比如背包問題、圖和樹的遍歷、貪心算法，在工作中我都接觸并實踐過，那么自然對它們的理解更加深刻。

如果你確實工作中接觸不到什么算法題，但你對算法感興趣，可以抽點時間去學習一些常見的數據結構和算法。除此之外，你也可以去看一些源碼，也能學習到一些常規算法的實現。在我看來，代碼看的多了，寫的多了，自然可以接觸到算法相關的知識。

當然，面試官出算法題的目的也不是要考倒你，通常這只是一個加分項，主要考察你的思維能力，如果面試中真的遇到一些算法題卡殼了，你也不要放棄，至少要說一些你的思路，完全放棄是下下策。

要記住，面試是一個平等的過程，作為候選人就是要盡量把自己的能力和優勢展示給面試官，尤其是一些匹配崗位需求的技能，可以 show 出來。不要覺得自己是來找工作的就顯得唯唯諾諾的，要自信一些（但不能狂），這也能給面試官留個好印象。

最后，面試前也要對你面的公司和團隊有個大致的了解，如果這個團隊還做過一些對外輸出的事情，比如有開源項目或者是技術博客，可以重點關注一下，在面試的時候也可以聊一聊，因為人都是有虛榮心的，有些面試官發現自己團隊做的事情被人關注了，自然會很高興，對你的印象也會更好。

通常面試最后面試官會問你有什么問題需要提問的，千萬不要傻傻的去問對方對自己面試的評價如何，如果你對團隊感興趣，可以問一下團隊的技術棧，所做的事情，團隊的人員情況，技術氛圍等等，也可以問問如果自己有幸進入這個團隊，大致要負責哪方面的事情。如果能明顯感覺自己這次面試失敗了，也可以虛心請教面試官自己有哪些不足，或許能找到自己未來努力的方向。

寫給面試官

對于面試官，我想說面試官有些時候代表的是一個公司的門面。面試官的專業能力是要相當過硬的，因為他需要從各個方面考察候選人的技術能力和綜合素質是否達到自己的用人標準。

我在百度的時候面試官最低級別都是 T5（相當于阿里的 p6）起步，而且會接受專業的培訓，并且通常面試官要和候選人平級或者是更高的級別，否則可能會因為段位不夠不能夠充分考察出應有的能力而不能做出相對客觀的面試評價。

有些公司不知道出于什么考慮派一些段位較低的面試官出站，有些時候還會鬧出一些不愉快的事情讓公司的口碑和形象受損。在我看來，招聘還是一件很嚴肅的事情，因為你招來的人未來是要和你一起共事的，所以一定要非常重視。

那么，作為面試官，你應該如何面試呢？

對于前端茫茫多的知識點，想短時間內都考察一遍不現實，而且面試官也很忙，有些時候面試占據了太多的工作時間。所以我的經驗是出一套難度適中的筆試題，HTML、CSS、JS、廣度、編程、算法題都有涉及，然后對于工作五年之內，預期是 p6 及以下的候選人，先讓他們做題。然后根據筆試的結果，就能夠篩掉一批不合適的候選人。

那么筆試題通過了，面試的時候就可以針對筆試題的知識點，做一些深入的提問，通常問到對方不會或者你不會為止，這樣就可以充分考察候選人對某個知識點的掌握程度。

除了筆試題的部分，剩下的面試我建議是針對候選人簡歷中提到的技術深入提問，而不要問他不了解的技術，舉個例子：如果對方是一個 React 玩家，即使你團隊的技術棧是 Vue，我也不建議你去問他 Vue 的問題，因為毫無意義，不過你倒是可以問他 React 和 Vue 相比，他們的優劣在哪里，這樣可以考察他對技術有沒有做一些深入的思考。

候選人簡歷中沒提到的技術，但是你招聘的需求中有的，你可以問，如果候選人有了解那么你可以繼續深問，如果候選人不是很了解，那么就沒有必要繼續問了。有些經驗淺的面試官會就一些他非常熟悉的領域，或者是最近研究的一些技術瘋狂提問，即使候選人已經表示這方面研究不多，這種面試體驗想想都覺得很差。

當然，如果說你問了很多招聘要求的技術候選人都不會，那么說明候選人并不適合你們崗位，通常從簡歷篩選階段就能篩掉這部分人。

要記住，你面試的目的不是為了考倒候選人，也不是為了炫技，你要做的是考察候選人的技術能力、學習能力、潛力等等綜合能力，所以應該多讓他有機會展示自己的能力，從他對技術或者是項目的描述中深挖一些更深層次點去提問，或者是從你的經驗上去判斷他的做法可能會存在的問題，然后再去問他有沒有解決，如果沒有的話，不妨問他有沒有思路啥的。所以，這就要求面試官本身有一定的段位。

我在知乎看到某個資歷較淺的面試官面了一些工作多年的候選人一些基礎的 JavaScript 問題，因為對方沒有回答出來而在知乎上掛出來，言語中充滿著嘲諷的意味。我覺得大可不必這樣，首先，你有沒有去發現候選人其它方面的亮點，有沒有給候選人充分的機會展示自己的能力，如果這位候選人真的沒有答出基礎的問題，確實有一定問題，但也沒必要在公開場合上說，因為面試中存在著信息不對稱，如果有一天你去面試別人再問你一個相對基礎的問題而你也恰好不會，如果也被掛出來，你的感受又是如何？

你這樣做只能說明你的面試非常不專業，對于一個工作經驗久的人我不會在乎他還記不記得這些 JavaScript 基礎，我對他本身的要求就會很高，我會更多的去問他最近深入研究的技術，或者考察他對于自己過往項目架構設計的理解，也可能會給他一個場景，拋出一些問題，來看看他對這些問題的理解和思考。

所以針對不同的候選人，對應的期望和要求是不一樣的，對于工作五年之內的候選人，我更多是看他的干活能力，能不能獨當一面。而對于工作更高年限的候選人，除了能干活之外，我還要考察他在專業領域的深度，對于一個較為復雜，涉及多個功能點的業務系統，或者技術難度較高的底層系統，能否做良好的架構拆解并實現。