程式設計師面試介紹專案經驗

　　　　在面試中，考官通過看你的簡歷或者你的介紹來了解你所做的專案，那麼考官肯定想更詳細的瞭解您的專案，看是不是與你的簡歷寫的專案經驗一致。也就是考核你是否具有真實的專案經驗。一般來說，在你的簡歷至少有一個重點專案，放在簡歷專案經驗欄的第一位。把專案的業務功能描述清楚。在這裡你就是重點談一個專案就可以了。小編教你如何從下面幾個方面來進行陳述

　　

　　1. 用一句話簡述專案

　　2. 詳細的列出專案實現的功能

　　3. 說出專案實現的技術和架構，能說出專案的不尋常之處，比如採用了某項新技術，採用了良好的架框等

　　4. 能讓別人感覺出專案的規模

　　5. 說出你在專案中的責任

　　通過這些來證明你是的確開發過了這個專案，並且這個專案是一個真實的。還有就是你是真正具有專案經驗的。合乎企業的用人需要。

　　特別注意要把專案所實現的功能描述得越詳細越好。當然用詞要簡潔,表達要流利。其次要儘可能採用專業術語，顯得你的專業。不要犯低階錯誤。

　　請記住，你要描述的是整個專案而不僅僅是你做的那一個模組。有些專案你只參與了其中一個模組，但是你要把整個專案描述出來，不要僅僅描述你參與的那一個模組。

　　說出你專案採用的技術及架構，還要能說明你在專案中的責任。

　　回答例項：

　　面試官：令狐沖,能介紹一下你做的大宋俠士綜合管理平臺吧!

　　令狐沖：好的，大宋俠士綜合管理平臺是為大宋武林聯盟開發的，實現武林聯盟管理的自動化。大宋俠士綜合管理平臺能夠自動收集大宋各路俠士,英雄好漢,隱居高人資訊並對他們的個人資訊及所作所為進行跟蹤管理,實現俠士資訊維護,查詢.俠義事件維護,俠士等級管理,俠士獎懲管理,俠義活動釋出，抗災募捐管理等。

　　系統基於B/S三層架構，採用Spring + Hibernate + Spring MVC框架.使用Oracle 資料庫.

　　本專案只投入15個人，開發週期為6個月。本人在專案中進行了前期的需求分析，系統架構實現，資料庫建模，及部分編碼工作。

　　問題之三、談談你們是怎麼對這個專案進行開發的?***談談你們是怎麼進行專案開發的?***

　　分析：這個問題是考核你是否熟悉軟體開發的流程，同時也是考核你的專案經驗，你的專業素養，從這裡可以判斷出你參與過多少專案，可以判斷你對軟體工程的理解和熟悉程度。這個問題是十分關鍵的，你需要準備的知識點有：軟體專案的生命週期、軟體專案的開發模型、面向物件的分析和設計、軟體質量保證等。

　　軟體專案的生命週期:

　　專案計劃

　　需求分析

　　設計***概要設計和詳細設計***

　　編碼

　　測試

　　釋出

　　維護

　　專案計劃階段：走訪客戶，進行交流溝通，獲得客戶原始需求。

　　對客戶的需求和市場等進行調研，分析，編寫可行性分析報告。

　　通過不斷的與客戶溝通，找客戶不同環節的使用者進行交流來獲取需求。召開評審會議，報告可行性分析，報告使用者原始需求，報告專案遠景規化。

　　需求分析階段：

　　在客戶原始需求的基礎上不斷與客戶溝通，充分的熟悉和深入客戶業務，獲得充分的業務需求，完善使用者需求和功能性需求，瞭解客戶的相關約束而獲得非功能性需求。最終編寫《需求規格說明書》;召開需求評審會議，客戶確定需求，並簽定合同;編寫專案計劃說明書;編寫測試計劃;召開專案啟動會議，專案正式啟動。

　　概要設計階段：根據《需求分析說明書》，進行用例分析,獲得充分而有效的用例。編寫介面原型，編寫編碼規範和介面風格規範,資料庫設計規範。用uml工具畫用例圖，編寫有效的用例規約文件。劃分專案功能模組.評審用例及用例規約文件。

