在美帝面試工程師，是一種有趣的體驗。以前曾經在朋友圈里發過一些體驗，這兩天，面試了兩個很有意思的工程師，其中一個勾起了我一份塵封的回憶。今天我們講講這三個人。

[[211620]]

(一)

SH 君。我昨天面試的 SH 君。他的背景是廣告系統 —— 他在之前的公司現學現用，用 erlang 實現了 RTB system。他學習能力很強，系統知識豐富，考慮問題周全，僅僅使用了一年多 erlang，在其之上的造詣就相當不錯。我和他聊了進一個小時，越聊越投機 —— 一般到這個時候我會問 candidate 一些奇奇怪怪的問題，比如，你最近在讀什么書?最近發現了什么有意思的開源項目等等。對他，我拋出了這么個問題：如果 erlang core team 愿意在語言和 VM 層面為你實現幾個 feature，你希望是什么?

這個問題非常 open，既考察 candidate 對已有系統的理解，又考驗 candidate 知識的豐富程度。

出人意料地，他一口氣提了三個愿望：1) 更好的 refc 管理，提高內存效率同時又不引發 “leak” 2) 引入 type system，最好像 haskell 那樣嚴格區分 pure / impure function 3) 把 OTP 的核心功能，比如 application / supervision tree 做到語言級別，而非以 lib 形式提供。

對于 1) 和 2) 我不太意外。3) 很有意思，也很有想法。我讓他進一步澄清 —— 他說，他雖然沒有太多 akka 的 knowledge，但 akka 顯然在某些方面青出于藍而勝于藍。akka 下，任意一個 actor spawn 出來，都有默認的 supervisor，erlang OTP 提供了 supervision tree，可語言或者 VM 本身卻沒有把這個作為缺省行為 —— 如果我們因為上下文的需要臨時 spawn 一個 process，絕大多數情況，會額外去 monitor 它以便妥善進行 error handling，既然如此，為何不默認就 supervise 呢?

甭管這個想法對與不對，單是這份思考，就超過很多很多的程序員了。

(二)

B 君。今天面試的是 B 君。android 工程師。粗一看簡歷，B 君就讓我回想起了很久前面試的 S 君(下文會說)，原因很簡單：又一枚硅谷活化石。B 君 80 年開始工作時，我還沒出生。那是是 DEC 如日中天的年代(誰都不曾料到把 IBM 逼到墻角的小型機之王，幾年后就就被 PC 的浪潮沖擊得七零八落)，他在 DEC 工作，隨后換了不下十家公司，著名的有 amazon 和 twitter。如果按照正常孩子十七歲的花季上大學推算的話，他現在已經年逾古稀。在國內程序員圈子還在熱火朝天地討論程序員 35 歲后該干嘛時，他卻精神矍鑠地參與一線 android 開發。并且，他是三本 android 書籍的作者，最近一本于 16 年出版，叫 android concurrency。雖然老爺子不幸錯過了計算機近代史上幾乎所有能發家致富的機會，他依然樂樂呵呵，沒有自艾自憐。

和他面試的前一個小時，我上 amazon 翻看這本書的評論和可供預覽的章節。平心而論，書寫得并不算是優秀，概念解釋得不夠清晰(面試時也印證了他對 concurrency 和 parallelism 沒有清楚的定義，可能我是一個對 concept 過于較真的人吧)，對 android 之外 concurrency 的 big picture 也不了解(比如 actor model，CSP，STM 等)。當然，能寫書，已經非一般人所及，他的 android 的造詣不淺，而且在近六十歲高齡活躍在技術一線還不斷寫書，實在是我輩之楷模。(和老爺子閑聊時，他說他還會繼續出書)

(三)

S 君。和 S 君的面試已經過去一年多，如若不是當初寫了篇未完成的文章，保留了些許鮮活的記憶，我對 S 君的記憶僅僅停留在「他是個活化石」的階段。

這是當時的文章：

10多年前我剛加入 Juniper 時，同事們每天中午都要一起聚餐。有一陣子，來了很多總部的華人工程師，聊起硅谷的各種軼事，一位做 Kernel 的大神同事 Yi 說起他有次在釣魚，和旁邊的老頭閑扯，一扯扯出來個以太網的發明者。那時我就感慨，硅谷 TM 真是個神奇的地方。

