2021阿里淘系前端面試5面+HR面，仿佛聽到說別愛我沒結果

前言

相信很多人都會有一個進大廠的夢吧，這篇文章來講講阿里淘系前端的“夢”，一共是5面+HR面，結尾會單獨說對于未來前端展望（開始做夢了哈哈哈哈），一次好的面試同時也是進步的貧訓，能夠發掘你一些似懂非懂的問題，讓你去深入挖掘，還能將你的痛點暴露出來，面試下來是識訓滿滿的，

一面

這一面主要問了基礎部分, 一部分題目我會帶上提示

• TCP 三次握手/四次揮手/等待2MSL意義/建立連接但客戶端故障

• TCP 慢啟動/擁塞控制, 快速重傳/快速恢復

• TCP UDP QUIC(QUIC是Http3的底層協議)

• Http2相對于Http1.1新增了哪些東西, 主要是信道復用之類的

• 瀏覽器渲染程序, 注意只是渲染程序, 就是從決議DOM樹到展示在螢屏這個程序

  主要是 令牌化/建樹/收集樣式表/布局渲染樹/繪制串列/柵格化/繪制圖塊/…這些程序，

• 強快取與協商快取, 主要講了下E-Tag和Last-Modified以及對應的標識, 強快取方案與協商快取方案的場景, 比如index.html該用哪個?

• CSS的水平居中與垂直居中

• 移動端1px, 老問題啦

• Git操作, 主要是revert與reset, 我們作業室使用的是Git Flow, 并且區分Master和Dev分支這種, 小哥說了一個Git Flow無法handle的場景, 即一個feature還未合并到Master, 但是后面的一個feature已經通過提測要并進主干, 這時要如何處理?

• React: 新舊生命周期的問題, 為什么要廢棄舊版的(約束開發者以及Fiber架構可能會將其打斷), 新版的有什么特點(getDerivedStateFromProps(nextProps, prevState), 這個方法是靜態方法, 也就說你無法在里面獲取到this, 還有就是入參為prevState, 這樣就保證state和props之間更隔離). 還有就是我覺得很好玩的getDerivedStateFromErrors和componentDidCatch的協作.

• React: PureComponent, 淺比較, 放一下shouldComponentUpdate中shallowEuqal的原始碼:

    const hasOwn = Object.prototype.hasOwnProperty;
  
    function is(x, y) {
      if (x === y) {
        return x !== 0 || y !== 0 || 1 / x === 1 / y;
      } else {
        return x !== x && y !== y;
      }
    }
  
    export default function shallowEqual(objA, objB) {
      if (is(objA, objB)) return true;
      if (
        typeof objA !== "object" ||
        objA === null ||
        typeof objB !== "object" ||
        objB === null
      ) {
        return false;
      }
  
      const keysA = Object.keys(objA);
      const keysB = Object.keys(objB);
  
      if (keysA.length !== keysB.length) return false;
  
      for (let i = 0; i < keysA.length; i++) {
        if (!hasOwn.call(objB, keysA[i]) || !is(objA[keysA[i]], objB[keysA[i]])) {
          return false;
        }
      }
      return true;
    }
  復制代碼
  

• React: setState之后發生的.
  多次setState的合并與獲取最新的state, 其實這倆個是同一處代碼(好像是particalState), 內部對引數的Object型別和Function型別做了不同的處理, 為函式的情況下, 會在setState呼叫完成并且組件開始rerender的時候被呼叫.

• Node: stream和Buffer, 面試前不久剛寫過流式的檔案上傳所以記憶猶新, 回答了四種流(可寫/可讀/可寫可讀/可轉換), 以及常用的幾個pipe方法

  Buffer的話主要提了一下它是堆外記憶體(V8的常駐記憶體由代碼區/堆疊/堆/堆外記憶體組成)啥的.

• Node: 記憶體管理, 這個有看到過通過啟動命令更改堆記憶體上限的文章所以了解的多了一下, 主要關鍵詞有 新生代/老生代假說, Scavenge演算法(采用復制實作記憶體回收, 典型的犧牲空間換時間), From/To空間, 標記清除, 標記整理, 增量標記(將標記階段拆分為控制在5ms內的小步驟, 每隔一段時間執行, 提高程式流暢性.)

二面

