時間飛快，轉眼間8102還差一個月就over了，順了順好幾天沒理的鬍渣兒，好像已經老了不少。 不，我還很年輕！雖然年終還沒到，但好像也差不多了。 幾經輾轉，年底前終於拿到了微信的offer，可以說是今年一大幸事了。 是一個結束，結束本命年的坎坷；是一個開始，開始新的徵程。 這篇雜文就簡單記錄一下微信 ...
時間飛快，轉眼間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吧，有時會懶得寫代碼懶得做技術，有時又很能投入進去。
應該多回顧一下過於做過的東西，有沒有價值，有沒有提升，自己有沒有懈怠。多看看外面的世界是怎樣的。
新的平臺，帶來新的機遇和挑戰，就加油吧 ^-^
