【年終總結】微信前端社招有感
時間飛快，轉眼間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吧，有時會懶得寫程式碼懶得做技術，有時又很能投入進去。
應該多回顧一下過於做過的東西，有沒有價值，有沒有提升，自己有沒有懈怠。多看看外面的世界是怎樣的。
新的平臺，帶來新的機遇和挑戰，就加油吧 ^-^