成為 Ruby on Rails 工程師快一年了，身為一個菜鳥工程師，常常在思考資深工程師除了技術能力之外還需要什麼。托 Alpha Camp 的福，最近得到了一個跟 honestbee 工程副總進行一場模擬面試的機會，這場活動的本質是給想要成為資深工程師的人的一個 demo show，這個 live demo 面試過程的活動相信能夠給想要成為資深工程師的人一些啟迪。雖然知道自己離資深工程師還有一段距離，但我覺得去了解資深工程師的面試問題，能夠幫我釐清還需要哪些能力才能夠勝任這個職位。這篇文章述說了我從這次活動從準備到完成的心得，主要聚焦在心態以及面試題目的拆解過程。
心態的準備
在面試前，先建立幾個心態：
- 先想清楚，資深工程師的價值在哪裡？除了技術層面外，資深工程師還必須有與其他部門溝通、團隊合作、帶著剛入行工程師成長的能力。
- 關注解決問題的過程，不要只關注自己的表現好不好。在面試時關注自己表現好不好其實是無可厚非的，但是面試的本質是在看面試者解決問題的思路，當只關注回答對不對的時候，會陷入尋找正確答案的泥沼中，很多問題是沒有正確答案的，重點是思考問題、拆解問題的過程。
- 試著去思考面試問題想問什麼。有的面試問題看起來像是技術問題，但是其實也是在了解參加面試者對於工程師文化甚至是公司文化的理解。舉個例子：當被問到關於 code review 流程的問題時，心裡可能只想著”PR”、“coding style”、”merge”等等關鍵字，但 code review 文化的建立其實是工程師間交流與養成新進工程師非常重要的一部份。
題目拆解範例
列出幾個印象比較深的問題，並寫出我回答這些問題的思路：
如何確認系統的效能是合格的？
這種看起來很廣泛的問題，就是需要慢慢拆解的問題。如何將大問題拆解成一個一個的小問題然後一一解決，是在寫程式或者解決其他問題時很重要的能力，以下列出拆解這個問題的步驟：
a. 首先要先定義什麼是合格的效能。假設希望能夠使用者點擊之後在 0.5 秒內將頁面回傳給使用者看到。
b. 現在有一個數字了（0.5秒），那得有一個量測的方法，我舉了 New Relic 這個服務作為例子。這個服務能夠紀錄每個頁面的 response time ，將資料視覺化給開發者監控自己軟體的效能。
c. 有量測方法以後，便可以進一步的去拆解，網頁回應的速度又可以拆解成前端跟後端，接著只要說明前端、後端如何 tune 效能即可。
為何要離開現任公司？
這個問題要注意的點是不能製造出對立感，意思就是說，不能想要藉由貶低現任公司來凸顯面試公司的好。回答這題我從目前的公司屬於接案公司開始，說明現在執行的專案的規模是比較小的(流量、資料庫大小、軟體規模等等)，都是一兩個人負責，但也因為這樣可以接觸到很多不同的技術。
而 honestbee 的產品流量比較大，可以接觸到跟現在專案規模完全不同的流量，相對的也能夠接觸到更多處理這種大流量的技術（microservices、NoSQL等等）。同時大公司的團隊合作文化也是我想體會的，在擁有良好團隊合作文化的公司成長速度會非常快。
有在專案中找出可以改善的地方並且實作嗎？從中學到什麼？
這題是在看面試者有沒有自己找出產品問題的能力、以及學習新技術的能力，同時也是在試探面試者是否有產品思維，如果平常沒有這些習慣，遇到這樣的問題就會很容易卡住。
這題我舉了改進產品的搜索功能作為例子，闡述了如何將中文分詞功能納入搜尋功能裡面，並且提到為了研究這個功能，從底層去了解 Elasticsearch 的運作方式，不是只用 gem 包裝好的功能。
回答問題的細節
在面試的過程中，一開始的問題只是一塊敲門磚，面試官會沿著問題開始挖掘。比如說當我回答完關於 API 的問題，面試官便又追問了：『那如果有二十幾個資料來源的話要怎麼處理？』；或者是我回答完團隊合作的問題，面試官馬上又問：『那你寫 code 的時間會因為這樣變少，你要怎麼應對？』。
大部分的面試者都知道，當被問倒時不要裝懂。但是很重要的一點是，要試著去用自己理解的概念去解決問題，不要沒有思考便說不知道，再強調一次，面試的過程是去試著解決問題，而不是追求正確答案。而真的想不出來的時，另外一個很好的做法是把球丟回給面試官，請他替你解釋一些自己不懂的概念，很多時候這樣會讓自己可以想出可行的解法來。
結語
很感謝 Alpha Camp 的 Bernard 以及 honestbee 的 Sam 在活動開始的前後給我很多的建議與鼓勵，很開心能夠參加這次的活動。在線上進行一百個人觀看的面試直播是很難得的經驗，希望這篇文章可以讓沒有看到直播的朋友也能夠有一點收穫。
