你的簡歷能爲你贏得一次面試機會嗎？

最近我在幫朋友的公司招人，招人的第一步是要篩選簡歷，在這過程當中，我發現雖然能收到不少簡歷，但實際能經過篩選能進入到技術面試流程的簡歷很少，估計10份裏不會超過4份能經過篩選。

若是無法經過技術面試，那麼候選人尚且能收集面試題，回家繼續準備，畢竟他和麪試官也交流過，也不算沒收穫，但對於這些無法經過篩選的簡歷，簡歷的主人每每是無從得知的（公司不會主動通知），因此他們依然會混混沌沌，能夠預想，在不短的將來，他們依然沒法獲得面試機會。

不知彼而知己，一勝一負，這句話能很好地反應當前大多數程序員投簡歷找工做的現狀。

​

目前很多比較初級的候選人根本是經過廣發簡歷以求獲得面試乃至跳槽的機會，卻不知這種不清楚面試關鍵點和不分析公司具體招聘需求的作法不只會下降找到好工做的效率，更會讓你們和一些心儀的公司失之交臂，從而只能「湊合」地進入一個能知足本身工資要求的通常公司。

簡歷的做用在於向招聘方展現你和這個崗位的匹配度，從而去爭取面試機會，僅此而已。不過我見過很多候選人的簡歷很是花哨，篇幅也比較長，但在其中卻很難看出他能勝任這個崗位。要知道，招聘方只能從簡歷開始瞭解到候選人的信息，因此簡歷不用面面俱到，簡明扼要地列出應聘方關心的要點便可；也不用想方設法地在格式上費腦筋，能讓招聘方感到一目瞭然便可。

1 簡歷中應包含的要素，一個都別落下

在篩選簡歷時，招聘方每每須要從大量的簡歷中找到值得面試的（這個比例起碼是 5 比 1），因此停留在每份簡歷上的時間不會很長。

因此你們在準備簡歷應當注意「直接」兩字：能讓篩選人能直接地看出本人的教育背景、工做經歷和項目經理，並讓他們「直接」感到這份簡歷能歸入考慮範圍。

根據這個原則，你們能夠按次序在簡歷中列出以下表所給出的要素。

2 該如何描述公司的工做狀況

這部分通常是按時間倒敘描述，好比能夠按以下的格式寫：

2015 年11月到 2017 年 10 月，在 xx 公司，職務是 Java高級開發。離職理由是想進一步發展。

2012 年 2 月到 2015 年 11 月，在 xx 公司，職務是 Java初級開發。離職理由是想進一步發展。

這部分的內容應當儘可能靠前，在羅列公司狀況時，請你們注意以下的四個要點：

第一，工做狀況能夠和項目經驗分開寫，通常會在後繼的項目經驗裏寫具體用到的技術框架以及所作過項目的細節，在這裏的工做狀況描述裏，能夠不用過於複雜，讓招聘方看到你以前的公司狀況便可。

第二，儘可能別出現長時間的「空白期」，好比上份工做是 2 月份結束的，而下份工做是 6 月開始的。若是出現持續三個月以上的「不在職狀態」，須要在簡歷中說明狀況，好比這段時間你是換城市發展了，或辭職複習考研或複習考公務員，總之得找個能說得過去的理由。

第三，在簡歷上，儘可能別讓人感受你每份工做都作不長，但不能以此做假。好比我見過有候選人會合並公司，好比2016 年 11 月到 2017 年 3 月在 A 公司，2017 年 4 月到 10 月在 B 公司，他爲了避免讓招聘方感受他換工做太頻繁，在簡歷上就寫 2016 年 11 月到 2017 年 10 月在 B 公司工做，而故意合併了 A 公司的經歷。這樣的話，若是遇到背景調查，會露餡，即便有些公司不作調查，在勞動手冊等材料上也能反應出真實的工做狀況，因此這種作法有必定的風險性。

這裏推薦的作法是，不要合併公司，但能夠寫明理由，好比:

當時小王是被外派公司 A 以人力派遣的形式外派到 B 公司，但沒過多久 A 公司因某種緣由再也不具有人力派遣的資質了，這時小王就不得不終止與 A 公司的合同轉而和 B 公司簽約。

