關於值班這件事

上個禮拜有兩件事讓我頗有感觸，一是美國職場上的升遷，二是關於值班，且讓我再牢騷一番。

前文提到我的饅頭如何發揮影響力，成為組裡的技術領導。他其中一項對自己的要求是，值班的事情就在值班時間內做完。這邊所謂軟體工程師的值班，並不是待在公司裡面24 小時過夜等換班，而是長達一週168 小時的待命狀態。這一週內，值班工程師放下手邊產品開發的工作，負責產品相關的各種技術支援、修補、更新、聯繫。不少組不讓新進工程師負責值班的，除非人力吃緊。我有幸能夠為組裡服務。

PagerDuty 是值班工程師的好夥伴，一旦系統出現狀況，PagerDuty 接受到系統警訊後，會用寄信、傳簡訊、打電話等方式騷擾值班工程師。如果值班工程師在十分鐘內沒有回覆，PagerDuty 就會向上通知主管。
上禮拜它就打了一次小報告。

星期四早上六點起床後，看到小老闆在Slack 上關心昨晚十一點的PagerDuty 警訊。哎，我不留意把手機關靜音了，沒收到警訊。早上去辦公室馬上跟小老闆報告情況：

「FedEx 無法處理一個錯誤地址，導致有一些產品被退貨，但不用擔心，我已經處理好了！」

小老闆聽了臉色一沉，說了一句「這不應該發生的」(This should not happen)

聽到他的回答，我心涼了一半。我知道自己雖然菜，但這種小問題第一時間是可以解決的，不需要在深夜11 點讓小老闆來關切，深覺自己有愧饅頭對我的尊尊教誨…

「工程師的睡眠不應該被這種問題打斷，FedEx 11點也沒在收件的，我們應該處理一下PagerDuty 發佈警訊的優先順序」他接著說。

事後小老闆開了一張ticket, 討論如何分類PagerDuty 收到的警訊，僅有嚴重的問題必須做夜間通報。

Definitely a 🙂 in our retro next week.

美國職場升遷原則

美國職場的升遷的原則是，先做該職缺的事，名份稍後自然掛上，工作近半年的我有些許體悟。

今早收信，剛入職帶我的「饅頭」(mentor) 升遷為Tech Lead。在Square, 這個職位要做負責項目的重大技術決定，並協調團隊上的工程師支援開發，是比資深工程師更進階的職位。他才加入公司兩年，時間不長，但絕對是實至名歸。

我有幾個觀察：

• 他做事特別快。剛入職的時候，小老闆交代我的第一個項目，請饅頭估計要花多久時間，饅頭說他大概要花一天，所以他預期我三天能做完。小老闆說新人慢慢來吧，給我一個禮拜的時間，然後我到了第二個禮拜終於把事情搞定。
• 自我要求嚴格。我第一次值班(on-call) 的時候，收到很多各式各樣的任務(tickets)，對於不熟悉系統的我來說，值星帶拿下後還得繼續做值班時被分配的任務，拖延原本手邊的工作。我問他該怎麼克服這個問題，饅頭答曰：「把值班任務全部按時解決就好了，至少我是這麼做的。」
• 引導新人學習。我向他請教項目問題的時候，他不曾直接給我答案。他寧願花很多時間跟我談系統架構，談當初設計的理念，闡述他接下來的想法，談Why 等囉哩囉唆的，饅頭知道，但饅頭就是不告訴我How。

而這些正是Tech Lead 會做的事。每次和他對談完，我的敬佩之心就油然而生，不知道何時才能到他的境界。但我不氣餒，畢竟我和他也是有幾分像似之處，我們加入Square 前都不會Ruby on Rails, 然後前一份工作都是大學程式設計課程助教。

只是他才剛滿22 歲而已

那些年，我們一起追的程式語言

在Square 的某個下午，隔壁組的同事圍成一圈，歡迎一位新進畢業生。大家一邊喝威士忌，一邊自我介紹，酒酣耳熱之際，灣區碼農們聊起了各自的「第一次」。

「我的第一次發生在11 歲，在聖路易安娜的老家，那時我正在寫個人網站，用Visual Basic 隨便弄的。」C 小哥略帶靦腆地說。

「那是一款遊戲，用Java 寫的。嚴格來說，我不清楚事情是在哪裡發生，因為我正在飛機上。」M 小哥帥氣地說。

「Tony，輪到你了，說說你的第一支程式吧？」

還沈醉在同事們的經歷中，語塞的我，將杯中物一飲而盡，凝視遠方。

•••

交大工程三館地下室，擠滿了資訊科學系的新生，我很興奮地坐在第一排，迎接第一堂程式設計課程。講師小黃簡短地歡迎新生後，開始在講台前眉飛色舞地講課。但奇怪的是，我總是聽不見他說什麼，第一堂課結束，只記得他再三叮嚀：下載Visual Studio。透過C++，我學到程式裡面的變數、函數、條件、迴圈、遞迴等概念，但我對C++ 這個語言的本質還是很陌生。