• 微信小程式, 這個是二面的重點提問之一, 包括以下幾個方面:

  • 生命周期, 包括應用級的和頁面級的
  • 架構, View - Native - JavaScript的層級, 系統層能力, 如微信開放能力/離線存盤/網路請求等. 視圖層的話, 安卓下是騰訊自主研發的基于Blink的X5內核, IOS的話則是自帶的WebKit-Webview
  • 使用async/await, 小程式目前好像并不能原生支持async/await語法, 需要引入FB的Regenerator庫. 說到這個, 我很好奇Taro/Remax這些方案中是如何處理async/await的, 降級為Promise嗎?
  • 鑒權, code2session這個api, 使用sessionKey生成token, openid作為主鍵入資料庫, 再回傳自定義的登錄態標識
  • 與 H5/RN/Flutter/PWA 這些差異, 主要是和 H5/PWA , 我其實不太認同 PWA是小程式祖師爺 這種說法, 甚至認為不是一個性質, 只是他們的目的/玩法是相似的
  • WXS, 當時小程式也用到了, 主要特點就是運行在View層的邏輯, 并且由于JavaScript在IOS下運行在JSCore, 安卓下運行在V8的原因, 在IOS上WXS可以達到JS數十倍的性能, 但在安卓上和JS持平.
  • setState, 很神奇的一點: 資料改變同步而視圖更新異步, 主要也是因為上面提到的架構的原因. 有興趣的可以再查閱相關資料
  • 小程式如何做到禁止訪問Dom, 我的理解是小程式壓根就沒提供DOM/BOM的API, 并且在打包編譯的JS里也獲取不到Window物件

• @Penumbra/cli, 一個思路類似Feflow的腳手架, 也是 腳手架核心+模板插件包+構建器 的一個組合, 模板插件包的話, 前端包含 Webpack/Parcel + TypeScript/JavaScript的組合, 后端包含Koa/Egg + RESTFul/GraphQL的組合. 主要問了這些問題:

  • 為什么要整這個東西, 解決了哪些問題?
  • 帶來了什么好處?
  • 為什么還添加了Parcel

• Parcel和Webpack

• 錯誤監控, 我們目前使用的方式是Sentry以及Release時上傳Source-Map檔案的方式. 自己實作的話, React的思路主要是一個最外層的<ErrorBoundry />組件, 借助getDerivedStateFromError與componentDidCatch來捕獲錯誤.

• Https加密機制

• Git Rebase 與 Git Merge

• Flutter 與 React Native底層

• Serverless, 這一塊可以講FaaS以及BaaS, 還有Serverless對前端意義, 這個問題千人千面, 就不展開來講了.

三面&四面

三面和四面發問的角度和提出的問題比較類似, 因此就放在一起講了，

• 介紹專案, 通常會問面試官是對業務型專案還是設施型專案比較感興趣, 業務型的話就介紹小程式, 設施型就介紹@Penumbra/cli

  不要東扯一點西扯一點, 以 技術堆疊 -> 業務場景 -> 亮點 -> 難點 -> 提煉總結 -> 自我提升 這幾個步驟來敘述會更加條理清晰, 其中亮點/難點以STAR法則介紹最佳

• @Penumbra/cli這個, 上面已經介紹過, 就不再贅述. 主要為了體現 新工程目錄建立繁瑣 -> 應當成員之間統一目錄結構 這個意識

• GraphQL, 主要介紹了這些:

  • GraphQL的意義, 與RESTFul的差異
  • 對后端的影響
  • Apollo生態, 在這里我想大膽猜測下, 未來的BFF層一定少不了這三個東西: Apollo-Server & TypeGraphQL & Apollo-Rest-Datasource, 至于它們是什么感興趣同學可以去查查. Apollo不僅提供了服務端支持, 也提供了客戶端支持, 即Apollo-Client, 同時使用Server和Client來構建應用真的能起到1+1>2的效果, 因為二者就像是一體的
  • 推廣阻力, 其實只要一個團隊比較年輕就沒有什么阻力, 主要是可能有一定的學習/開發/維護成本~ 嚷嚷著"學不動了"在前端世界里可能真的寸步難行

• Webpack性能調優, 從 打包速率 / 打包大小 / 互動友好 三個方面入手的, 這里可以稍微列舉一些我覺得比較好用/有趣的Plugin:

  • friendly-errors-webpack-plugin, 主要是對拋出的錯誤做了界面優化, 很多cli都在用
  • speed-measure-webpack-plugin, 測量各個環節的打包耗時, 也可以找出哪一個loader/plugin耗時最久
  • terser-webpack-plugin, 壓縮JS
  • webpack-bundle-analyzer, 分析打包產物
  • webpack-visualizer-plugin, 同樣是分析打包產物, 但是更直觀
  • webpack-parallel-uglify-plugin, 并行壓縮, 好像和terser功能重復了
  • webpackbar, 強烈推薦! 在打包時會有進度條(VuePress就用的這個)
  • preload-webpack-plugin, 預加載

• 至于從配置入手的話, 主要是減少查找檔案時間和減少build代碼體積, 前者可以通過resolve欄位中配置extension, loader中配置exclude, 后者的話則主要是Tree-Shaking(注意, CSS也可以做搖樹優化), 代碼分割(動態加載以及Lodash/Antd這種龐大的模塊), Source-Map模式, 壓縮代碼等等，

