面試經驗分享

2025 年，我因個人因素需要換工作。由此，開始了為期數個月的在職應徵，其中面試的職稱都是 SRE（Site Reliability Engineer）。

不同公司的面試流程¶

這裡不會寫上實際的公司名稱，因為不想被以該公司的關鍵字 Google/AI 到。（有發現自己的一些文章會被 ChatGPT 引用）

台灣新創公司¶

第一階段會寄一個 container 給你，要你啟動這個 container 然後開始進行考題。考題包括：

啟動 server 來收 request，這就可以測試基本程式撰寫、 container network interface 管理、基本 HTTP header 和 body 的處理；
進到 container 進行後續考題的操作；
串接 MySQL 並優化 container 中一段 SQL 的性能；
串接 Redis 並找出藏在其中的密碼；
理解 image，並找出藏在某 layer 但被刪除的密碼；
理解一段程式碼並找出方法讓他顯示密碼（謎底是透過環境變數）；

據後來該公司的主管說，這些考題都是實際遇過的場景，做起來確實有一種在面對公司實際狀況需要進行的操作。

第二階段約 3 個小時（聊了很多天），會有一段實戰考題，然後主管是用視訊和螢幕分享觀看解題過程。過程會提供一台 VM 去 SSH 還有一段程式碼，邏輯大致是接收 RabbitMQ 後做一些簡單的資料整理再把資料更新到 MySQL 中，題目則是對其進行優化，包括 RabbitMQ、程式碼、MySQL 或者直接簡述可能的架構調整。最後主管會把資料量從提升約數萬或數百萬倍，並考驗整個架構的可靠性。可以進行優化的項目包括：

定義 baseline；
RabbitMQ 發送接收的調整，避免單點受到洪流且允許跨節點的接收訊息；
長連線的管理；
MySQL 資料結構優化；
多 query 整併成單一 query；
除錯邏輯的捨棄（或者做個開關），在一些邊緣運算這需要考慮；
整體架構調整讓該應用可以擴容。

台灣網路服務公司¶

第一階段約 30 分鐘，和主管視訊來確認未來工作內容和公司業務。同時會讓我簡述一下個人經驗，不會深入，只是做個初步了解。

第二階段約 1 小時，是針對上次簡述中主管有興趣的專案進行深入探討，過程中滿專業的，會專注在 why 的本質討論。

台灣物聯網服務公司¶

第一階段約 1 小時，視訊和主管跟未來同事討論一些過往經歷，並簡單說明公司營運方向和未來工作內容。

第二階段是和高階主管面試，未進行。

國際新創公司¶

這個面試只到第 1 階段，因為後續職務內容不是想要的而沒有接續進行。儘管如此，仍進行了約 1 個半小時的視訊談話，因為對方公司做的是有趣的軟體工具，所以會去挖掘一些公司的料來體驗一下，可以感受到員工對產品的努力。例如，如何避免業務邏輯在跨國 K8s 叢集間相互影響，或者產品定位去搶市場份額的挑戰。

台灣跨國大公司¶

第一階段是用人主管視訊說明公司架構、公司業務、工作內容、公司文化、部門間互動方式，不太聚焦技術問題，只是簡單詢問我工作中專案遇到問題以及怎麼解決，不過對方也有明說不是技術主管，相關技術細節討論會在下次面試由高階主管進行。

接著就是在家進行 HackerRank，有三題，總用時記得是兩個小時，前兩題用一個小時完成，不難。第三題到時間結束還是沒有全對，內容有點忘了，簡單說明就是該題目最終會轉化成計算某個數的 n 次方，在從應用邏輯轉到數學公式這段可能花了約 5~10 分鐘，後面都是在解這個公式。但因為數字的範圍會到 \(n=2^{30}\) 所以他會要我們用 mod 1,000,000,007 的方式去算，最終會得到一個必須用費馬小定理去算的簡易公式，事實上就是我自己工作上常接觸的 RSA 算法，但因為錯誤地以為要先計算小於 1,000,000,007 的質數數量（事實上只是計算小於且和互質 1,000,000,007 的數的數量），導致計算錯誤。

再來就是進公司進行英文測驗和性格測驗，太久沒考英文了，我還在慢慢寫的時候發現時間快用完了，後面閱讀測驗直接看題目猜答案，想不到竟然過了...

