騰訊、阿裏、網易 這種級別的我不敢說，以我個人的經歷來分享一下吧。
先交代背景：上海的創業公司，成立快十年，團隊規模近百；主力是自己的產品，有時也作為技術合作方幫合作夥伴做一點外包；前端團隊10人以內，目前主要技術棧是 React。
負責招聘工作也有 2 年了，題主給出的要求，別說這些大廠，我們這些普通小廠基本也都這麽要求。但從以往的情況看，大部份應聘者都是：
總的來說就是能幹活，但知識結構不夠系統，規範性太差，需要團隊裏有人帶。
有人說是不是你要求太高了，有本事的都去大平台了，能來你這兒的品質不會太高。這話有一定道理，但說真的，我的要求已經很低了。給大家看一些我面試經常聊到的話題，個人認為都還是很基礎的，如果這個水平都達不到的，我是真的不放心把計畫交出去：
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，而是你做事情的方式讓人覺得「專業」、「靠譜」，事情交給你之後就能放心的回去等結果了。人家要的是結果，而不是你某一點的能力有多厲害，資本方是不在意技術細節的，只有你自己在意。
能幹活的有一堆，但是有自己獨立思想的人，真就那麽稀有。也正因為稀有，才體現出價值。如果滿天飛的都是「高級」了，那麽我們是不是又要重新定義什麽是「高級」了呢？
====================
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，你也應該清楚自己在新團隊中的地位。