　　詳細設計階段：根據完整的用例及需求進行分析，獲得資料庫所需的相關資訊,畫資料庫E-R圖，編寫資料設計說明書.進行資料庫建模。進行詳細的分析，用uml工具畫類圖，確定每個功能模組的子功能，抽取專案的公共部分成為一個公共模組。確定專案的架構基礎。確定需要用到的類及類成員和方法。確定一些輔助類及方法。對每一個用例都用uml工具畫出順序圖。編寫詳細設計說明書，評審詳細設計說明書, 進行基礎框架搭建。列出任務清單，進行任務分配。

　　編碼階段：以小組的形式進行程式碼編寫，編寫單元測試用例，每完成一個類都要進行單元測試。每完成一個功能點和模組都要進行整合測試。確保每一個功能點和模組完成後都是一個可以看得見、摸得著的產品。而不是等到最後才進行統一的除錯和搭配。每天都要對程式碼進行檢查和優化，也就是所謂的重構。

　　測試階段：根據測試計劃對專案進行系統測試，以及使用者的驗收測試

　　產品釋出：交付完整的產品和設計文件。把產品佈署到客戶的計算機上,確保產品的正常執行。客戶簽收。

　　維護階段：為客戶提供技術保障，對產品進行相應的維護和升級工作

　　軟體常見開發模型

　　瀑布模型：最經典的過程模型，適用於需求明確，規模較小的專案

　　噴泉模型：迭代，無間隙特點，適用於面向物件的軟體開發過程

　　螺旋模型：

　　MSF模型：微軟解決方案過程模型

　　什麼是極限***XP***程式設計：極限程式設計是對敏捷軟體開發方法的一種實現。它強調測試先行，也就是在編寫程式碼的時候先編寫測試用例;迴圈迭代，每一次迭代都是一個可用的產品;重構，不斷的對程式碼進行優化;結對程式設計，兩個人為一對共同進行程式碼編寫;它強調團隊之間的知識傳播，讓團隊的每個人都能熟悉軟體開發的各種技術。如：支援熟悉資料庫的人去做介面，做介面的人去做資料庫等，通過不定期的角色轉換來增強團隊的能力。要求客戶參與到軟體開發中來,開發出最適合客戶需求的產品。

　　單元測試一般是在編碼的時候同步進行的，一般是以類為單位進行測試，當一個類完成了編碼，並編譯正確後才進行的測試，測試這個類是否已經能夠實現指定的功能。一個類能夠正常的編譯成功並不意味著這個類就已經完成了，還要通過測試，設定斷言來確定他是否已經達到了預期的效果，實現了特定的功能。除錯，編譯通過只能證明程式碼的語法沒有錯誤。

　　單元測試由程式設計師自己來進行，也可以在專案小組內互動進行。單元測試是採用白盒測試

　　整合測試一般指實現了一個功能點或一個模組後,為了測試這個模組是否已經實現了需求要求的功能。整合測試可能需要對多個類進行組裝，也可能需要與以前已經測試通過的模組進行組裝，是對產品元件的系統整合和執行。整合測試可以根據模組的大小分不同的級別，在現行的軟體開發中，每完成一個功能模組都必須要進行一次整合測試，使得你完成的模組是一個可以執行的產品。整合測試一般可以由專案小組的負責人***或指定一個小組成員***來完成。整合測試採用白盒式測試和黑盒測試

　　系統測試一般指項完程式碼已經全部完成，交給測試小組來進行測試。進行系統測試的人員獨立於開發小組，系統測試人員把完成的產品佈署在相應的計算機環境中，按照測試計劃進行測試，驗證系統是否滿足了指定的需求。系統測試除了測試產品應滿足基本的功能需求外，還要對產品的效能，使用者介面，安全性，壓力，可靠性，安裝和反安裝等幾個方面進行測試

　　系統測試採用黑盒測試

　　驗收測試一般指產品交付給客戶，負責把產品佈署在指定的計算機環境中。由使用者根據需求文件，進行的總體測試。驗收測試的內容和系統測試一樣，只是執行者不同。都是除了測試系統完成基本功能外還要對效能，安全性，可靠性等進行測試。驗收測試也是採用黑盒測試

　　為什麼需要測試?測試是對軟體質量的保證，只能通過嚴格測試的軟體才是合格的軟體，測試並不是說讓軟體能夠編譯通過，測試是讓軟體產品最大程度的滿足客戶的需求度。

　　回答例項：

　　考官：令狐沖，能談談你們是怎麼樣對這個專案開發的嗎?

