1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        面試館:你們項目中的難點是什么,你是如何解決的?

        共 3802字,需瀏覽 8分鐘

         ·

        2021-04-03 21:21

        作者:亦遜

        https://juejin.im/post/5e7aed9c6fb9a07cac1d872d

        前言

        本篇文章的作者是來自阿里淘系用戶增長前端團隊的“亦遜”,18年作為雙非本科生通過層層面試,校招進入阿里,今天以過來人的身份給大家分享在面試官問起項目經(jīng)驗時,該如何回答。

        說起面試

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

        STAR法則

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

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

        • Situation:事情是在什么情況下發(fā)生,基于一個怎樣的背景;
        • Task:你是如何明確你的任務的;
        • Action:針對這樣的情況分析,你采用了什么行動方式,具體做了哪些工作內容;
        • Result:結果怎樣,帶來了什么價值,在整個過程中你學到了什么,有什么新的體會。

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

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

        盡管這樣面試官也同樣希望了解當時項目的背景,是什么原因導致你要想到通過做 Webpack 插件來解決而不是通過其他工具,以及這個插件給項目帶來了怎樣的價值(是構建性能還是其他?)。背景和結果是面試官非常看重的一部分,必須拿出足夠的理由和價值來說服面試官,否則盡管你在這個項目投入了足夠的精力但最終并沒有為你的面試評價加分,這是十分可惜的。

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

        • Compiler 和 Compilation 以及它們的區(qū)別;
        • Webpack 是通過什么方式實現(xiàn)了插件之間的關系以及保證它們的有序性;
        • 開發(fā)插件時需要依據(jù)當前配置是否使用了某個其他的插件而做下一步?jīng)Q定,如何判斷 Webpack 當前使用了哪些插件;
        • 開發(fā)插件過程中借鑒了其他插件的思路,我對這個插件源碼的理解;
        • 等等等等。

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

        面試場景還原

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

        面試官:

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

        我:

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

        面試官:

        那問題解決了么?

        我:

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

        面試官:

        不錯,詳細介紹一下具體過程吧。

        我:

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

        面試官:

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

        我:

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

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

        面試官:

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

        我:

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

        • 詞法分析階段:字符串形式的代碼轉換為令牌(tokens)流,令牌類似于AST中的節(jié)點;
        • 語法分析階段:把一個令牌流轉化為 AST 的形式,同時把令牌中的信息轉化為AST的表述結構。

        面試官:

        你項目中說的 AST 遍歷的過程能再詳細說說么?

        我:

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

        總結一下

        面試官的「套路」

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

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

        開放性的問題基本是考察思維發(fā)散能力,考察在某個領域的深度和廣度,基本上會結合技術問題來問,或者是結合工作內容來問。

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

        面試者的「應對」

        1. 就實際情況做回答,提前準備的時候多發(fā)散,多思考,多總結。這一塊是可以自己準備的加分項。
        2. 發(fā)散性問題主要是看自己平時積累。首先基礎知識要牢固,同時也要了解最新技術動態(tài)。面對這類問題切記也不能答非所問而跑題了。


        ??愛心三連擊

        1.看到這里了就點個在看支持下吧,你的點贊,在看是我創(chuàng)作的動力。

        2.關注公眾號程序員成長指北,回復「1」加入高級前端交流群!「在這里有好多 前端 開發(fā)者,會討論 前端 Node 知識,互相學習」!

        3.也可添加微信【ikoala520】,一起成長。

        “在看轉發(fā)”是最大的支持

        瀏覽 97
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            大桥未久av一区二区三区 | 四虎精品成人无码A片 | 麻豆av一区二区三区 | www.av视频.com | 亚洲中文字幕乱伦 | 国精产品一区一区三区有限公司杨 | 涩爱av色老久久精品偷偷鲁 | 尤物禁止想象AV | 韩国三级片中文字幕 | 国产AV 无码 乱噜噜 |