這樣雖然看上去小王是換了公司，但實際上沒有。經過相似的合理解釋，招聘方就再也不會質疑小王的工做能力和穩定性了。

第四，能夠寫上合適的離職理由，尤爲當你短期裏換工做比較多，可能引發招聘方的質疑的狀況裏，更該考慮些合適的理由。合理的離職理由能夠是，想爲本身提供一個更大的發展空間，或想經過升級來獨當一面，以此進一步提高本身的能力，或公司因資金等方面的緣由倒閉了。總之，這不是我主觀上不穩定，而是因爲客觀緣由致使我不得不換工做。而可能會致使沒面試機會的離職緣由是，待遇問題（雖然你們心知肚明，但不能這樣寫），或沒法承受大壓力，或同事領導排擠。這類理由每每會暴露出候選人的缺點，因此不建議你們採用。從這意義上來說，「合同期滿」也不是一個好的離職緣由，由於若是候選人能力強，那麼爲何原公司不和你續約呢？

總之，在描述公司狀況時，一旦出現會讓招聘方感受你能力不強或不穩定時，必定得醒目地寫上足以信服的理由，這樣你的簡歷纔會有機會被繼續被讀下去，進而你纔會有技術面試的機會。

3 描述項目經驗的技巧

以前已經提到過，招聘方很是注重候選人簡歷上相關技術項目經驗，由於這至少能有效地證實候選人實踐過相關技術，而不是隻具備理論知識。

具體而言，招聘方首先會看候選人最近半年的項目裏用的是不是和本崗位相關的技術或框架，若是是，那麼說明候選人能在入職後能直接上手幹活。其次，會看候選人全部項目經歷中和本崗位所用技能（或框架）一致時間年限，通常招聘方會對這個年限有個最低的標磚，固然越長越好。

若是你們本身感受項目經歷明明很匹配但最終卻連面試的機會都沒，那麼問題大多就出在這個環節，下面咱們來具體分析下描述項目經驗的技巧。

3.1 儘可能把學習培訓項目和畢業設計項目往商業項目上靠

商業項目是指能掙錢的項目，和它對應的就是些不以掙錢爲目的的學習項目或畢業設計項目。正由於客戶付了錢，因此商業項目的要求要遠遠高於學習或畢業設計項目，這也是爲何招聘公司會看重商業項目而會主動過濾學習項目的緣由。

職位描述上的相關技能年限通常只是指商業項目經驗，而通常不會包括學習項目經驗。因此對於一些介於商業項目和學習項目之間的項目，儘可能當成商業項目來寫。

好比小張在大三時幫計算機系的王老師所在的 ABC 軟件公司幹了半年的活，若是小張在簡歷上寫：

在校期間，從 x 年 x 月到 x 年 x 月完成了 xx 系統，用到了xx技術。

那麼這多半會被當成相似於課程設計的學習經驗，但若是再加上以下關鍵性的描述：

這個系統是屬於xx公司的xx商業項目裏的一部分，我和另外三位開發人員作了半年，最終這個系統成功上線並在客戶 xx 公司的環境裏投入運營。

那這樣小張的商業項目總年限裏就能加上這半年時間了。又如小李在作畢業設計時，花了 7 個月的時間參與了導師的一個電商商業項目，他主要的工做是設計一個調度算法，但也參與了一些諸如訂單管理模塊的工做。若是他就平淡地寫一句：畢業設計是 xx，畢業論文是xx，那麼招聘方看過就算了，也不會認爲小李在作畢業設計時還有過商業項目經驗，這樣小李未免有些吃虧。

但若是這樣寫：

在 x 年 x 月到 x 年 x 月的 7 個月裏，在畢業設計中，我參與了 xx 公司的xx電商項目，客戶方是 x，我參與了訂單管理和 xx 模塊，並設計了其中的調度算法，在個人畢業論文裏，詳細介紹了這種作法。

文字沒修改太多，但足以讓小李增長 7 個月的商業項目經驗。

