【offer收割機必備】我簡歷上的Java項目都好low，怎麼辦？

（1）高級工程師必備：系統設計能力

咱們通常在招聘高級及以上工程師的時候，必定會嚴格考察一項能力，系統設計能力。

由於若是你僅僅是對各類各樣的技術都熟悉，有技術廣度，也有必定的技術深度，其實是不夠的。若是你的系統設計能力不到位，可能致使你在開發系統的時候會亂用技術。

好比說，有的系統他有一些本身特殊的業務場景和技術挑戰，實際上在這個場景之下比較合適的是採用 「緩存 + 數據庫」 的技術方案來應對。

可是呢，有的工程師會不少技術，可是缺乏這種準確的分析系統問題，提出合理的技術方案的能力，也就是缺乏系統設計能力，致使他可能會引入Elasticsearch這種技術來嘗試解決這個問題。

那麼結果必然是失敗的。因此以前不少人找我問問題，說我在XX場景下，用了XX技術，可是沒有起到我想要的那個結果啊？

我幫他一看，這不是必然的麼，你的XX技術應該用在YY場景下，結果你用到XX場景下，確定是不行的。

這就是系統設計能力的重要性。

那麼落地到如今的互聯網行業的面試，你們應該會注意到，不少大廠都會愈來愈開始問一些系統設計類的問題，舉幾個例子來看看：

1

若是讓你設計一個秒殺系統，你會如何設計？

2

若是讓你來設計一個消息中間件，你會從哪些方面來考慮？核心的架構以及數據結構如何設計？

3

若是讓你來負責一個電商雙11大促系統，你會如何來考慮和設計？

4

咱們公司有這樣的一個業務場景，XXXX，我給你畫個圖，YYYY， 就根據這樣的一個場景以及面臨的問題。若是讓你來設計這個系統， 你會如何考慮？

其實若是你在面試的時候遇到上面的那些問題，就是典型的系統設計問題。

面試中的系統設計問題主要分爲兩類，一類是常規性的，好比秒殺系統的設計，另一類是那個公司本身的業務場景下的系統設計。

第一類系統設計問題其實很好快速突擊準備，你能夠到網上搜一搜互聯網公司常問的一些系統設計問題。

收集好一些典型問題以後，百度一些技術博客給出的技術架構設計的思路，將這些思路本身進行整理總結，而後轉化爲本身的語言，最後落地到紙上畫出架構圖。

到面試現場，你可以畫圖把這個系統設計思路說清楚，這個基本就OK了。

這個準備時間不長，突擊的話可能幾天時間也足夠了。

固然，仍是那句話，最好的結果，必然是你本身自己作過相似的一些有挑戰的系統。

此時你遇到這種系統設計問題，直接能夠很牛叉的說，這類系統我以前作過，而後把本身以前的項目經驗都現場畫圖給說出來。

第二類系統設計問題就不太好準備了，由於徹底考驗的是你實打實的系統設計能力，短期內針對一個業務場景和技術難點，可否迅速給出一個初步的架構設計和技術方案。

第二類系統設計問題，從長期積累和準備的角度，個人建議是在平時本身在開發系統的時候多思考，本身的這個系統有沒有什麼技術難題，針對這個技術難題應該用什麼什麼技術，什麼方案來解決，這就是潛移默化的在積累系統設計能力。

可是若是從臨時抱佛腳的角度，平時沒那樣的積累，遇到第二類靈活開放的系統設計問題，那也不能一問三不知，大眼瞪小眼。

所以，個人建議是：

對於你要面試的公司，儘量的多作了解。好比公司業務背景，大概用戶量，這些均可以瞭解一下。

若是目標公司有官方的社區或者官方公衆號，關注一下，看看上面的技術分享。

而後若是面試時，面試官針對他們公司的具體業務出了一個系統設計題目，你若是沒有思路，建議儘量的結合第一類的常規系統設計題目來思考套用。

舉個例子，好比你面試一個p2p金融業務的公司，若是被問到大量用戶同時搶標，如何設計架構？

你沒有作過，可是你能夠結合一些常規的系統設計題，好比秒殺系統的設計思路，套用在這個新的業務上。

而你若是在面試這家公司前，大體瞭解了其業務背景，那麼對你回答這類系統設計相關的題目，確定也是頗有幫助的。

（2）如何讓你的項目經驗更有技術含量

在解決了系統設計問題以後，任何一個公司，任何一個面試，都必定會涉及到你做爲一個工程師最最核心的價值和能力，就是你的經驗，具體來講就是你作過的項目。

這塊是面試準備時的重中之重，應該做爲最高優先級來對待。

有不少同窗，作的項目其實挺不錯，可是平時疏於總結，面試前也不許備，結果面試時支支吾吾，半天答不上來，白白浪費面試機會。

好比一個很是典型的項目經驗的面試考察情景以下：面試官反覆的追問項目的各個地方的技術實現細節，就想看看有沒有哪一個地方是有必定的技術難度的，能夠體現出這個候選人的一些項目上的亮點。

可是呢，候選人說來講去，老是從業務的角度去說，就說有哪些子系統組成，分別是幹什麼的，如何交互的，看來看去都是系統業務的東西，就是沒看到什麼有技術含量的東西在項目裏體現出來了。

若是出現上述的狀況，那麼這個候選人要拿大廠offer的機率就很低了。

由於你的項目裏沒看出來什麼東西，沒什麼亮眼的地方。你看起來就跟千千萬萬個普通的工程師沒任何區別。

