如何考察程序員穩定性

A. 怎樣快速確定程序員編程水平

想要快速確定程序員的編程水平，可以從以下四個方面考慮：
第一，知識的考察。這個是幾乎每個公司都會做的，也是很有效的手段，基本就是考試。包括問語法問標准演算法問API問一切有標准答案的問題。一個人懂得多，不一定寫得特別好，但是什麼都不懂一定寫不明白。這個方式還可以按需求選人才，比如我們就在php做前端，那我就可以問一堆關於php的，如果我是做嵌入式的，那我可以問一堆c。可以考察這個程序員在和公司需求的交集上完成的怎麼樣。這也是最最簡單和直觀的方法。
第二，對過往項目的理解。這個也是在簡歷關很常問的，說說你當時做的這個項目吧。這個問題非常有效地考察了他是否理解他之前做的東西。有的人簡歷寫的巨漂亮可是實際那項目和他沒關系，或者他就是復制粘貼的代碼，其實自己啥都沒寫。這種時候你和他聊的足夠深入之後能很明顯地發現他自己說不明白了。同時還可以考察一定的語言表達能力和邏輯能力。用我們的話說，先問到面試官不會的深度，然後讓他給面試官講明白。如果他做的東西，他蒙圈的時候比面試官還早（前提是面試官不是搞這方向的），那一般就比較悲劇了。
第三，對寫程序本身的理解。我們很喜歡問一道題，描述一下你是怎麼寫程序的。凡是說我事先design好所有的模塊、介面、功能，然後逐一實現，然後程序就work的，我們都心裡默默補上「呵呵」。因為這是不可能的，只能說明他沒寫過大程序或者沒總結過寫程序的經驗。沒有人在完成一千行以上的程序的時候在沒寫之前就做好所有模塊設計的，何況更大的程序。當然還有就是他會不會認為程序跑通一次就完成了（即寫程序有沒有test階段）之類的。
第四，動手寫程序的能力。這個說實話是面試的時候不太容易考的，因為時間有限。現在的大公司基本是45－60分鍾一輪，一輪還要問好幾個程序題，所以寫的代碼都是片段的，大概20行左右，根本沒法體現一個人會不會寫程序。所以很多人不需要會寫程序，只需要刷好leetcode之類的演算法題庫就可以進大公司（相信我我認識很多）。我們認為一個好的程序員一定要在限定時間之內完成一個完整工作，滿足要求的程序。從輸入到輸出到corner case的驗證。而不僅僅是研究明白某個基礎演算法如何用nlogn而不是n^2解決。這一關卡下去了無數看起來很美好的人。因為我們的題目是不可能在那個時間內找到最優解的，就像絕大部分工程中的編程一樣。一個較好的可用解往往比最優解要有價值的多，因為後者需要大量的時間，很可能沒有前者直白，而且提升未必很高。這是我們公司最在乎的一點。

B. 如何辨別一個程序員水平的高低呢

有的時候單純靠一個面試很難辨別一個程序員的水平是什麼樣的。原因很簡單，因為很多面試題在網上都有，如果刻意准備那麼一般都能回答的不錯。所以想辨別一個程序員的水平需要一定的方法。

上述幾方面我們稱為應能力，還有一些軟能力也是非常重要的，比如責任心，對技術的態度，學習能力等等。當然，這些就更難考量了，本文暫不介紹。

如果上述幾方面都比較不錯，那麼這個程序員的水平應該是不錯的。即使對目前的工作的知識儲備可能還有欠缺，但經過一段時間後必然可以

C. 關於c語言程序的穩定性，求大神幫忙啊

在設計程序的時候考慮各種有可能的錯誤和異常，
因為用戶並不一定會嚴格按照程序員的設定來使用程序，好比輸入數字，但用戶輸入了字母，這些都需要在程序中考慮（可以判別輸入，不合法則提示繼續輸入）。
c++引入的異常機制，來處理程序異常。c的話，要自己仔細考慮，編寫健壯、穩定的程序了。
當然，測試也很重要，寫完程序要找一些容易出錯的來測試（每一個軟體開發都有內部測試階段），然後完善代碼

D. 如何辨別一個程序員水平的高低

1.自己介紹項目，看對項目的提煉總結能力（也是抽象能力）；
2.自己印象最深的bug，可以知道大概技術深度；
3.設計模式提問，看有沒有學習方法；
4.語法基礎問題，多線，分布，安全等問題，看知識面廣度；
5.智力問題，看反應能力，分析問題思路等
上述五步基本可知是否是一個好程序猿

