關鍵詞是 “輕松”，面技術的人一定要輕松，因為技術人很容易繃著。我們面試的那個屋子，有一個正經的凳子，還有一個放在地上的那種，類似于野餐時的一個靠墊。我面試時，經常坐在這個靠墊上，就是我仰視他，他俯視我。

通常來講一般是不好的，交流最好是平等的，但是做技術的人這樣是可以的，特別是如果我們對他專業水平判斷上覺得比較吃力時，我們要通過一些附加的東西來判斷，這些附加的東西一定要建立在一個非常好的溝通基礎上。
面試技術人才，可以注重幾個加分項：

在一個行業里，可能有一些技術問題是廣泛有共識的，就不需要再費太多心思鉆研技術。那這個時候，招進來的人了解這個共識會有優勢。

就像唯品會，早期時候，它是一個非常簡單的技術架構，三層，應用、緩存、數據庫。這個應用結構跟其他電商的有很多相似性，在電商里面存在庫管系統，它后面還有一個很大的后臺系統。這個跟社區，跟 UGC 體系設計是不一樣的。如果有行業經驗的話，就知道這樣的一個庫管系統應該怎么做比較合適。

我覺得創業公司有一個會張羅的，又會做技術的人是非常幸福的一件事。因為很多大公司流程管理通常來講是比較嚴格的，從產品設計到產品原形，到切圖，到開發都有人給你做好了，自己不用費心。但是在創業公司里面，很多時候是需要有推動能力，怎么能夠把這個東西在不影響進度的情況下，盡快地推出去。這個時候管理經驗是比較重要的。

我們之前有一個客戶，說他的項目老延期。延期的原因其實是非常簡單，他的產品定義導致工程師陷入了....深深的思考。

這個產品定義是：短時間之內，你不能頻繁改你的個人資料。工程師就想短時間是多長時間？三天？七天？于是他自己設計了一個非常復雜的算法，來處理這個短時間之內不能重復修改個人資料這個事。但實際如果要做管理的人就知道，這個事不重要，就跟產品經理打聲招呼，說我給你做成三天了，或者說這個東西暫時不是很好設計，我能不能放一放？稍微溝通一下，就能減少浪費的時間。

公開資料指的是，比如在中國架構師大會，在一些論壇、知乎等公開的場合發表過東西。因為工程師如果對自己的專業沒有信心，他是不敢說這些事的，會被人噴，工程師說話一般都不留情面，很喜歡去批判，所以他敢公開地寫自己的資料，寫這些他對技術的觀點，都是經過仔細的打磨。
 

這里的聰明就是大家理解的聰明，我總結了一下，所有我覺得最后很棒的工程師都非常聰明，而且都是看起來很聰明。那些一開始覺得可能大智若愚的，最后其實也不怎么太能干。好的工程師一定是聰明的，怎么表現出來聰明呢？你跟他對話時，會很舒服，你問的問題他一定聽得懂。就算不懂這個專業，也能夠很好地交流。能聽懂問題，能很順暢地把自己所要表達的東西有邏輯性地說出來，這個事其實很重要。也有的工程師，他不跟你說很多，他就說這個很簡單，這也未必不聰明。他說這個很簡單的時候，你可以問他如果不用這個方法會不會很復雜。總之，一定要把他邏輯性里他最后沒說出來的那個東西問出來。

如果喜歡把簡單問題講復雜，這個人請到團隊里，是有可能對這個團隊造成傷害的。現在很多 CEO 很難去管理自己技術團隊，原因是溝通不便，明明是一個很簡單的問題，他非要把它說得很繞，說得非常復雜，說成某種神秘的東西，越神秘的東西你越不好控制。他問你要錢、要人的時候，你又不好評估，這個處境就很尷尬很被動。所以說當一個不太愛交流的工程師說 “這很簡單”，其實這是一個好事，讓他簡單講一下，如何做，第一第二第三，聽一聽就大概知道了。如果不了解他所說的領域，就看他說那幾點之間的邏輯性是不是能找出漏洞出來，這個一般是能夠看出來他的技術水平怎么樣的。

Geek 是雙刃劍，非常牛的 Geek 可以解決超具挑戰的問題，但如果你團隊里沒有一個人能控制得了他，是有風險的。

主要是三個事情，第一是過度使用技術，有些 Geek 喜歡用的技術確實太前沿，不成熟。檢驗這個可以去搜他所用的技術關鍵詞，看有多少關鍵詞的結果，社區活躍不活躍，有沒有開源的東西，對標的產品里面有沒有人在使用，來看這個技術的風險有多大。

