軟體開發工程師的面試應該考察哪些素質，如何做權衡？
想要找到技術足夠牛，價值觀也與公司一致的人往往是可遇而不可求的事情。
現實中，技術面試可能會遇到一些權衡。
可能剛出校門的人或跨了領域的人，基礎很好但沒有職位所需的領域知識，需要從頭學起。也有一些人有多年工作經驗，但基礎一般，領域知識的掌握深度也一般，但可能可以解決公司或項目組面臨的人手不夠的迫切問題。像這種情況，如何做權衡？
面試中，基礎方面的考察，數學，數據結構與演算法，寫程序的功底，掌握到什麼程度會認為是合適的人選？
再有，演算法和數學題可能相對容易設計，但軟體抽象的領域則不是三兩句話就說得清的，如何在面試中考察一個人抽象的能力，和設計易於維護易於測試代碼的能力？
有很多日常的dirty work，以及很多業務邏輯性的代碼，事實上並不需要太多數學以及演算法方面的知識也能解決。那麼招人標準抬得很高，讓超水平的人來解決這些問題，是否又有浪費之嫌？
問題有點大，也有些雜，總的來說，是一段時間以來遇到的一些問題和困惑，在微博上請教了@Milo Yip，被建議到知乎上來提問，希望各位牛人可以不吝賜教。：）
謝邀。
首先介紹一下背景
行業：我所在的行業IT很重要但並不是revenue center，屬於燒錢部門，地位不能跟純互聯網公司或者遊戲公司比
組：我們組最近幾年的方向都是招一條龍的程序員，以便減少溝通成本和方便問責。這裡的一條龍不但包括技術上寫前後端和資料庫的代碼，也包括在公司內部和用戶溝通拿需求，測試，發布部署前後的行政工作。基本上出了問題推都推不掉。
個人：我本人從來沒有在國內工作過，所以經驗上可能會有所偏差。我一般來說都是第二面，第一面主管已經面過了，簡歷上的問題問的差不多了，所以我很少會問簡歷上的問題。除非有匪夷所思的經歷。
從最近幾年招人的經驗中得出的結論主要有以下幾點。按重要性排序如下：
1 - 態度
這是我最看重的特質，當然這個態度說的不是對我的態度，而是思考問題和解決問題的態度。
個人來說比較偏好的是對自己感興趣的領域具備『打破砂鍋問到底』的精神，具備這樣精神的人往往有一種完美主義，對於自己的代碼有強烈的mental attachment，會自己擠時間不斷地fix bugs，增加unit tests或者refactoring，長遠來看對項目質量非常有好處，組裡有這樣的人非常省心。（哎，我幹嘛幫資本家去想這些）
這樣的面試，我一般直接問candidate你最有自信的技術是什麼？然後順著這個不斷地深入挖掘。通過「如果你來設計」這樣的假設，來考察應聘者對自己自信的技術到底有何種程度的了解，到底有沒有想過這些技術為什麼會是這樣的。
案例1，我對資料庫很熟悉
那麼「如果你來設計」的問題就會類似這樣：
1，如果你來設計資料庫，你會怎麼管理文件的？ 比如我insert了一行數據到employee表，具體在後台發生了什麼事情？ 會有什麼樣的寫入操作？有哪些東西會被更新
2，好，現在record已經在數據裡面了。我跑一句 select * from employee where last_name = "Smith"。你覺得資料庫具體做了哪些事情把這一條數據給返回的？ 它是怎麼從文件系統中把這一條記錄給找出來的？
3，假設我的employee表裡已經有一些數據了，這時候我加了一個新的column，會發生什麼事情？ 文件系統中需要做哪些改動？
4，假設我的employee表裡已經有一些數據了，這時候加了一個index，又會發生什麼事情？ 要寫入哪些文件，具備什麼特性的數據結構？
5，好，現在已經有index了，那麼同樣的查詢 select * from employee where last_name = "Smith" 在執行的過程中會有什麼區別？看能不能具體展開解釋
6，如果你來設計資料庫，你會怎麼實現join呢？如果兩個表都建了索引是怎麼做的？如果兩個都沒有呢？如果一個表有索引？
7, 等等等等。。。。
案例2，我用Spring用得最熟
1，singleton到底有什麼用？我用static method為什麼不能做同樣的事情？ 什麼情況下會用static method更好一些？
2，dependency injection到底有什麼用？ interface在這裡的作用到底是什麼？
3，好，這麼看來，spring確實可能在某些情況下有點用，那麼如果你來改善spring的話，你會改進哪些點呢？
4，能不能大致講講，你覺得autowire具體是怎麼實現的？實際使用中會有哪些問題呢？
5，constructor injection和method injection的優劣比較？ 什麼情況下用哪一個？
6，spring在unit test中起到什麼作用，哪些情況下可以不用spring，給一下具體的例子？
7，如果有一天Oracle想在語言層面支持DI，你會怎麼設計syntax？為什麼？
8，等等等等。。。。
注意：這裡主要考察的是思維能力，看看他有沒有想過這些問題，而不要糾結於Sybase或者Spring是否真的是這麼實現的。我再重複一遍，不要糾結回答的準確性，關鍵是這個人的思路怎麼樣，是不是能自圓其說。
這一部分一般持續20分鐘到30分鐘，取決於candidate的素質和話題本身能不能聊出東西來。可能因為我的這個面試方式比較少見，感覺許多candidate一開始會比較緊張。這時候作為面試官需要不斷地給於正面回饋，讓他覺得自己還不錯，以便放鬆下來。當然，如果實在是太差的基本就直接「do you have any questions for us」了。
2 - 經驗
這個經驗不但包括過去公司里從事過哪些項目，也包括平時都做些什麼。因為我的行業關係，我感覺純大公司流或者純互聯網公司流的都有缺憾。前者過於保守死板沉悶，後者過於激進缺乏質量意識，都比較極端。最理想的是在大公司工作一段時間，同時業餘維護一個github項目之類的。這種人一般既比較積極主動，又能理解並遵守歷史遺留問題。屬於兼容並包的好隊友。
這一塊一般10分鐘，取決於有沒有東西聊。
3 - 演算法
這個可能會引起爭議，演算法上只要不是太差就行，畢竟我們日常工作牽涉演算法的部分不是特別多。 由於一般我們第三面會有別的同時做pair programming，所以我這邊都是大概問一個簡單的但是實際的問題。舉個例子，給你一列區間，如何把它合併起來？
def merge(ranges: List[Int, Int]): List[(Int, Int)] = ???
偽代碼寫在紙上就行了。就是看看基本的排序遞歸的使用。具體排序演算法也不是非得寫出來。
這一塊一般15到20分鐘。
4 - 對新技術的熱情
最近有關注什麼新技術嗎？angularjs啊，好在哪兒呢？akka啊，解釋解釋什麼是Software Transactional Memory啊？之類的。因為很多人很喜歡聊這些，也算是給自己充充電。
可能是我個人經歷的關係，對新技術的熱情是一個必要條件，但並不單獨構成一個加分項，我見過很多對新技術很有熱情，完全只是因為好奇，想嘗鮮的想法。對於組和公司的利益卻不怎麼放在心上。把組裡的項目當成試驗場，這樣的人最後往往需要其他組員幫他擦屁股。
這一塊基本就是閑聊，當是收尾了，5到10分鐘吧。你就這麼想把，這個人進來了，要跟你一起做同一個項目。你願不願意？在我們這，願意就給hire，不願意就給nohire，然後經過了一整天的面試這個人就有了很多hire和nohire，到時候一看便知。
謝@David Chang 邀請 
我擔任管理職位時間也不長，到現在為止大約面試了40人左右（包括校招），你的這些問題我也曾經遇到過，也自己思考和實踐過，因此以下回復談不上專業和權威，僅供參考。
我理解和提煉一下你的問題，你的第一個問題應該是：招人的原則是什麼？
例如：我是招一個技術高手呢，還是招一個正好精通目前團隊負責的業務人員呢，還是招一個畢業生呢？
之所以有這個問題，其實原因就在於：沒有哪個選擇是完美的！
技術高手看起來很好，但如果業務不熟悉，需要花費大量時間去慢慢培養，而且你還會擔心高手來了後技術沒有用武之地，是不是會不穩定；
精通業務的人能夠很快上手，但如果業務稍微變化，或者遇到技術難題，團隊又歇菜了；
畢業生有衝勁、有潛力、便宜，但技術、業務上要投入較多人力和時間培養；
所以，單純的關注究竟招哪個類別的人員時好時壞其實沒有很大意義，招聘的首要原則是：按需招聘！
你的團隊經常遇到技術難題要攻關，或者需要較高的技術水平才能完成工作，那肯定要招技術水平高的人；
你的團隊主要在於業務開發，沒有很大技術要求；或者已經有一兩個技術高手了，主要是業務開發人手不足，那麼就招聘精通業務的人；
你的團隊目前人員搭配合理，但考慮到後面可能會擴展，或者有人員可能不穩定，那麼就招有潛力的畢業生(或畢業不久）的來培養。
對於一個團隊來說，最好也是各種人才搭配，而不能一味追求技術高，要是一個團隊全是技術高手，除非是研究型的團隊，否則真的是很浪費和很難管理的。
我理解你的第二個問題是：如何面試才能識別出你要的人才？
明確第一個問題的答案後，回答你的第二個問題就方便多了，其實還是一樣的指導思想：按需面試！
你的招聘職位需要什麼樣的技能和素質，那就按照需要來面試。
如果你都不清楚你的職位需要的技能和素質，那麼面試的效果肯定不會太好，要麼招聘了不合適的人，要麼篩掉了合適的人。
以你舉的「演算法和數據結構」的例子來說吧，在面試之前，你可以問自己幾個問題：你們團隊是研究演算法的么？你們要自己實現演算法么？你們要改進演算法么？
如果答案是Yes，那麼你就設計好面試題；如果答案是No，那就不要浪費時間了。
我理解你的第三個問題應該是一些具體的面試技巧，特別是對於一些比較抽象的問題，例如分析和設計。
我分享我個人的一個經驗：不要拿書上的東西來面試這些能力，而採用「情景面試」的方法。
「情景面試」就是由你設定一個業務場景或者問題背景，然後由面試者來回答解決方案，或者說你可以和面試者一起來探討解決方案。在這個過程中，你可以感覺到面試者的分析能力、設計能力、知識寬度和廣度、交流理解能力、應變能力。
舉個簡單例子：假設你要面試一個Web後台開發高級工程師，你可以給這樣一個題目：「假設要你設計一個日PV100萬的Web網站，你會如何做」，如果面試者回答還OK的話，你可以繼續問「如果擴展到1000萬呢，方案該如何演進」。。。。。。。。
當然，每個行業的「情景」設計是不一樣的，最好的情景就是來源於你當前負責的業務，但要適當抽象和提煉，不然和業務太強相關了，如果面試者沒有行業背景，可能回答很差。
最後稍微吐槽一下在技術面試中面試演算法，如果是針對畢業生或者剛畢業不久，這個面試倒還有點作用，如果是面向有3年以上的工作經驗的人，還以這個方法來面試的話，是沒有任何效果的。首先，很少有面試者自己精通演算法，所以我們會看到大部分面試官面試所謂的演算法，都是面試最簡單的那幾個，你要真牛逼，自己寫個B-tree演算法看看；
其次，演算法和數據結構這幾個東東，稍微特訓一下，基本上就可以背住了，完全達不到區分人員的目的；
第三，絕大部分人工作中不會自己去寫演算法，真正實用的演算法，和大學課本上的那幾個原理性質的演算法，有很大的區別
謝邀
首先說一下自己：
在讀大四本科生，現為國際某軟體公司實習生
在今年3月份開始，和其他大三的碼農一樣，參加了一些公司的實習生招聘，有的進入了最終面，拿了offer，也有的筆試就被刷了T_T,因此下面說的都是基於實習生面試來說
1. 基礎知識非常重要(基礎知識包括數據結構和演算法，計算機網路，操作系統，資料庫，編程語言大多會問C/C++ 等)。基礎知識貫穿整個筆試面試，建議面試前好好複習，平時也要牢固掌握。
2. 項目經歷。感覺項目經歷反應了你做過哪些事情，具有哪些能力，所以面試官都很喜歡問。一方面是了解整個項目的規模以及難度，還有就是看你是不是真的有參與，是否知道其中的細節。這些問題都了解後，會根據項目的細節問你當時是怎麼實現的，或者有沒有遇到困難怎麼解決，或者有沒有優化的方法等。在這裡還是考察個人的能力。
3. 不同公司不同職位要求不同，建議根據相關職位準備相應的知識。
4. 溝通能力和解決問題能力。現場可能會有一些問題你不能馬上回答出來，面試官會嘗試引導你一步步地解決，給你提示，因此需要有一個好的溝通和解決問題的能力，在和面試官交流中，讓他看到你的實際能力到了哪裡。
以上是自己在面了那麼多公司後的一些心得，希望能對你有幫助。
這個問題是和公司和工作性質相關的。
以我所在的部門而言，較偏向於技術研發多於純粹軟體開發，所以會比較看重基礎。但由於國內一般比較不看重技術研發方面，而是重於產品製作，所以較難找到合適的有經驗的人材。在這個情況下，通常比較希望慢慢培養基礎好的畢業生，讓他們養成良好的技術研究及軟體開發習慣，包括做實驗驗證想法、寫單元測試、寫各種文檔、嘗試做一些軟體設計、與客戶溝通分析需求等等。這需要長時間的投入，不斷討論、檢查代碼文檔、給予建議等等。
當然，程序員總不會100%時間做高大上的事情，總要做一些較簡單、枯燥的工作，這也是一種訓練。
或許有時候可能用不著全部基礎，但有良好基礎的人往往有更好的潛力，在未來可以做更深入的事情。我面試技術人員主要看三點：
1 基礎及相關知識的掌握程度，就算沒有掌握的很全，也應該有那種基礎很重要的覺悟，並且一直在學習。
2 對待技術的態度， 是出於興趣，還是為了那份薪水，區別是不同的。
3 溝通、性格、責任感、團隊精神， 這幾點很重要，將來會直接影響到你的工作。。
技術相關問題可以直接了解， 溝通和性格的問題，需要多了解一下他生活或者對待某些事情的看法去側面了解， 更多的是面試時候是看直覺。
舉個例子， 前段時間面試一個android工程師， 面談了10分鐘，覺得不錯，就讓他做上機測試題， 測試題其實很簡單的， 獲取一個介面的數據， 顯示到listview上就可以了， 但是這人突然表現的很生氣， 摔門而出， 我不知道他為什麼這樣，也許是因為我給的題太簡單了，但是不管怎麼說， 他的性格、態度、行為，已經出賣了他， 假如讓他到了團隊工作， 那他也是一個定時炸彈。
謝邀。沒有在中國長期工作過，下面主要講的都是美帝的情況。我們是一個世界500強公司的美國分部，汽車軟體行業。分享一點我做面試官的感受，也不一定對，但還是想寫出來，希望對在美國找工作的童鞋們有點幫助吧。
面過的人也不少了， 有校招也有社招。插一句，其實我是個很沒原則的面試官。遇到中國人，只要不是差得離譜我都會放水的；但是如果是印度人，就基本上會在問題里挖坑等著他跳。
一，簡歷
簡歷是面試人的第一印象。公司都能給面試人出機票酒店錢讓他來面試了，說明簡歷肯定不錯，電面也忽悠得挺好。所以onsite的時候我的第一個任務就是驗證一下面試人簡歷的水分有多少。
教育背景、工作過的公司我倒是不擔心面試人造假，畢竟有背景調查擋著；至於簡歷上的技能、經驗和項目經歷，那水分可能就大了去了。這部分我喜歡按照簡歷，一個點一個點的問。我們公司是做汽車軟體的。如果是社招，面試人有幾年行業工作經驗，那麼簡歷中一定會羅列很多行業中用的工具、軟體和技能。
比如，面試人說「5年嵌入式C語言經驗、熟悉MISRA編程規則」，那麼我不會問他 「MISRA規則都有哪些?」 ,因為這個問題很容易準備。 我會問面試人：「你最討厭的MISRA規則是哪條？」 。 我的經驗是，如果沒有大量的編程經驗（或者根本不熟悉MISRA)，面試人基本上是楞在那的。而這時，他到底寫過多少行代碼就值得懷疑了。
如果是校招，那麼問這些專業問題是不合適的。我會看面試人上過哪些課、做過哪些course project，然後問他課程里的知識點。
比如，只要面試人上過任何嵌入式編程相關的課，我都一定會問一個問題：How to toggle an LED linked to a particular pin ？我希望面試人在20秒內給我答案，因為這是全美幾乎所有大學嵌入式編程課的第一個實驗。如果這個問題居然答不上來，那我很難相信面試人好好上了編程實驗課。
給面試人的建議：簡歷上的基本事實一定要真實，至於程度，可以摻點水但是不能離譜。掌握的技能、知識和項目，寫到簡歷上了就一定要會，至少不能是一問三不知。
二，基礎知識
無論是社招還是校招，我們都會問一些很基礎的問題，比如static,volatile, constant 這些關鍵詞怎麼用之類。有一次我問老闆，為啥我們每次都得問這些基礎問題，就算不會，隨便在網上搜一下什麼「嵌入式編程面試必考題」之類的都有，完全考不出面試人的水平。 老闆說，很多人就是告訴他這是必考題他也不去看，不僅水平差，還根本不認真準備面試。所以用這些題可以排除明顯不合格的面試人。
給面試人的建議：去面試以前搜一搜面經，看看常問的問題，再翻翻專業課的課本，基礎知識不能掉以輕心。
三，團隊意識
前面兩關都過了，就會著重考察一下團隊協作的能力。這部分考查就很玄幻了，往往考查效果也不太好。無非就是給面試人一個可能的工作場景，問問他怎麼處理。比如多任務的時候如何確定優先順序，如何跟隊友配合之類的。校招的話可以再問問做course project的合作經驗。逃不掉的問題是項目中遇到了哪些困難、怎麼處理的。我覺得這個問題都問爛了，反正我從來不問。
我最喜歡問的是組間合作的問題。假設一個項目，你有個別的組的合作者，你們不在一起辦公。他就是不配合你工作，發郵件不回，打電話不接，分配給他的活也不做你咋辦？別以為不會遇到這種事，大公司里組間互掐的事多了去了。
給面試人的建議：團隊合作的問題，解決方法無非是優化流程、提出方案、請示老闆。不要自己定優先順序，給個方案然後讓老闆定。與隊友共事，服從項目主管安排，明確分工和責任，把自己的工作做到簡明、清晰、可回溯，團隊交流email留底。
四，職業發展
這裡我會考察一下面試人未來三到五年是怎麼打算的，畢竟企業需要一個相對穩定的人員配置。剛畢業的學生，一般頭兩三年不太會換工作，但是如果不是美國人的話，一年以後往往會要求辦綠卡，要考慮到時候公司願不願意支持。工作五年左右的人，很可能會期望一兩年後能晉陞項目主管，要考慮面試人有沒有這個意向以及公司有沒有這個潛力到時候提供相應職位。
總之這部分就是了解一下面試人自己的職業期望是否符合公司的現狀和發展預期，面試人的職業規劃是不是make sense。怎麼說呢，這部分面試效果也很一般，因為哪個面試人會全都說實話呢對吧。只要沒有明顯的硬傷就行了。以前來過一位中國博士姐姐，本來什麼都好，面試時候提到男朋友，不知道和老闆說了什麼，讓老闆堅定的認為她幹不了多久就會和男朋友一起去加州...於是到手的offer也沒了（當然啦人家可能也看不上我們公司的offer）。
給面試人的建議：問職業發展的時候回答的中規中矩就行了。剛畢業的孩子就說希望踏實幹幾年學點知識，以後的事情以後再說。有工作經驗的呢，除了非要這個offer 不可，不然就照自己的需求直說就行了。另外，什麼家庭啊，信仰啊，婚姻啊，年齡啊什麼有的沒的面試的時候面試官是絕對不會問的，自己就不要主動提了。誰知道面試官來了興趣會有什麼奇葩想法。
五、直覺(霧）這部分就更懸了。就像輪子哥說的，就是一個願不願意一起共事的感覺。我上一份工作離職的時候，老闆跟我說：「你知道我為什麼當初招你嘛？你面試的時候給我看了你做的Excel 宏，剛好我自己的第一份工作也是做Excel 宏，我就決定要你了！」 -_-!
給面試人的建議：聽天由命吧...
謝邀。手機作答，寫一下要點。
首先我們確定，要招的是開發工程師，不是產品經理，不是項目經理，不是架構師，不是cto。那麼，招進來就要立刻產生直接的生產力。以此為前提：
一面，主持者：hr
1，候選者期望薪酬是多少，是否超預算。
2，從聊天中判斷候選者的心理狀況，篩除奇葩。
3，了解候選者前任工作狀況，必要時會打電話給前任公司了解情況。
4，介紹公司情況。
二面，主持者：項目帶頭人
1，了解候選者技術背景，過往的成就。
2，根據項目所需的技術，在候選者的技術背景範圍之內，選擇一個問題，現場作答。
3，根據項目所需的技術，但超出候選者的技術背景，選擇一個問題，現場作答。
三面，主持者：cto
1，了解候選者的技術偏好。
2，了解候選者的技術積累以及感悟。
3，介紹候選者預計要分配的項目和崗位。
可能剛出校門的人或跨了領域的人，基礎很好但沒有職位所需的領域知識，需要從頭學起。也有一些人有多年工作經驗，但基礎一般，領域知識的掌握深度也一般，但可能可以解決公司或項目組面臨的人手不夠的迫切問題。像這種情況，如何做權衡？
有閑錢就人才儲備，沒閑錢就項目優先，公司能夠存活下去是第一位的，其次才是發展。
面試中，基礎方面的考察，數學，數據結構與演算法，寫程序的功底，掌握到什麼程度會認為是合適的人選？
再有，演算法和數學題可能相對容易設計，但軟體抽象的領域則不是三兩句話就說得清的，如何在面試中考察一個人抽象的能力，和設計易於維護易於測試代碼的能力？
有項目經驗，以考察項目經驗優先，從面試人員對其在項目中所做工作的描述就可以對其代碼能力，業務熟悉程度以及人際溝通等各方面了解個七七八八。再深入問一下做項目的時候遇到過什麼問題，怎麼解決的？這時候側重要了解的就是解決問題的能力，會包括數學，數據結構與演算法的深入討論。
沒有項目經驗，場景測試吧。從一個已有項目中的實際問題聊起，看看面試人有何反應，以及能夠提出怎樣的解決方案。
一言概之，從實際項目出發，逐層深入，從架構到模塊到技術難點，以開放式場景代替固定答案的演算法與數學題，重點觀察/考察的是思考的過程，而非結果。不過這種方式對面試官的能力要求很高，不是所有的面試官都能以這種方式考察被面試對象的
有很多日常的dirty work，以及很多業務邏輯性的代碼，事實上並不需要太多數學以及演算法方面的知識也能解決。那麼招人標準抬得很高，讓超水平的人來解決這些問題，是否又有浪費之嫌？
真正高水平的人都是聰明的懶人。像這樣的dirty work或者重複性勞動，本身就可以通過跑腳本或者流程優化的方式大大提高效率。你會發現當你真正僱傭到一個超水平的人去做這種事情的時候，他的效率會比死腦筋做這些dirty work的人高很多倍，然後這些dirty work就被他們打理得不那麼dirty了，再然後他們所採用的工作流程和腳本就可以推廣到整個Team乃至部門使用，再再然後他們就被晉陞了（或者跳槽）然後你又開始招聘新人補他們的坑。。。
我這邊招人的話普遍是如下
1.滿足該崗位的技術能力（不扯細節代碼，從一些技術實現方式上即可快速了解其程度）
2.喜歡編程（從自己做的非公司項目看）
3.可塑造（比如夠年輕，可彌補技術能力問題）
4.交流能力好（說話聽不清或者解釋的東西讓人很難理解，基本沒戲）
5.有一定產品意識（能對產品提出質疑或從技術角度糾正產品的問題，而非像機器一樣只幹活）
謝邀。
我首先會先介紹一下公司以及職位的情況，這是對面試者最基本的尊重，不過一般HR會跟面試者有這方面的溝通，我也就盡量提一下說因為HR講過了，所以我就不問了。
然後，我就問對方尋找工作的主要意圖是什麼：想要學習，賺經驗值？還是懷才不遇，想要尋找發揮空間？還是純粹『想找份工作』？等等。
這部分我也會盡量保持跟面試者輕鬆的『聊天』，比方說刻意講一些梗，看對方能否會心一笑。這裡主要是感受下彼此彼此『氣質』是否相近。
然後，我會儘可能全面的去了解對方的能力，應用知識、基礎理論、演算法、心理素質等等等，我會習慣在各個方面都問到對方回答不了，呈現出極限為止。因為需要問很多，面試節奏會非常快，只要某一方面我覺得了解足夠了，我就會立刻換一個領域繼續問。
這樣的面試法，有被我面得生氣的，也有被我面哭的，也有被我面得願意降薪加入的。
整個面試過程我會控制在45分鐘左右，最後，我一定會留出來5~10分鐘給面試者提問。
這實際上也是一個非常重要的問題，好的候選人，或者說對我們公司感興趣的人，或者說對自己職業發展有想法的人，一定會有很多問題的。
最後，我司在招聘，坐標上海，歡迎投簡歷：ezbuy招聘-前海煦逸信息技術（深圳）有限公司招聘1.有潔癖
各類元素的命名、包名字空間劃分，代碼自解釋
這些素質能很快區分出「高-中低」兩個層次。
2.對「為什麼」感興趣，熱衷並善於動手解決「怎麼干」
3.懂取捨，懂平衡
「趨勢-性能-成本-維護」這些方面懂審時度勢，趨利避害。
1是好員工，搞定多且平凡的瑣事
2是能手，搞定難點
3是牛人，給個方向目標，帶著1、2就能把事了了。
考察1，百行代碼的基礎邏輯試題足夠。
考察2，面試官可無意曝露或偽造自身項目架構爛點，或表達含糊不清。
好奇心強愛刨根問底的應聘者會追問、提疑慮、給建議。
太傲的不屑的放棄。
考察3，暴露一堆爛尾，面試者能總結出失敗點很好，給出整改方案更好，還能敏感準確預計改造點風險和技術/非技術阻力，有靠譜成本估算，收吧
國內IT偏項目，較少偏學術。
多數情況三分靠琢磨、三分靠經驗，三分靠偏執，一分靠天賦，九十分看臉。
學歷，忽略吧。。。
所以挑這類人可能最簡單的方式就是有針對性的給出一堆mess，然後看對方的應變、心態和思維縝密度。
瀉藥。
做過一段時間的面試官，最後總結就是有眼緣，會說話。
有眼緣不解釋。
會說話的表現在幾個方面：
- 用術語回答問題。
- 不拐彎抹角。
- 不羅嗦。
- 說話的態度。
其他的都不是問題。
現在的軟體開發，只要不是一個人自己做，有同事、有百度、有谷歌什麼問題都可以解決，解決不了的是溝通還有你願不願意跟他合作這兩個問題。
不同的公司會有不同的側重，這個我也很難給出一個固定的模板
不過總體來說，公司要找的是一位【有綜合素質的員工】，而不是一個無腦的【碼農】
簡單來說，就是所謂的【硬實力】+【軟實力】
硬實力：你的技術能力
軟實力：交際能力，問題處理能力，團隊合作能力等等
舉個例子，比如NBA裡面，除非你能達到詹姆斯，科比，杜蘭特這樣的水準，這種硬實力達到世界級的水平，整個團隊的戰術都圍繞你進行，你不用太多擔心其他的要素。
否則，軟實力還是很重要的。
通常，美國矽谷的科技巨頭，如谷歌，FACEBOOK等等，會綜合考察面試者以下的能力（當然，技術能力是最重要的，但我也見過演算法大牛因為非技術問題不過關而掛掉面試的情況）
- 你過去的經驗/你以後的潛力
- 你的技術能力（數據結構，演算法設計，系統設計）
- 你是否自律，是否有自我激勵能力，注重結果
- 團隊合作精神，交際能力，是否是一個合格的組員
- 領導力，以後成為領導的潛力
- 和公司的文化匹配（所謂的culture fit）
不同的公司對上面的要素會有不同的側重，但總的來說，硬實力（技術）很重要，但軟實力也非常重要，你需要明白，公司尋找的是【一位團隊的隊員】，而不是【無腦碼農】
如果有其他任何問題可以私信我，祝樓主好運謝邀，上面@庄生 已經回答的很好了，大多數公司基本都是考察態度、經驗、演算法、熱情。我在創業公司和大公司都有過工作經驗，也面試了很多的人，創業公司和大公司在對人才的要求還是有一些區別，這裡再補充幾句吧。
創業型公司創業型公司，特別是早期的創業公司，對學習能力是特別注重的。因為這類公司在開始的時候不很穩定，能給與的薪資也不會很高，招聘大牛有一定的困難，所以很多都傾向招聘畢業生或者工作經驗不多的人才。這類人才最大的缺點是經驗不足，而創業公司往往員工較少，開發任務較重，各種跨度較大的技術問題都需要你來解決，因此學習能力在這個階段是非常重要的，需要逢石開路遇河搭橋的開拓精神。面試時，學習能力是一種比較虛的東西，但要考察還是有辦法的，面試官問的最多的是：
- 你在項目開發過程中有什麼是最印象深刻的？
- 在項目開發中你遇到的最難的事情是什麼，怎麼解決的？
- 面對一個從未涉及過的技術問題，你會怎麼去解決？
這樣的問題，我面試過的很多人中答得好的並不多，大多數人說沒有什麼困難或者沒有印象深刻的，讓人感覺資歷一般或沒有鑽研過技術難題。雖然大多數創業公司不一定會有高難度的問題需要解決，但是這卻是考察學習能力的一種方式。這時候，你需要從你的記憶深處，調出最高度的技術問題，說清楚解決的思路，以及在解決的過程中你發現了哪些新的知識點，為什麼這麼做?
大公司
大公司人才濟濟，工作流程規範，技術領域細分，對人才的要求更多是有技術深度.在同學app上看到一個帖子，有位同事的朋友在創業公司做CTO，憑一己之力開發了兩款app, 客戶端、前端、後台、資料庫均有涉及，這位同事推薦他的朋友來騰訊面試，在第一輪就被刷下去了，因此他非常不解，發帖質疑。其實我的經歷和上面提到的這位CTO經歷類似，都是從創業公司轉大公司。確實在創業公司很多有能力的人都是全棧工程師，這類人才在創業公司的前期階段都是求之而不得的。而大公司的產品動不動就是幾個億的用戶量，每個細節都要求做到最好，穩定、高性能的產品質量對技術深度提出了更高的要求，比如iOS開發，多線程同步、界面切換、文件存儲、CoreAnimation動畫、GPU硬體加速等等，再加上各種奇葩的疑難crash和性能問題，每個點都是一個無底洞，深入下去需要研究的技術問題非常多。如果希望進大公司，平時注意下技術知識的積累，對一些感興趣的點做一些深入研究。
技術是個無止境的東西，能夠對一兩個點有深入研究就已經非常不錯了。在騰訊做技術面試時，如果是畢業不久，我一般會重點考察計算機基礎方面的能力，比如演算法、數據結構和常見的一些軟體術語，對有工作經驗的，往往會針對項目經歷來提問，對提到的知識點都會不斷深入地往下問，如果能有幾個點能達到一定的深度，通過的可能性就非常大了。
@David Chang 謝邀
平時上來有點少，前面幾位前輩已經說得很好了，我也發表一下自己的看法吧。
總體來說，面試和招人是直接相關的～所以這個直接會關係到，你把小伙或者妹子招進來後，能否提升你們團隊的效率以及為公司獲取更多的盈利。
以前我也看過面試官給我自己的評價，或者其它面試官會怎麼評價一個面試者。其實面試需要招的人很大程度上和公司規模、公司文化較耦合。對於個人成長上，大致階段可以分三種（至少目前以我的工齡來說，只能這樣分了，目前 2 年社會經驗）- 剛出校門
- 出校門有一段時間
- 已經能夠獨擋一面，負責一個項目屬於自己職責的內容
- （這塊我還沒涉及，但是肯定會有，就是自己的職責搞定的同時，協助多部門的合作問題）
分開來說一下吧：
- 剛出校門
對於這塊的心情我應該更清楚，因為畢業不久。剛出校門的時候會有兩種情況：
（1）在學校正常學習，還沒有做過實際項目
（2）在學校完成正常學業的情況下，已經有若干實際項目經驗
對於第一類同學（不分學校），應該首先解決的是能夠面試的問題，這裡假設都通過筆試或者內推到達面試階段。
這類同學的面試肯定注重的是基礎和對自己平時喜歡技術的理解，基礎這個是大家都會提的，但是又是很難做的事情，為什麼呢？因為不好面，如果是學霸，那麼面試經取得很多。那麼這個時候對於基礎的考察能夠做一個變形，也就是考活學活用的問題。
對於基礎過關的情況下，還需要考察是否符合一個成為技術人的情況，就是是否有對技術的追求問題，比如一個熱愛技術的人會有很好的自主性，會讓他具有更多的潛在價值。
對於已經有項目經驗的同學，根本上還是應屆生，還是需要考察基礎，這塊必須的。然後肯定會有更多的期望，就是考察項目。現在就可以回到［軟體抽象］問題的考察上了，因為如果沒有業務場景和技術場景的支持，談軟體方面是很虛的東西（我就是軟體工程畢業）。
對於［軟體抽象］的考察上，我是 Java 體系的...所以拿 Java 來說吧，對於這部分來說，Java 其實有很多設計模式，單一職責、享元模式等等。這些說起來抽象，但是對於長期來看，還是很有用的，不論面試什麼職位，需要的是給一個業務場景讓他去分析，就選擇他項目中的場景來說，對於業務的分析能力和業務映射到代碼重構上的能力，至於分析出來的和力度是否合理這個需要面試官來判斷。
2. 出校門有一段時間
這個就屬於社招了，對於社招肯定有不一樣的要求。基礎，是肯定需要具備的，但是肯定會看更多方面。比如我現在就是前端職位，對於數學的考察面試也有，但是更多偏向於場景。比如月影姐姐之前的分享，也沒有說用到很多高數的導數和積分求解等東西，用到的更多是經典數學模型，比如：三角函數、向量的解決方案、圓與橢圓的函數解析等等吧，這些都是高中就可以搞定的，能否用於現在技術就看你是否對這些數學模式有了自己的理解。這部分在面試的時候，就需要給一個場景去讓面試者去選擇一個更優模型去求解，選的場景複雜度可能直接會關聯到需要的數學模型複雜度。這就能夠很好考察到面試者對於用數學思維去解決現實場景的能力，也不需要說是讓你像求解一個高數泰勒公式這種。。。
3. 已經能夠獨擋一面，負責一個項目屬於自己職責的內容
要招這部分的人，除了技術方面就可能會考察一些更多的東西了，我也有一些欠缺的能力，只說一下自己的看法。
（1）對於項目需求本身的理解，這是技術之外的，對於一個做軟體的人來說，項目的需求分析的重要程度是第一的，如果這塊不能考慮好，直接就是一個無用項目或者最後會死掉的項目，所以才會有需求評估、風險評估這些東西；面試的時候就需要考察更好的溝通能力，對業務的理解能力，這塊很好考察的，對於業務深入與否，表達就可以見分曉。
（2）對項目進度的把控，這部分我自己也做的不太好，這個和經驗會直接掛鉤，比如給你一個項目，對項目需求點的劃分=&>功能點的劃分=&>落實每個功能點需要的工時/人。沒經驗肯定是有考慮不周到的地方。那麼在面試的時候，這部分就需要看面試者自己的說法了。。。這個水分多。
（3）砍掉不合理需求，或者目前並不需要的需求，把控最後項目正常上線。
- 首先要與面試官有眼緣，以前我有個朋友能力不錯，去面試技術負責人，就因為和對方互相看不慣，導致最後面試失敗
- 技術與公司的匹配度，比如你精通 C ，去了一家 Java 的公司，基本上成本就上升了
- 認同公司文化，符合公司文化，這個會影響到一個人的心情和長久度
- 是否熱愛自己所面試的職位，這方面會從談吐中得知
- 最後還有就是才開的公司肯定就是向前沖，先能生存，所以就先更注重招進來的人是否能快速讓項目活下來，至於個人成長比例不會太大。大公司有閑錢慢慢等你起來，所以面試就會有這部分的比例，對於要招能幹活的，直接看技術能力和溝通能力。
- 剩下說一下代碼質量和代碼測試的問題，公司開始盈利了，走在穩定的道路上，那麼會關注這塊了，這塊直接 show code，Github 這類就比較好考察撒～這塊面試可以放篩選一面後，因為每個都去看下他代碼太累。
一個公司，需要更多具有不同能力的人才能生存的，所以你說的某一方面擅長的，就看當時公司情況下需要具備此技能的人。比如，解決 bug 很快的，這類也有好處，能快速解決問題，然後丟開發的事情給其他人去做。不會到處需要萬事通的現在，團隊戰鬥都是，當然有萬事通我們也不拒絕，是吧，哈哈！
1. 基礎知識掌握程度，各種基本演算法、語言基礎、操作系統基礎等等要非常紮實；
2. 代碼風格良好，邏輯清晰；
3. 發展潛力大，熱愛軟體開發，對自己使用過的技術能深入掌握原理；
4. 有計劃的閱讀技術書籍，不滿足於現在項目和技術；
5. 參與一些開源項目；
6. 數學英語功底比較好；
7. 性格和人品；
8. 良好的溝通能力；
9. 和項目契合程度高；
大概就是從知識、能力、潛力、溝通能力、人品等角度考察
做事情是不是夠快
一般是如何解決問題的，是如何思考的，思考的正確性和系統性
是否能主動溝通和快速領悟; 而不是一味死抗(第二聲)
獨立思考能力; 批判的能力; 反問和質疑的能力。
只說其它考察之外的一個特別方法：
設身處地
請 對方假設他自己在面試別人，會出一個 什麼樣的面試題，並 附加自認為較佳的答案以及為什麼。。。
範圍可以根據你自己公司、產品、項目的特點而增加約束條件，以免 針對性不強而浪費
根據他的選題和答案，可以了解他對約束條件之下的可選範圍內的 側重點（知識面）、分析方法（業務+邏輯）、判斷選擇（喜好、傾向性）
這要從公司的規模、現狀以及你本人的需求來決定。
如果公司規模大，資金充沛。那把兩個人都招進來也無妨，一個作為技術人材儲備，一個作為解決現有問題。
如果公司剛剛成立，資金有限，同時急需產品盈利，那肯定只能把那位有多年經驗的留下來以解決當下之急。
上述兩種為基本狀況，招人對於面試者而言也有主觀的部分。
假如公司規模小，但成立時間較長。而你作為核心元老，為了公司的長遠發展，同時也為了惜才，也可以把那位有潛力的新人招進來。一方面你可以自已加班加點的工作來彌補新人的工作量。另一方面，既然是有潛力，那麼這位新人對於工作也必定能夠快速上手。而且你不用懷疑新人對於工作的熱情，年青人可是幹勁十足。
推薦閱讀：