算法細節，架構設計，職場成長，一個都不能少

六月七月，寫了十多篇緩存架構設計，彙總在《緩存架構，一篇足夠？》。

八月九月，寫了十多篇MySQL內核的底層細節，彙總在《關於MySQL內核，必定要知道的！》。

很多小夥伴留言，問能不能同時「併發」多個系列，因而，九月份以來就同時啓動了如下幾個系列。

1、本身職場經歷

目前寫了兩篇：
《技術類簡歷要怎麼寫》
《找工做的血淚史》
但願本身走出校園，走向職場的經驗，能給到你們一些啓示。

這個系列的下一篇，準備寫本身職業生涯前兩年在百度的感觸，早就構思好了，只是遲遲沒有動筆。

2、數據結構算法類

也就是標題爲「拜託，面試別再問我XXXX」的這一系列，目前這一系列反饋比較好。

TopK，數1，斐波拉契數列：
《拜託，面試別再問我TopK了！》
《拜託，面試別再問我數1了！》
《拜託，面試別再問我斐波那契數列了！》

算法時間複雜度，一篇搞定：
《拜託，面試別再問我時間複雜度了！》

時間複雜度爲O(n)的排序問題：
《拜託，面試別再問我基數排序了！》
《拜託，面試別再問我計數排序了！》
《拜託，面試別再問我桶排序了！》

後續爭取講透更多更有意思的算法，但願這些文章可以幫助你們在面試中勝出，拿到本身心儀的offer。

3、管理經驗

除了在8月份已完結的，「leader教個人那些事」系列，已彙總在《這些年，leader教個人那些事》。

10月份又重啓了一個系列，「新晉leader那些事」，目前只輸出了一篇：
《要是我來幹，早搞定了 | 新晉leader那些事》

這一個系列必定會體系化的寫下去，心想，追劇「架構師之路」3年的小夥伴，如今應該都至少是主管，經理了吧？

4、數據庫相關

只輸出了一篇，關於數據庫主從同步延時很長，MySQL的優化思路：
《MySQL主從延時這麼長，要怎麼優化？》

5、架構相關

架構類的文章，是「架構師之路」啓動的初心，沒想到最近一篇長文，閱讀量如此慘淡，考慮後續減小此類輸出：
《消除單點，一篇搞定 | 架構設計篇》
畫外音：莫非這類比較長的文章，不適合碎片時間閱讀？

6、分佈式相關

這個系列，是你們在評論中但願啓動的，目前聊了CAP，2PC，後置提交等幾個話題：
《分佈式基礎，通俗易懂CAP？》
《分佈式基礎，啥是兩階段提交？》
《分佈式事務，原來能夠這麼玩？》
可是，從閱讀量和轉發量上看，不是很理想。

固然，我也不會只從閱讀量和轉發量來選擇創做主題，只要以爲有價值的東西，就會繼續寫下去，大夥以爲呢？
畫外音：固然，閱讀和轉發會帶來更大的動力。

有位小夥伴留言「技術圈爲數很少值得置頂的公衆號」，十分感動，感謝。

只要你們有收穫，凌晨筆耕不輟的時光，就不是白費。調研：追劇「架構師之路」3年的小夥伴，如今至少是主管，經理了麼？