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

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

如果沒法通過技術面試,那麼候選人尚且能收集面試題,回家繼續準備,畢竟他和面試官也交流過,也不算沒收穫,但對於這些沒法通過篩選的簡歷,簡歷的主人往往是無從得知的(公司不會主動通知),所以他們依然會混混沌沌,可以預想,在不短的未來,他們依然無法得到面試機會。

img

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

img

目前不少比較初級的候選人根本是通過廣發簡歷以求得到面試乃至跳槽的機會,殊不知這種不清楚面試關鍵點和不分析公司具體招聘需求的做法不僅會降低找到好工作的效率,更會讓大家和一些心儀的公司失之交臂,從而只能“湊合”地進入一個能滿足自己工資要求的一般公司。

簡歷的作用在於向招聘方展示你和這個崗位的匹配度,從而去爭取面試機會,僅此而已。不過我見過不少候選人的簡歷非常花哨,篇幅也比較長,但在其中卻很難看出他能勝任這個崗位。要知道,招聘方只能從簡歷開始瞭解到候選人的信息,所以簡歷不用面面俱到,簡明扼要地列出應聘方關心的要點即可;也不用千方百計地在格式上費腦筋,能讓招聘方感到一目瞭然即可。

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高級開發,如下是職位描述。

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

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

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

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

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

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

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高級開發的工作,我的詳細情況請看我的簡歷,如果可以,我非常願意向您這邊提供更多的個人信息。

最後列上署名

因爲有些公司的郵箱出於安全因素,會過濾附件,所以還是建議大家以附件形式發簡歷的同時,在正文裏也加上簡歷的內容。

總結

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


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

歡迎關注我的公衆號

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章