時間飛快，轉眼間8102還差一個月就over了，順了順好幾天沒理的鬍渣兒，好像已經老了不少。

不，我還很年輕！雖然年終還沒到，但好像也差不多了。

幾經輾轉，年底前終於拿到了微信的offer，可以說是今年一大幸事了。

是一個結束，結束本命年的坎坷；是一個開始，開始新的征程。

這篇雜文就簡單記錄一下微信前端社招的經歷，以及回顧這兩年半做過的東西。

一、過七關

微信社招，老早就聽說難度極大，十幾輪面試的情況都有。

所以急不得，大概今年下半年開始，本菜菜就著手準備了，主要是擴充知識面以及加深對相關知識的理解與運用（暴露了平時有點懶。。。）

說實話，這半年收穫頗多，熬夜也最多，應該有十來次為了理清某些東西，奮戰到半夜兩三點，若是失敗了就過幾天再戰...

可能不同的崗位性質不同，要求也不同，對我而言，整體上對業務解決能力要求很高，演算法方面則沒有太高要求

每輪都問到了職業規劃，為什麼離開目前的環境

我總共經歷了七輪（4輪技術、兩輪GM、一輪HR），輪次可穿插並不是按順序的。面試體驗都非常棒~

當時覺得可能面不到最後，沒有刻意去記錄面試問的東西，所以現在也忘得差不多了，也沒必要刻意去刷面試題，就算刷到了，不久之後也會忘的。

1、技術電面（1h）

這輪算是探實力吧，確認有沒有前端基礎和好的專案經歷。

首先以在公司承擔的角色作為開端，問了平常做過的一些專案，介紹其中一個，就從裡頭挖掘業務的問題和解決辦法，同時抽取一些前端技術題。

沒辦法，專案說起來不夠複雜呀，似乎面試官並不滿意，自己就趁機把話題引向了其他有特色的專案來突圍。

抽了一些部落格上記錄的知識點來問，期間竟然找了我四年前的文章（問了各種編碼，以及BOM頭優缺點適用性）和某道演算法題 -_- 

HTTP和HTTPS的握手過程，是否瞭解HTTP2的特點，以及怎麼理解它的多路複用

還講了對前端安全和效能的理解，移動端的認識等

總之第一輪感覺還好，勉勉強強，話比較多，時間不慢的。

2、技術現場（1h）

這輪感覺跟第一輪差不多，只是比較正式些，來到了廣州塔旁邊的T.I.T

除了栽在了iPhoneX劉海屏的相關問題和移動端適配是否需要支援高清屏的“爭論”外，基本穩住了氣場。

深知自己沒有可以拿出手的很牛逼的專案，為了體現自己還是會一些東東的，就只能穿插著講出幾個專案了。

講了前端優化的實踐（為什麼優化，怎麼優化，怎麼評估，還能怎麼優化）

前端錯誤收集（怎麼記錄，怎麼區分是不是第三方外掛的問題，怎麼上報，怎麼分析）

問了PC端和移動端的轉換，ES6常用的東西，陣列方法大全等

3、技術現場（1h）

本輪是和前一輪銜接在一起的，這種方式挺好的，可以節約候選人來回奔波時間。

當時感覺是總監級別的，因為氣場有點強大，短褲拖鞋很隨性，判斷得出來反應必須非常快才能留下好印象，後來才知道是組長

問的東西，前端方面相對少一點了，偏向於整體性

問了目前團隊現狀，在團隊前端沉澱，技術預研上做了什麼，為什麼這麼做，有沒有起到什麼作用。

列舉幾條前端程式碼檢查規則，為什麼這麼制定

有沒有做介面的統一規範，返回碼之類的規定，怎麼和後端協商好這些規則，怎麼讓新人很好地用好這些

為什麼要做小程式預研，它不是很簡單麼

MVVW是什麼，有什麼優缺點

怎麼實現記住登入功能（很強的整體性）

怎麼實現統一登入，或者授權登入需要考慮什麼（更強的整體性）

4、HR現場（35min）