第二階段的高階主管視訊面試則是會討論一些對事物的看法，例如你覺得 CI/CD 最重要的概念是什麼，當時回答是速度，因為之前和同事討論時，發現他們會覺得 CI/CD 執行太久，要坐在電腦前空等，所以我認為 CI/CD 的速度很大程度會影響整個公司的工作絲滑度。但聊完天後我覺得可外掛性也很重要，因為全公司產品都會用到 CI/CD，我怎麼在其中做 audit 或優化產品的 image、確保 API 遵照公司內規範等等，除了減少各團隊重複造輪子之外，也可以快速迭代各產品的管理政策。還有一個面試的問題是 OpenTelemetry 的推廣很大程度受到產品工程對於 debug 經驗的影響，例如有些產品就習慣用 log 去追問題，你要他去 tracing/metrics 他會沒有動力，該怎麼推廣？我回 log 不像 trace 有 sample rate，所以他的量體通常會比 tracing/metrics 大，相對應的就要付出更多成本去支撐不管是儲存或計算的資源，也就是用帳單去施壓工程。經過後續幾天的消化和思考後，我覺得應該要把這想成新產品的推出所面臨的使用者的舊習慣。不要想著要破壞使用者習慣，而是順著習慣慢慢調整，例如在 log UI 中的 trace ID 加上 link，直接連到 tracing 的 UI，使用者一樣可以用 log debug，隨著偶爾點一下 trace，慢慢就會增加使用 trace 的習慣。相同的道理也放在 metrics，例如 status code 欄位會連結到 2xx 比例的 dashboard 等等。最後再舉一個面試問題，你覺得你對 K8s 有多了解？這邊是回答 K8s 生態系統非常龐大，我在學習 K8s 時的方式是遇到問題然後去解決，解決過程中就有可能深入去理解，不管是程式碼、不同組件之間的交互作用或者 kernel 和 K8s 之間的互動等等。所以如果 100 分是 K8s 本身的創建和維護者的理解程度的話，我回答不出我是幾分，但至少我會去深入問題並盡可能地找出原因（至於能不能解決問題有時候就是隨緣了），然後再實際舉其中的 DNS 和 pod lifecylce 做例子，強調在特定面向的問題的深入理解。

接著就會進行 HR 面試，主要討論的是你遇到困難的處理方式以及跨單位溝通技巧，這邊就不贅述不過這階段還不會談薪資，要再等一次會議邀約才會討論薪資。當我在打這段的時候想到前陣子看到的一個溝通技巧，個人覺得很有趣。常常聽到有客戶想要出手干預工程開發的細節，當發生這種事的時候就容易讓產品難產或拖延進度，讓整個開發生命週期持續惡化，要避免這種事發生，工程應該在早期主動出手干預業務方向。舉個當時看到的例子就是要在公司內部開發管理廣告的後台，他在早期討論功能的會議前，就先去張羅各個類似產品提供的功能還有現行公司廣告的業務邏輯和細節。當會議開始時，他會在客戶提出功能後，再額外提供一些可以簡單實現的功能，這樣反過來出手干預業務方向，就他的經驗都會讓整個開發流程變得更流暢，也許是客戶更信任工程的關係。

總結¶

最後總結一些心得。

理想的工作流程¶

以下是我認為理想的面試流程：

視訊（這很重要）面談說明公司架構、公司業務、工作內容（包括技術棧）、加班狀況、公司文化、部門間互動方式，同時我這邊簡述一下自己的經歷和轉職（求職）動機，讓雙方有一個基礎的認識，並決定是否繼續，才不會浪費時間；
任何測驗檢驗我的能力、性向；
就技術、溝通能力、專案管理能力的細節討論，這過程也能讓我了解面試官的技術能力，並做進一步的判斷。

最後是否有一個 CTO 或高階主管做相處或認知測試我覺得都可以，不過我想強調的是，在最一開始透過視訊這種低成本的溝通方式來快速篩選是個很重要的過程，不然到處奔波真的很累。

公司該認真準備面試嗎？¶

對新創公司來說，每一次新進同仁都是巨大風險，由於處於新創時期，若招聘進來的同仁不能成功完成試用期，其中付出的成本會佔新創公司很大的一部分。這也是為什麼我會在新創公司中看到他們準備的面試都是充分準備過的，相比於較大的公司（包括我在職的公司）面試流程就較為鬆散，用人主管面試、高階主管面試然後就結束了，好一點的可能會加個 hacker test。當我遇到認真準備的面試流程，其實也會增加對這間公司的好感，個人認為這是值得做的投資。

祝福¶

最後，找工作是困難的，也祝大家可以找到理想的工作，加油。