面試時的交談

工作之后你做過這樣的事情嗎？

面試是一個誰主張誰舉證的過程，有時候需要面試者舉出實例，自我證明。

而我認為問一些我們工作中遇到的難題和業務場景是在“欺負”面試者，所以我喜歡問開放型問題：

在你工作之后，你有沒有像做畢業論文一樣對某一個 Topic 做過深入研究？如果有，請舉例，說得越詳細越好。

為什么要問這個問題？

因為我和面試者之間經常會發生這樣的對話：

我：平常看什么技術網站？

Ta：某某技術新聞站，某某博客網，某某微信公眾號……

我：最近有什么覺得不錯的文章，印象比較深，能給我講講嗎？

Ta：……

我：#￥^&#講個標題也行。

Ta：想不起來。

我（汗）：那你平常怎么學習的？你畢業之后通過哪些方式構建自己的知識體系，講給我聽聽。

Ta：看書（經過追問發現最近幾年其實沒讀完過幾本書，甚至連書名都記不住幾個）。看視頻（網絡教學視頻）。看技術網站（多半停留在首頁上……）。跟朋友聊天（QQ群，微信群，……，斗表情包，無比巨大的噪音）。

我：這樣吧，你工作之后有沒有針對工作中遇到的某一類問題，抽象出一個 Topic，有針對性地調研和做試驗？

Ta：……有吧……

我：你說的這個事兒，其他公司是怎么解決的？

Ta：……

新員工的試煉

我會告訴面試者，你來了之后，除了做業務之外，還必須做一個技術預研課題，課題范圍可大可小，你不僅僅要做試驗，還要公開分享你的所思所得。

WHY？

因為微信里收藏10000+篇技術文章，

因為知乎里收藏10000+個答案，

因為云筆記里離線復制了10000+篇文章，

……

很快樂，但并沒有什么卵用。

碎片化閱讀是很舒服，但意義不大，看似每天收獲滿滿，其實都成為過眼煙云。重復一下著名的學習金字塔留存率觀點：我們讀過的，知識留存率是10%。

我和面試者之間還經常會發生這樣的對話：

我：這個思路/技術選型是誰提出來的？

Ta：技術經理/領導/項目經理……

我：有沒有比較過其他實現思路？請講一下各自的優缺點。

Ta：領導讓這么干的，所以沒比較過……

針對某一個課題，深入思考，多方調研，做試驗證明，很多工程師可能今生僅此一次：他大學畢業時做畢業論文的那次…………

如果長期滿足于東點點，西點點，今天可能是 Webpack、npm、Gulp，明天可能是 Spark、機器學習、流式計算，假設你過目不忘，知識的廣度倒是有了，但缺乏深度，長此以往，可能徹底毀掉了深度思考的能力。

所以，我們要“訓練”，強制性要求你從定義問題開始，訓練自己主動搜索、主動鏈接、主動構建知識、主動試驗、有始有終的能力。

定義問題

首先我們提出的問題，它必須是有重要意義、急需結果、目標是商用，但可能沒有現成的、確定的解決方案，同時這個問題必須能夠給整個團隊創造學習機會，提供發展個人和組織技能的機會。

那么通過講述我們看到了什么，想解決什么，通過你我不斷的思考和討論，直到你能清晰地抽象出一個明確具體的問題——這個時候，問題其實已經解決了一半。

舉例。

我們的平臺由數以百計的形形色色分布式服務構成，每一個請求一路走來，會經過多個業務系統并留下足跡，并產生對各種 Cache 或 DB 的訪問。作為訪問入口的 App 開發部門首當其沖會接到用戶投訴，然而請求會被隨機分配到集群的各個節點，所以找到對應的日志片段，理清調用關系，找到在哪里斷的，成為一個令人生畏的工作。

如何解決？前提是先定義出一個好問題。

拿“分布式系統”、“集群”、“日志”、“排查”等等關鍵字，去搜索，去看各種頂級團隊的博客，去看各種架構師演講資料，終于把問題聚焦于“分布式跟蹤（Distributed Tracing）”這個命題。

于是，問題被抽象為一個 Topic：

如何實現分布式跟蹤：追蹤每個請求的完整調用鏈路，收集調用鏈路上每個服務的調用參數和異常堆棧，統計每個服務的性能數據；可視化調用鏈，可視化服務質量。

主動構建知識

曾經看到過這么一句話：

只能不斷地學習基礎知識以及和這個技術（問題）關聯的知識，就像 Wikipeida 一樣，當你進入一個詞條的時候，就會伴隨一堆新詞條，于是，當多年后，我看到 “知識廣度是深度的副產品”這句話時，簡直就是說到我的心里去了。

仍以上面的例子舉例。

確定了分布式跟蹤的大方向之后，我們可以收集整理出各個公司在這個 Topic 上的實踐，Google的Dapper，淘寶的鷹眼，Twitter的ZipKin，京東商城的Hydra，eBay的Centralized Activity Logging （CAL），大眾點評網的CAT。

接下來我們還可以整理出它們的架構思路和優缺點，我們可以發現有的解決方案對工程侵入太重，給開發者造成了額外的負擔，有的解決方案依賴于該公司特有的、閉源的技術體系。

主動做試驗

怎么設計試驗，通過什么數據，打算證明什么，這也是一種能力。

舉例。

在實現實時數據大屏的時候，我們的一位工程師在 MySQL+Canal 后接入分布式消息隊列時，試驗了 Kafka 和 RocketMQ，目的是，第一求證能否確保嚴格的消息順序，這是數據庫變更訂閱希望看到的，第二做一下壓力測試，比較一下二者的性能。

有始有終

我這里說的有始有終，包含幾個意思：

畢竟這是一個商業應用，是要上線的，前前后后都要考慮清楚。我們考慮哪些點？首要的就是監控報警。其次是線上數據如何遷移，線上應用如何接入。再次是性能。

公開分享你的所思所得，不僅做，還要寫下來，還要說出來。你一定要輸出你在這個問題上構建的知識結構，幫助自己，幫助大家，共同進步。

如是重復再重復，訓練再訓練，不妨試試看遵循 70-20-10 的學習法則：70%的學習時間放在針對現實生活和工作中遇到的任務、問題解決，20%的學習時間放在人與人之間正式的、非正式的反饋、輔導，10%的時間學習知識和信息（可能是碎片化的學習，也可能是讀書）。

這樣可能像把你裝進一個沙袋里吊起來，從四面八方用狼牙棒打你，酣暢淋漓。