阿里淘系前端-暑期實習面經 | 掘金技術徵文

時間 2020-06-08

原文原文鏈接

前言

我真的太后知後覺了..., 本來覺得實習是大四的事情, 暑假安心在家裏摸魚, 三月初某天和一樣是17級的同窗聊天時, 忽然知曉對方已經到了字節跳動前端終面, 頓時一驚, 問了才知道原來有暑假實習這個東西! 並且還僅限大三(研二)! 因而火速開始複習前端基礎以及覆盤以前的項目. 當時的規劃大概是這樣色的:html

非科班, 計算機基礎軟肋, 選擇重點補計算機網絡, 算法和數據結構只准備了一些, lc30道題大概.
無社會實習經歷, 但有很多項目經歷, PC/小程序/後端均有完整項目. 重點覆盤其中的亮點難點.
對基礎設施/工程化/智能化有興趣, 落地過基於GraphQL的BFF, CI/CD/Docker/Serverless/錯誤監控/埋點都有實踐..., 重點準備並做爲簡歷亮點(後來事實證實這一塊真的挺重要).

肯定了規劃以後我就開始8107的準備了, 大概在3-18投出了簡歷, 經歷20天5輪技術+1輪HR成功上岸.前端

一面

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

TCP 三次握手/四次揮手/等待2MSL意義/創建鏈接但客戶端故障webpack

我這裏還提了握手失敗/泛洪攻擊/RST包等ios
TCP 慢啓動/擁塞控制, 快速重傳/快速恢復, 這也是我準備比較多的, 畢竟以前沒接觸過.git
TCP UDP QUIC(QUIC是Http3的底層協議)程序員
Http2相對於Http1.1新增了哪些東西, 主要是信道複用之類的.github
瀏覽器渲染過程, 注意只是渲染過程, 就是從解析DOM樹到展現在屏幕這個過程web

主要是 令牌化/建樹/收集樣式表/佈局渲染樹/繪製列表/柵格化/繪製圖塊/...這些過程, 推薦閱讀瀏覽器的工做原理：新式網絡瀏覽器幕後揭祕面試
強緩存與協商緩存, 主要講了下E-Tag和Last-Modified以及對應的標識, 強緩存方案與協商緩存方案的場景, 好比index.html該用哪一個?
CSS的水平居中與垂直居中, 這個因爲我平時CSS寫的很少, 一般是在UI庫基礎上作微調, 只回答了以前記錄的方案.
移動端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, 淺比較, 關於淺比較這個我在本身以前一篇講useSelector的文章中提到過. 放一下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內的小步驟, 每隔一段時間執行, 提升程序流暢性.)

一面主要問的都是基礎, 面試官給個人感受就像學長同樣! 還給我解答了一哈回答得很差的問題. 一面時間大概一個多小時, 感受問題都問到我心坎上了? 就是沒有問到不太會的問題.

Web安全, XSS與XSRF攻擊. 這裏還扯了一下Axios的X-XSRF-TOKEN機制. 惋惜是在面試後纔看到冴羽大大的預測最近面試會考 Cookie 的 SameSite 屬性, 否則還能加一波分?

二面

可能由於簡歷上寫的工程化比較多, 二三四面都問了比較多工程化的東西.

微信小程序, 這個是二面的重點提問之一, 包括如下幾個方面:
- 生命週期, 包括應用級的和頁面級的.
- 架構, 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, 這個主要是由於一些小項目小demo用Parcel是真的簡單, 好比這個我本身搭的一個Parcel-Tsx-Template, 真-開箱即用, 真-零配置. 可是要寫什麼正式項目的話, 仍是老老實實Webpack.
Parcel和Webpack, 由上面的展開問的, 說了一下兩者的差別(內置HMR與代碼分割, 預置配置), 還有就是Parcel其實也有Loader和Plugin, 以前翻了一下源碼, 叫@Parcel/transformer-xxx這種. 還有就是Parcel打包前會作資源樹分析優化, 而且過於黑盒, 內部寫死了一套配置(好像叫config.json).
還順便提了下Umi, 由於簡歷上有個Umi + Dva + Antd Pro的項目, 分析了下Umi啥的: 我我的以爲Umi是"框架的框架", 即在Webpack的基礎上作了一套性能調優到極限的配置和知足大部分開發需求的生態(插件)等等.
錯誤監控, 咱們目前使用的方式是Sentry以及Release時上傳Source-Map文件的方式. 本身實現的話, React的思路主要是一個最外層的<ErrorBoundry />組件, 藉助getDerivedStateFromError與componentDidCatch來捕獲錯誤.
Https加密機制
Git Rebase 與 Git Merge
Flutter 與 React Native底層, 我只講到Skia引擎, 畢竟Flutter還沒寫過完整項目...
Serverless, 這一塊我主要講了FaaS以及BaaS, 還有Serverless對前端意義, 這個問題千人千面, 我本身的理解不必定是對的, 就不展開來說了.