計科專業從事軟體開發十幾年了，主要在瀏覽器內核領域研究的比較多，最近在研究伺服器後台方向，辨別程序員水平高低主要看做出了什麼產品，如同現在的程序員主要是項目經驗，簡歷上寫的一堆項目經驗都是面試的時候主要提及的問題。經常在面試中會問兩個關鍵點：一個是做過什麼項目；一個是在項目組中承擔什麼職務，畢竟參與過和做的多少程度是不一樣的，這些都是可以通過一些具體的細節檢測出來，問題越具體越是容易看出水準，具體的東西不是能夠編造出來的。

有很多技術公司直接不通過筆試，僅僅通過簡單的面試就確定工資水準了，最簡單的測試程序員水平的直接用筆試的方式，筆試可以把一些細節量化，盡量的細節化也是能測試出程序員基本功的，但這種基本用來測試初級程序員的，很多高級的程序員看到有筆試直接就抬腿走人了，因為有些程序員在一個方向做的時間太長了，很多基本功都忘得差不多了，所以筆試可能不過關，現實中很多程序員筆試不過關，面試還可以，也一樣可以做項目說的就是這類人，起碼這算是非常優秀的程序員。

有很多公司採用谷歌的方式，直接採用上機寫代碼的方式檢驗程序員水平，這種方式比較直接，但在現實中可能消耗的時間以及面試官的精力，目前只有極少數的公司用這種方式，國外的公司用這種方式比較多，這種看基本功非常有效。通過代碼可以看到編碼習慣以及演算法的設計上，都能直接看的出來。

普通的程序員直接看項目的經驗，高級的直接看做過的產品，特別是產品主要設計人員，這就是程序員內心的自豪感，畢竟作為一個程序員起碼要有自己設計開發的產品，也算是不白做一個程序員，在程序員的職業經歷中如果能經歷過一個產品從開始設計的初稿到最後推向市場，如果是完整的經歷，將是一種巨大的財富，只要經歷過一次都會對產品設計有一個比較層次的認識，這種能力需要靠直接的面試語言表達來展示出來，談下對產品的認識以及產品穩定性性能等方面的總結，能到這個層面起碼是高級軟體工程師的級別。

當然有些程序員內在的東西不是靠語言或者寫代碼看出來的，因為一個優秀的程序員不僅僅是代碼能力以及框架能力，還有幾個非常重要的能力

程序員的能力表面是可以直接展示出來，但很多內在需要是需要時間的磨合才能了解，人就才能見人心，而且很多優秀的程序員是培養出來的，能夠長時間在一起的隊友都是時間長了磨練出來的。

希望能夠幫到你。

自認為不是一個好的面試官，因為我認為在這么短的時間內，准確地衡量出來程序員水平的高低是有比較大的難度的，並且我有多次看走眼的時候，面試的時候覺得能力還不錯，但是入職工作了一段時間之後，編程能力不忍直視。

工作之後接觸一段時間，我會從這么幾個方面觀察他們，以判斷技術能力的高低和發展潛力。

能不能出活兒、能不能debug

能不能把開發任務按時按質量地完成，當然是最主要的衡量標准了:

解決問題的方法

在開發過程中，難免會遇到沒有見過的問題，有些程序員遇到問題無從下手，而優秀的程序員，自有一套解決問題的方法。

分析問題、流程設計的思路

有人會認為，程序員的主要工作就是敲代碼，上班大部分時候都是在敲代碼，其實並不是這樣：

總結問題和改進問題的能力

好的程序員，相同的問題不會犯第二次，差的程序員，總會在一個問題上栽跟頭：

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

不請自來，一介碼農路過，留下些看法。

程序員主要是有四種綜合能力，也就是debug 能力、 performance分析、 保護性編程和 投入產出比。

僅僅獨立完成日後必然成高手？

在這里不能說一棒子打死，至少對於很多人來說，能獨立完成是沒什麼問題的，有的是因為對業務熟悉，有的是真的基礎扎實。但怎麼說呢，程序員和瀏覽器打交道是最多的，現在這個互聯網時代，遇到的大部分問題網路都是可以解決的，也就是普通程序員 + 網路 = 超級程序員。 但很多人也沒明白具體的原理，甚至都是這個項目抄抄那個項目抄抄的，久而久之雖然解決了平時的業務，但進步的空間卻很少，甚至止步不前，寫出來的代碼也可能存在很多坑，所以，僅僅能獨立完成任務的話，離高手還有比較遠的一段距離。

如何辨別高手程序員？