在招聘過程當中，咱們常常會看到有些候選人蔘加了培訓學校，在裏面也作了一些實訓項目。若是這些項目是用來讓學生練手的，而沒有產生商業價值，那麼雖然這些項目可能來自真實項目，名字也叫 xx 實訓項目，但很是惋惜，咱們無法把它當成商業項目。不過咱們看到過一份印象比較深入的簡歷，某候選人小丁在某三個月的時間內，一邊參加培訓，一邊還在朋友的公司裏兼職作着 xx 信息管理系統的項目。那麼若是小丁能很好地在簡歷中很好地說明這個狀況，並且還能在面試中很好地回答相應的問題，那麼咱們不得不相信小丁在這個三個月裏確實作的是商業項目。

對於高級程序員而言，他們的項目年限通常會超過 3 年，因此多挖掘出來的商業項目年限就屬於錦上添花了。不過很多公司在招聘時每每會設個最低年限標準（通常是 1 年半到兩年），這對剛畢業的或工做經驗小於 2 年的初級程序員而言無疑是道坎，因此若是你們處於這青黃不接的時間段裏，就更得挖掘這些「嚴格意義上還算商業項目」的項目經歷並寫到簡歷中，這至少能幫你們爭取到更多的技術面試機會。

不只如此，咱們發現大多數初級程序員的水平其實也差很少，這時就得看誰的商業項目經驗豐富了。好比有次咱們沒法從兩位候選人中權衡，由於他們的綜合條件和麪試狀況都差很少，但其中有一位在大三階段有段爲期 6 個月的商業項目實習經驗，另外一位沒有（也有可能他也有但沒當成商業項目來寫），這種狀況下咱們就錄用了有實習經驗的候選人了。

3.2 經過具體案例來看項目經驗該怎麼描述

​ 假設某公司須要招一個Java高級開發，以下是職位描述。

一、計算機及相關專業畢業，3 年以上 Java Web 項目開發經驗；熟悉 Linux 平臺。

二、精通 JAVA 編程，熟悉 Spring、Spring MVC、Mybatis/Hibernate等開源框架，熟悉經常使用 cache 機制, Jsp/Servlet 等技術。

三、熟悉 Tomcat、Nginx 等應用服務器的配置和優化。

4、熟悉數據結構和算法，熟悉 Java 多線程開發。熟悉 MySQL、Redis，熟悉數據庫索引。

5、瞭解 Web 前端技術，包括 HTML5/CSS/Javascript等。

六、擁有良好的溝通能力和文檔能力。

7、勤奮而善於思考，願意不斷挑戰和提高本身。

這裏先說個技巧，若是候選人能經過簡歷讓招聘方確信，在最近的項目裏他用到了很多和招聘崗位相關的技術，那麼他獲得面試機會的可能性就會大大提高，由於招聘公司會認爲候選人能入職後很快上手，而不會有太長的熟悉期。因此，咱們能夠按以下思路改寫最近作的一個項目。

那麼咱們就能夠根據職位需求，從以下幾個方面來描述項目經驗。

第一，簡要描述項目的背景，好比時間範圍，客戶是誰，項目規模有多大。

從x年x月到如今（這個時間範圍至少是最近半年），我參與某外匯交易系統，客戶是xx銀行，這個項目組的構成是，1位項目經理外加10位開發，總共的規模大概在80我的月左右。

第二，大體描述項目的需求和包含哪些模塊，而後簡要說下你作了哪些模塊，同時說下在這個項目用到的開發工具和主要技術點，這部分的描述以下所述。

這個外匯交易系統包括掛盤撮合成交、實盤成交、反洗錢和數據批處理等模塊，我主要負責了掛盤撮合成交模塊，其中用到了 Spring MVC架構，數據庫是 Oracle，用 Mybatis 實現的 ORM，該系統是運行發佈在Weblogic 服務器上，咱們還用了 Nginx 來實現負載均衡，用 Redis 來緩存數據。在這個項目裏，我還用到了JS 實現了一些前臺頁面。

這裏請你們注意以下的要點。

​ 1. 招聘方在看簡歷時，更關注的是用的技術，因此這裏無需過分展開該項目裏的業務細節，好比無需用大篇幅來寫掛盤撮合成交模塊裏幹了什麼事情。

