金三銀四你是否已準備好！這份阿里淘系前端-實習面經助你成功

前言

時間過得很快，彷彿20年的金九銀十就在昨天，21年的金三銀四隨之而來了，尚未準備好面試的同窗們不要慌，今天和你們聊得的是淘系前端面試，一共是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代碼(夢仍是要有的). 雖然如今業界已經有一些方案, 但都還存在着或多或少的問題. 這也是我最感興趣的方向之一.

只能說面試真的是很玄學的東西, 若是每一面都能碰見和你至關合得來的面試官, 那整個面試流程真的會很輕鬆愉快。春招逐漸接近尾聲, 也但願你們都能拿到本身滿意的offer！