BAT裡因為實習時間要求只面了兩家，另外面了若干比較有名的創業公司，都是前端。目前沒有失敗過，只有在確認發offer協商實習時間和是否能到崗的階段因為家庭原因主動放棄了一些，感覺敗了很多RP，OTZ……真的很對不起HR姐姐們和一些熱情的面試官，所以來介紹一下個人經驗補點RP……首先要明白的是，應聘實習是一個雙向選擇的過程。因為前端入門門檻相對於其他崗位低，所以相對而言要在候選人裡挑到靠譜的前端就更難，個人體會是目前要招前端的地方很多都確實非常缺人，但也怕招到不靠譜的人來創造負價值，所以如果你比較靠譜的話自然會有團隊主動找你想讓你加入，而如果你想進大廠的話，只要在面試的階段儘可能表現出自己靠譜，就OK了。個人感覺對於前端來說，靠譜的表現主要有以下幾種：1. 要有比較好的計算機基礎這裡的計算機基礎指的是資料結構與演算法，作業系統，編譯原理，計算機網路等等。雖然相對於其他方向而言，前端在工作中用到計算機基礎的地方可能少一點，但是無論大小廠，招實習生其實都是為正式招聘做儲備，所以會比較希望招將來有更大發展空間的人，就像裡 Web 前後端分離的意義大嗎？ - 知乎使用者的回答 和 怎樣成為全棧工程師（Full Stack Developer）？ - 知乎使用者的回答 描述的那種。如果你具備比較好的計算機基礎素養，那麼以後在擴充到其他領域（WebGL —— 計算機圖形學，Node.js 底層 —— 作業系統，JS 引擎和各種預編譯工具—— 編譯原理, etc.）的時候會更快上手。另外有一些公司對前端的概念不侷限於 Web 前端，也包括移動端偏前端的部分，這裡也需要你有比較好的計算機基礎才能做好。前端領域有很多人已經不滿足於造輪子，直接跑去造語言了，如果你程式設計基礎夠好，接觸過各種形形色色的程式語言和正規化，再上手這些東西也會方便些（比如Ruby/Python->CoffeeScript，Haskell->LiveScript）。雖然也有很多地方為了招到足夠多能來幹活的前端會降低對計算機基礎的要求，但是打好這方面的基礎是沒有壞處的，如果面試筆試被問到且答得上來，也是能夠加分的。一些大廠經常會出現“不是前端的面試官來面前端”的情況，我個人是覺得如果這類面試官問的都是計算機基礎問題的話，其實真的無可厚非，畢竟人家在面“一個前端程式設計師”之前，是在面“一個程式設計師”啊……2. 要懂得現代前端的一些新技術比如：前端自動化工具（Gulp/Grunt等）模組化（CommonJS，AMD/CMD模組載入器，各種Bundler，ES2015 Modules等）前端 MV* 框架（Backbone，Angular等）編譯到 CSS 和 JS 的一些語言（Less/Sass/CoffeeScript等）前端自動化測試工具（Karma，Mocha，Web Driver等）其他有一些同學覺得這些東西懂得越多越好，我個人是覺得這些工具不一定要都瞭解（畢竟它們很多也未必能火多久），但對這些東西要有大致的概念，並且每個領域的用過一兩種（最好是在專案裡），清楚它們的優缺點和必要程度。這是區分在前端上投入過一定精力的人和跨行來兼職前端的人的標誌。去大廠校招應聘前端的會有很多隻是做過一些 Web 專案，但不一定對前端的技術很瞭解，只是看前端門檻比較低就去投簡歷的人。如果你對這些新技術比較瞭解的話，起碼能夠證明你是比較專注前端而且花過一定時間在上面的。同時，前端現在確實是一個每天都有很多輪子冒出來的領域，也需要你有足夠強的自學能力和（英文）文件閱讀能力去跟上社群的這些新動態。接觸過比較多的輪子，才會有自己的判斷，不會老是人云亦云火一個學一個。這些工具裡，確實也有很多在合適的場景下可以提高前端的生產力或者程式碼質量，對這些東西有一定關注，也表明你對自己的生產力和程式碼質量是有一定關注的，這其實是一個更廣義的靠譜程式設計師的特性。3. 懂得什麼是 Web 標準和瀏覽器開發維護的流程，並且會跟進新發布的標準和主流瀏覽器新實現的特性當然面試的時候一般不會直接問你這方面的問題，但是如果你懂這裡面的水大概是怎麼一回事的話，在很多問題上（特別是相容性問題上）都能回答得比較深刻一些。最好清楚：HTML、CSS、DOM，ECMAScript 和一些泛 HTML5 的標準是怎麼制定的W3C 和 WHATWG 的區別各種標準的不同版本和提交狀態是怎麼回事知道標準和實現的差距（有些人喜歡把 W3C 標準奉為圭臬，但現實中瀏覽器們並不是這樣的）知道 ECMAScript 和 JavaScript 的區別知道瀏覽器的一些常見做法（比如給 CSS 特性加字首）的緣由標準和瀏覽器這灘水還是很渾的，涉及到很多利益糾葛和大廠的博弈，如果你大概清楚他們的一些事情，不光自己做前端相容的時候會容易一些（不會只抱怨“為啥XXX就是不能OOO”而是懂得他們的無奈並且認真尋找解決方案），在新特性出來的時候也更容易消化（不是“啊又出了個新東西要學好煩啊”而是“在郵件列表上爭（si）論（bi）了那麼久他們終於把這個搞出來了”），你自己對前端比較基礎的那部分的知識體系更會有條理得多。個人覺得這也是區分比較有經驗的前端和臨時跨行的前端的關鍵之一，這些東西是需要你經過一段時間的耳濡目染才能理清楚，而且會在一定程度上影響你的工作的。4. 多看書，多關注技術資訊技術資訊的來源包括RSS、郵件訂閱、比較重要的郵件列表、或者follow Twitter和微博上一些比較有影響力的開發者。個人經驗是，一般在二面或者三面的時候，面試官都會問類似“你從哪裡接觸前端的新技術/你看過哪些書”的問題，因為前端現在技術更新很快，比較專注於前端這方面的人一般都會有自己接觸新技術的渠道，他們自然也會比較關心候選人是不是有在跟進社群的一些動向。其實這也能夠排除那些不太靠譜的臨門跨行的人，因為他們平時一般不會特意去關注前端技術的新動態的。5. 不僅懂得一些東西怎麼寫，更要懂得一些東西不要怎麼寫Web 標準大多不是嚴格向後相容的，很多幾年前常用的寫法，現在已經被社群的大多數人強烈建議避開了，有很多特性也隨著時間的流逝被打上了 deprecated 的標籤，如果你不幸拿著一本比較老的書入門，又不在網上驗證上面說的每一句話，那麼很有可能你就這樣被誤導很久，比如 HTML可能會逐步被XML所取代嗎？（來自《css權威指南》） - 賀師俊的回答 這樣的情況……與之類似的還有：JavaScript 裡那數量令人歎為觀止的坑一些在經驗比較豐富的前端看來屬於常識的東西（比如：為什麼 CSS 大多放在 head，JavaScript 多放在 body 底端？）劃分各種模組、檔案，新增模板的正確方式（比如錯誤方式是一堆指令碼/樣式寫在一個超大檔案裡，或者在有替代方式的情況下在 JavaScript 裡拼字串）解決一些老問題的新的best/better practice（比如不要到了 2015 年還深陷在回撥地獄，去看看 promise 和 generator）……這些知識都需要你有一定的前端方面的經驗，看過比較多相關的部落格和書，才能慢慢積累起來，所以也能區分靠譜的前端和不靠譜的前端。6. 不依賴某一個特定的框架或者庫比如很常見的“離開了jQuery就不會寫前端”星人……也不是說要做原生 JavaScript/CSS 和 DOM 的原教旨主義者，但高度依賴某個框架或者某個庫的話，通常意味著換了一個框架/庫你的學習成本會比不依賴特定輪子的人高，因為這通常是處於還不知道前端領域“什麼是什麼”的階段的表現。事實上前端領域的這些輪子有一些都是其他領域早就有，或者根本不需要的東西，其中很多的實現原理也不是那麼複雜，只不過是髒活累活。個人覺得對這些東西應該報以“不能知其然而不知其所以然”的態度，起碼大概清楚它們的實現是怎樣的套路，知道它們的優缺點，多接觸幾種，這樣在換一個替代品的時候很快就能上手。因為前端的特殊性，在開發比較大的專案的時候使用庫和框架是必須的（比如遇到各種滑鼠事件的前端相容問題時，總不能全都就地寫 if-else 吧，總得封裝一下。遇到非常 data-driven 的專案，還用手動操作 DOM 的寫法很難維護吧，用個 MV* 框架真的不純是偷懶了），但是這些東西都是會迅速改朝換代的，死守著某個特定的庫或者框架，確實不太靠譜。很多公司喜歡問候選人“原生 API 寫個 Ajax 請求怎麼寫”這類問題，感覺很大程度上也是在排除這類人……7. 懂一點點設計這裡說的不是切圖啊PS啊AI啊什麼的，而是大概懂基礎的視覺傳達/色彩構成/平面構成的知識。畢竟前端是和設計師聯絡最密切的程式設計師，雖然前端要做的事不僅僅包括 UI/UX，但是 UI/UX 卻都主要依賴前端來實現。很多時候，設計師（特別是不會前端技術的設計師）給出的設計可能很難（在照顧相容性的前提下）實現，這個時候不應該跟他硬拼讓他改設計，或者自己默默糾結怎麼用很 hack 很難維護的方法去實現，而是理解設計的意圖，並且跟設計師溝通，儘可能在工程上容易實現容易維護的前提下實現設計的意圖，哪怕要修改一些具體的表現形態。最恐怖的就是丟一張圖過來，讓你做到 pixel perfect，你也不問三七二十一直接開工，程式碼寫得彆扭也不去溝通，遇到不相容就打個哈哈矇混過關了……設計的目標是讓大眾都能更容易地使用，這樣做是與設計師存在的意義背道而馳的，我也遇到過一些設計師會主動來問前端怎樣的設計在瀏覽器裡容易實現，怎樣的設計比較彆扭，這樣他才能結合多方面的資訊去做設計上的決定。如果你對設計不關心，不與他交流的話，實際上相當於剝奪了一些關心工程實現的設計師的知情權（一般正常的設計師看到自己的設計實現出來效果不好，也會小鬱悶的……）。個人覺得與設計師溝通的技巧，也是一個靠譜的前端應該具備的素養。8. 懂一點點後端（這個是我看了一下別人的答案補加的）。其實這個和第一點的目的類似，最重要的是別要做一個非得等隊友來才能開工的人。大廠（主要是阿里系）有不少在用 Node 做前後端分離一類的事，另外做前端的經常要在後端還沒寫完的時候自己去 mock 一下資料介面，如果你懂怎麼搭建簡單的伺服器和 serve 資料給前端，那麼就可以提高開發的效率。即使你只想專注前端，但前端有很多東西（比如 JS 跨域，WebSocket，SSE，WebGL 的素材獲取）都需要你懂得架設簡單的後端才能去實踐，這時候不懂後端通常就意味著你要放棄學習這些知識，或者只能紙上談兵。一個正常的前端肯定是要對計算機網路和 HTTP 等協議有一定了解的，有了這些知識去學簡單的後端其實是很水到渠成的事情。9. 在前端投入足夠的時間意識到以上幾點還需要投入足夠多的時間才能看到成果，不然很容易出現“道理我都懂，可是OOO”的情況，那最後也還是靠譜不了的……如果不是真的對前端感興趣並且投入足夠多的時間，與其為了“好找工作”而投前端，不如轉一個更合適的方向。阿里前端的困局與突圍 · Issue #141 · lifesinger/lifesinger.github.com · GitHub 和 圖靈社群 : 閱讀 : 企業軟體領域前端開發的困境 都能說明這個問題。另外有些面試官喜歡問你一些很細節的 API （雖然我個人覺得這類問題很囧），這些東西很多時候都是靠的“無他，但手熟爾”，雖然有一些確實有點刁難人的味道，但有一些真的是如果你經常寫前端，重複多幾次就會記住的，如果記不住，只能說明你前端寫的不夠多。還有一些沒足夠實戰經驗的人很少遇到過的問題（比如 JS 跨域），也是需要在前端投入足夠多的時間，才會接觸到（無論是紙上談兵，還是專案裡遇到）。其實綜上所述，不靠譜的前端大概表現就是：計算機基礎不好（更糟糕的是程式設計基礎都不行，不過程式設計基礎和計算機基礎好不好跟績點高不高專業對不對口這些其實真的不一定有什麼關係……），對前端的認識還停留在十年前，對社群出現的新工具完全不認識（沒認識全很正常，但完全不瞭解就有點兩耳不聞窗外事一心只讀聖賢書的味道了……），不懂 Web 標準是怎麼回事或者不在意標準，遇到相容問題就複製貼上搜到的程式碼，對於一些在社群裡是常識的坑毫無意識地各種踩，“離開了jQuery/某庫/某框架就不會寫前端”星人，或者平時根本沒怎麼做過前端的東西，只是做做 Web 專案順帶寫前端，到應聘了臨門一腳跑過來……不管是平時學習還是筆試面試，儘量避免向這些特徵靠攏就可以了。事實上大廠們招人不一定會要求這麼嚴格，而且大廠裡的團隊本身也未必個個靠譜，但是平時有在這些方面努力的話，起碼如果掛了會知道自己哪裡不足，或者到底是他的問題還是你的問題……以上大概就是我覺得拿到大廠（or前端比較靠譜的中小廠）前端offer需要的水平，其實我感覺沒必要拿“實習”這個詞來限定自己，儘量往高水平靠攏，才能做到是你來選公司，而不是公司來選你，這樣你才能結合興趣/家庭/個人規劃之類的因素拿到最適合自己的 offer。另外，我覺得面試這回事是這樣的，上面提到的這些特徵，每一條單獨拿出來，在不確定面試官的情況下，既不是拿到offer的充分條件，也不是拿到offer的必要條件，某一條不滿足，也不是拿不到offer的充分或必要條件。大廠的面試官有很多種，有些設計出身喜歡問設計，有些後端出身喜歡問偏後端的東西，有些喜歡問你API細節，有些喜歡問你實現思路，有些喜歡看你學習能力，有些面試官本來就不是前端所以喜歡問你基礎題。如果你側重某一些方面，雖然無可厚非，但是運氣不好遇上期望不同的面試官，可能你就會得到比較低的評價或者掛掉。確定能拿 offer 的唯一途徑，就是面面俱到，這當然是不可能的要求，但大廠的種種因素配合起來往往就是在找這種不存在的人才，真的想拿 offer 的話，就只有硬著頭皮儘量靠攏。就像國內很多大廠裡比較著名的前端們文章/部落格/知乎裡提到過的一樣，前端這塊水不是很深，但水非常非常寬，在考慮將來作為一個前端如何發展如何應對天花板之前，先要腳踏實地把這些屬於前端的“本分”的東西搞好。事實上前面提到的這些東西我也沒有全都做到。作為前端，個人覺得最重要的是要保持一顆開放、謙卑的心，不要牴觸新東西，永遠記得外面的世界還有很多東西自己不懂，要繼續學習。 有任何疑惑加群QQ786276452
對前端的技術，架構技術感興趣的同學關注我的頭條號，並在後臺私信傳送關鍵字：“前端”即可獲取免費的架構師學習資料
知識體系已整理好（原始碼，筆記，PPT，學習視訊），歡迎免費領取。還有面試視訊分享可以免費獲取。關注我，可以獲得沒有的架構經驗哦！！