也就是結合我們一開始列舉的那四個能力進行判斷。不同級別的程序員，在那綜合能力面前，強弱也是不同的。例如在奔潰的或者其他性能調優問題上，即使是面對大量復雜的代碼，在信息不全的時候也會一步步的分析，抽絲剝繭縮小范圍，最終定位根本原因

，並且最終給出一個好的方案。

如何成為高手程序員？

當然還有看他摘了帽子是否禿頂這樣的笑話，就再不贅述了。

第一階段（黃金）:會用編程語言實現需求，比如現在的業務系統，都會找一些會搬代碼的人來拼工作量，也就是能自己獨立基於搭好的框架實現crud常規操作。

第二階段（鉑金）:除了crud，還會有一些自己踩過坑的經驗，知道如何處理一些常見問題，或者可以基於搜索引擎快速解決一些異常情況。

第三階段（鑽石）:能解決一些疑難雜症和會通過debug部分源碼類庫查看到這些疑難雜症是如何引發的，並通過編碼解決這些問題，還能進行一些局部的性能優化，類似某個系統介面緩慢可以單獨去優化。

第四階段（星耀）:會基於整個系統進行設計和規劃，根據業務特性選擇合適的框架，從源頭控制開發遇到問題的頻率，可以自主的搭建框架並完善機制，了解各個組件工作原理。

第五階段（王者）:小說裡面總是說練武功的永遠比不過創造武功的，同樣的道理，用框架的也往往不如寫框架的，所以寫框架的這類人單獨分層。

第六階段（榮耀）:其實這個階段不應該列入進來，因為這類人往往不編碼的，只是給出思想；像Hadoop這種框架就是基於人家發表的一些論文（bigdata)進行編碼實現的，這類人注重的是思想和演算法，區塊鏈，大數據，雲計算等等概念的創造和理論的支撐是這類人提出來的，這些人才是真正影響行業走向的人。

程序員的水平高低，不是靠語言或外在表現就能看出來的，不是看他會多少技術、參加過多少項目、寫了多少博客，而是看他在實際業務場景中解決問題的能力，尤其是面對一些特別復雜的問題，或在高強度、高壓工作狀態下解決問題的能力與態度。

技術可以通過學習掌握，但是解決問題、定位問題的能力卻不是一蹴而就。大家可能會說，「解決問題的能力」這個太寬泛了吧，可以更具象化嗎，有具體的測量方法嗎？簡單整理了以下幾點供參考。

優秀的代碼能力

會寫出滿足需求的代碼，早就不是評判程序員水平的標准了。代碼編寫既要滿足業務需求，同時還要考慮後續的軟體維護，說得通俗些，既要自己爽，也要別人爽。一個優秀的程序員，會致力於寫出更簡單、更效率、可讀性強、擴展性強的程序代碼。

邏輯思維

程序員在日常工作中，需要理解各式各樣的業務需求，所以這就需要程序員具備一定的邏輯思維能力。可以說，邏輯思維是程序員的靈魂，因為每一行代碼都是程序員邏輯的體現。

debug能力

項目著急上線，發布時出現問題？

業務高峰時段，系統宕機了？

業務催、運營催、用戶催、老闆催！

各種形態的bug，各種著急的心情，背後無數支眼睛盯得內心慌慌......

這些都是一位合格程序員所需要面對的日常。不同的程序員，在解決問題的方法、效率、質量等方面，都各有千秋。一個經驗豐富的程序員，能夠扛住各方壓力，在復雜條件下找到核心問題，通過抽絲剝繭的分析來找到產生問題的原因，並快速進行應對處理，事後及時復盤總結，減少同類問題出現的概率。

學習能力

隨之互聯網的發展，越來越多的人湧入程序員這個賽道，競爭日益激烈，加之新技術層出不窮，更新迭代快，程序員所使用的語言、框架、模式都會發生天翻地覆的變化。如果不主動學習，你很快就會被落伍淘汰。

溝通能力

這種其實在面試過程中能體現出來，溝通主要是技術溝通，以及和客戶之間的溝通，所有技術都不是閉門造車就能搞定的，溝通能讓事情推進起來更加順暢，包括和產品經理之間的流暢的溝通也顯得非常重要。程序員的能力表面是可以直接展示出來，但很多內在需要是需要時間的磨合才能了解，人就才能見人心，而且很多優秀的程序員是培養出來的，能夠長時間在一起的隊友都是時間長了磨練出來的。

責任心

線上出bug了，第一時間響應、處理；

團隊項目進度緊張、人手緊缺，主動補位；