　　令狐沖：首先，我們這個專案已經有了一個基本的使用者原始需求。但這是不夠的，我們都知道需求分析是十分重要的，所以我們在使用者原始需求文件的基礎上，再次進行了分析，通過不斷的與客戶溝通，充分的瞭解和熟悉使用者的業務，完善了業務需求和功能需求。還對使用者業務需求和功能需求分析完善為實現軟體的必須的非功能性需求。得出專案需求規格說明書，經過評審會議確認通過。

　　根據需求規格說明書進行用例分析，通過分析和討論找出充分的有效用例，並用Rose畫用例圖。對每一個用例進行詳細的分析，完成每個用例的用例規約文件，並編寫介面原型。劃分專案模組。最後對用例及用例規約文件進行評審驗證。編寫”程式碼編寫規範”及介面風格規範，資料庫設計規範,編寫概要設計說明書。

　　根據需求規格說明書和分析各個用例規約文件，獲得資料庫的基本資訊原型。也可以說是資料庫表的草稿，根據資料庫表草搞進行分析，進行資料庫設計和優化。編寫資料庫設計說明書。採用PowerDesigner進行資料庫建模，並生成SQL指令碼。確定專案框架，設計公共模組和輔助類。根據對資料庫模型和用例規約文件的分析，列出物件清單和理清物件關係。用Rose來畫類圖。對每一個用例都用rose畫出時序圖。編寫詳細設計說明書。列出任務清單，分組進行程式碼編寫。

　　在程式碼編寫階段，先統一完成所有的實體類。對於非實體類則先完成類的框架，也就是隻寫方法和註釋文字。具體方法的實現暫時為空。然後再進行程式碼填寫。每完成一個類的程式碼編譯通過後都要進行重構和單元測試。每完成一個功能和模組都由會由小組長進行整合測試。使得完成的模組是一個真正可以執行的，可見的功能實現。

　　在各個小組都完成自己的模組後就進行模組整合，進行一次大規模的整合測試。然後把產品產給產品測試小組進行系統測試。

　　問題之四、你們是怎麼保證軟體開發的質量的?

　　分析：這個問題其實上面的講解已經給了答案了。軟體質量是軟體實現對需求的滿足度。開發的軟體越滿足客戶的需求，說明軟體的質量越高。反之就是質量越低。儘管你開發的軟體使用了新的技術，良好的設計，豐富的功能;但是這些功能都不是客戶需要的，客戶需要的功能沒有實現或者是很多沒有實現。這樣的軟體也是失敗的軟體。為了保證軟體質量，也就是讓開發的軟體最大程度滿足客戶的需求，只有兩個方法。一個是獲得充分完整的需求，二是能過測試，以需求為中心編寫測試計劃。來保證軟體合乎需求。

　　回答例項：

　　考官：你們是怎麼來保證軟體的質量的呢?

　　令狐沖：要保證軟體的質量首先就要獲得完整的需求，在需求分析階段做了大量的工作與客戶各個環節的代表性使用者進行溝通，充分了解和熟悉客戶的業務。並且從需求到設計階段都保持與使用者的溝通和交流。讓使用者的業務專家一直參與我們的需求，分析和設計工作。

　　其次我們會在需求分析後就編寫測試計劃，在開發的每個階段都進行相應的測試來保證程式碼是乎合相應需求的。在程式碼編寫過程中，每完成一個類都由程式進行單元測試，每完成一個功能點或模組都要進行整合測試，每一次整合測試都對上一次的已經測試通過的產品進行迭代, 也就是以前測試成功的都會加入到本次測試中來。使得每個完成的功能和模組完成後都是一個可以執行的，可以看得到的產品;同時也歡迎使用者來見證我們的整合測試結果。程式碼編寫完成後進行最後一次整合測試，然後交由獨立的測試小組對專案進行系統測試。

　　問題之五、你為什麼離職的?***你為什麼離開以前公司的?***

　　分析：這個問題幾乎在任何場合的面試都會有，有時是在技術面試的時候問，有時是在人事面試的時候問，有時會在技術面試和人事面試的時候都問。其實也比較好回答，回答的抽象一點比好。切記不要說以前公司的壞話，如果你這樣做。人家會想，你以後離職後同樣也會說這家公司的壞話.一般都是說為了某求更好的發展空間。讓人感覺你是經過深思熟慮後才選擇他們公司的。

　　回答例項：

　　考官：你為什麼離開以前公司的?