直接就來到了hr面，很快吧......流程可以隨意插進來

一不小心提前1h到了現場，前臺那小夥子也不知怎的，直接就聯絡hr了，說實話我本不想打擾的

不過hr馬上就下樓來接待了，進入稍許嘈雜的咖啡廳慢等，服務質量還闊以，在這裡是要點個讚的

本輪面試主要考察了團隊感受，過往的專案經歷，技術學習能力，薪酬期望

期間面試官也很直白的說，她要知道有沒有解決複雜問題的能力

直接從大學階段問起了，從在校時期做的最好專案，到工作時期做的最好專案，

聽起來似乎還是沒對胃口，就只有拿出自己為解決問題不辭辛勞很有決心的不堪歷史來說了 -_- 

問了平時解決問題的方式，有沒有從團隊中學到了什麼，跟誰學到的，團隊中角色，覺得團隊有什麼問題

5、GM現場（30min）

本輪是直接連著HR面的，基本沒問技術，側重考量業務理解能力以及是否適合部門

看到面試官戴著一個佳明跑表，想必也是跑馬人士哈哈哈，相對來說還是蠻輕鬆的，把之前的專案又說了一遍

如果要做一個數據分析系統，在前端方面可以做什麼東西（涉及了需求理解、功能拆分、技術實現）

問了自己做過什麼業務，期望什麼業務方向

介紹了職級體系，部門的業務特點

6、GM電面（15min）

本輪面試可以說是最慘的了，感覺面試官並不滿意自己做的專案，草草就收場了，也就誕生了第七輪技術面。

團隊的成員分佈，各角色職責和定位，怎麼進行版本迭代，一個系統的開發與維護週期是怎樣的，專案延期的時候怎麼做的

因為做的主要是內部系統（面向公司內部的需求），被問到為什麼不嘗試部門間轉崗，為什麼兩年多了還一直在做內部系統

介紹公司其他部門團隊的業務等

7、技術現場（1h）

本輪面試屬於技術交叉面，即由其他部門的人來面，主要還是因為前幾輪表現不佳，讓面試官們猶猶豫豫的。

這小哥一直樂呵呵的，看起來很容易談得來，也確實很容易談得來。後面HR說他是少有的T4級前端，大大牛呀...真是隨和

面到後面才知道，他一直想挖出我拆分問題的能力，如何對大的問題進行分解，逐個擊破，同時思維要發散，也許還有更簡便的方法。

一個難題，比如我提到了曾經想過整一個適合部門的CI/CD方案並實現，不過遇到了蠻多難題就沒有做下去了

這裡就缺了拆分問題模型的能力，不應想著難度太大做不了就做不了，而應該分析好從小的做起，一點一點地新增，慢慢堅持。

其實是自己作死挖了坑自己跳進去了..

說了經常寫技術部落格和整一些Github專案是一個非常好的習慣，挑了效能和安全方面的專案實踐來問，

為什麼用requestAnimationFrame來代替setTimeout

首屏太慢的問題除了SSR這種方法還有沒有其他更簡便的方法（在前端方面直接幹）

前端規範的落地，碰到的問題和解決過程

過往業務能力與技術能力的實踐

有沒有看過一些原始碼，整理的webpack專案有什麼難點，怎麼進行優化的

怎麼除錯，sourcemap是什麼東東

兩顆樹比對一般怎麼做，React中虛擬DOM是什麼，它在樹對比方面做了什麼優化，新版本React有什麼效能上的變化

從開始到結束，進行了差不多一個月，進度好像還是蠻快的，

總之，就目前這個部門的社招面試而言，我感覺側重考察的點是 是否具有解決複雜業務的能力，

當然，學習能力，技術專研，技術廣度在兩三年經驗這個階段是非常重要的。

二、出師不利

其實我在這前兩週，還面了微信公眾平臺那個部門，一面電面就跪了，面完感覺可掛可不掛的樣子

主要問題出在：

用了很久的JQ，卻沒認真地看過原始碼，被問到如何像JQ那樣實現動畫向左再向右不同的速度，回答得七零八亂

