這是門檻問題。

至於BAT，面試同樣嚴格。

根本原因1，是因為僱傭關係，程式設計師太多了，公司太少了，僧多肉少，沒辦法。

根本原因2，會得越多，哪怕進去寫增刪改查的程式碼，也會考慮很多意外情況，保證程式碼的高可用性和效能。

應屆生也可以寫增刪改查的程式碼，如果沒人稽核，可能在特定情況下，bug會更多。

如果你是面試官，你肯定會招人特別嚴格的，不嚴格，就容易留坑。

至少大廠需要造，擰螺絲的事情都外包出去了，給你的工資越高，造的可能性就越高。特別是行業領頭的大廠，遇到問題想谷歌百度可能都沒有多少資料，這時候只能靠自己的人脈圈子，和自己的學習能力。比如讓你限流限頻，防羊毛黨。或者出現系統使用者量暴增，導致要緊急擴容。又或者有一個隱形bug導致oom，限時就要定位到。我在安卓剛剛在國內興起的時候，負責實現影片截圖音訊獲取，在電腦上做成flv影片流，當時沒有人做這個。光這個flv格式就搞了兩三天，現學ffmpeg又幾天。後來有了HDMI以後，使用晶片去做了。當你在一個領頭羊企業，和一個全新領域的時候，不會造肯定是不行的。如果能力不夠，就會在大廠擰螺絲，維護已有的祖傳程式碼。能力足夠，就會去做框架，做全新的領域，試探性專案。

個人沒有在巨頭公司工作過，但有幸做過一段時間的面試官。就個人來看，程式設計師面試是並非是“造火箭&擰螺絲”，其實是在考察程式設計師的各方面能力，不僅僅包括技術能力。

面試過程中，面試官不僅僅是針對應聘者做過什麼，是否真實進行調查。其實在一定程度上，也會進行問題的擴充套件延伸問答。

這是在考察應聘者，是否對工作所涉及的相關領域有延伸解讀，有沒有自主學習或者技術選擇能力。

如果應聘者有此方面的能力，說明他真正對工作內容進行了思考。

當然，技術能力是關鍵的。面試有時常涉及演算法問題，即使面試的職位跟演算法其實沒有太大的關係。

演算法題目其實在考我們的思維方式。實現功能，其實是工作的最基礎要求。若沒有效能上的考量，應聘者即使透過面試，其工作內容也只是搬磚。

有時一些複雜的難解的面試題，不僅僅是在考察應聘者的技術能力。態度或是否認真仔細也是觀察的另一方面。

可有時應聘者不自知，從網路上查詢答案粘貼後，竟連回車換行都懶得提換。

如果你站在面試官的角度，你會如何理解這樣行為？

所以，不要從表面上看待問題。應聘技術崗位，不僅僅看的是技術。別小看那張“造火箭”的面試題，它能在短時間內，從側面向面試官展示你的工作細節。