做爲一個程序員,想必你們曾經都作過一些項目,可能如今手頭上也還有一些項目。
不過仍是有不少學生朋友來問我「沒有項目怎麼辦」,誠然,確實有很多同窗沒有實習經歷,又沒有什麼像樣的項目經歷,對於這樣的同窗,簡歷上的項目經歷難道只能空着了嗎。
其實否則,就算你是跟着一些課程作項目,你也能夠經過豐富項目內容的方法把項目變成本身的,只要你真的去作了,真的理解了代碼邏輯,同時有所收穫,這個項目就是有價值的,是能夠登上簡歷這一大雅之堂的。
正由於如此,如今不少簡歷上的項目經歷的質量都是良莠不齊,同時有的項目經歷又很是類似,面試官一眼就能知道你的項目究竟是真是假。
大部分的面試官都會對你的項目經歷進行提問,你能不能清晰到位地描述號好你的項目經歷,決定了你的項目價值,即便項目再牛掰,你不能把它講清楚,那麼也是白搭。
因此,回答關於項目方面的問題,是有技巧可循的,比技巧更重要的是 3 條原則,這也是我經歷各類面試以後總結出來的東西。
項目經歷,貴在真實,簡歷造假什麼的真的不要想了,面試官稍微深刻問一下簡歷上的東西,保證你會一臉懵逼,簡歷上那些高大上的技術到頭來反而成爲你被面試官抓住的把柄。
何謂真實,首先,你要真的作過這些項目,其次,對項目的描述要真實,能夠適度修飾,但不要太過誇大。
項目是真實的,你本身內心纔會有底,面試官問的有問題,你纔有把握可以回答。退一萬步講,就算你真的騙過了面試官,那你也諞不了你本身,簡歷造假若是在往後被發現,那處罰也是至關嚴重滴。
不少朋友都犯過一個錯誤,包括我,就是把喜歡把項目經歷寫的天花亂墜,好比把整個系統的開發工做都寫在簡歷上,把部門的技術棧搬到簡歷上,把那些你沒參與的工做都寫到了簡歷上。
其實這只是看起來很美好而已,當面試官問你比較不熟悉的模塊時,你就只能說這個不是你作的,那個也不是你作的,這就十分尷尬了,在面試官那裏必定也是大大扣分的。
在吃了幾回這樣的虧以後,我簡歷上的項目經歷再也沒有出現和我無關的內容了,面試官問到實現細節我也可以應對自如,畢竟本身作過,內心確定清楚呀。
因此,與其期望着拿別人作得模塊來渾水摸魚,不如想一想如何提煉一下你的項目內容吧,就算真的只是簡單的CRUD,也沒有關係,所謂「亮點自尋」,這個時候你就應該想辦法把項目裏的亮點找出來。
好比你用了哪一個ORM框架來實現數據庫交互,爲何用Mybatis而不用Hibernate,或者是用了哪一個Web框架、日誌系統、構建工具,又或者用了什麼數據庫、緩存,爲何要用這些技術。
除此以外,你也能夠介紹一下本身如何優化模塊的性能,複雜的業務邏輯又是如何實現的。
這一點與其說是原則,不如說是技巧。把「分點敘述」翻譯成白話文就是「一個模塊用一段話來介紹,若是你作了 3 個模塊,那麼就分一、二、3點,分別用一句話來介紹所作的內容」
這裏補充一下,你能夠在分點描述裏說起技術棧,或者是在項目總結的部分介紹相關技術棧。
好比:一、我負責部門數據運營報表模塊的開發工做,使用JUC併發工具、線程池等技術完成該模塊的業務邏輯開發,使用MySQL數據庫、Hibernate框架完成數據層的處理,同時我對該模塊的業務代碼進行了優化,提高了數據報表30%的響應速度。
爲何要分點敘述,其實就是讓你的項目條理更清楚,面試官很容易就能看出你作了哪幾個模塊,能夠對應地進行提問。
之前我沒有分點描述項目,結果面試官只能從一大段話中提取一些關鍵字來提問,這可能讓面試官很不滿意。
不僅是項目經歷裏的模塊須要分點描述,你本身在介紹本身的項目時也應該經過這種方式來完成,這樣的好處顯而易見。
你很快就可以條理清晰地向每個面試官介紹本身的項目,而且針對每個模塊均可以很天然說出它們的難點、亮點,以及實現過程。
不要問我爲何知道的,當我面試的次數愈來愈多時,我已經習慣了介紹項目、回答項目問題了。因此每次遇到關於項目的問題基本上都是張口就來,面試官一問什麼我就知道要答什麼了。
雖然以上三點原則不能包治百病,可是對不少同窗來講應該是蠻有益處的。
文能寫做,武能Coding。是我黃小斜,不是黃老邪