問了JQ中選擇器的識別解析順序是怎樣的，為什麼從右到左，我竟然說成了從左到右效能應該會更高。。。可能是大腦空白了吧

問了在React中事件處理回撥裡面，連續setState N次，會出發幾次render，理解錯誤，以為他說的是特殊的那種自定義事件繫結，回答了這個事件不會受到事務處理的週期影響，所以是N次。我還有骨氣地爭論了起來。。。

問了平時有沒有意識去看一些專案中用到的框架外掛原始碼，我竟然表達出了一種並不想了解其內部實現的論調 -_-

專案中的某種解決方案太暴力了，還有更優雅的方案沒有用到，聯想到所做專案複雜度和技術追求應該不會很高

也不知當時是怎麼了，面完就呆坐在那回想，不敢相信自己會那麼回答

應該就是很久沒被面試了吧，慌了神，也沒有總結好自己所做的專案，分析出專案中的重要部分，技術積累還是不足。

不服呀，隨之就利用了接下來的一週時間，把JQ原始碼完整地看了一遍，我等菜菜只看懂了八九十這樣子（也算是第一次完整地看原始碼）

然鵝，公眾平臺的告吹經歷，直接導致了下一個運營平臺的不合適（因為是同一個大團隊負責的），可以說很慘烈了

還好後面有個機遇

三、這兩年半

算起來畢業差不多兩年半了，畢業那會定下來的職業規劃，前端規劃，現在看來肯定是沒實現多少的了。回想起來，還真沒有什麼可說的

前一年半大概過得很瀟灑，大部分週末都會帶著小相機外出拍來拍去的，逛了廣佛附近蠻多所謂的景點（四五十個應該有了），

近一年意識到再這麼下去會不會廢了，就減少了週末外出的次數，想著看看書搞搞個人專案什麼的，

然鵝那是不可能的，在家會不知不覺玩起了手機，還熬夜玩手機...

部門負責的是公司內部的系統，內部系統，即使用者群體為內部員工

常人看來多為管理後臺，外加很多奇奇怪怪的許可權

許可權多那是沒錯，但管理後臺就真沒幾個了，內部系統也可以有各種各樣的系統

就係統來說，算下來應該新開發了十來個新系統了，專案參與度都非常高，各有特色，也有蠻多有意思的技術點

對業務的理解能力應該有了一些提升，至少不會趨於侷限，能經常從整體的邏輯關聯上考慮問題了

其中大概有三個系統，大大鍛鍊了前端整體架構方面的能力（這裡指的是需求整體分解，功能模組劃分及通訊，技術實現規劃，人員分工排期）

也從最初的對產品畢恭畢敬到現在的產品沙比-_- 需求調整真是非常快

整了一些移動端活動頁，不過也僅是活動頁了，若是說移動端的系統，我還是沒有太多經驗的，所以後面就跟隨技術的步伐，整了個移動端的適配佈局，以備不時之需。

移動端的除錯，部門內一直沒有一個可用的方案，一碰上問題，根本不知道怎麼解決。後面就整理了一個比較完整的除錯方案，用得還算方便

資原始檔快取的問題一直存在，很多時候大家會忘記加上時間戳（或不知道要加，或忘了加）

為了改善這個問題，把塵封已久的Node.js拿出來玩了玩，整了一個本地監聽檔案改變則更改相關引用資源時間戳的小工具，在其他老專案中也一直沿用著

在requirejs專案中的去快取配置是比較暴力的，設定urlArgs直接配置所有資源的時間戳，後來想著能不能結合Grunt和Gulp來自定義資源的時間戳，正好也可以搞起前端構建工具，然鵝都失敗了，檔案依賴實在不好解決。把目光投向webpack，也是想著先結合一下，差不多到成功的時候發現，一個關鍵的路徑依賴問題實在搞不下去了，時間關係只有放棄（當時這塊已經研究了一週多了，不能再浪費時間）。就放棄了對requirejs專案進行這種時間戳優化