​ 2. 若是在這個項目裏用到了職位介紹裏給出的技術，應儘可能寫在項目描述裏，但也要不能不顧事實地一股腦全寫上。

第三，這裏能夠在剛纔的基礎上展開寫這些技術在項目裏是如何用的，以此來進一步證實你和所應聘職務的匹配度。一樣這裏也應圍繞技術，而別多寫業務細節，你們能夠參考以下的範例。

具體而言，在這項目的掛盤撮合成交模塊裏，咱們用到 Spring MVC 框架，用到了其中的攔截器來攔截非法的掛盤訂單請求，在數據庫層面，咱們還把一些經常使用數據放入 Redis 裏，在 Redis 裏咱們用到了 list 和 set 這兩種數據類型，並且還用到了 master-slave 模式。在使用 Nginx 時，咱們是經過配置來避免出現 Session 粘滯的問題。

若是你們只寫用到過 Spring MVC 和 Nginx，那麼篩選簡歷的人看一眼就過了，最多認爲你們用過。但若是你們再寫一些只有用過才能知道的細節點，好比 Nginx 的 master-slave 模式，那麼就會給招聘方留下比較深入的印象，你們給他們的感受就會是不只用過，並且熟悉（或精通）。

3.3 這些亮點你大多作過，不加在簡歷中有些惋惜

咱們見過很多簡歷，在描述項目時，也能像上文同樣，能根據招聘職位的具體要求展現出本身的匹配點，這種簡歷屬於「達標」，便可以歸入考慮範圍。在這個基礎上，若是你們在項目裏有下表列出的亮點，必定請寫上，這就是你們優於別人的地方。

JVM 調優方面

設計模式方面

數據庫調優方面

• 好比說在項目裏用過批處理預處理事務等高級知識點；

• 能經過監控查看哪些 SQL 語句須要調優；

• 能經過索引執行計劃等方式對 SQL 語句進行優化；

• 進一步的話，能經過數據庫集羣等方式分散對單個數據庫的壓力；

• 若是作過，也能夠寫一些關於 NoSQL 和大數據方面的經驗；

SpringMVC 架構方面

• 用過其中諸如攔截器、AOP和事務等高級技能點；
• 在搭建框架時，能一塊兒參與並熟悉如何經過框架來提高代碼的可維護性；

學習和解決問題的能力很強

好比能夠寫，在項目裏，本身被分擔一塊你們都不大熟悉的技能，但你在短期裏就完成了技術調研並把它用到項目裏。

能承擔大的工做壓力

• 因爲客戶方催進度的緣由，這個項目須要加班（總之加班緣由不是你形成的）；
• 在這種狀況下，你能和你的團隊一塊兒連續奮鬥，最終成功地完成進度；

上述的一些技能要求未必會出如今職位描述裏，但確實都屬於亮點，並且在你們的項目裏，多少會用到些，因此不加有些惋惜。固然，若是你們有其它的亮點，也能夠加上，畢竟這能提高你們簡歷的價值。

3.4 多寫些和項目管理相關的技能

咱們見過很多簡歷，在其中更偏重技術或諸如溝通和協做方面的能力，但事實上，項目管理方面的技能一樣重要。這裏可能會有個誤區，很多人認爲初級程序員的簡歷無需寫項目經驗，但事實上，項目管理技能也是靠積累的，哪怕剛工做1個月，也能積累這方面的能力。

在這方面，項目經理更偏重於如何根據項目需求合理地分配任務和協調進度，對於程序員而言，則能夠在簡歷中寫項目管理的方式以及如何使用常見的管理軟件來提高項目管理的效率。

這裏咱們就以敏捷開發爲例，向你們展現下如何介紹本身項目管理的方式。

咱們這個項目採用了敏捷開發的模式，具體而言，咱們會根據項目整體需求，設置若干個發佈點，在時間上，每隔1個月就會設置一個。根據任務的優先級，咱們先會大體定下每一個發佈時間範圍內的大體任務，而在每一個發佈時間範圍內，會根據當前狀況適當微調。

並且，咱們項目組還引入了「天天站立會議（ Stand up Meeting ）「的形式，天天咱們項目組會用大體20分鐘的時間一塊兒討論下每人已經完成的任務、要作的任務和遇到的問題，這樣即便遇到阻礙性的問題，也不會耽擱整個項目好久的時間。

