程序員面試介紹項目經(jīng)驗
程序員面試介紹項目經(jīng)驗
在面試中,考官通過看你的簡歷或者你的介紹來了解你所做的項目,那么考官肯定想更詳細的了解您的項目,看是不是與你的簡歷寫的項目經(jīng)驗一致。也就是考核你是否具有真實的項目經(jīng)驗。一般來說,在你的簡歷至少有一個重點項目,放在簡歷項目經(jīng)驗欄的第一位。把項目的業(yè)務(wù)功能描述清楚。在這里你就是重點談一個項目就可以了。學(xué)習(xí)啦小編教你如何從下面幾個方面來進行陳述
程序員面試介紹項目經(jīng)驗
1. 用一句話簡述項目
2. 詳細的列出項目實現(xiàn)的功能
3. 說出項目實現(xiàn)的技術(shù)和架構(gòu),能說出項目的不尋常之處,比如采用了某項新技術(shù),采用了良好的架框等
4. 能讓別人感覺出項目的規(guī)模
5. 說出你在項目中的責(zé)任
通過這些來證明你是的確開發(fā)過了這個項目,并且這個項目是一個真實的。還有就是你是真正具有項目經(jīng)驗的。合乎企業(yè)的用人需要。
特別注意要把項目所實現(xiàn)的功能描述得越詳細越好。當(dāng)然用詞要簡潔,表達要流利。其次要盡可能采用專業(yè)術(shù)語,顯得你的專業(yè)。不要犯低級錯誤。
請記住,你要描述的是整個項目而不僅僅是你做的那一個模塊。有些項目你只參與了其中一個模塊,但是你要把整個項目描述出來,不要僅僅描述你參與的那一個模塊。
說出你項目采用的技術(shù)及架構(gòu),還要能說明你在項目中的責(zé)任。
回答實例:
面試官:令狐沖,能介紹一下你做的大宋俠士綜合管理平臺吧!
令狐沖:好的,大宋俠士綜合管理平臺是為大宋武林聯(lián)盟開發(fā)的,實現(xiàn)武林聯(lián)盟管理的自動化。大宋俠士綜合管理平臺能夠自動收集大宋各路俠士,英雄好漢,隱居高人信息并對他們的個人信息及所作所為進行跟蹤管理,實現(xiàn)俠士信息維護,查詢.俠義事件維護,俠士等級管理,俠士獎懲管理,俠義活動發(fā)布,抗災(zāi)募捐管理等。
系統(tǒng)基于B/S三層架構(gòu),采用Spring + Hibernate + Spring MVC框架.使用Oracle 數(shù)據(jù)庫.
本項目只投入15個人,開發(fā)周期為6個月。本人在項目中進行了前期的需求分析,系統(tǒng)架構(gòu)實現(xiàn),數(shù)據(jù)庫建模,及部分編碼工作。
問題之三、談?wù)勀銈兪窃趺磳@個項目進行開發(fā)的?(談?wù)勀銈兪窃趺催M行項目開發(fā)的?)
分析:這個問題是考核你是否熟悉軟件開發(fā)的流程,同時也是考核你的項目經(jīng)驗,你的專業(yè)素養(yǎng),從這里可以判斷出你參與過多少項目,可以判斷你對軟件工程的理解和熟悉程度。這個問題是十分關(guān)鍵的,你需要準備的知識點有:軟件項目的生命周期、軟件項目的開發(fā)模型、面向?qū)ο蟮姆治龊驮O(shè)計、軟件質(zhì)量保證等。
軟件項目的生命周期:
項目計劃
需求分析
設(shè)計(概要設(shè)計和詳細設(shè)計)
編碼
測試
發(fā)布
維護
項目計劃階段:走訪客戶,進行交流溝通,獲得客戶原始需求。
對客戶的需求和市場等進行調(diào)研,分析,編寫可行性分析報告。
通過不斷的與客戶溝通,找客戶不同環(huán)節(jié)的用戶進行交流來獲取需求。召開評審會議,報告可行性分析,報告用戶原始需求,報告項目遠景規(guī)化。
需求分析階段:
在客戶原始需求的基礎(chǔ)上不斷與客戶溝通,充分的熟悉和深入客戶業(yè)務(wù),獲得充分的業(yè)務(wù)需求,完善用戶需求和功能性需求,了解客戶的相關(guān)約束而獲得非功能性需求。最終編寫《需求規(guī)格說明書》;召開需求評審會議,客戶確定需求,并簽定合同;編寫項目計劃說明書;編寫測試計劃;召開項目啟動會議,項目正式啟動。
概要設(shè)計階段:根據(jù)《需求分析說明書》,進行用例分析,獲得充分而有效的用例。編寫界面原型,編寫編碼規(guī)范和界面風(fēng)格規(guī)范,數(shù)據(jù)庫設(shè)計規(guī)范。用uml工具畫用例圖,編寫有效的用例規(guī)約文檔。劃分項目功能模塊.評審用例及用例規(guī)約文檔。
詳細設(shè)計階段:根據(jù)完整的用例及需求進行分析,獲得數(shù)據(jù)庫所需的相關(guān)信息,畫數(shù)據(jù)庫E-R圖,編寫數(shù)據(jù)設(shè)計說明書.進行數(shù)據(jù)庫建模。進行詳細的分析,用uml工具畫類圖,確定每個功能模塊的子功能,抽取項目的公共部分成為一個公共模塊。確定項目的架構(gòu)基礎(chǔ)。確定需要用到的類及類成員和方法。確定一些輔助類及方法。對每一個用例都用uml工具畫出順序圖。編寫詳細設(shè)計說明書,評審詳細設(shè)計說明書, 進行基礎(chǔ)框架搭建。列出任務(wù)清單,進行任務(wù)分配。
編碼階段:以小組的形式進行代碼編寫,編寫單元測試用例,每完成一個類都要進行單元測試。每完成一個功能點和模塊都要進行集成測試。確保每一個功能點和模塊完成后都是一個可以看得見、摸得著的產(chǎn)品。而不是等到最后才進行統(tǒng)一的調(diào)試和搭配。每天都要對代碼進行檢查和優(yōu)化,也就是所謂的重構(gòu)。
測試階段:根據(jù)測試計劃對項目進行系統(tǒng)測試,以及用戶的驗收測試
產(chǎn)品發(fā)布:交付完整的產(chǎn)品和設(shè)計文檔。把產(chǎn)品布署到客戶的計算機上,確保產(chǎn)品的正常運行??蛻艉炇?。
維護階段:為客戶提供技術(shù)保障,對產(chǎn)品進行相應(yīng)的維護和升級工作
軟件常見開發(fā)模型
瀑布模型:最經(jīng)典的過程模型,適用于需求明確,規(guī)模較小的項目
噴泉模型:迭代,無間隙特點,適用于面向?qū)ο蟮能浖_發(fā)過程
螺旋模型:
MSF模型:微軟解決方案過程模型
什么是極限(XP)編程:極限編程是對敏捷軟件開發(fā)方法的一種實現(xiàn)。它強調(diào)測試先行,也就是在編寫代碼的時候先編寫測試用例;循環(huán)迭代,每一次迭代都是一個可用的產(chǎn)品;重構(gòu),不斷的對代碼進行優(yōu)化;結(jié)對編程,兩個人為一對共同進行代碼編寫;它強調(diào)團隊之間的知識傳播,讓團隊的每個人都能熟悉軟件開發(fā)的各種技術(shù)。如:支持熟悉數(shù)據(jù)庫的人去做界面,做界面的人去做數(shù)據(jù)庫等,通過不定期的角色轉(zhuǎn)換來增強團隊的能力。要求客戶參與到軟件開發(fā)中來,開發(fā)出最適合客戶需求的產(chǎn)品。
單元測試一般是在編碼的時候同步進行的,一般是以類為單位進行測試,當(dāng)一個類完成了編碼,并編譯正確后才進行的測試,測試這個類是否已經(jīng)能夠?qū)崿F(xiàn)指定的功能。一個類能夠正常的編譯成功并不意味著這個類就已經(jīng)完成了,還要通過測試,設(shè)置斷言來確定他是否已經(jīng)達到了預(yù)期的效果,實現(xiàn)了特定的功能。調(diào)試,編譯通過只能證明代碼的語法沒有錯誤。
單元測試由程序員自己來進行,也可以在項目小組內(nèi)交互進行。單元測試是采用白盒測試
集成測試一般指實現(xiàn)了一個功能點或一個模塊后,為了測試這個模塊是否已經(jīng)實現(xiàn)了需求要求的功能。集成測試可能需要對多個類進行組裝,也可能需要與以前已經(jīng)測試通過的模塊進行組裝,是對產(chǎn)品組件的系統(tǒng)整合和執(zhí)行。集成測試可以根據(jù)模塊的大小分不同的級別,在現(xiàn)行的軟件開發(fā)中,每完成一個功能模塊都必須要進行一次集成測試,使得你完成的模塊是一個可以運行的產(chǎn)品。集成測試一般可以由項目小組的負責(zé)人(或指定一個小組成員)來完成。集成測試采用白盒式測試和黑盒測試
系統(tǒng)測試一般指項完代碼已經(jīng)全部完成,交給測試小組來進行測試。進行系統(tǒng)測試的人員獨立于開發(fā)小組,系統(tǒng)測試人員把完成的產(chǎn)品布署在相應(yīng)的計算機環(huán)境中,按照測試計劃進行測試,驗證系統(tǒng)是否滿足了指定的需求。系統(tǒng)測試除了測試產(chǎn)品應(yīng)滿足基本的功能需求外,還要對產(chǎn)品的性能,用戶界面,安全性,壓力,可靠性,安裝和反安裝等幾個方面進行測試
系統(tǒng)測試采用黑盒測試
驗收測試一般指產(chǎn)品交付給客戶,負責(zé)把產(chǎn)品布署在指定的計算機環(huán)境中。由用戶根據(jù)需求文檔,進行的總體測試。驗收測試的內(nèi)容和系統(tǒng)測試一樣,只是執(zhí)行者不同。都是除了測試系統(tǒng)完成基本功能外還要對性能,安全性,可靠性等進行測試。驗收測試也是采用黑盒測試
為什么需要測試?測試是對軟件質(zhì)量的保證,只能通過嚴格測試的軟件才是合格的軟件,測試并不是說讓軟件能夠編譯通過,測試是讓軟件產(chǎn)品最大程度的滿足客戶的需求度。
回答實例:
考官:令狐沖,能談?wù)勀銈兪窃趺礃訉@個項目開發(fā)的嗎?
令狐沖:首先,我們這個項目已經(jīng)有了一個基本的用戶原始需求。但這是不夠的,我們都知道需求分析是十分重要的,所以我們在用戶原始需求文檔的基礎(chǔ)上,再次進行了分析,通過不斷的與客戶溝通,充分的了解和熟悉用戶的業(yè)務(wù),完善了業(yè)務(wù)需求和功能需求。還對用戶業(yè)務(wù)需求和功能需求分析完善為實現(xiàn)軟件的必須的非功能性需求。得出項目需求規(guī)格說明書,經(jīng)過評審會議確認通過。
根據(jù)需求規(guī)格說明書進行用例分析,通過分析和討論找出充分的有效用例,并用Rose畫用例圖。對每一個用例進行詳細的分析,完成每個用例的用例規(guī)約文檔,并編寫界面原型。劃分項目模塊。最后對用例及用例規(guī)約文檔進行評審驗證。編寫”代碼編寫規(guī)范”及界面風(fēng)格規(guī)范,數(shù)據(jù)庫設(shè)計規(guī)范,編寫概要設(shè)計說明書。
根據(jù)需求規(guī)格說明書和分析各個用例規(guī)約文檔,獲得數(shù)據(jù)庫的基本信息原型。也可以說是數(shù)據(jù)庫表的草稿,根據(jù)數(shù)據(jù)庫表草搞進行分析,進行數(shù)據(jù)庫設(shè)計和優(yōu)化。編寫數(shù)據(jù)庫設(shè)計說明書。采用PowerDesigner進行數(shù)據(jù)庫建模,并生成SQL腳本。確定項目框架,設(shè)計公共模塊和輔助類。根據(jù)對數(shù)據(jù)庫模型和用例規(guī)約文檔的分析,列出對象清單和理清對象關(guān)系。用Rose來畫類圖。對每一個用例都用rose畫出時序圖。編寫詳細設(shè)計說明書。列出任務(wù)清單,分組進行代碼編寫。
在代碼編寫階段,先統(tǒng)一完成所有的實體類。對于非實體類則先完成類的框架,也就是只寫方法和注釋文字。具體方法的實現(xiàn)暫時為空。然后再進行代碼填寫。每完成一個類的代碼編譯通過后都要進行重構(gòu)和單元測試。每完成一個功能和模塊都由會由小組長進行集成測試。使得完成的模塊是一個真正可以運行的,可見的功能實現(xiàn)。
在各個小組都完成自己的模塊后就進行模塊整合,進行一次大規(guī)模的集成測試。然后把產(chǎn)品產(chǎn)給產(chǎn)品測試小組進行系統(tǒng)測試。
問題之四、你們是怎么保證軟件開發(fā)的質(zhì)量的?
分析:這個問題其實上面的講解已經(jīng)給了答案了。軟件質(zhì)量是軟件實現(xiàn)對需求的滿足度。開發(fā)的軟件越滿足客戶的需求,說明軟件的質(zhì)量越高。反之就是質(zhì)量越低。盡管你開發(fā)的軟件使用了新的技術(shù),良好的設(shè)計,豐富的功能;但是這些功能都不是客戶需要的,客戶需要的功能沒有實現(xiàn)或者是很多沒有實現(xiàn)。這樣的軟件也是失敗的軟件。為了保證軟件質(zhì)量,也就是讓開發(fā)的軟件最大程度滿足客戶的需求,只有兩個方法。一個是獲得充分完整的需求,二是能過測試,以需求為中心編寫測試計劃。來保證軟件合乎需求。
回答實例:
考官:你們是怎么來保證軟件的質(zhì)量的呢?
令狐沖:要保證軟件的質(zhì)量首先就要獲得完整的需求,在需求分析階段做了大量的工作與客戶各個環(huán)節(jié)的代表性用戶進行溝通,充分了解和熟悉客戶的業(yè)務(wù)。并且從需求到設(shè)計階段都保持與用戶的溝通和交流。讓用戶的業(yè)務(wù)專家一直參與我們的需求,分析和設(shè)計工作。
其次我們會在需求分析后就編寫測試計劃,在開發(fā)的每個階段都進行相應(yīng)的測試來保證代碼是乎合相應(yīng)需求的。在代碼編寫過程中,每完成一個類都由程序進行單元測試,每完成一個功能點或模塊都要進行集成測試,每一次集成測試都對上一次的已經(jīng)測試通過的產(chǎn)品進行迭代, 也就是以前測試成功的都會加入到本次測試中來。使得每個完成的功能和模塊完成后都是一個可以運行的,可以看得到的產(chǎn)品;同時也歡迎用戶來見證我們的集成測試結(jié)果。代碼編寫完成后進行最后一次集成測試,然后交由獨立的測試小組對項目進行系統(tǒng)測試。
問題之五、你為什么離職的?(你為什么離開以前公司的?)
分析:這個問題幾乎在任何場合的面試都會有,有時是在技術(shù)面試的時候問,有時是在人事面試的時候問,有時會在技術(shù)面試和人事面試的時候都問。其實也比較好回答,回答的抽象一點比好。切記不要說以前公司的壞話,如果你這樣做。人家會想,你以后離職后同樣也會說這家公司的壞話.一般都是說為了某求更好的發(fā)展空間。讓人感覺你是經(jīng)過深思熟慮后才選擇他們公司的。
回答實例:
考官:你為什么離開以前公司的?
令狐沖:以前公司對我很好,我在以前公司干得也很愉快。我因為合同到期,為了獲得更好的發(fā)展空間及謀求對自己能持續(xù)發(fā)展的環(huán)境。并向公司辦理了離職手續(xù),完成了工作交結(jié)。(后面這句也可以不談)
問題之六、談?wù)勀愕穆殬I(yè)規(guī)化
分析:企業(yè)都希望他所招聘的人是潛力股,看你是不是一個追求上勁的人,還有想看看你能夠在企業(yè)長期干還是僅把其當(dāng)著一個跳板??偟恼f來,回答這個問題要讓人覺得你是一個可培養(yǎng),有潛力人。記住要看是什么樣的人來面試你。如果是項目經(jīng)理來面試你,你就不要說你以后的職業(yè)規(guī)化是項目經(jīng)理。你就可以說你的職業(yè)規(guī)化是成為架構(gòu)師,或者是技術(shù)專家等。否則他可能會認為你是一個對其有威脅的人。就算他內(nèi)心知道這不算什么,可能心理總會有一點點不爽。如果是老總面試或人事問你這樣的問題,你則可以說項目經(jīng)理也無妨,不過要給人有一種覺穩(wěn)的感覺。
回答實例:
考官:你的職業(yè)規(guī)化是怎么樣的呢?(考官是項目經(jīng)理)
令狐沖:我思維能力比較強,擅于邏輯分析。在之前的工作中積累了一定的架構(gòu)經(jīng)驗,以后就想成為一名架構(gòu)師和技術(shù)專家
程序員面試什么最重要
目標
相信和不少朋友一樣,有了幾年工作經(jīng)驗成為Senior后就開始了面試別人的經(jīng)歷。我在最初這個階段只是按照自己的想象把”找到基礎(chǔ)好的程序員“,”找到算法能力優(yōu)秀的程序員“,”找到有Android開發(fā)經(jīng)驗的程序員“等作為面試的目標。但是,實際的經(jīng)歷告訴我,尤其是按“基礎(chǔ)好”,“算法好”這些目標招到的人最終效果并不好。比如,有的面試者基礎(chǔ)知識和算法掌握情況不錯,進程、線程、內(nèi)存等概念清晰,基本的Hash,二叉樹,快速排序等數(shù)據(jù)結(jié)構(gòu)和算法也比較熟悉,但是進公司后在實際工作中表現(xiàn)得很糟糕。后來,我才發(fā)現(xiàn)原來是我的面試目標出了問題,我原先的面試方法更像是大學(xué)的算法或操作系統(tǒng)期末考試,按照這種方法讓許多并不合適的人通過了面試,同時也可能錯過了許多合適的人。
后來,我的反思是,從公司的角度講,面試的根本目的是找到“能夠干好工作”的人,而“高學(xué)歷”,“算法好”,“基礎(chǔ)好”,“有經(jīng)驗”這些都是表象而不是根本,它們并不能直接和“工作好”劃等號。
方法
目標明確了,但接下來的問題是假設(shè)面試者是一個黑盒系統(tǒng),“工作好”不是直接可觀測變量,你所能直接觀測的變量是基礎(chǔ)、算法、經(jīng)驗、學(xué)歷、性格、談吐、年齡等等。所以,實際上,你只能從“基礎(chǔ)好”,“算法好”等可以直接觀測的量去推測“工作好”的概率,這就是一個在“X好“條件下”工作好“的條件概率問題:P(工作好 | X好)。
根據(jù)這個模型,面試所應(yīng)該考察哪些方面就很明顯了,那就是選擇那種最具有區(qū)分性的方面來考察。比如,考察面試者的體型特征沒有太大意義,因為P(工作好|高),P(工作好|矮),P(工作好|胖),P(工作好|瘦)的概率都差不多;所以,體型特征不具有區(qū)分性,這不是面試所應(yīng)該關(guān)注的內(nèi)容。
面試官應(yīng)當(dāng)結(jié)合職位的要求明確哪些因素具有比較好的區(qū)分性。比如,如果要招一名技術(shù)門檻比較高的3D游戲引擎開發(fā)工程師,面試者A具有3D游戲引擎開發(fā)的經(jīng)驗,但是在基礎(chǔ)知識和算法面試方面表現(xiàn)一般;面試者B相反,基礎(chǔ)知識和算法面試表現(xiàn)很好,但沒有游戲開發(fā)經(jīng)驗,而你只能選擇其一。你選誰呢?其實,這就是兩個條件概率問題P(工作好|經(jīng)驗好,基礎(chǔ)一般,算法一般)和P(工作好|沒經(jīng)驗,基礎(chǔ)好,算法好)。這個問題就留給面試官來判斷了,就我個人而言,對于技術(shù)門檻較高需要技術(shù)積累的職位,經(jīng)驗更加說明問題,因此,我更傾向于面試者A。
下面,我再結(jié)合自己的經(jīng)驗談?wù)剬γ嬖囍谐R姺矫娴目捶ā?/p>
算法
算法是Google和MS等大公司面試所重點考察的內(nèi)容。我個人很喜歡算法,曾經(jīng)參加ACM/ICPC拿過北京賽區(qū)的13名。但是,就個人經(jīng)驗來看,我所接觸過的絕大多數(shù)開發(fā)職位而言,算法都不適合作為考察面試者優(yōu)劣的主要因素。對于普通的非算法性開發(fā)職位,考察面試者的算法就相當(dāng)于考察他打乒乓球好不好一樣,與目標“工作好”的相關(guān)性太低。就我個人的經(jīng)驗來看,差不多P(工作好|算法好)=50%,也就是算法面試沒有太大的區(qū)分性。
甚至,還有一種很不好的情況特別多地出現(xiàn)在算法好的面試者身上,我稱之為“只磨刀,不砍柴”。什么意思呢?有類人只對什么A*算法,異步編程,JVM類加載機制這種純技術(shù)問題感興趣,對實現(xiàn)用戶需求毫無興趣。這類人看起來有一定的技術(shù)能力,但是對公司來講貢獻十分有限,甚至不如技術(shù)一般但認真負責(zé)的人。所以,一旦遇到面試者算法好,我就特別留意考察會不會是這種“只磨刀,不砍柴”的人。
另外,雖然我個人不了解Google和MS,但我對于其特別重視考察算法能力的面試策略是持懷疑態(tài)度的。即使在這樣的世界級大公司,算法雖然重要,但可以想象在項目實施過程所遇到的各種各樣問題中,算法問題絕大多數(shù)時候不會是主要瓶頸,沒有到那種需要每個人都是算法高手的情況。實際上,絕大多數(shù)項目真正難點并不是一兩個算法瓶頸,甚至也不是單點的技術(shù)瓶頸,而是系統(tǒng)性的組織、協(xié)調(diào)、設(shè)計、開發(fā)問題,有大量的看起來不是那么有技術(shù)含量的臟活累活,也有許多問題是由于信息不足,并不是技術(shù)能力強就能克服這些困難。一個團隊最好優(yōu)勢互補,有人算法強,有人業(yè)務(wù)分析能力強,有人擅長后端服務(wù),有人擅長前端界面,有人聰明,有人踏實,這是最好的。如果按照“算法好”的單一標準選材,必定會把許多優(yōu)秀的人才拒之門外。
基礎(chǔ)
基礎(chǔ)面試是指考察諸如指針使用、進程線程概念等基礎(chǔ)知識的面試,十分類似于大學(xué)期末考試題。我曾經(jīng)以為基礎(chǔ)面試十分重要,但是現(xiàn)在不這么看了。在工作中基礎(chǔ)的確是重要的,但是在面試過程中,它必須具有區(qū)分性才有意義,也就是說P(工作好|基礎(chǔ)好)的概率要高,那么考察指針使用,進程線程區(qū)別這樣的基礎(chǔ)題目才有它的意義。我的實際經(jīng)驗是,基礎(chǔ)面試并不具有很好的區(qū)分性,和算法一樣, 差不多P(工作好|基礎(chǔ)好) = 50%。同時,基礎(chǔ)面試是最容易準備的,中國人有長期的應(yīng)試教育經(jīng)驗,要準備幾個把玩指針題目太容易了。
我曾經(jīng)遇到過這樣的面試者,他的C語言基礎(chǔ)和編譯、鏈接等原理掌握得非常好,給我留下了深刻的印象,我給的面試結(jié)論是:知識面不寬,只會C語言,但基礎(chǔ)很扎實,建議錄用。后來的事情證明了那個結(jié)論的前半部分是對的,但是”建議錄用“錯了。他在實際工作中表現(xiàn)得一塌糊涂,不理解需求,不理解整體架構(gòu);同時,上班時間不是花在項目上,而是花在閱讀諸如《程序員的自我修養(yǎng)》之類的書籍上。最后,這位同事由于長期“不出活”離開了公司。
基礎(chǔ)不是不重要,而是“基礎(chǔ)好”不足以說明面試者能干好工作,因為基礎(chǔ)是屬于局部性知識,而實際工作需要綜合性能力,二者有天壤之別。C語言、操作系統(tǒng)能考高分,但是不會寫程序的人在大學(xué)我們還見得少嗎? 軟件開發(fā)就像蓋房子,綜合能力是設(shè)計和搭骨架,基礎(chǔ)知識是碼磚。張小龍原先Foxmail是Delphi開發(fā)的,他它不懂C#,你如果要招聘一個開發(fā).NET Email客戶端的人,你考察他對CLR掌握得好不好有意義嗎? 讓張小龍來開發(fā)一個C#版的Foxmail真的會有困難嗎? 你招一個精通C#但沒有Email客戶端開發(fā)經(jīng)驗的人來真的比張小龍靠譜嗎?
我說基礎(chǔ)知識不重要,和古人說的“不積洼步無以至千里”是不是矛盾呢?不矛盾!“洼步”與“千里”是一種可累加關(guān)系,但再多的“基礎(chǔ)知識”都累加不成“綜合能力”。學(xué)習(xí)軟件開發(fā)要像持續(xù)集成一樣,一開始就是一個完整的系統(tǒng),雖然規(guī)模不大,問題很多,但它麻雀雖小五臟俱全,從小系統(tǒng)到大系統(tǒng),從簡單系統(tǒng)到復(fù)雜系統(tǒng)逐步演化。
所以,基礎(chǔ)好本身不足以說明太多的問題,必須進一步考察綜合能力。對于基礎(chǔ)面試表現(xiàn)不好的面試者,如果時間允許也要進一步考察,有的面試者其實是有能力的,只是沒有進行充分的準備。最理想的狀態(tài)當(dāng)然是基礎(chǔ)和綜合能力俱佳,若不能兼顧,應(yīng)當(dāng)綜合能力優(yōu)先。
經(jīng)驗
這里所說的經(jīng)驗不是通過工作了多少年來衡量的,而主要是指面試者的經(jīng)歷,比如,是否完整地實現(xiàn)過一個軟件,或作為主要開發(fā)者完成過一個項目。經(jīng)驗的重要性在于它能說明一個人的綜合能力。從項目的性質(zhì)、規(guī)模和難度,面試官就可以大致判斷出面試者的綜合能力。如果一個面試者一直在大公司負責(zé)一個小模塊的開發(fā)維護,那么基本可以判斷他不具備獨立或作為主要開發(fā)者承擔(dān)一個項目的能力,只適合在另一家大公司做類似的事情。對于門檻較高需要長期技術(shù)積累的職位,相關(guān)經(jīng)驗更顯得尤為重要,比如,Linux內(nèi)核開發(fā),JVM開發(fā),游戲引擎開發(fā),數(shù)據(jù)庫實現(xiàn),高級UX等。對于這類職位,沒有經(jīng)驗的面試者即使綜合素質(zhì)不錯也是需要長時間的學(xué)習(xí)和積累才能勝任。所以,基本上如果確定了你的職位屬于此類,那么相關(guān)經(jīng)驗毫無疑問應(yīng)該成為首選因素,換句話說,P(工作好 | 相關(guān)經(jīng)驗好)的概率是非常高的。
通過項目經(jīng)驗判斷面試者的優(yōu)劣比通過基礎(chǔ)和算法測試更加靠譜,所以,面試過程中面試官應(yīng)該花比較多的時間聽面試者介紹項目經(jīng)驗,并進行深入地探討交流,了解面試者的知識面、思維能力、表達能力等。同時,可以結(jié)合項目提一些基礎(chǔ)知識和算法的問題,比如,如果面試者做過C++相關(guān)的項目,那就可以問他如何進行內(nèi)存管理?是否熟悉智能指針?如果面試者的回答不能令人滿意,那么就基本上可以判斷他的項目做得不是很好。
要注意的是,經(jīng)驗也是一個多維度的事物。比如,C++股票交易中間件系統(tǒng),這就涉及(C++,中間件,股票) 3個維度。假如面試者A做過C++股票交易客戶端,面試者B做過C的股票交易中間件。從語言角度看,A最匹配,從項目性質(zhì)看,B最匹配,你如何選擇?這就是在多個維度中,哪個維度更重要的問題,就這個例子而言,我個人更傾向于B,因為我認為中間件開發(fā)經(jīng)驗是主要矛盾,而從C切換到C++并不是問題。所以,面試官需要判斷哪一種經(jīng)驗是主要的,而哪一種經(jīng)驗是次要的。比如,我們招聘Android應(yīng)用開發(fā),這個職位的Android技術(shù)門檻并不高,它的真正難點在于做出好的用戶體驗(UX)。所以,如果一個面試者沒有Android的經(jīng)驗我們是可以接受的,但是我希望他在UX方面有經(jīng)驗,至少做過其他平臺的移動應(yīng)用開發(fā)。
性格
現(xiàn)在,我來談我認為最重要的因素:性格。這可能是許多初為面試官的朋友所難以想象的,怎么會是性格最重要呢?說實話,當(dāng)我意識到這一點時,我自己也很驚訝!說白了,還是 P(工作好|性格好)的概率最高啊。我的實際經(jīng)驗是,如果一個人的性格好,他能把工作做好的可能性是最高的,性格好遠比基礎(chǔ)好、算法好要靠譜。
一個人如果技術(shù)上有缺陷,經(jīng)驗上有不足,但性格好,在團隊中是很容易由其他人來補位的,他自己也很容易逐漸補起來;相反,如果一個人的性格不好,所有的技術(shù)優(yōu)勢經(jīng)驗優(yōu)勢都發(fā)揮不出來,甚至還會起到負作用,而且性格缺點很難改變。我一直談到實際工作所需要的是綜合性的能力,這種綜合能力的發(fā)揮中性格是至關(guān)重要的。項目中不止會遇到技術(shù)問題,要涉及溝通、協(xié)調(diào),不同的人不同的部門既有合作又有磨擦,如何處理這些事情都需要一個良好的性格??梢哉f,在開發(fā)團隊里讓你與眾不同的不是你從哪個學(xué)校畢業(yè),也不是你過去的經(jīng)驗,而是你的性格。
當(dāng)然,性格是一個復(fù)雜的東西,它包含了很多的方面,并非所有方面都是程序員面試所需要關(guān)注的。我的經(jīng)驗是可以重點考察這些方面:
1) 態(tài)度積極還是消極。有的面試者在談吐中就會自然給你一種積極上進的感覺,或者你可以在他的經(jīng)歷中發(fā)現(xiàn)他積極的因素,這些都不是太難看出來的。相反,有的面試者你能明顯感覺到他的消極情緒。積極性在工作中是十分重要的,積極的人能給團隊帶來朝氣,也更易于合作?;旧希绻_定面試者屬于態(tài)度積極的,他通過我這一關(guān)的可能性就會大大增加;相反,如果確定屬于態(tài)度消極的,即使技術(shù)能力不錯我也會十分謹慎。
2) IQ。我的經(jīng)驗是,總體來看,聰明的人在工作中的表現(xiàn)更為優(yōu)秀。在面試中要考察一個人是否聰明并不一定要像Google和MS那樣找些專門測試IQ的智力題,其實,你只需要看他討論問題是不是很有邏輯性,思考和說話是不是反應(yīng)敏捷就可以做出大致的判斷。另外,眼睛是人心靈的窗戶,一個人聰明與否,眼睛是會說話的。不過,聰明也不完全是優(yōu)點,比如,當(dāng)公司或項目遇到困難時,往往是聰明人先跑掉了,堅守的往往是IQ一般的人。
3) 語言表達能力。語言表達能力也是程序員十分重要的一項素質(zhì),它關(guān)系到項目中的溝通是否順暢。面試官可以看看面試者能否用簡明的語言介紹清楚曾經(jīng)做過的項目,能否抓住要點,能否考慮到聽者的相關(guān)背景。一般來講,語言表達能力強的人綜合能力都不會太差。
4) 是否具有用戶意識。有人說程序員是做研發(fā)的,哪來什么用戶?只有銷售、市場人員才會和用戶打交道。其實,這是完完全全的錯誤認識。你寫一個模塊,甚至一個API,只要有別人用,他就是你的用戶。有的程序員設(shè)計一個模塊或是一個軟件總是習(xí)慣于從使用者的角度來考慮,盡量地方便使用者,這就是一種良好的用戶意識。具有良好的用戶意識的人更能考慮別人的感受和整體的需要,而不是單純地從自己和局部來思考問題。當(dāng)面試者談及過去的項目經(jīng)驗時,面試官可以常常站在用戶的角度對其進行提問,從這個過程中觀察其是否具有良好的用戶意識。
5) 如何應(yīng)對質(zhì)疑和壓力。面試官應(yīng)該對面試者的回答以及以往項目進行合理的質(zhì)疑,看看他如何應(yīng)對。曾經(jīng)有一位面試者談到做游戲登錄服務(wù)器的經(jīng)歷,我就問:“如果登錄服務(wù)器掛了,怎么辦呢”?他說原先雖然沒有考慮這個問題,但是可以怎么怎么改進。其實,大家都理解項目中有各種不完美,這里面原因很多,只要面對質(zhì)疑和壓力能從容應(yīng)對努力往好的方向思考解決就可以了,不需要掩飾缺陷,更不應(yīng)該有情緒。我遇到過有的面試者,一旦你對其項目提出質(zhì)疑,他馬上產(chǎn)生反抗情緒,或不高興,或不承認有問題,這很容易一下子看出來他在工作中容不得質(zhì)疑和批評,這種人要想合作就很困難。
6) 個性特點。許多面試者喜歡在簡歷上寫“精通C++/Linux“,這些字眼看得人麻木,如果有人寫”喜歡C++/Linux“,我就會有一種眼前一亮的感覺。“精通”是沒有感情色彩的敘述,而“喜歡”包含了面試者的個性,我更愿意看到面試者的個性。我相信對某樣?xùn)|西真正的熱情遠比你當(dāng)前對它的掌握程度更為重要。其實,N年的經(jīng)歷告訴我們,同一個班的同學(xué),同一個項目組的同事,雖然每天所學(xué)的知識,所接觸的工作都是相同的,但其實每個人的成績和表現(xiàn)差異是十分明顯的。那么,到底本質(zhì)的差異是什么呢?其實,就是每個人的個性。是個性使得有的人業(yè)余時間去打球,有的人業(yè)余時間去看書,有的人喜歡Linux,有的人喜歡Mac。一個人在團隊中扮演的角色也和他的個性有很大的關(guān)系。面試官應(yīng)該引導(dǎo)面試者展現(xiàn)自己的個性,并判斷其是否有益于團隊。
總結(jié)
最后總結(jié)起來,我的經(jīng)驗是:
1) 面試官的目標是找到”工作好“的人,一定要圍繞這個目標來進行面試,如果把面試當(dāng)成了算法或操作系統(tǒng)期末考試這就走入了誤區(qū);
2) 面試過程是通過學(xué)歷、性格、基礎(chǔ)、經(jīng)驗、算法等可以測試的因素去綜合判斷面試者“工作好”的概率;
3) 在各種因素中,性格 > 經(jīng)驗 > 基礎(chǔ) > 算法。性格是最重要的,如果性格不好,所有技術(shù)能力都會大打折扣,而且技術(shù)缺陷容易彌補,性格缺陷很難改變;經(jīng)驗體現(xiàn)了一個人的綜合能力,你可以從面試者過去的經(jīng)歷中判斷他能從事哪種工作,不能從事哪種工作;基礎(chǔ)和算法則主要起到輔助參考的作用,基礎(chǔ)好的程序員一般適應(yīng)性比較強,學(xué)新技術(shù)更快,但是切忌單純從基礎(chǔ)來判斷一個人的能力。