• React函式式組件

• React Hooks:

  • useState

  • useEffect, 不傳dep與傳入[], 分別對標類組件的哪個生命周期.

  • useLayoutEffect

  • useRef, 還有useImperativeHandle與forwardRef

    • useRef，使函式式組件也能夠享受到獲取 DOM 元素或者自定義組件，父組件獲取子組件參考而后呼叫子組件方法，如 focus 等

    • forwardRef，可以獲取父組件的 ref 實體作為子組件的引數（與 props 同級），然后再把這個 ref 系結到自己內部節點，就可以實作 ref 的透傳了！

    • useImperativeHandle，常與 forwardRef 搭配使用，可以控制向父組件暴露的屬性以及方法，第一個引數即為 forwardRef 包裹后得到的父組件 ref 實體

  • useMemo與useCallback

• Hooks思想, 比如Vue3的新API, 社區React生態也在紛紛擁抱Hooks思想, 比如上面提到的的React-Redux的useSelector和useDispatch, React-Use還有Umi-Hooks等等

• Node的Cluster模塊, 主從模式, 底層的Libuv

• CI/CD

• 埋點, 主要是以GA為代表的一鍵式埋點方案, 以MixAlpha/神策資料為代表的可視化埋點等

• 測驗, Jest/Enzyme/Puppeteer撰寫單元/集成/E2E測驗

• Flutter

五面

五面的面試官可能比較忙, 因此整個面試程序大概就二十分鐘左右. 以自己的經歷為主, 如果你是獨行俠, 也可以講一講自己在社區的貢獻等等, 不要直接說你喜歡獨來獨往一個人全干，

HR面

這一面就是常見的問題啦:

• 大學成績
• 興趣愛好
• 有沒有女朋友 倆人以后的職業規劃
• 個人職業規劃
• 成就感
• 團隊協作經歷
• 從小到大比較順利還是坎坷(?)
• 為什么學習前端
• 手上有別的offer嗎
• 為什么想來阿里, 當然是因為阿里是前端的寶地了

這些問題比較主觀, 為了避免誤導我就不講啦

總結&未來前端展望

對未來前端的展望是二面問到的問題, 我個人的想法主要分這么三點:

• 多端方案, 隨著5G的發展, 物聯網設備也在逐漸成熟, 到時候前端程式員要適配的螢屏可能又多了幾種? 我覺得未來可能會出現真正的多端解決方案, 即更全面的Rax或者Taro, 真正的一次撰寫處處運行. 當然理想是好的, 在它還未乘著七彩祥云到來前, 還是專心學好每一端吧~
• 侵入后端, Serverless無疑是前端仔的下一個風口, 它給予了我們向后端進發的能力, 讓我們"自己和自己聯調", 也無需操心自己寫的服務被流量打爆掉. 后端同學則能夠解放出來, 去做一些更有意義的事情.(真的不是搶飯吃)
• 智能化, 雖然現在到處都是賦能這個概念, 但是我還是覺得, 前端的終極之一就是賦能其他崗位, 讓運營能夠自己搭自己想要的活動頁, 讓產品爸爸自己選要對哪些控制元件/事件/指標進行埋點, 讓不想從零學前端的后端直接拖拖拽拽配一個界面出來, 還有就是前端同學, 直接設計圖生成UI代碼(夢還是要有的). 雖然現在業界已經有一些方案, 但都還存在著或多或少的問題. 這也是我最感興趣的方向之一，

96道web前端面試題

講完面試經歷面試題是不能少的，自己及小伙伴面試問到的題目整理出了96道題目，篇幅原因列舉部分題目：

• 什么是函式柯里化?
• 創建物件有幾種方法？
• 怎樣通過ES5及ES6宣告一個類？
• call、apply的共同點與區別?
• 用javascript實作物件的繼承,繼承的幾種方式,這幾種方式的優缺點?
• 說說你對作用域鏈的理解？
• 談一談this在各種情況的指向問題？
• 閉包的特征有哪些？
• 閉包應用場景有哪些？
• 實際開發中閉包的應用？
• 如何理解js的單執行緒？
• js為什么是單執行緒的？
• 同步和異步的區別是什么？分別舉一個同步和異步的例子？
• 什么是任務佇列？
• 堆疊和佇列的區別？

完整版的96道web前端面試題直接點擊這免費領取噢，為我們的夢加油！

最后想說淘系面試官都很 NICE ，個人的面試風格就是比較偏閑聊那種，所以面試的時候感覺就很匹配，面試官問的問題都是具有關聯性的，可能它會取你上個問題回答中的答案進行追問，給了你很大的發揮空間，讓你能夠充分利用你的知識體系進行回答，對于你一些不會的問題，也不會過多的追問，引導著你，同時又體現出他對你的尊重，