后來又陸陸續續聽到同事們不少關于偶遇硅谷活化石的故事，比如面試遇到和蓋茨喬布斯同時代的程序員等等，聽得我如癡如醉。

上周終于遇到一個和喬老爺子同時代的面試者 S君，78年印第安納大學畢業。MIPS 的早期員工，NeXT 早期員工(他是在喬老爺子被自己親兒子蘋果掃地出門，剛領養了 NeXT 這個義子后加入的)，數個公司的 VP，包括 NEC(好吧，NEC現在已近算不得什么好公司了，不過曾經火過)。

然后他來我們 Tubi TV 這座小廟面試!

這在國內是無法想象的!你能想象鮑岳橋簡晶這些讓人敬仰的超級程序員前輩們跑到你的 startup 來面一個程序員的職位么?

S君住在 Atherton，硅谷著名的富人區，想來是不缺錢的。整個面試過程中，有個問題好幾次我幾乎脫口而出：您看上去并不缺一份薪水，憑資歷(或者人脈)也可以去一些大公司領個閑置安度晚年好了，為何要來 Tubi TV 這樣一個處在需要事事操心的階段的創業公司?但顧忌到文化的差異，我強忍住了。

作為熱身，我問了他在 NeXT 的履歷，他說自己做 object-c compiler。我對 compiler 并非諳熟，不敢造次，扯了幾句后就把話題移到喬老爺子身上。S君立刻打開了話匣子，講起了各種軼事(程序君按：媽蛋我當時為啥沒把這些軼事記錄下來)，隨后他目光一暗，說老爺子自從接手 Pixar 后，精力就都投在那邊了，在 NeXT 就很少出現他的身影。

隨后我們聊起了 MIPS。我漸漸感受到他對技術的那份熱愛 —— 這也可以解釋他輾轉多家公司，有大大小小公司的 VP title，卻還愿意在一線做事。

他說他在加入 NeXT 之前兩年，1984年(好吧，那時候我還穿著開襠褲滿地連滾帶爬地蹣跚學步呢)，加入剛剛創立的 MIPS，親歷了一套指令集從學術界到工業界的轉型，因此對 MIPS 飽含感情。因為在 Juniper 做過中斷處理相關的代碼，我對各種 RISC CPU，尤其是 MIPS 和 ARM 比較熟悉，于是便班門弄斧，用 branch delay 試了試他的底。他說他主要的工作是優化 TLB，設法優化掉 CAM(那時估計還沒有TCAM)和 DRAM 之間的 SRAM(那個年代 SRAM 無比貴)，但指令流水線也是懂的。在他如同教科書般詳細介紹完 branch delay 在早期幾代 MIPS CPU 的演進后，我突然想起一個困擾我多年的問題：為何 MIPS 有 branch delay，而同為 RISC CPU 的 ARM / PowerPC 卻沒有在指令級別做這種事情。他解釋說就 RISC 而言，MIPS 是更純粹的 RISC CPU，而 ARM / PowerPC 在工業界已經為了性能做了些改進(妥協)，另外，暴露過多的流水線的邏輯給軟件工程師(注：主要是寫編譯器和 Kernel 底層代碼的工程師)會使得編譯器過于復雜(靜態的編譯難以完美預測指令動態執行時的狀態)。所以他覺得 ARM 的做法是正確的，尤其是后來 hyperthread(超線程)的出現印證了這一點，pipeline 的復雜已經使這種簡單的優化失去了意義，唯有 CPU 自己的亂序執行才是王道。

我聽得津津有味，這個思路不就是 imperial programming(程序員告訴 CPU 做事的步驟)和 functional programming(程序員告訴 CPU 想干什么)的差別么?

既然提到了 ARM，我便順勢問他是否了解 literal pool。

可惜，文章在這里就戛然而止，后來的面試過程我已經記不清楚，唯一能確定的一點是，他沒有來 Tubi TV。

(四)

本來有感而發，火車上隨便寫寫，發篇長文字圖片了事，不經意間寫了這么些。程序員的人生道路很長，未來還有一波又一波的浪潮，大部分人注定會錯過所有揚名立萬的機會，一輩子做一個普通的勤勤懇懇的程序員。對于這幾個面試，我其實有蠻多感悟的，但思慮再三，還是決定就此擱筆，讓大伙兒自己思考吧。