從而也誕生了另外一個方案：使用webpack和es6（或者再加上React）作為技術棧。webpack這個東西，其實配置是蠻複雜的，好像也沒有一個比較完整的構建配置例子和說明。React和Vue提供了開箱即用的腳手架，但當時覺得還是自己整一個好一點，就花了非常多精力去除錯配置項，印象中最麻煩的應該就是熱更新替換、jquery相關引用、編譯效能、模組提取權衡、資源路徑處理這幾塊，不過最終還是搞了起來搞出成績，績效拿到了唯一的一個S。多的時候會同時開十幾個專案的編譯程序編譯，隨之整了一個同步讀取可用埠的npm包，防止熱更新埠衝突。為了便於維護，也對開發和生產環境做了區分。

後端已經完善了一套程式碼規範，而前端竟然參考的還是後端的PHP規範，也只有JS有這種規範。沒有規矩不成方圓，就在某個季度初期，決定把前端規範搞一搞。遂參考了大大公司們的規範，結合專案中的使用情況，整了一套適合部門的規則，看著算是比較完整的。然鵝，人是不可信的，還是應該有工具來限制好這個規範的實施，又搞起了前端程式碼檢查工具，經歷了選工具、選規則集、各編輯器配置規則集、webpack配置規則檢查四個痛苦的過程，本來還想弄一下SVN的hooks來做提交前檢查的，只記得遇到了蠻多問題就沒有繼續往下了。不過，前端規範的落地，目前來說並不是非常理想，落地這塊還是蠻有難度的，還得考慮後端突然也改前端的程式碼。

渣渣電腦越來越卡，專案編譯得越來越慢， 在webpack4趨於穩定的時候，覺得應該升級升級以提升效率，果不其然，升級後速度提升了近7倍。結合日常開發的那堆專案，心想應該可以讓配置更為簡單，便對配置項再度抽離，核心檔案抹平不同專案之間檔案路徑的不同，對外暴露業務關鍵配置部分，績效繼續拿了個A

前端安全這塊也是一個很大的知識點，自己最初也是懵懵懂懂的，後來也是想著要徹底理解它，以在部門內進行分享為目標去研究它。在專案中不斷地測試後，最後便整理出了之前那篇文章，因眼界不足還有很多可以改善的，得等以後慢慢去整了。

前端效能方面，完整地看了Chrome DevTools和相關官方出品的文件，早些時候也過了過那本《Webkit技術內幕》。目前進行了四個比較有意義的優化實踐，兩個移動端活動頁的卡頓優化（主要是安卓手機呀為什麼經常卡..），一個頁面載入效能優化，一個頁面執行時效能優化。目前正在嘗試做JS執行優化的實踐

前端錯誤記錄，打點監控方面，也沒有做過太多的實踐，這個和前端測試一樣，都算是沒啥經驗了。目前正在開展這塊的調研

原始碼解析方面，完整看了JQ原始碼，看了React原始碼實現的主要部分，理解了webpack編譯生成的檔案規則

看書方面，看了兩本小說，十幾本技術相關的

個人專案方面，就寫了四五個小專案

帶了兩個新人，第一個是個好苗子可惜後面就撤了

另外一個就差一些了，沒啥基礎，校招後端轉過來的（也不能怪他，就怪老大騙他進來做前端）

面了十幾個人，有不一樣的感受，還是很感謝能有這種麵人的經歷的

團隊管理方面，說真的，我們前端老大真是失職呀，團隊基本沒什麼成長，沒什麼規劃，也經常請假，我都替他憂心。找個好老大很重要

所以平時就承擔了一些本該前端負責人才做的工作，也瞭解到並實踐了一些管理者的日常

然鵝好像沒啥興趣，看起來我還是比較偏向做技術的...

最後回頭看看，技術提升的曲線的是有些放緩了，可能我不算是那種Geek吧，有時會懶得寫程式碼懶得做技術，有時又很能投入進去。

應該多回顧一下過於做過的東西，有沒有價值，有沒有提升，自己有沒有懈怠。多看看外面的世界是怎樣的。

新的平臺，帶來新的機遇和挑戰，就加油吧 ^-^