又或者，在項目推進過程中如果只是關心自己模塊內容，對於整個項目置之不理，只守著自己的一畝三分地。

隨著時間軸的拉長，你會發現，有此f技術能力不是最好的，甚至不如你的小夥伴，最後做到了技術主管或經理、甚至更高職位，這裡面除了技術實力，還有一個叫「責任心」的東西。

結束語

判斷一個程序員的水平高低，核心是其解決問題的能力，而解決問題的能力養成，需要扎實的底層基礎來支撐，要綜合其代碼質量、項目經驗、框架能力、邏輯思維等等多方面，不能單看某一方面。

而對於1-6歲的程序員來說，想要成為一個高級程序員，變得越來越優秀，唯有持之以恆去學習、積累、實踐、修煉。

----end----

一：50歲的時候，頭發還是黑色的濃密的。

二：賺到的錢能保證家人快樂的生活。

三：當公司不要你的時候能成功轉型。

其他的例如編程經驗、寫代碼厲害啊什麼的根本不值一提。

這就是程序員的面試嘛 :-)

（1）是否能熟練使用所用編程語言的主要功能；

（2）是否知道用合適的數據結構解決問題；

（3）是否知道基本的演算法，並且用這些演算法解決問題；

（4）只看少量代碼的話，從變數命名和程序結構一般能夠判斷是否是新手；

（5）給出具體問題，能夠用程序解決，能考慮到所有的邊界條件；

（6）考慮程序的可擴展性，可維護性；

再往高一點走，就需要

（7）面對模糊的問題能夠分析並且找到細節和具體的需求；

（8）知道利用已有的庫，架構和工具等來解決新的問題，而不是什麼都自己實現；

（9）能發現並改進已有程序中的瓶頸；

（10）對整個大項目的程序架構有很清晰的了解，知道相互之間的依賴，以及知道為什麼採用這樣就架構；

（11）給一個大的項目，能夠對整個項目的程序架構和組件進行合理的設計，考慮並行性，低延遲，大數據量等各種需求和應對方式。

帶領團隊已多年，項目數十個，對判別程序員水平的高低，我有自己的看法，歡迎大家一起交流。

1.代碼質量。

優質的代碼，首先是經得起考驗。靜態分析工具過一遍，無錯誤，無警告。當然警告部分需要人工重審，因為靜態分析工具不一定完全正確。過了這一關，重要的還須過測試關，少Bug或無Bug的代碼，才是好代碼。優質的代碼帶有技術氣質和藝術氣質。閱讀起來，有一種賞心悅目的快感，即工整美觀，干凈利落，又蘊含著理論常識，運用技巧，精準到位。

2.表達能力。

3.文檔能力。

文檔形式包括但不限於PPT，文字，圖表，音視頻。文檔內容包括但不限於API說明，工具手冊，項目事項，技術論述，陷阱總結，方案展示，指導手冊。文檔要求必須是滿足公司或部門的規范和格式，否則五花八門的，不利於交流和傳承。

以上3點，是我量化判斷程序員水平的標准，僅供參考。相比水平，其實我更看重程序員的態度，執行力，時間觀念，自學力等等，也是很重要的團隊作戰能力，也可以說是程序員水平的考量吧。

謝謝大家。

E. 程序員如何規劃才能讓職業生涯長期穩定呢大家有建議分享嗎

對於軟體開發人員來說，通常情況下，職業發展有幾種選擇:專注技術，成為技術專家；回到技術銷售，技術支持等。所以，要想走得更遠，必須要有過人的本事。隨著技術的發展，從技術管理走向先進管理。這是大家都能看清楚的方向，都在朝著這些方向的金字塔尖努力。程序員要根據自己的基本素質和技術能力選擇開發級別，由低到高逐步開發。也是一個具有相應素質的程序員一步步的發展軌跡，包括強大的技術背景和全面的管理能力，也就是所謂的「兩條腿走路」的職業規劃發展路線。「如果是這樣的話，我相信你不會在35歲的時候倒閉。

3.實施路線。

初級程序員，中級，高級，系統分析師，項目經理，實施經理，實施總監。

4.銷售路線

初級程序員，中級，高級，系統分析師，項目經理，實施經理，產品經理，售前顧問，銷售經理。

F. 軟體測試的方法一共有幾種

1、從是否關心內部結構來看

（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。

（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。

（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。

2、從是否執行代碼看

（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。