相關的內容無需多，你們只需列些敏捷開發的必作點，以此來證實本身實踐過這種開發方式便可。若是招聘公司也是採用相似的項目管理方式，那麼這點必定是個很好的加分項，即便招聘公司採用其它方式，好比瀑布模型，那麼你寫上這話，招聘方的評價就不會僅僅是「熟悉項目開發的技術」，並且仍是「瞭解並實踐過XX項目管理方式，對項目管理有必定的瞭解」，這樣這份簡歷得到面試機會的可能性就大大增長了。若是你們在項目裏用到的不是敏捷管理模式，而是其它的管理方式，也能夠照着這個思路寫。

此外，正規的項目多少或用些項目管理的工具，你們也能夠在簡歷中列一些本身用過的，以此來進一步證實項目管理方面的經驗。在下表裏，咱們總結了一些常見的開發人員能用得上的項目管理工具。

Junit (單元測試)

開發人員在開發完成後，能夠用 Junit 來編寫本身代碼的單元測試代碼，運行單元測試代碼後，能測試本身開發的模塊

Maven （構建項目）

經過 Maven，咱們能給項目引入必備的 jar 文件，也能方便地編譯(build)和發佈項目代碼。

Jenkins（持續集成工具）

咱們通常會用重複的工做來發布不一樣版本的項目，好比運行 ant 腳本，把生成的 jar 放入指定的 Linux 目錄並設置一些 script 文件的可運行權限。咱們能夠經過設置 Jenkins 腳原本配置這些重複的工做。

Jira（缺陷或任務管理）

每當遇到一個Bug或一個新任務，咱們能夠建一個 Jira，此時該 Jira狀態是 Open，程序員開始開發時，會設置成 In Progress，完成開發後能設置成 In QA，這樣測試人員就能介入測試，測試完成後，測試人員能把它設置成 In UAT，一旦把該任務部署到生產環境，就能 Close 這個 Jira。也就是說，經過 Jira，咱們能在項目裏很好地跟蹤和監控具體問題和任務的當前狀態。

Git（版本管理）

經過 Git 或 SVN 等版本管理工具，在項目裏咱們能方便地創建提交或回退各人的修改，還能分支版本。Git 還有個好處：能夠設置成「評審後才能提交」的模式，這樣某人要往主版本提交的代碼必需要通過一人或多人的評審，這樣就能很好地控制代碼的質量。

Sonar（代碼質量管理）

經過 Sonar，咱們不只能檢查代碼是否還有 bug，還能查看代碼的質量，好比代碼的註釋率是多少，單元測試覆蓋率是多少。Sonar 還能給出一些代碼方面的建議。總之，經過 Sonar，咱們能提高代碼質量。

具體而言，你們能夠在簡歷加上以下的內容：

在這個銀行（或其它）項目裏，咱們用 Maven 來管理項目，用 Git 作版本管理，用 Junit 來作單元測試，用Jira 來作 bug 管理，在代碼上線前，咱們還會用 Sonar 來掃描代碼，若是發現一些可改進點，好比 Junit 覆蓋率不高，咱們會及時改正。

你們在簡歷中寫這部分的內容時請注意以下的兩個要點：

​ 1. 在項目管理方面通常都會用到些工具，也就是說，你們能夠寫上在本身項目裏用到的工具以及這些工具應用在哪些方面，但別什麼都不寫。

​ 2. 面試官在看到相關描述後，通常會在面試中詢問些細節，好比 Jenkins 的配置方式等，也就是說，你們不只要寫，還得適當地瞭解下這些工具的使用細節，以備面試時的提問。

4 投送簡歷時的注意要點

簡歷準備得再好，若是用不恰當的方式投遞出去，一樣沒法獲得面試機會，因此你們在發送簡歷時，應當注意以下的要點。

4.1 不要發送「萬能「簡歷，根據具體的職位要求進行微調

這多是很多求職者的 「通病」，他們每每就準備一份簡歷，而後看到一個合適的工做機會就發一份，也不關注這個公司的行業背景，也不看這個職位的具體要求。