並且，在薪水方面，你要價23k，可是另一我的要價是20k，還有一我的要價是18k。

在這種狀況下，你以爲你的offer好拿麼？咱們爲何不找一個更年輕，更有活力的，有衝勁的小夥子，他也作過跟你相似的一些沒太大技術含量的項目。

雖然你工做了5年，人家就工做了3年，可是從技術和項目兩塊考察，你跟他沒太大區別。你不過就是比他多工做了2年，多作了幾個沒技術含量的項目罷了。

可是在薪資要求方面，你可比人家多了5k，在這個時候，面試官在沒更好選擇的狀況下，必定會找那個薪資要求僅18k的小夥子。

這也是爲何不少同窗很差好準備出去面試，結果面半天，總是被人家說：你先回去等通知，咱們要再多面試幾個候選人綜合考察一下。到最後面試好屢次也拿不到幾個offer。

其實緣由很簡單，你沒什麼能打動面試官的亮點，沒什麼太突出的能力。而你的工做年限越長，薪資要求越高，就越是不容易拿到好公司的offer。

上面說的，是一個極端，這類同窗對本身作過的項目絕不重視，致使沒法在面試中復現項目中的各類技術細節、技術難點。

這樣，即便你的項目很牛，那又有何用，你當時作項目的時候，面試官又不在場。。。

然而，也有很多同窗，他們的項目其實並不高端，甚至是有點low。可是呢，人家憑藉本身精心的準備，加上一些面試技巧，巧妙的讓本身的項目脫胎換骨，瞬間變得高大上。

因此說，項目準備，百轉千回，這裏面有很多門道，接下來我們就來聊聊。

一樣，我們分爲兩條路線來談：一個是長期準備型；一個是短時間突擊，臨陣磨槍。

對於前者，我我的的建議，仍是像以前說過的同樣，平時你工做的時候，必定多給本身設立技術挑戰。總結起來一句話：沒有困難，製造困難也要上。

這裏面可能會存在對於架構的過分設計的問題，站在公司的層面會以爲花那麼多時間設計這些架構實在是無用功，可是從我的發展的角度，爲了你的職業生涯發展，你有時不得不過分設計一下。

何況，這個對公司也未必是一件壞事，萬一你公司之後規模發展起來了呢？這個誰又說的清楚。

舉個例子，你在公司目前是負責一個OA辦公系統，就內部幾十我的使用，主要就是寫寫業務，crud啥的，看起來很low的項目。

而後呢，你使用的技術就是簡單的SSM，可能連SpringBoot都沒上，整個項目就部署的一個單體工程，沒有微服務、沒有緩存、跟全部高併發高可用等技術徹底絕緣。

確實，幾十我的用，你何須殺雞焉用宰牛刀呢？

可是想象一下，若是你的公司是一個世界500強，這套OA系統有上萬人使用，那麼狀況確定就不一樣了，可能就須要另一套技術架構。你徹底能夠在工做中給本身作這樣的假設，設置這樣的難題。

固然，這只是筆者舉的一個例子，之因此用這個舉例，是想說明一下，不管你作的是什麼項目，你均可以從某種角度出發，給本身製造各類技術難題，而後解決難題。

你能夠在不要給工做量增添太多的狀況下，儘量從公司發展的角度去考慮，向領導闡述你的考慮，這樣公司將來發展5~10年，這套架構都夠用了。

而且在面試時，你在闡述項目經驗的時候，可讓面試官看到你在裏面有更多的技術架構的設計，考慮到了解決更多的技術問題，那麼天然你的面試表現就會更好，就更加容易會拿到更好的offer了。

上述就是所說的第一點，長期狀況下應該如何積累本身的項目面試經驗。

接下來講說第二點，項目的短時間突擊應該如何進行，才能儘量的讓咱們的項目顯得更加吸引人。我估計可能更多的同窗須要這方面的技巧。

可是筆者仍是事先強調，這種短時間突擊、臨陣磨槍，效果確定是比不上長期的一步步穩紮穩打，這只是一種應對面試的退而求其次之選。

若是你們有時間，或者說經過這種短時間突擊的打法拿到了心儀的offer，仍是應該沉下心來，一步步積累，技術的東西，來不得半點馬虎。

若是你以前由於種種緣由，在面試前沒有作過多的長期積累，那麼短時間的狀況下，應該如何臨陣磨槍呢？

我這裏的建議是，你本身至少應該反覆思考，你目前負責的系統應該引入什麼樣的技術架構，採用何種技術方案，才能抗住各類衝擊。

突擊準備，你確定沒有大把時間來付諸實踐，可是你必定要本身思考，同時百度一下國內大型互聯網公司的技術架構，他們使用了哪些高大上的技術，對於某個技術難點採用了什麼技術方案。

而後在面試的時候，能夠對面試官闡述一下你對這個項目一些問題的思考，以及技術方案、架構如何來設計，這樣設計能夠解決什麼技術問題，有沒有更好的方案選擇。

這樣一來，你起碼比普通工程師多一些思考，提出更多的方案，這也能成爲你更加亮眼的地方。

仍是那句話，作，總比不作強。你對本身的項目思考了不少的技術方案，這樣和麪試官總還有一些技術上的交流和探討的東西。你的項目也不至於說充滿了各類CRUD，毫無亮點可言。

做者：Java填坑之路 連接：https://www.jianshu.com/p/6f4b48e6a37c 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。