二面主要針對項目進行發問, 不得不說果真是前輩, 不少項目死角都被揪出來了, 還好的確以前花了時間思考了下也答上來了. 建議覆盤項目能夠找個有經驗的同窗來幫你想一想這個項目會從哪些角度被提問, 畢竟當局者迷嘛.

三面&四面

三面和四面發問的角度和提出的問題比較相似, 所以就放在一塊兒講了.

介紹項目, 我一般會問面試官是對業務型項目仍是設施型項目比較感興趣, 業務型的話就介紹小程序, 設施型就介紹@Penumbra/cli.
小程序因爲 UI/交互/先後端都是本身搞的, 因此能講的真的蠻多, 可是一般會更聚焦於這個小程序的業務場景(圖書資源整合), 這也是在介紹項目時我以爲比較好的一種方式:

不要東扯一點西扯一點, 以 技術棧 -> 業務場景 -> 亮點 -> 難點 -> 提煉總結 -> 自我提高 這幾個步驟來敘述會更加條理清晰, 其中亮點/難點以STAR法則介紹最佳.
@Penumbra/cli這個, 上面已經介紹過, 就再也不贅述. 主要爲了體現 新工程目錄創建繁瑣 -> 應當成員之間統一目錄結構 這個意識.
GraphQL, 可貴遇到會問這個的, 要知道我但是把這個做爲簡歷亮點的, 可是卻無人問津..., 主要介紹了這些:
- GraphQL的意義, 與RESTFul的差別
- 對後端的影響, 其實吧我以爲如今不太可能用GraphQL做爲應用的主API(除非出現了爲圖式查詢而生的數據庫, 至於FB和GitHub的GraphQL API我以爲是其內部有自研的方案), 也就是讓後端同窗來搞, 大部分場景應該仍是後端同窗搞微服務, 而後前端同窗本身來寫一個BFF層作接口的聚合/清洗/鑑權等等, 也就是說並不會"這個世界充滿了對後端的壓迫, 後端何時才能站起來, 氣抖冷"hhhh. 既然讓前端寫, 那確定是用Node了, 這個時候Apollo這些方案就真的很香了(下面會多介紹下.)
- 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, 摘抄一下以前的筆記, 也可參考[譯]React高級話題之Forwarding Refs
  - 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, 咱們工做室的流程仍是挺完善的, 包括commitlint -> Husky + Lint-Staged + Code Review*n + ZEIT/now測試環境, 而後纔是Gitlab pipeline到OSS.
埋點, 這一塊我以前調研過, 能夠讀讀我以前寫的這篇關於埋點的一些思考, 主要是以GA爲表明的一鍵式埋點方案, 以MixAlpha/神策數據爲表明的可視化埋點等.
測試, Jest/Enzyme/Puppeteer編寫單元/集成/E2E測試. 稍微問了下單測覆蓋率, 很沒底氣的說了可能就50%不到hhh.
Flutter, 感受這種不是比較熟練的技術放到簡歷上不太好, 好比我用Flutter只能寫寫簡單的Widget和頁面這種, 因而就沒問得太多.

五面

五面的面試官可能比較忙, 所以整個面試過程大概就二十分鐘左右. 也是介紹了一下小程序與腳手架, 面試官應該是高P, 主要關注我在團隊中的角色, 我對本身的定義集中在 參與前端技術棧選型&推進新的前端架構&參與對新人培訓指導等, 這一塊的話也是以本身的經歷爲主, 若是你是獨行俠, 也能夠講一講本身在社區的貢獻等等, 不要直接說你喜歡獨來獨往一我的全乾.

HR面

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

大學成績
興趣愛好
有沒有女友倆人之後的職業規劃
我的職業規劃
成就感
團隊協做經歷
從小到大比較順利仍是坎坷(?)
爲何學習前端
手上有別的offer嗎
爲何想來阿里, 固然是由於阿里是前端的寶地了

這些問題比較主觀, 爲了不誤導我就不放本身答案了.

總結&將來前端展望

只能說面試真的是很玄學的東西, 若是每一面都能碰見和你至關match的面試官, 那整個面試流程真的會很輕鬆愉快. 春招逐漸接近尾聲, 也但願你們都能拿到本身滿意的offer, 還在面試的同窗能夠讀讀我整理的前端基礎, 感受有用的話就點個⭐吧~

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

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