其實你們的簡歷是 「閉門造車」 的形式寫出來的，只能 「儘量」 地描述本身掌握的技能（沒法徹底描述出你項目裏用到的全部技能要點），而每一個公司的職務要求必定不會徹底相同，因此你們在發送簡歷前必定得根據具體的職位需求改寫相關的項目經驗描述，以求達到 「匹配度」 最高的效果。

相反，若是你們針對不一樣的公司發的是同一份簡歷，那麼就得撞大運了，這樣必定會失去很多「匹配度不高「的面試機會，其實修改簡歷所用的時間不會太多，但效果必定是大相庭徑。

4.2 在招聘會上，儘可能要口頭說出你和這個職位的匹配點

在招聘會上，你們只能是發送同一份簡歷，在這種狀況下，你們必定得儘量地和招聘方交流幾句，同坦誠的措辭，口頭說下你和這個職位的匹配度，同時讓招聘方感覺到你熱切想獲得這份工做，這樣比「遞交簡歷無其它互動「的效果要好不少，至少能給招聘方留下些許印象。

4.3 簡歷以正文形式發送，別讓招聘方覺出敷衍

在不少場合下，你們是經過郵件的方式發送簡歷，在這種方式下，因爲只是經過文字，沒法面對面直接交流，因此你們應當儘可能讓招聘方感覺到本身求職的誠意，至少別讓他們感受出「敷衍」。

這裏來舉些可能會讓招聘方感覺到「敷衍」的例子。

例子 1

從郵件的標題和稱謂上，看不出這份郵件是給本公司專門定製的。好比咱們常常會收到這樣的簡歷，標題是「應聘xx崗位」，開頭是，尊敬的先生*/**女士，*在其中第一沒有公司的稱謂，第二咱們已經在招聘要求裏寫了負責收簡歷的是人事王先生，但這裏沒有具體的稱謂，這就會讓咱們感受這份郵件是通用的，而不是專門發給咱們公司的。

恰當的作法是，在郵件標題裏寫上具體的公司名，好比 應聘 xx 公司的xx崗位，在開頭上寫，xx公司，尊敬的人事王先生，這裏若是沒有留收簡歷人的稱謂就寫 尊敬的人事，這樣就會讓人感到候選人在這份郵件至少是下過功夫的。

例子 2

從郵件列表裏，咱們能看出候選人是羣發郵件，把同一份簡歷發給不一樣的公司。這種狀況很少，但有，恰當的作法是，在一封郵件裏，只給一個公司發送求職信息。

例子 3

有些候選人在郵件裏，直接用附件的形式發簡歷，而沒有任何正文的內容。這就沒法讓招聘方感受到候選人的誠意了。

比較恰當的作法是，候選人還應當在郵件裏寫上以下樣式的求職信。

xx 公司，尊敬的人事張先生：

我在 xx 招聘網站上看到您這邊的招聘 Java 高級開發的信息，特來應聘。

我叫 xxx，今年 xx 歲，xx 大學 xx 系畢業，本科學歷，手機是 xx。

我有 x 年 java 經驗，用過 Spring MVC 等技術（根據職位描述列出用到過的其它 Java 技術），數據庫方面，我用過 xx，也有過調優經驗（數據庫方面的經驗也請和職位描述一致）。再根據職位描述寫一些本身和這個崗位相匹配的技術。

我很是願意加入貴公司從事Java高級開發的工做，個人詳細狀況請看個人簡歷，若是能夠，我很是願意向您這邊提供更多的我的信息。

最後列上署名

由於有些公司的郵箱出於安全因素，會過濾附件，因此仍是建議你們以附件形式發簡歷的同時，在正文裏也加上簡歷的內容。

總結

很天然地，對於絕大數的人，人們都會想去擺脫單調乏味，找到好的工做，也就是被僱傭去作有趣、有挑戰性、有回報的工做。正由於此，取而代之的是，咱們要花點時間把本身培養成最好的候選人，而後花點時間確保你的簡歷能表明你和你的技能，作最好的工做。

---

本文首發於微信公衆號 【程序猿雜貨鋪】，關注公衆號，獲取更多精彩文章！