　　令狐沖：以前公司對我很好，我在以前公司幹得也很愉快。我因為合同到期，為了獲得更好的發展空間及謀求對自己能持續發展的環境。並向公司辦理了離職手續，完成了工作交結。***後面這句也可以不談***

　　問題之六、談談你的職業規化

　　分析：企業都希望他所招聘的人是潛力股，看你是不是一個追求上勁的人,還有想看看你能夠在企業長期幹還是僅把其當著一個跳板。總的說來，回答這個問題要讓人覺得你是一個可培養，有潛力人。記住要看是什麼樣的人來面試你。如果是專案經理來面試你，你就不要說你以後的職業規化是專案經理。你就可以說你的職業規化是成為架構師，或者是技術專家等。否則他可能會認為你是一個對其有威脅的人。就算他內心知道這不算什麼，可能心理總會有一點點不爽。如果是老總面試或人事問你這樣的問題，你則可以說專案經理也無妨，不過要給人有一種覺穩的感覺。

　　回答例項：

　　考官：你的職業規化是怎麼樣的呢?***考官是專案經理***

　　令狐沖：我思維能力比較強，擅於邏輯分析。在之前的工作中積累了一定的架構經驗，以後就想成為一名架構師和技術專家

　　程式設計師面試什麼最重要

　　目標

　　相信和不少朋友一樣，有了幾年工作經驗成為Senior後就開始了面試別人的經歷。我在最初這個階段只是按照自己的想象把”找到基礎好的程式設計師“，”找到演算法能力優秀的程式設計師“，”找到有Android開發經驗的程式設計師“等作為面試的目標。但是，實際的經歷告訴我，尤其是按“基礎好”，“演算法好”這些目標招到的人最終效果並不好。比如，有的面試者基礎知識和演算法掌握情況不錯，程序、執行緒、記憶體等概念清晰，基本的Hash，二叉樹，快速排序等資料結構和演算法也比較熟悉，但是進公司後在實際工作中表現得很糟糕。後來，我才發現原來是我的面試目標出了問題，我原先的面試方法更像是大學的演算法或作業系統期末考試，按照這種方法讓許多並不合適的人通過了面試，同時也可能錯過了許多合適的人。

　　後來，我的反思是，從公司的角度講，面試的根本目的是找到“能夠幹好工作”的人，而“高學歷”，“演算法好”，“基礎好”，“有經驗”這些都是表象而不是根本，它們並不能直接和“工作好”劃等號。

　　方法

　　目標明確了，但接下來的問題是假設面試者是一個黑盒系統，“工作好”不是直接可觀測變數，你所能直接觀測的變數是基礎、演算法、經驗、學歷、性格、談吐、年齡等等。所以，實際上，你只能從“基礎好”，“演算法好”等可以直接觀測的量去推測“工作好”的概率，這就是一個在“X好“條件下”工作好“的條件概率問題：P***工作好 | X好***。

　　根據這個模型，面試所應該考察哪些方面就很明顯了，那就是選擇那種最具有區分性的方面來考察。比如，考察面試者的體型特徵沒有太大意義，因為P***工作好|高***，P***工作好|矮***，P***工作好|胖***，P***工作好|瘦***的概率都差不多;所以，體型特徵不具有區分性，這不是面試所應該關注的內容。

　　面試官應當結合職位的要求明確哪些因素具有比較好的區分性。比如，如果要招一名技術門檻比較高的3D遊戲引擎開發工程師，面試者A具有3D遊戲引擎開發的經驗，但是在基礎知識和演算法面試方面表現一般;面試者B相反，基礎知識和演算法面試表現很好，但沒有遊戲開發經驗，而你只能選擇其一。你選誰呢?其實，這就是兩個條件概率問題P***工作好|經驗好，基礎一般，演算法一般***和P***工作好|沒經驗，基礎好，演算法好***。這個問題就留給面試官來判斷了，就我個人而言，對於技術門檻較高需要技術積累的職位，經驗更加說明問題，因此，我更傾向於面試者A。

　　下面，我再結合自己的經驗談談對面試中常見方面的看法。

　　演算法

　　演算法是Google和MS等大公司面試所重點考察的內容。我個人很喜歡演算法，曾經參加ACM/ICPC拿過北京賽區的13名。但是，就個人經驗來看，我所接觸過的絕大多數開發職位而言，演算法都不適合作為考察面試者優劣的主要因素。對於普通的非演算法性開發職位，考察面試者的演算法就相當於考察他打乒乓球好不好一樣，與目標“工作好”的相關性太低。就我個人的經驗來看，差不多P***工作好|演算法好***=50%，也就是演算法面試沒有太大的區分性。

