騰訊、阿里、網易 這種級別的我不敢說，以我個人的經歷來分享一下吧。
先交代背景：上海的創業公司，成立快十年，團隊規模近百；主力是自己的產品，有時也作爲技術合作方幫合作伙伴做一點外包；前端團隊10人以內，目前主要技術棧是 React。
負責招聘工作也有 2 年了，題主給出的要求，別說這些大廠，我們這些普通小廠基本也都這麼要求。但從以往的情況看，大部分應聘者都是：
- 1-5 年工作經驗，專科 > 本科，跨專業 > 計算機專業。
- 大部分是一畢業就從事前端的；排第二的是 UI 轉前端；然後是其他更遠的行業轉過來的。
- 項目做過不少，但技術含量普遍不高，體現不出什麼。
- 會 Vue 的比會 React 的多，全家桶做 SPA 都會，服務端渲染基本沒接觸過。
- 基本功勉強及格，但提到規範、標準瞭解非常有限。
- Node.js 最多跑過 Demo。
- Webpack 用過但不會配置，Git 會基本操作但不懂 Git Workflow。
- ESLint 之類的基本都聽過，堅持做的沒幾個。
- 鮮有自己博客或者 Github 有可展示的內容的。
- 英語水平普遍很糟糕。
總的來說就是能幹活，但知識結構不夠系統，規範性太差，需要團隊裏有人帶。
有人說是不是你要求太高了，有本事的都去大平臺了，能來你這兒的質量不會太高。這話有一定道理，但說真的，我的要求已經很低了。給大家看一些我面試經常聊到的話題，個人認爲都還是很基礎的，如果這個水平都達不到的，我是真的不放心把項目交出去：
Q：簡單介紹下 React / Vue 的生命週期
A：幾個鉤子函數基本能報出來（如果不講究按順序、按掛載/更新區分、能把單詞用英文念出來並且唸對的話），稍微深入一點問下各個階段都做了什麼，一半以上就“不太清楚”了。更有甚者我問 React，對方回答 created、mounted，提醒之後還覺得自己沒錯的。
Q：【React】定義一個組件時候，如何決定要用 Functional 還是 Class？
A：簡單的用 Functional，複雜的用 Class。（不能算錯吧……但也不能算答到點子上）追問怎麼界定“複雜”，答不上來。
Q：【React】HOC、（非）受控組件、shouldComponentUpdate、React 16 的變化
A：不清楚、沒接觸過。
Q：【Vue】介紹一下計算屬性，和 data、methods、watch 的異同
A：基本都能巴拉一些，說的大部分都對，但就是說不到最關鍵的“當且僅當計算屬性依賴的 data 改變時纔會自動計算”。
Q：【Vue】爲什麼 SFC 裏的 data 必須是一個函數返回的對象，而不能就只是一個對象？
A：我承認這個問題有點小難，有一定的區分度，不是每個人都有關注過，但是官方文檔有說明這一點，但凡看過的肯定有印象。即便沒完整看過文檔，在初次學習的過程中難道就不覺得奇怪嗎？“學而不思”的人和“學而思”的人，區別還是挺大的。
Q：CSS 選擇器的權重
A：經典問題了吧？背都能背出來吧？僞類、僞元素分不清楚，只知道內聯、!important、ID、Class 之間的順序，加上其它的就懵了，而且只說誰大於誰，講不出四位數的計算方法。單層選擇器比較還行，幾個疊加起來就迷糊了。
Q：JS 有哪幾種原始類型
A：基礎題，能說上來幾個，答不全，主要問題集中在 null 和 undefined 沒考慮進去、對象和數組算不算原始類型、以及 Symbol 很多人不知道。
Q：ES 2015+ 有哪些新特性
A：這題可以說的很多，根據應聘者的回答去展開，可以很容易地看出應聘者有沒有系統地學習過這方面的東西，以及有沒有持續地去跟進語言標準的發展。但這一題能回答的比較好的，寥寥無幾，大部分是遇到問題然後零零散散現學的，不夠全面、也不夠深入，簡單用過，但稍微問點細節就只有“尷尬而不失禮儀的微笑”了。
Q：工程化工具的使用（Webpack、ESLint、Yarn、Git）
A：基本都有所接觸，但只是“用過”，算不上“會用”，一切順利還好，真遇到問題了，立馬就懵。
Q：Node.js
A：寫過 Demo 的水平。
Q：未來 1~2 年的職業規劃、下一步最想學的技術、最希望往什麼方向發展、怎麼看待XXX技術
A：大部分人對自己沒有一個明確的態度和規劃。說白了就是還沒從學校裏出來，什麼都等着別人來安排。
難嗎？
以 3 年爲例，差不多也算是職場上一道分界線吧。優秀的人不會擔心沒處去，不那麼優秀的人各有各的理由。個人感覺這個階段的人大部分都還缺少一些“職業性”，對自己在職場上的“人設”沒有很好的關注過，只知道風往哪兒吹自己就往哪兒去，對自己的未來完全沒有規劃。很多人的技術成長都依賴於公司的業務，學不到東西全怪公司太小接觸不到技術難點，然後就想着跳槽，寄希望於新的環境能有牛人帶。殊不知技術的積累和公司做什麼項目一點關係沒有，完全是靠自己對行業的理解，以及空閒時間的安排。
我自己工作年頭也不算太長，到今年年底算整 3 年。多的咱不說，畢竟沒經歷過的沒有發言權，分享一下我所理解的1 ~ 3 年，3 ~ 5 年應該有的樣子吧。
第 1 年：
以自己經歷來說吧。16 年入行，Bootstrap + jQuery 實現功能沒問題，但代碼設計功力還很淺。我入行的時候 React 和 Vue 剛火起來，Bootstrap + jQuery 還是主流，ES2015 已經出來，我也學了一半了，但 Gulp、Webpack 還一樣都不會。接手的第一個項目是 Angular.js 的，之前沒學過，第一天就讓改東西，只能現學現賣，接下來一週自己花時間把 Angular.js 基本用法搞懂。同年自學了 LESS、SCSS、Stylus、PostCSS，工具方面把 Gulp、Grunt、Bower、npm、Yarn、Webpack 都學了一遍。剛入行時候最大的感覺就是整個行業都在往組件化走，同期有一大堆的工程化工具需要掌握，整天活在一堆聽不懂的名詞裏，所以當時的目標就是儘快把這些不懂的東西弄懂，能跟同行說上話。
第2年：
頭一年的目標還是順利達成了，到年底，我已經全面採用 ES2015+ 開發了，相關的工程化工具也都基本掌握了，但到框架層面還是隻會 Angular.js，而主流市場好像已經有了新的選擇。看網上評論說 Vue 上手簡單，於是從 Vue 入手，開始學習新的技術棧，做了幾個項目覺得比較穩了，就開始挑戰 React。這一年 Angular 也開始了大改版，到下半年的時候，我找了一個相對不重要的項目，試水了一把 NG4，並實踐了 TypeScript。至此，主流的技術棧基本都掌握了，滿足常規業務需求不成問題。
第3年：
18 年開始公司迎來了一個高速發展期，單個項目的規模光靠一個人已經顧不過來了，需要團隊協作。既然是團隊協作的項目，那麼就要考慮大家的能力差異，不能再像以前那樣隨心所欲了，需要給團隊制訂一套技術選型方案，以及必要的開發規範。好在之前對主流的幾大技術棧都有過了實踐，因此這時候也纔有了選擇的權利，一番權衡之後，爲團隊定下了現在的技術方案，並整理了一套開發規範，包括開發環境、代碼風格、開發流程、最佳實踐等等。這一年也是我第一年真正以一個 Team Leader 的身份去帶團隊，身份的轉變也打亂了我原本的學習計劃，我很難再有比較連續的時間可以用來系統地學習一些技術，經常會被一些雜事打斷，可能是各式各樣的會議，可能是團隊成員遇到的技術難題，我從一個主攻手的位置，變成了一個輔助型的角色，遊走在幾個項目之間，哪裏需要就去補位。當然，即便如此，我還是會在晚上、週末，給自己留出時間去做技術積累，前兩年主要是在彌補廣度上的不足，現在開始就需要往深度去走，例如設計模式、語言標準、代碼規範、內核原理、算法優化，當然一些常規的技術也還是需要花時間去學習的，像 RN、Electron 都是非常值得投資的東西，包括一些服務端的內容，想做 CTO 的話這些都跑不了。
小結一下，前 2 年主要在於觀察和積累，從剛入行的新人快速成長爲一個能夠獨立負責項目的開發者，對行業內主流的技術方案足夠的熟悉，常見的問題要能馬上給出方案，不熟悉的問題也要有思路該怎麼去解決，做到“但凡是我領域內的，不允許自己做不到”。紮實的基礎在任何時候都是你說話的底氣。到第 3 年，這些儲備應該已經就緒，至少不能讓它成爲你的短板，這時候需要開始思考一些基礎技能以外的東西，比如管理能力，無論往後準備走什麼路線，即便是純技術路線，也早晚會要帶團隊。帶團隊也是需要方法的，這種能力誰也不是與生俱來，面對不同的團隊也需要因地制宜給出不同的方法，所以要學的東西還很多。當然技術方面也不要因此而放下，技術的更迭是永恆的，這方面的學習也是一個持續的過程，只要你還在技術圈混，技術實力永遠是你服衆的最佳利器。什麼時候跟不上了，也就差不多要被淘汰了。
3~5 年
這一階段我還沒經歷到，但是很快就會進入，所以自己也有一些打算。進入到這個階段的人都是跳槽市場上最受歡迎的，往年一直都很安靜的求職 App 開始大量地向我拋橄欖枝，各種獵頭也是隔三差五的聯繫我，畢竟從概率上講，3 年以下都還算新人，能淘到的寶很少，從 3 年以上的人裏挑就會容易許多，畢竟到這個時候了，該經歷的也都經歷過了。當然跳槽並不是我們這裏要討論的問題。
到了這個階段，市場默認你已經是個比較成熟的開發者了，沒人會再把你當做應屆生看待，你需要表現出足夠的職業性，對技術、對行業的看法也需要有一定的深度了。從這裏開始，應該開始接觸一些通用工具的開發、系統設計、性能優化、新技術探索、團隊管理等初級開發者做不來的事，如果你還是隻做一些一線的業務開發，出個頁面調個接口之類的，那麼就該考慮到底是自己能力不行，還是被環境束縛了。
所以爲什麼招不到人，因爲真就是沒有那麼多“野生的”符合條件的候選人。大把大把的人其實完全有潛力成爲市場想要的那一種，但是需要人去點化，讓他們明白自己要怎麼去做才能更好的成爲市場需要的樣子。多年來的教育培養出了一大批“懂事聽話”的孩子，現在放任他們自由了，反倒不知道怎麼做決定了。都想伯樂能看到自己，卻不明白自己要怎麼樣準備，怎麼樣展示。
所謂的“高級”，很多時候其實指的並不是你在某一方面的技術有多 NB，而是你做事情的方式讓人覺得“專業”、“靠譜”，事情交給你之後就能放心的回去等結果了。人家要的是結果，而不是你某一點的能力有多厲害，資本方是不在意技術細節的，只有你自己在意。
能幹活的有一堆，但是有自己獨立思想的人，真就那麼稀有。也正因爲稀有，才體現出價值。如果滿天飛的都是“高級”了，那麼我們是不是又要重新定義什麼是“高級”了呢？
最後，不免俗的，招聘走一波。簡歷可以選擇發給 ：
- 貓叔（[email protected]）
- 拉鉤網鏈接https://www.lagou.com/jobs/5173180.html
====================
FAQ ====================
1）評論區有人回覆說難道只要會這些基礎題就可以 20-40 K 嗎？網絡、數據庫、操作系統、數據結構、算法，這些計科的基礎都不問的嗎？上海的錢這麼好賺的嗎？
當然不是！你能問出這種問題說明你自己心裏也有數。
我舉例的幾道題只是一部分，用來說明我的觀點的，不是把我完整的面試過程全給你了，這不是開卷考……
本着實用至上的原則，我一般會先從這一類的問題開始，回答得比較好的，纔會往下深入。二元一次方程都都解不來的，我跟你談微積分有意思嗎？
====================
2）評論區裏有不少人（甚至一些來自大廠的朋友）認爲在面試中問這些基礎題沒有意義，覺得這些知識點無法體現出候選人的實際能力，甚至不需要記在腦子裏，用到的時候上網搜就行了。
對於這一類的觀點，我一貫的態度是：不敢苟同。
前面列舉的這些題，其實是在起個話題，候選人如果對這塊比較熟悉的話，會有很多東西可以講。這時候根據候選人的表現，至少可以看出：1）候選人對特定知識點的掌握程度。2）候選人的知識體系是否足夠系統，能否融會貫通。3）候選人表達、溝通能力如何，有沒有學傻掉。這其實是對候選人能力的綜合考察。
我並不反對日常工作中上網查一些 API、語法，得道有先後，術業有專攻，有些事在所難免。這些題如果有少部分回答得不是很好，甚至完全答不上來，都是可以接受的；但如果大面積的答不到點子上，那就有問題了。這些都是非常基礎的知識點，日常工作中幾乎每天都會接觸到，如果這些還不能脫口而出，還需要上網查，你讓我怎麼放心把項目交給你。
成敗在於細節。我們平時遇到的 Bug，很多時候其實就是一些很基礎的點沒注意，出了問題，這時候如果心裏沒點數，就很難排查出問題的所在。同樣的，在 Code Review 中，我們經常會看到一些問題代碼，雖然功能實現了，但實現的方法並不好，究其原因，就是對這些技術細節理解不夠，導致很多問題沒有考慮到。如果是新手開發者，可以理解，畢竟還在成長；但如果你頂着“高級工程師”的 title 還總幹這種事，那就要好好反省一下了。事情雖小，但如果放任不管，積少成多，遲早會釀成大禍。
專業和業餘的區別，在我看來，就在於各種細節。同樣遇到一個問題，一個需要上網查，一個直接脫口而出，高下立判。況且，在搜索引擎的幫助下，業餘開發者也可以輕鬆做到 60 分；如果你也只是如此，那拿什麼體現你的“專業”呢？
有些人覺得我已經工作好幾年了，應該去幹一些更大的事，就不必再糾結這些基礎的細節了，那是新手該考慮的事。再高級的上層建築，也都是建立在良好的技術基礎上的，底子不牢靠，越高越容易倒，摔得也越重。試問，是什麼樣的偉大事業，連這些最基本的問題都解決不了的人也能勝任？
====================
3）關於 CSS 權重的那道題
首先，這只是諸多面試話題中的其中一個，不是說這個答不上來就直接 PASS，不要見風就是雨 OK？
其次，有些朋友對這個話題的意義提出了質疑，鑑於討論的比較多，這裏就展開一下：面試中問這個問題，可以考察些什麼：
- 很多人習慣於 LESS / SCSS 嵌套式寫法後，已經不再關心選擇器的權重了，甚至都忘了還有權重這回事兒，所以第一個考察點：是否知道 CSS 選擇器有權重一說，這是一個 0 跟 1 的問題。
- 上面提到的這部分人，很多是把 LESS / SCSS 中的嵌套層級就當做權重去處理問題，所以這就帶出了問題的核心：權重如何計算。一方面作爲一個基礎知識來考察，另一方面也考察候選人是否過度依賴某種工具，類似的經典問題還有“不用 jQuery，純 JS 如何實現 XXX”、“不用 Bootstrap，純 CSS 如何實現 XXX ”。到這兒都還是基礎題。
- id > class，內聯 > 外聯，!important 最大，大部分人都能答到這裏，以我個人標準也可以認爲 60 分了，給過吧；但其實這裏可以回答得更好（接下來開始的就比較有區分度了）。元素標籤呢？僞類呢？僞元素呢？屬性選擇器呢？後代/兒子/兄弟選擇器呢？這就可以衍生出一系列問題：CSS 有哪些選擇器？僞類和僞元素的區別？權重的計算規則是什麼？
- 爲什麼我們要在意權重？在爲應用編寫樣式時，我們難免會遇到新編寫的樣式不生效的情況，打開檢查工具一看，發現是被已有樣式覆蓋了，這時候就需要對權重有足夠的瞭解，才能搞清楚每一組選擇器的影響範圍是多大，該怎麼去調整才最合理，總不能每次都簡單粗暴直接加 !important 吧。
- 繼續展開，權重的問題解決了，但計算畢竟繁瑣，有沒有什麼最佳實踐可以減少不必要的權重計算呢？這就可以考察 CSS 的設計能力、對主流規範的認知情況、對新技術的瞭解程度，比如儘量用 class 進行標識而不要直接用元素標籤、給 class 添加前綴以避免和第三方樣式庫衝突，比如採用 OOCSS、SMACSS、BEM 等方案對 class 的命名進行規範，比如通過 CSS Modules / Styled-Components 等方案避免不必要的樣式覆蓋等。
從一個簡單話題起頭，後面可以帶出很多東西，能聊到哪裏，就看雙方的水平到哪裏。
有水平的面試官，除了自身實力過硬，同時也清楚面試不是爲了秀優越，而是發現和吸引優秀的人才加入團隊。作爲 Team Leader，我們真心希望候選人能夠比我們更厲害，這樣團隊纔會越來越好，如果 Team Leader 的水平就已經是一個團隊的天花板，那這個團隊的成長一定是有問題的。如果你應聘高級崗位，但技術實力連鄙視對方 Team Leader 都不夠，那麼即便最終給你發了 offer，你也應該清楚自己在新團隊中的地位。