面試官日記:前端面試(80% 應(yīng)聘者不及格系列) 之JS 面試題

??

一位大佬在做面試官這 2 年多的時(shí)間內(nèi),面試了數(shù)百個(gè)前端工程師,驚訝的發(fā)現(xiàn),超過 80% 的候選人對下面這道題的回答情況連及格都達(dá)不到。這究竟是怎樣神奇的一道面試題?他考察了候選人的哪些能力?對正在讀本文的你有什么啟示?且聽他慢慢道來

不起眼的開始

招聘前端工程師,尤其是中高級前端工程師,扎實(shí)的 JS 基礎(chǔ)絕對是必要條件,基礎(chǔ)不扎實(shí)的工程師在面對前端開發(fā)中的各種問題時(shí)大概率會(huì)束手無策。在考察候選人 JS 基礎(chǔ)的時(shí)候,我經(jīng)常會(huì)提供下面這段代碼,然后讓候選人分析它實(shí)際運(yùn)行的結(jié)果:

??

這段代碼很短,只有 7 行,我想,能讀到這里的同學(xué)應(yīng)該不需要我逐行解釋這段代碼在做什么吧。候選人面對這段代碼時(shí)給出的結(jié)果也不盡相同,以下是典型的答案:

A. 20% 的人會(huì)快速掃描代碼,然后給出結(jié)果:0,1,2,3,4,5;

B. 30% 的人會(huì)拿著代碼逐行看,然后給出結(jié)果:5,0,1,2,3,4;

C. 50% 的人會(huì)拿著代碼仔細(xì)琢磨,然后給出結(jié)果:5,5,5,5,5,5;

只要你對 JS 中同步和異步代碼的區(qū)別、變量作用域、閉包等概念有正確的理解,就知道正確答案是 C,代碼的實(shí)際輸出是:

2017-03-18T00:43:45.873Z 5

2017-03-18T00:43:46.866Z 5

2017-03-18T00:43:46.868Z 5

2017-03-18T00:43:46.868Z 5

2017-03-18T00:43:46.868Z 5

2017-03-18T00:43:46.868Z 5

接下來我會(huì)追問:如果我們約定,用箭頭表示其前后的兩次輸出之間有 1 秒的時(shí)間間隔,而逗號表示其前后的兩次輸出之間的時(shí)間間隔可以忽略,代碼實(shí)際運(yùn)行的結(jié)果該如何描述?會(huì)有下面兩種答案:

A. 60% 的人會(huì)描述為:5 -> 5 -> 5 -> 5 -> 5,即每個(gè) 5 之間都有 1 秒的時(shí)間間隔;

B. 40% 的人會(huì)描述為:5 -> 5,5,5,5,5,即第 1 個(gè) 5 直接輸出,1 秒之后,輸出 5 個(gè) 5;

這就要求候選人對 JS 中的定時(shí)器工作機(jī)制非常熟悉,循環(huán)執(zhí)行過程中,幾乎同時(shí)設(shè)置了 5 個(gè)定時(shí)器,一般情況下,這些定時(shí)器都會(huì)在 1 秒之后觸發(fā),而循環(huán)完的輸出是立即執(zhí)行的,顯而易見,正確的描述是 B。

如果到這里算是及格的話,100 個(gè)人參加面試只有 20 人能及格,讀到這里的同學(xué)可以仔細(xì)思考,你及格了么?

學(xué)習(xí)交流前端方面的技術(shù),打算深入了解這個(gè)行業(yè)的朋友,可以加下小編的前端學(xué)習(xí)裙330336289,邀請碼(寂靜)

每天都有分享前端知識和學(xué)習(xí)方法,歡迎小伙伴加入交流

追問 1:閉包

如果這道題僅僅是考察候選人對 JS 異步代碼、變量作用域的理解,局限性未免太大,接下來我會(huì)追問,如果期望代碼的輸出變成:5 -> 0,1,2,3,4,該怎么改造代碼?熟悉閉包的同學(xué)很快能給出下面的解決辦法:

??

巧妙的利用 IIFE(Immediately Invoked Function Expression:聲明即執(zhí)行的函數(shù)表達(dá)式)來解決閉包造成的問題,確實(shí)是不錯(cuò)的思路,但是初學(xué)者可能并不覺得這樣的代碼很好懂,至少筆者初入門的時(shí)候這里琢磨了一會(huì)兒才真正理解。有沒有更符合直覺的做法?答案是有,我們只需要對循環(huán)體稍做手腳,讓負(fù)責(zé)輸出的那段代碼能拿到每次循環(huán)的 i 值即可。該怎么做呢?利用 JS 中基本類型(Primitive Type)的參數(shù)傳遞是按值傳遞(Pass by Value)的特征,不難改造出下面的代碼:

??

能給出上述 2 種解決方案的候選人可以認(rèn)為對 JS 基礎(chǔ)的理解和運(yùn)用是不錯(cuò)的,可以各加 10 分。當(dāng)然實(shí)際面試中還有候選人給出如下的代碼:

??

細(xì)心的同學(xué)會(huì)發(fā)現(xiàn),這里只有個(gè)非常細(xì)微的變動(dòng),即使用 ES6 塊級作用域(Block Scope)中的 let 替代了 var,但是代碼在實(shí)際運(yùn)行時(shí)會(huì)報(bào)錯(cuò),因?yàn)樽詈竽莻€(gè)輸出使用的 i 在其所在的作用域中并不存在,i 只存在于循環(huán)內(nèi)部。

能想到 ES6 特性的同學(xué)雖然沒有答對,但是展示了自己對 ES6 的了解,可以加 5 分,繼續(xù)進(jìn)行下面的追問。

追問 2:ES6

有經(jīng)驗(yàn)的前端同學(xué)讀到這里可能有些不耐煩了,扯了這么多,都是他知道的內(nèi)容,先別著急,挑戰(zhàn)的難度會(huì)繼續(xù)增加。接著上文繼續(xù)追問:如果期望代碼的輸出變成 0 -> 1 -> 2 -> 3 -> 4 -> 5,并且要求原有的代碼塊中的循環(huán)和兩處 console.log 不變,該怎么改造代碼?

新的需求可以精確的描述為:代碼執(zhí)行時(shí),立即輸出 0,之后每隔 1 秒依次輸出 1,2,3,4,循環(huán)結(jié)束后在大概第 5 秒的時(shí)候輸出 5(這里使用大概,是為了避免鉆牛角尖的同學(xué)陷進(jìn)去,因?yàn)?JS 中的定時(shí)器觸發(fā)時(shí)機(jī)有可能是不確定的,具體可參見 How Javascript Timers Work)??吹竭@里,部分同學(xué)會(huì)給出下面的可行解:

??

不得不承認(rèn),這種做法雖粗暴有效,但是不算是能額外加分的方案。如果把這次的需求抽象為:在系列異步操作完成(每次循環(huán)都產(chǎn)生了 1 個(gè)異步操作)之后,再做其他的事情,代碼該怎么組織?聰明的你是不是想起了什么?對,就是 Promise。

可能有的同學(xué)會(huì)問,不就是在控制臺輸出幾個(gè)數(shù)字么?至于這樣殺雞用牛刀?你要知道,面試官真正想考察的是候選人是否具備某種能力和素質(zhì),因?yàn)樵诂F(xiàn)代的前端開發(fā)中,處理異步的代碼隨處可見,熟悉和掌握異步操作的流程控制是成為合格開發(fā)者的基本功。順著下來,不難給出基于 Promise 的解決方案(既然 Promise 是 ES6 中的新特性,我們的新代碼使用 ES6 編寫是不是會(huì)更好?如果你這么寫了,大概率會(huì)讓面試官心生好感):

??

相比而言,筆者更傾向于下面這樣看起來更簡潔的代碼,要知道編程風(fēng)格也是很多面試官重點(diǎn)考察的點(diǎn),代碼閱讀時(shí)的顆粒度更小,模塊化更好,無疑會(huì)是加分點(diǎn)。

??

讀到這里的同學(xué),恭喜你,你下次面試遇到類似的問題,至少能拿到 80 分。我們都知道使用 Promise 處理異步代碼比回調(diào)機(jī)制讓代碼可讀性更高,但是使用 Promise 的問題也很明顯,即如果沒有處理 Promise 的 reject,會(huì)導(dǎo)致錯(cuò)誤被丟進(jìn)黑洞,好在新版的 Chrome 和 Node 7.x 能對未處理的異常給出 Unhandled Rejection Warning,而排查這些錯(cuò)誤還需要一些特別的技巧(瀏覽器、Node.js)

追問 3:ES7

既然你都看到這里了,那就再堅(jiān)持 2 分鐘,接下來的內(nèi)容會(huì)讓你明白你的堅(jiān)持是值得的。

多數(shù)面試官在決定聘用某個(gè)候選人之前還需要考察另外一項(xiàng)重要能力,即技術(shù)自驅(qū)力,直白的說就是候選人像有內(nèi)部的馬達(dá)在驅(qū)動(dòng)他,用漂亮的方式解決工程領(lǐng)域的問題,不斷的跟隨業(yè)務(wù)和技術(shù)變得越來越牛逼,究竟什么是牛逼?建議閱讀程序人生的這篇剖析。

回到正題,既然 Promise 已經(jīng)被拿下,如何使用 ES7 中的 async await 特性來讓這段代碼變的更簡潔?你是否能夠根據(jù)自己目前掌握的知識給出答案?請?jiān)谶@里暫停 1 分鐘,思考下。

下面是筆者給出的參考代碼:

??

總結(jié)

感謝你花時(shí)間讀到這里,相信你收獲的不僅僅是用 JS 精確控制代碼輸出的各種技巧,更是對于前端工程師的成長期許:扎實(shí)的語言基礎(chǔ)、與時(shí)俱進(jìn)的能力、強(qiáng)大技術(shù)自驅(qū)力。

。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容