　　甚至，還有一種很不好的情況特別多地出現在演算法好的面試者身上，我稱之為“只磨刀，不砍柴”。什麼意思呢?有類人只對什麼A*演算法，非同步程式設計，JVM類載入機制這種純技術問題感興趣，對實現使用者需求毫無興趣。這類人看起來有一定的技術能力，但是對公司來講貢獻十分有限，甚至不如技術一般但認真負責的人。所以，一旦遇到面試者演算法好，我就特別留意考察會不會是這種“只磨刀，不砍柴”的人。

　　另外，雖然我個人不瞭解Google和MS，但我對於其特別重視考察演算法能力的面試策略是持懷疑態度的。即使在這樣的世界級大公司，演算法雖然重要，但可以想象在專案實施過程所遇到的各種各樣問題中，演算法問題絕大多數時候不會是主要瓶頸，沒有到那種需要每個人都是演算法高手的情況。實際上，絕大多數專案真正難點並不是一兩個演算法瓶頸，甚至也不是單點的技術瓶頸，而是系統性的組織、協調、設計、開發問題，有大量的看起來不是那麼有技術含量的髒活累活，也有許多問題是由於資訊不足，並不是技術能力強就能克服這些困難。一個團隊最好優勢互補，有人演算法強，有人業務分析能力強，有人擅長後端服務，有人擅長前端介面，有人聰明，有人踏實，這是最好的。如果按照“演算法好”的單一標準選材，必定會把許多優秀的人才拒之門外。

　　基礎

　　基礎面試是指考察諸如指標使用、程序執行緒概念等基礎知識的面試，十分類似於大學期末考試題。我曾經以為基礎面試十分重要，但是現在不這麼。在工作中基礎的確是重要的，但是在面試過程中，它必須具有區分性才有意義，也就是說P***工作好|基礎好***的概率要高，那麼考察指標使用，程序執行緒區別這樣的基礎題目才有它的意義。我的實際經驗是，基礎面試並不具有很好的區分性，和演算法一樣， 差不多P***工作好|基礎好*** = 50%。同時，基礎面試是最容易準備的，中國人有長期的應試教育經驗，要準備幾個把玩指標題目太容易了。

　　我曾經遇到過這樣的面試者，他的C語言基礎和編譯、連結等原理掌握得非常好，給我留下了深刻的印象，我給的面試結論是：知識面不寬，只會C語言，但基礎很紮實，建議錄用。後來的事情證明了那個結論的前半部分是對的，但是”建議錄用“錯了。他在實際工作中表現得一塌糊塗，不理解需求，不理解整體架構;同時，上班時間不是花在專案上，而是花在閱讀諸如《程式設計師的自我修養》之類的書籍上。最後，這位同事由於長期“不出活”離開了公司。

　　基礎不是不重要，而是“基礎好”不足以說明面試者能幹好工作，因為基礎是屬於區域性性知識，而實際工作需要綜合性能力，二者有天壤之別。C語言、作業系統能考高分，但是不會寫程式的人在大學我們還見得少嗎? 軟體開發就像蓋房子，綜合能力是設計和搭骨架，基礎知識是碼磚。張小龍原先Foxmail是Delphi開發的，他它不懂C#，你如果要招聘一個開發.NET Email客戶端的人，你考察他對CLR掌握得好不好有意義嗎? 讓張小龍來開發一個C#版的Foxmail真的會有困難嗎? 你招一個精通C#但沒有Email客戶端開發經驗的人來真的比張小龍靠譜嗎?

　　我說基礎知識不重要，和古人說的“不積窪步無以至千里”是不是矛盾呢?不矛盾!“窪步”與“千里”是一種可累加關係，但再多的“基礎知識”都累加不成“綜合能力”。學習軟體開發要像持續整合一樣，一開始就是一個完整的系統，雖然規模不大，問題很多，但它麻雀雖小五臟俱全，從小系統到大系統，從簡單系統到複雜系統逐步演化。

　　所以，基礎好本身不足以說明太多的問題，必須進一步考察綜合能力。對於基礎面試表現不好的面試者，如果時間允許也要進一步考察，有的面試者其實是有能力的，只是沒有進行充分的準備。最理想的狀態當然是基礎和綜合能力俱佳，若不能兼顧，應當綜合能力優先。