(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。

3、從開發過程級別看

（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。

(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。

（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

在系統測試中，對於具體的測試類型有：

（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。

（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。

（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。

（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。

（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）

（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。

（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。

（11）數據處理測試：對完成專門數據處理功能所進行的測試。

（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。

（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。

（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。

（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。

（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。

（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。

（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。

4、從執行過程是否需要人工干預來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。

（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）

5、從測試實施組織看

（1）開發測試：開發人員進行的測試

（2）用戶測試：用戶方進行的測試

（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環境看

（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(6)如何考察程序員穩定性擴展閱讀

軟體測試的內容：

1 得到需求、功能設計、內部設計說書和其他必要的文檔

2 得到預算和進度要求

3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )

4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試

6 確定對測試環境的要求 ( 硬體、軟體、通信等 )

7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等

8 確定對測試的輸入數據的要求

9 分配任務和任務負責人，以及所需的勞動力

10 設立大致的時間表、期限、和里程碑

11 確定輸入環境的類別、邊界值分析、錯誤類別

12 准備測試計劃文件和對計劃進行必要的回顧

13 准備白盒測試案例

14 對測試案例進行必要的回顧 / 調查 / 計劃

15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

19 跟蹤問題 / 錯誤，並解決它

20 如果有必要，重新進行測試

21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具

G. HR如何快速判斷應聘的程序員是否靠譜

招人這個事情放到如何重要的地位，其實都不為過。前趕集網CEO楊浩涌在一次開放式演講中說過，CEO要花一半精力去找人。其實在Google、Facebook、Alibaba等一些公司在招聘一個員工的時候，他們是很耗費時間和精力的。一個好的人是值得花非常多的時間。你看重的人，在他身上花精力是非常值得的，他會被打動，他會感知到你確實非常在乎他，士為知己者死，好的人才覺得跟你是有共鳴的，他願意加入你這個團隊。

其實在一些中小公司，可能HR會初步篩選一些簡歷，然後給面試官進行面試。但其實很多時候，面試官面試的這位應聘者根本不靠譜（注意，我們現在說的是程序員招聘這個方向）。這樣一來其實不僅浪費面試官的時間（其實，你知道，一般能夠作為面試官的，在公司裡面其實是很忙碌的），也是在浪費面試者的時間。所以，我個人覺得，HR在招聘的時候，首先可以通過一些基本的問題來快速判斷應聘的程序員是否靠譜，通過HR的初步篩選後，面試官再和應聘者電話或者當面聊一些技術層面、邏輯思維層面以及團隊合作層面的問題，這樣就大大的增加了招聘的效率。

我個人覺得有兩點：

因為程序這個行業變化更新很快，不要說剛入行的程序員，就是工作了十年的老司機，也需要不斷的學習，而看書是學習的最直接體現。

HR可以在和應聘者電話溝通的過程中，可以詢問他的業余時間都是怎麼過的，如果應聘者沒有提到讀書、看書之類，我覺得多半不靠譜。當然看書並不局限於一些技術方面的書，也可以是一些非技術的書，我覺得愛看書的人，兩方面的書都會看的。

我覺得第二點非常重要，首先我想要的是，應聘者簡介、清晰、有條理的描述出他最近做完的一個項目或者產品的大的需求是什麼，他自身在整個團隊裡面充當的是什麼樣的角色，能否描述清楚他自己做的某些功能。

如果HR能夠很清晰的理解應聘者所描述的這些問題，我覺得他是靠譜的。

首先，如果作為一個非技術性的HR，能夠聽懂應聘者的解釋，我覺得應聘者溝通、理解能力是完全沒有問題。

其次，他能描述出來這個項目或者產品的大的需求是什麼，說明他不是在蠻干，也說明他並非只是關注於手頭上的事情，他還在關注整個團隊在做什麼樣的事情，這也體現了團隊精神。

然後，他能描述出來自己做的某個功能，說明他是真正的去實踐過和思考過，思考和實踐是作為一個靠譜程序員必備的素質。

總體上，快速判斷一個程序員是否靠譜也就是這兩點，如果這兩點都OK ，沒有問題後，我覺得HR再和應聘者約時間，再和面試官聊。

提出一點建議

就是HR先進行一輪電話面，溝通一些基本問題，從中覺察應聘者在表達、溝通、描述以及學習方面的能力。如果還行，可以和應聘者約定一個時間進行技術面，而面試官可以把時間選擇在晚上，也就是7-9點鍾，這個時候，上了一天的班，可以更好的投入到面試的上面。通過電話面，了解一下技術，以及以前的工作經歷，沒有問題的話，再約時間當面聊。

這是我能想到的，不喜可以噴......