面試時的交談

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

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

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

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

為什么要問這個問題？

因為我和面試者之間經(jīng)常會發(fā)生這樣的對話：

我：平常看什么技術(shù)網(wǎng)站？

Ta：某某技術(shù)新聞站，某某博客網(wǎng)，某某微信公眾號……

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

Ta：……

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

Ta：想不起來。

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

Ta：看書（經(jīng)過追問發(fā)現(xiàn)最近幾年其實沒讀完過幾本書，甚至連書名都記不住幾個）?？匆曨l（網(wǎng)絡教學視頻）?？醇夹g(shù)網(wǎng)站（多半停留在首頁上……）。跟朋友聊天（QQ群，微信群，……，斗表情包，無比巨大的噪音）。

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

Ta：……有吧……

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

Ta：……

新員工的試煉

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

WHY？

因為微信里收藏10000+篇技術(shù)文章，

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

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

……

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

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

我和面試者之間還經(jīng)常會發(fā)生這樣的對話：

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

Ta：技術(shù)經(jīng)理/領(lǐng)導/項目經(jīng)理……

我：有沒有比較過其他實現(xiàn)思路？請講一下各自的優(yōu)缺點。

Ta：領(lǐng)導讓這么干的，所以沒比較過……

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

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

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

定義問題

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

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

舉例。

我們的平臺由數(shù)以百計的形形色色分布式服務構(gòu)成，每一個請求一路走來，會經(jīng)過多個業(yè)務系統(tǒng)并留下足跡，并產(chǎn)生對各種 Cache 或 DB 的訪問。作為訪問入口的 App 開發(fā)部門首當其沖會接到用戶投訴，然而請求會被隨機分配到集群的各個節(jié)點，所以找到對應的日志片段，理清調(diào)用關(guān)系，找到在哪里斷的，成為一個令人生畏的工作。

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

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

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

如何實現(xiàn)分布式跟蹤：追蹤每個請求的完整調(diào)用鏈路，收集調(diào)用鏈路上每個服務的調(diào)用參數(shù)和異常堆棧，統(tǒng)計每個服務的性能數(shù)據(jù)；可視化調(diào)用鏈，可視化服務質(zhì)量。

主動構(gòu)建知識

曾經(jīng)看到過這么一句話：

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

仍以上面的例子舉例。

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

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

主動做試驗

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

舉例。

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

有始有終

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

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

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

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

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