　　經驗

　　這裡所說的經驗不是通過工作了多少年來衡量的，而主要是指面試者的經歷，比如，是否完整地實現過一個軟體，或作為主要開發者完成過一個專案。經驗的重要性在於它能說明一個人的綜合能力。從專案的性質、規模和難度，面試官就可以大致判斷出面試者的綜合能力。如果一個面試者一直在大公司負責一個小模組的開發維護，那麼基本可以判斷他不具備獨立或作為主要開發者承擔一個專案的能力，只適合在另一家大公司做類似的事情。對於門檻較高需要長期技術積累的職位，相關經驗更顯得尤為重要，比如，Linux核心開發，JVM開發，遊戲引擎開發，資料庫實現，高階UX等。對於這類職位，沒有經驗的面試者即使綜合素質不錯也是需要長時間的學習和積累才能勝任。所以，基本上如果確定了你的職位屬於此類，那麼相關經驗毫無疑問應該成為首選因素，換句話說，P***工作好 | 相關經驗好***的概率是非常高的。

　　通過專案經驗判斷面試者的優劣比通過基礎和演算法測試更加靠譜，所以，面試過程中面試官應該花比較多的時間聽面試者介紹專案經驗，並進行深入地探討交流，瞭解面試者的知識面、思維能力、表達能力等。同時，可以結合專案提一些基礎知識和演算法的問題，比如，如果面試者做過C++相關的專案，那就可以問他如何進行記憶體管理?是否熟悉智慧指標?如果面試者的回答不能令人滿意，那麼就基本上可以判斷他的專案做得不是很好。

　　要注意的是，經驗也是一個多維度的事物。比如，C++股票交易中介軟體系統，這就涉及***C++，中介軟體，股票*** 3個維度。假如面試者A做過C++股票交易客戶端，面試者B做過C的股票交易中介軟體。從語言角度看，A最匹配，從專案性質看，B最匹配，你如何選擇?這就是在多個維度中，哪個維度更重要的問題，就這個例子而言，我個人更傾向於B，因為我認為中介軟體開發經驗是主要矛盾，而從C切換到C++並不是問題。所以，面試官需要判斷哪一種經驗是主要的，而哪一種經驗是次要的。比如，我們招聘Android應用開發，這個職位的Android技術門檻並不高，它的真正難點在於做出好的使用者體驗***UX***。所以，如果一個面試者沒有Android的經驗我們是可以接受的，但是我希望他在UX方面有經驗，至少做過其他平臺的移動應用開發。

　　性格

　　現在，我來談我認為最重要的因素：性格。這可能是許多初為面試官的朋友所難以想象的，怎麼會是性格最重要呢?說實話，當我意識到這一點時，我自己也很驚訝!說白了，還是 P***工作好|性格好***的概率最高啊。我的實際經驗是，如果一個人的性格好，他能把工作做好的可能性是最高的，性格好遠比基礎好、演算法好要靠譜。

　　一個人如果技術上有缺陷，經驗上有不足，但性格好，在團隊中是很容易由其他人來補位的，他自己也很容易逐漸補起來;相反，如果一個人的性格不好，所有的技術優勢經驗優勢都發揮不出來，甚至還會起到負作用，而且性格缺點很難改變。我一直談到實際工作所需要的是綜合性的能力，這種綜合能力的發揮中性格是至關重要的。專案中不止會遇到技術問題，要涉及溝通、協調，不同的人不同的部門既有合作又有磨擦，如何處理這些事情都需要一個良好的性格。可以說，在開發團隊裡讓你與眾不同的不是你從哪個學校畢業，也不是你過去的經驗，而是你的性格。

　　當然，性格是一個複雜的東西，它包含了很多的方面，並非所有方面都是程式設計師面試所需要關注的。我的經驗是可以重點考察這些方面：

　　1*** 態度積極還是消極。有的面試者在談吐中就會自然給你一種積極上進的感覺，或者你可以在他的經歷中發現他積極的因素，這些都不是太難看出來的。相反，有的面試者你能明顯感覺到他的消極情緒。積極性在工作中是十分重要的，積極的人能給團隊帶來朝氣，也更易於合作。基本上，如果確定面試者屬於態度積極的，他通過我這一關的可能性就會大大增加;相反，如果確定屬於態度消極的，即使技術能力不錯我也會十分謹慎。