大三暑假，和前室友罩哥聊天，他正在籌劃程式設計校隊的暑假集訓。當時交大學生不熱衷程式設計比賽，罩哥找不到人參加的情況下，把我給拉了進去。教練是奧賽銀牌的資工學長卡車司機，帶我們練習UVa Online Judge 的程式設計題目。

我和Y 同學在第一次練習的時候，打開了Visual Studio，IDE 還沒開完，她已經用Vim 寫完snippet，然後我就她被鄙視了。大四開學，我們前往東京參加ACM 區域賽，飛機上K 學弟不看解題相關書籍，津津有味地讀「程式語言」，我一臉疑惑問這是為什麼呢？K 學弟笑曰：「因為這本書很有趣。」再一次，我又被鄙視了。

此時熟悉許多實作於C++ 的基礎資料結構和演算法，半年過去，我和Y 同學和D 學長組了一隊參加教育部的大專盃程式設計比賽。國手培訓營出身的學長大發神威，帶我們拿下第三名。我拿這紙獎狀去推甄，最後吊車尾正取台大資訊研究所。順帶一提，K 學弟後來也進台大，畢業後去MIT 攻讀博士，他當年那燦爛的微笑依然深植我心。

大四下我去UIUC 交換，在一門圖學課用C++ 寫了一個ray tracer。和一般程式競賽百行內的小品相比，ray tracer 對記憶體需求大，程式邏輯也相對複雜。我中體會C++ 的繼承、多型等物件導向特性。香檳的春天，算是我和C++ 的蜜月期，從無到有完成有一定複雜度的系統，讓我更了解她，也更信任她。但終究，我無法忍受她時常segmentation fault，上研究所後，我就很少聯絡她。

最後一次見到C++ 是在Google，當時我的工作是整合Google Brain 和OpenCV，實作一個根據使用者可能感興趣的內容，自動生成動態圖像廣告的MapReduce 類別。隨著C++11 發布，她已經有不小轉變。時髦的語法，減少型別判斷的冗句。內建的std::unique_ptr 降低許多memory leak 的機會。加上Google 內部超強的infrastructure 和豐富的codebase，用C++ 工作真是寫意輕鬆。

我曾以為，這次能和她走到最後。

直到用C++ 面試找工作的時候，才認清這麼多年了，自己始終沒有好好去了解她。白板，是我最後寫下const T& 的地方。

•••

“Tony?”
「那只是個課堂作業，在交大，用C++。」我微笑以答。

初階軟體工程師面試心得

從新創公司到軟體巨擘，不同公司對初階軟體工程師的面試略分三類：

1. Conversation
經驗交流面試，主要考察求職者過往經驗與公司目標是否契合。

這類公司通常專注於一個產品，需要大量的背景知識才能上手，比方說做光場相機的Lytro, 增強實境的Magic Leap, 虛擬實境的Oculus。面試官並不在乎求職者會不會反轉二元樹，他在乎的是對電腦視覺的基礎、對C++ 的理解程度、以及對電腦視覺函式庫的熟悉程度。

這種面試幾乎沒有速成模式，基本上通過履歷篩選拿到面試的，應該都具備相關的專案經驗，就是看經驗的深度廣度有沒有達到公司徵人的門檻而已。

2. Whiteboard Interview
白板面試，主要考察求職者解題與分析能力。

這類面試在我求職過程中佔了大宗，Google, Facebook, Uber 等幾乎你能想得到的公司都是進行白板面試。一個白板面試的基本流程就是考官給一道題目，受試者在白板上寫下自己的答案。面試官考察受試者在沒有語法高亮或是編譯、直譯器等補助工具的環境下，從思維上怎麼解決題目，並分析解法。

題目包括 a) 演算法 b) 物件導向程式設計 c) 系統設計，每間公司的出題偏好不同。Google 只考演算法，Facebook 考演算法和物件導向程式設計，Uber 三個都考之外還加behavior questions。其中，Uber 會讓你在電腦用熟悉的環境編程，但與面試官的交流不出白板面試的框架。

此類面試是可以速成的，大家常說的「刷題」，就是增進白板面試的能力。

3. Pair Programming
結隊編程面試，主要考察求職者內化的編程習慣與反應能力。

同樣是給一個程式問題，面試官與受試者，一人一副鍵盤，坐在同一台電腦前一起解決問題。與白板面試不同的地方在於，面試官就不好意思出一張嘴說 “I don’t know. You tell me.”，雙方必須在程式碼上面做交流。

三種面試中，我最喜歡這種，受試者也可以在一起編程的過程中更了解面試官。不過也許是成本過高，此次面試只有Square 是採用這種模式。

此類面試速成難度較高，但是可以準備的。我認為遵循物件導向的原則，多實作簡易的類別，能提升現場寫程式碼的品質。