最近部門招聘，很多工程師，包括我在內都參與了內推和麵試的過程，經過這次招聘，我發現能夠最終拿到offer的人，基本上在看到簡歷的那一瞬間就已經定下來了，後續的面試只不過是一種驗證而已（注意，是驗證，而不是走過場），除非你面試過程中犯錯誤，或者你不想來，否則，那個offer一定是可以拿下的。

那些拿下offer的人，基本上都有這麼一些特徵

1. 學校不錯，一般都是985，211，如果學校一般，那麼你下面的2和3滿足的話，問題也不大。

2. 之前三年工作經驗，都是在業內有些名氣的企業，比如百度，IBM，騰訊，思科等等。國內的軟體企業的工作經驗往往認可度不高，甚至遠遠不如一些拿到了風投的創業企業的認可度高。當然，如果一家號稱在創業的企業，卻沒有任何人投資，基本上也不要想得到認可了。

3. 職位級別，基本上都達到了高階工程師/高階測試工程師, Senior xxx Engineer的級別

4. 之前工作經驗和當前職位要求都匹配，比如崗位要求Java的，候選人之前也是用Java的，崗位是iOS/Android的，候選人之前也是幹這個的

但是，滿足前面4點，三年經驗也只能保證你能有P6的評級，不一定能保證P7的評級，那麼，如何才能評到P7呢？以筆者觀察到的案例，是否P7一條最關鍵的就是你是否業內有知名度。

之所以提到知名度，源於筆者認為，這一條對於候選人來說最容易提升，否則，你和現有的阿里的工程師去拼JVM實現，MySQL優化，毫無優勢，面試官有什麼理由給你那麼高評級呢。

那麼，如果我要拿P8呢？筆者鄭重的提示讀者，如果你親自拜讀了這篇博文，並且覺得收穫匪淺，那麼你肯定還沒達到P8的要求，因為筆者所見的P8，在業界知名度，綜合能力方面，都已經超越了我言語所能描述的地步，我這篇文章，對於他們來說，一點價值都沒有。這種修養，絕對不是三到五年就能薰陶出來的。

再看看p8到底是個什麼樣的存在

知道了P8是個什麼樣的存在了

那回過頭來 先弄清P7需要哪些具體的知識，我自己總結幾張體系圖；

01

閱讀原始碼

程式設計師每天都和程式碼打交道。經過數年的基礎教育和職業培訓，大部分程式設計師都會「寫」程式碼，或者至少會抄程式碼和改程式碼。但是，會讀程式碼的並不在多數，會讀程式碼又真正讀懂一些大專案的原始碼的，少之又少。這也造成了很多錯誤看原始碼的方式。

那要如何正確的分析原始碼呢？

我們的目標應該放在最常用的框架上面，下面就介紹兩個：一個是Spring，另一個是大家用來覺得一直不怎麼出問題的Mybatis。

spring原始碼

mybatis原始碼

02

分散式架構

隨著我們的業務量越來越大和越重要，單體的架構模式已經無法對應大規模的應用場景，而且系統中決不能存在單點故障導致整體不可用，所以只有垂直或是水平拆分業務系統，使其形成一個分散式的架構，利用分散式架構來冗餘系統消除單點的故障，從而提高整個系統的可用性。同時分散式系統的模組重用度更高，速度更快，擴充套件性更高是大型的專案必不可少的環節。

03

微服務

關於微服務架構的取捨

在合適的專案，合適的團隊，採用微服務架構收益會大於成本。微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。需要避免為了“微服務”而“微服務”。微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

04

效能調優

我們不僅僅對專案要運籌帷幄，還要能解決一切效能問題。只有深入學習JVM底層原理，Mysql底層優化以及Tomcat調優，才能達到知其然，知其所以然的效果。除了效能優化之外，也能提供通用的常見思路以及方案選型的考慮點，幫助大家培養在方案選型時的意識、思維以及做各種權衡的能力。

05

開發工具工程化

通過一小段描述資訊來管理專案的構建，報告和文件的軟體專案管理工具。程式設計師的戰鬥，往往不是一個人的戰鬥，我們如何在一個平臺下高效的去重，進行程式碼review，對功能進行調整，debug，做到在統一的規劃下步步為營，混亂的堆程式碼的過程中找到自己的記錄。這一切都依賴於有效的工具。

06

專案實戰

要想立足於網際網路公司，且能在網際網路浪潮中不被淹沒，對於專案的開發實戰演練是不必可少的技能，也是對自身能力的一個衡量，有多少的量對等於獲得多少的回報。看似簡單的一個專案需求圖譜，其中的底層原理，實現原理又能知道多少？你搭建一個完整的B2C專案平臺到底需要多少知識？這一切都是需要我們考量的。