第二個就是 Geek 一旦走了之后，里面的代碼沒人能改得了。很多工程師都會說這個東西我還不如推倒重寫，這個原因就在于很多代碼是非常難去改的。是一個新房子重新裝修比較簡單，還是你已經裝好了二手房，你把它拆了重新再裝比較簡單呢？接盤其實比重新做還要復雜的多。這也就是說 Geek 團要做一個技術方案時，需要有一些文檔，需要有一些討論記錄，需要有一些輔助性的東西能讓他把自己的思路講出來。那種獨狼型的，很厲害，一個人把事全搞定了，但是別的人不知道怎么接，如果他走了，你的公司就有巨大的風險。

最后一個風險就是不以業務為導向。一般來講要做以業務為導向、技術為驅動，這樣是個比較好的方式。不以業務為導向的一個很重要的表現形式就是一個工程師在接產品需求的時候不問任何問題，這個東西給你做，看一眼說 OK。這一定有問題，幾乎沒有任何一個產品需求是沒有問題的。

我舉個例子，大家來看看。我在微博的時候，有一個產品經理跟我提，說我要給微博大 V 做一個需求。這個需求其實不難，但大 V 這件事不簡單。大 V 是一個很虛的概念，什么叫大 V 呢？是王老師、徐老師這種有幾千萬粉絲的叫大 V，還是有八百萬、五百萬的叫大 V 呢？代碼是數學邏輯，它沒有模糊的概念。如果我們拍下來說一千萬以上叫大 V，這個人突然掉了一個粉，變成 999 萬，那他還是大 V 嗎？這個事情是沒法做的，大 V 這個標簽是很虛的東西，所以說幾乎所有我們認為理所應當分分鐘就搞定的產品需求里面，都是有各種各樣的技術問題。

但是如果我不以技術為導向，我覺得這個事情很簡單，接了。接了然后我就慢慢做，我就自己設計一個很復雜的方法把大 V 算出來，然后我還可以預估這個人什么時候可以成為大 V，根據他過去一周粉絲增長的數量，我完全可以做得非常復雜，而且技術上做得非常漂亮，但是并沒有卵用，但是技術大咖 Geek 會很爽，做了這個東西，非常有成就感。
 

普通工程師最關切的就是我到這能學什么東西，所以這個時候，我們應該在術語上會來強調一下我們這確實有牛人帶你，我們這個團隊技術上有多厲害。像我每次招人的時候，我都會說我們是新浪微博通訊平臺核心團隊出來的，然后怎樣怎樣，讓他覺得這個事情是可以學到東西。

技術主管看重的是專業要對口，業務要好，領導要支持。技術主管的年齡通常 30 歲左右，積累了一些經驗，所以希望要大展所長，專業要對口。業務好會給他很大的信心。我問了幾個之前在微博的同事，跳槽的，大部分都是這樣的情況。專業上，他認為對口，業務上，他覺得未來有發展，領導也比較支持他。

Facebook 有一個技術管理的金句，當一個工程師在專注寫代碼的時候，即使是跟他打招呼，say 一下 hello，也是在打擾他工作。工程師最好的狀態就是他每一天早上一睜眼就知道我今天要干什么，有序的、穩定的去干。最好不要不斷地打斷他，不斷地調整他的工作節奏。

晚上七八點鐘的時候，要在技術團隊里面轉圈。一般來講，如果一個工程師的工作順利，而且又有節奏的話，他到七八點鐘的時候，不會是那種愁眉苦臉的樣子，一定是很輕松愉悅的。因為今天一天的工作差不多要結束了，看看博客，看看線上服務器怎么樣，一定很輕松，很舒服的一個狀態。如果他是非常痛苦的在那搞一個東西，很有可能陷入到了短期之內不要變更資料這樣的問題里面去。這個時候，要技術的老大來主動發現，所有中國的工程師都是這樣的，你要主動地去接觸他，不要等他來匯報。

我覺得周報還是很有必要的，特別是技術老大寫周報，我覺得是有道理的。這個主要是為了讓技術的人學會用非技術的語言來描述技術問題。什么是技術語言呢？典型的就是說我這周把我的數據庫分了 128 個表，消息隊列我設了 64 個隊列，每個隊列長度是多少，然后部署在什么服務器上，這是一種技術性的語言。

非技術的語言是這樣的：我們現在處理的這個請求峰值或者是用戶量是多少多少，下面我要做數據庫相關的擴容，能夠承載這些數據量。我要做消息隊列，主要是為了提高寫入的能力，預計要花多長時間把這個事做完，做完了之后，我就能達到多少多少量了，然后這件事情我現在已經完成了多少多少，后面可能有什么風險，最壞情況下可能要延遲一周。

大概這樣的一個東西，你就能知道技術的團隊忙活了一周，他們能對業務帶來什么樣的改進。比如說我要承載多少多少數據量，這個事是誰來定的？肯定是我們業務團隊來定，比如我要做個活動，我要做個雙十一，那我要預算服務器要到什么程度，這個項目才不會掛，這個很重要。