　　2*** IQ。我的經驗是，總體來看，聰明的人在工作中的表現更為優秀。在面試中要考察一個人是否聰明並不一定要像Google和MS那樣找些專門測試IQ的智力題，其實，你只需要看他討論問題是不是很有邏輯性，思考和說話是不是反應敏捷就可以做出大致的判斷。另外，眼睛是人心靈的窗戶，一個人聰明與否，眼睛是會說話的。不過，聰明也不完全是優點，比如，當公司或專案遇到困難時，往往是聰明人先跑掉了，堅守的往往是IQ一般的人。

　　3*** 語言表達能力。語言表達能力也是程式設計師十分重要的一項素質，它關係到專案中的溝通是否順暢。面試官可以看看面試者能否用簡明的語言介紹清楚曾經做過的專案，能否抓住要點，能否考慮到聽者的相關背景。一般來講，語言表達能力強的人綜合能力都不會太差。

　　4*** 是否具有使用者意識。有人說程式設計師是做研發的，哪來什麼使用者?只有銷售、市場人員才會和使用者打交道。其實，這是完完全全的錯誤認識。你寫一個模組，甚至一個API，只要有別人用，他就是你的使用者。有的程式設計師設計一個模組或是一個軟體總是習慣於從使用者的角度來考慮，儘量地方便使用者，這就是一種良好的使用者意識。具有良好的使用者意識的人更能考慮別人的感受和整體的需要，而不是單純地從自己和區域性來思考問題。當面試者談及過去的專案經驗時，面試官可以常常站在使用者的角度對其進行提問，從這個過程中觀察其是否具有良好的使用者意識。

　　5*** 如何應對質疑和壓力。面試官應該對面試者的回答以及以往專案進行合理的質疑，看看他如何應對。曾經有一位面試者談到做遊戲登入伺服器的經歷，我就問：“如果登入伺服器掛了，怎麼辦呢”?他說原先雖然沒有考慮這個問題，但是可以怎麼怎麼改進。其實，大家都理解專案中有各種不完美，這裡面原因很多，只要面對質疑和壓力能從容應對努力往好的方向思考解決就可以了，不需要掩飾缺陷，更不應該有情緒。我遇到過有的面試者，一旦你對其專案提出質疑，他馬上產生反抗情緒，或不高興，或不承認有問題，這很容易一下子看出來他在工作中容不得質疑和批評，這種人要想合作就很困難。

　　6*** 個性特點。許多面試者喜歡在簡歷上寫“精通C++/Linux“，這些字眼看得人麻木，如果有人寫”喜歡C++/Linux“，我就會有一種眼前一亮的感覺。“精通”是沒有感情色彩的敘述，而“喜歡”包含了面試者的個性，我更願意看到面試者的個性。我相信對某樣東西真正的熱情遠比你當前對它的掌握程度更為重要。其實，N年的經歷告訴我們，同一個班的同學，同一個專案組的同事，雖然每天所學的知識，所接觸的工作都是相同的，但其實每個人的成績和表現差異是十分明顯的。那麼，到底本質的差異是什麼呢?其實，就是每個人的個性。是個性使得有的人業餘時間去打球，有的人業餘時間去看書，有的人喜歡Linux，有的人喜歡Mac。一個人在團隊中扮演的角色也和他的個性有很大的關係。面試官應該引導面試者展現自己的個性，並判斷其是否有益於團隊。

　　總結

　　最後總結起來，我的經驗是：

　　1*** 面試官的目標是找到”工作好“的人，一定要圍繞這個目標來進行面試，如果把面試當成了演算法或作業系統期末考試這就走入了誤區;

　　2*** 面試過程是通過學歷、性格、基礎、經驗、演算法等可以測試的因素去綜合判斷面試者“工作好”的概率;

　　3*** 在各種因素中，性格 > 經驗 > 基礎 > 演算法。性格是最重要的，如果性格不好，所有技術能力都會大打折扣，而且技術缺陷容易彌補，性格缺陷很難改變;經驗體現了一個人的綜合能力，你可以從面試者過去的經歷中判斷他能從事哪種工作，不能從事哪種工作;基礎和演算法則主要起到輔助參考的作用，基礎好的程式設計師一般適應性比較強，學新技術更快，但是切忌單純從基礎來判斷一個人的能力。