兩年經驗，盡然斬獲多家巨頭offer，如：螞蟻、頭條、PingCAP~

上一篇：深夜看了張一鳴的微網誌，讓我越想越後怕

來源：https://aleiwu.com

分享一篇面經，作者拿到了 PingCAP，今日頭條的 offer 以及螞蟻金服的口頭 offer。

準備過程

我自己是大學畢業後在老東家幹了兩年多，老東家算是一家”小公司”（畢竟這年頭沒有 BAT 或 TMD 的 title 都不好意思報出身），畢業這兩年多我也沒有在大廠待過，是以找坑的時候是非常非常虛的。迫于心慌，我好好思考了一陣來給自己打氣，當時真正找坑和準備面試的過程大概分為這幾個階段：

• 反思：自己是不是真的要離職，假如不離職，在老東家接下來應該做什麼才能繼續提升？
• 定位：我在硬性技能（編碼、架構）上的長處在哪？我在軟技能（溝通，團隊）上的長處在哪？這步順帶寫了履歷
• 尋找平台：哪些平台能同時滿足：1、有挑戰有上升空間；2、符合我的定位方向；3、團隊氛圍和老東家一樣好（或更好）
• 找人内推：基本都是在 v2 上找的（誠摯感謝各位幫助我内推的大佬）
• 面試談 offer

定位這一步其實花了好幾天時間，我先是梳理了自己的項目經曆和工作内容的專長，把 Java + Golang，做過的面比較廣（業務，中間件，基礎架構都做過）以及對 Kubernetes 雲原生有專長和興趣作為自己的“硬招牌”。然後把學習能力強，喜歡溝通合作，渴望挑戰作為我的“軟招牌”，最後把自己定位成一個“在過往經曆中展現出了過人學習能力和鑽研能力，同時渴望挑戰，不願意呆在舒适區”的形象（媽呀，打這段話的時候太羞恥了！）。

這個過程中，我的方法論是“換位思考”。自己過去也面試過不少人（是以平時公司讓我去面試，雖然累點苦點，但也都是積累呀），并且也和 HR 以及放出 HC 的業務方聊過我們希望放什麼樣的人進來。是以全程都在以面試官的心态來考察自己：

假如我是面試官，我會招怎樣的人進來做我的同僚？

舉幾個例子，下面都是我在這個過程中考慮過的問題（當然隻是我自己的喜好）：

• 對于一個畢業兩年多的人，我最希望他有什麼特質？這個階段的人其實還是“空杯”，我希望他有很強的學習能力和進取心，給自己部門培養出一個超級生産力；
• 什麼樣的行為會讓我“讨厭一份履歷”：把每個項目都大寫特寫，尤其是陳述細節沒有重點；羅列架構當能力，用過了一類場景的架構就覺得能解決一類業務諸如此類；
• 面試的時候我會偏向于問哪些問題？一是履歷上寫了“了解”或“精通”的語言與中間件；二是履歷上寫得比較有趣，又沒有完全交代清楚的項目。

定位之後，我要找的下一個位置基本鎖定在了 PaaS、雲原生、中間件方向。那接下來就是找坑了，這段時間“寒冬論”炒的火熱，好坑确實挺難找，最後兜兜轉轉找了四家的内推：Shopee（新加坡）、PingCAP、頭條、螞蟻。Shopee 那邊挺遺憾的，12 月初投完履歷後在 1 月初進行的第一輪 HR Screen，而當時另幾家面試已經臨近尾聲，于是選擇了推掉，後來确認是 12 月 Shopee 正好在休假，會說中文的 HR 都恰好不在，這也算是機緣巧合了，Shopee 給我的感覺（雖然隻有一面）是非常為員工考慮，HR 小姐姐很客觀地幫我梳理了很多去新加坡會帶來的利弊得失。

這幾家的履歷投遞出去之後，我着重把履歷裡“埋的幾個坑”，也就是自己寫了“了解并掌握”的語言與中間件以及專門用來勾引面試官問的項目好好複習了一遍。事後發現這一步還挺關鍵的，很多知識性的内容要是不複習一下真就全忘了，這也算臨陣磨槍，不快也光了吧。

接下來就進入正題，逐家講一下自己的面試體驗：

• 螞蟻 - 容器排程方向（CTO線）
• 頭條 - 工程效能方向
• PingCAP - Cloud 方向

螞蟻

面試前

螞蟻的面試挺獨特，每輪面試都沒有 HR 約時間，一般是晚上 8 點左右面試官來一個電話，問是否能面試，能的話開始面，不能就約一個其它時間。

全程 6 面，前五面技術面，電話面試，最後一面是 HR 面，現場面。

一面

• 介紹一下自己。
• 問項目經曆，聊“資料同步”。
• 接着聊上了 Kubernetes 的項目。
• 有沒有什麼鑽研得比較深得技術？（我：Kubernetes，Golang，Prometheus，Java）

• Kubernetes 的架構是怎麼樣的?

  這個問題很大，拆成 apiserver、controller、kubelet、scheduler 講了一下。

• Golang 與 Java 的比較。

  這個問題又很大，當時主要對比了 VM、協程支援、面向對象和泛型的差別、以及自己對各自使用場景的一些了解。

• Golang 的 gc 算法。

  知道是三色标記，不過細節說不上來。

• 從無限的字元流中，随機選出 10 個字元。

  沒見過也沒想出來，查了一下是蓄水池采樣算法，經典面試題，沒刷題吃虧了。

• 怎麼擴充 kubernetes scheduler，讓它能 handle 大規模的節點排程？

  單節點提速：優選階段随機取部分節點進行優選；水準擴充 scheduler 節點，Pod 做一緻性 hash 來決定由哪個 scheduler 排程。

• 你有什麼想問我的？

一面其實有點僵，我自己完全沒放開，面試官對我的回答沒有什麼回報和深入，都是“哦好的”然後就過了。是以我當時面完覺得自己其實已經挂了（我自己要是對候選人不感興趣，有時候也就問完問題走個過場溜了），後來收到二面電話着實吃驚了一下。

二面

• 先聊了聊項目。
• 給 Prometheus 做了哪些改動？
• 自研配置中心，具體做了哪些内容？

• 有用過 MySQL 的什麼進階特性嗎？

  這裡不太了解，我問什麼算進階特性，面試官就切換到了下一個問題。

• 配置中心的核心資料表是怎麼設計的？

• 為什麼在業務裡用 Redis，Redis 有什麼優點？

  單線程：并發安全；高性能；原語與資料結構豐富；采用廣泛，踩坑成本低。

• 對 Redis 裡資料結構的實作熟悉嗎？

  說了一個 zset 跳表。

• 用過 Redis 的哪些資料結構，分别用在什麼場景？
• Java 初始化一個線程池有哪些參數可以配置，分别是什麼作用？

• 自己寫的 Java 應用調優過哪些 JVM 參數，為什麼這麼調優？

  這個問住了，我隻知道最大堆最小堆，開 G1，開 GC 日志以及 OOM dumper 這些基本的。

• 用 Jetty 的時候有沒有配什麼參數，為什麼這麼配？
• Jetty QTP 等待隊列配置成無限的話，你覺得好嗎？會有什麼問題嗎？
• 用過 Linux Bash 裡的哪些指令，分别用它們幹嘛？
• 一道筆試題：需要在給的連結中作答，不能 Google，不能跳出, 不能用 IDE。

題目是這樣的：

啟動兩個線程，一個輸出 1、3、5、7……99，另一個輸出 2、4、6、8……100 最後 STDOUT 中按序輸出 1、2、3、4、5……100
           

我：我用 Go 實作吧。

面試官：不可以，用 Java 的 notify 機制實作。

我：（還沒意識到問題的嚴峻）那我用 Java BlockingQueue。

面試官：說不可以，要求用 Java 的 wait + notify 機制來實作。

我完全沒寫過 wait + notify，隻能表示不會（菜雞本雞了），面試官說那行吧你可以用 go 寫。

最後用 go channel 實作了一版，不過給的網頁上不能運作代碼，也不知道寫得對不對，然後面試結束。

這一輪面試官延續了一面的風格，問完一題就趕忙下一題了，似乎沒有表現出對我的回答有興趣或認可。是以這輪面完，我又覺得自己挂了……

三面

• 依然先聊項目。

• 對監控警報的項目很感興趣，問了挺多細節，最後問了一個問題：現在要你實作一個語義不弱于 PromQL 的查詢語言，你能實作嗎？

  這裡雖然看過一些 Prometheus 的代碼，但其實對 PromQL 的 lexer 和 parser 部分沒有細看，還好之前因為資料同步項目裡想寫聲明式 Stream SQL 研究過一點 ANTLR，用 ANTLR 寫文法 + AST 周遊塞查詢邏輯給糊弄過去了。

• 問我覺得做得最深入的項目是什麼？

  當然是資料同步（狗頭）。

• 聊資料同步項目（這個很符合我的預期，哈哈哈哈）。

• 問 Linux 掌握得怎麼樣？

  沒有系統學習過，基本上是自己運維踩坑積累的。

• 問 Golang 掌握得怎麼樣？

  用了半年，看過 effective go。

• 問算法掌握得怎麼樣？

  到圖為止都可以。

• 問最短路算法。

  隻記得 Dijkstra 了，描述了代碼流程。

• Kubernetes 掌握得怎麼樣?

  不怎麼樣，沒有自己寫過 controller 和 scheduler，但是對概念都很熟悉，看過 xxx 這幾部分的源碼。

• Kubernetes 的 exec 是怎麼實作的?

  這個問題正中下懷，之前寫了 PingCAP 的小作業正好對這塊特别熟悉。

這輪聊得順暢多了。同時發現螞蟻的面試官似乎挺喜歡讓你自己評價自己的：“你覺得自己 xxx 掌握得怎麼樣？”（隻有五位面試官，樣本不夠大，不能作數哦），這類問題其實我慌得要死，怕自己吹過頭了答不上來，面試挂了事小，丢了面子事大。早知道就預習一下怎麼吹噓自己了。

四面

• 介紹一下自己。
• 覺得自己基礎知識掌握怎麼樣？
• 平時一般會用到哪些資料結構？
• 連結清單和數組相比，有什麼優劣？
• 如何判斷兩個無環單連結清單有沒有交叉點？
• 如何判斷兩個有環單連結清單有沒有交叉點？
• 如何判斷一個單連結清單有沒有環，并找出入環點？
• TCP 和 UDP 有什麼差別？
• 描述一下 TCP 四次揮手的過程中 TCP 有哪些狀态？
• TCP 的 LISTEN 狀态是什麼？
• TCP 的 CLOSE_WAIT 狀态是什麼？
• 建立一個 socket 連接配接要經過哪些步驟？
• 常見的 HTTP 狀态碼有哪些？
• 301 和 302 有什麼差別？
• 504 和 500 有什麼差別？
• HTTPS 和 HTTP 有什麼差別？
• 寫一個算法題：手寫快排。

這一輪全程問的基礎知識，基礎紮實的話就沒問題了，不過個人感覺有一點像校招的問法。

五面

• 介紹一下自己。
• 在 Kubernetes 上做過哪些二次開發?
• 自己用 Helm 建構過 chart 嗎？有哪些？
• 有沒有考慮過自己封裝一個面向研發的 PaaS 平台？
• 配置中心做了什麼？
• 為什麼不用 ZooKeeper？
• 配置中心如何保證一緻性？

• Spring 裡用了單例 Bean，怎麼保證通路 Bean 字段時的并發安全？

  用并發安全的資料結構，比如 ConcurrentHashMap；或者加互斥鎖。

• 假如我還想隔離兩個線程的資料, 怎麼辦？

  ThreadLocal，然後舉了個例子。

• Golang 裡的逃逸分析是什麼？怎麼避免記憶體逃逸？

  這個不知道，認慫了。

• 對比一下 Golang 和 Java 的 GC。

  答了一下 CMS、G1和三色标記，我對比的點是 JVM 有分代回收，Go 的 Runtime 沒有，沒能深入地講。

• Golang 的 GC 觸發時機是什麼？

  門檻值觸發；主動觸發；兩分鐘定時觸發。

• 有沒有寫過 Kubernetes 的 Operator 或 Controller？（我：沒有寫過）

• 談一談你對微服務架構的了解。

  大體思路“微服務本質是人員組織架構演進與關注點分離”。

• 談一談你對 Serveless 的了解

  大體思路“Serverless 是繼 Docker 與容器編排之後的又一次應用開發與基礎設施提供方之間的邊界劃分”。

• 你認為 Serverless 是未來嗎？為什麼？

  大體思路“是雲服務的未來，把蛋糕從企業的IT、運維與中間件部門切走，形成規模效應，做得越多賺得越多；公司内的話 Serverless 能夠幫助加速前台業務疊代，但對中背景的收益還看不到，未來可能會有比 Serverless 更适合中背景的架構”。

• 面試官：最後你有什麼要問我的？
• 我：為什麼足足安排了五輪技術面，而且其中有兩輪似乎和 Kubernetes 沒有關系啊？
• 面試官：我們覺得你做過的東西挺多的，各個方向都想讓你嘗試一下（我的内心：……）。
• 我：那這輪是最後一輪技術面嗎？
• 面試官：不一定（我的内心：……）。

後續還問了面試官一些業務相關的問題，就不贅述了。

五面最後的三個吹水問題我還挺感興趣，可惜面試官隻是聽我講，沒有跟我讨論。還有就是問了面試官才知道，二面四面的面試官是 PaaS 平台那邊的，是以主要問 Java 沒有涉及到 Kubernetes 和 Go。

六面

HR 面，之前就聽說過阿裡系的 HR 是來“聞味道的”（看你是否适合阿裡的風格），而且有一票否決權。是以還是挺有壓力的。

• 問經曆。

• 為什麼要考慮出來看看呢？

  金句：”現在自己的技術成長有點碰到瓶頸，加上一直對您公司欽慕有加”

• 現在公司的主營業務是什麼？（這塊往技術上問了很多，感覺是想考察我解釋複雜問題的能力）
• 現在帶人嗎？report 層級是怎樣的？
• 對自己這幾年的經曆滿意嗎？
• 覺得自己有什麼缺點？
• 碰到過什麼很挫敗的事情嗎？
• 未來的職業規劃是怎樣的？
• 看機會的時候，主要考慮的是待遇、平台、人員還是什麼其他因素？
• 現在的待遇如何？
• 有什麼想問我的？

整體聊了 40 多分鐘，話題挺廣的，面試官也說了系統部這邊壓力挺大的，優秀的人才才能留下來。個人覺得 HR 面裡除了談薪酬的部分沒有什麼可準備的，想說什麼直說就行。因為到了 HR 面至少證明你的技術沒什麼問題，直說出來友善 HR 判斷兩邊的價值觀是否合拍，假如真的不合拍，那其實在 HR 這一面挂了比起進去之後再後悔又跳槽要好很多，畢竟大家都不喜歡頻繁跳槽的履歷。

小結

一些主觀評價：

• 面試難度：正常
• 面試體驗：正常
• 問題偏向：基礎知識，開發常識，技術見解

螞蟻的面試風格比較“高冷”，面試官給我的一緻感受就是很強，卧虎藏龍。面試内容上在基礎知識部分相對考察得多一些，沒有偏門和獵奇的問題，基礎知識紮實的同學可以大膽投投看螞蟻。

頭條

面試前

頭條每次面試前會有 HR 約時間，并提前發一個 zoom 位址過來，三場技術面與一場 HR 面全都是視訊面試。不得不說視訊面試體驗比電話面試好很多（尤其是對我這種很關注面試官反應的），假如有 HR 同學看到這篇文章，推薦考慮一下用視訊面試取代電話面試，效率會更高。

頭條的三場技術面風格都很類似：

• 問項目，抓出一些你擅長的領域或場景
• 問系統設計題，每題都會不斷深化需求讓你應變和權衡
• 問一道算法題(不難不偏)，先看思路，再要求寫一下僞代碼看邊界條件能不能一次過

這個面試流程我自己也一直在用，尤其是系統設計加上不斷的需求變更，能比較全面地考察後端的基本功和工程思維。是以頭條的面試套路很對我胃口，甚至好多類似的問題我自己也都問過候選人。

一面

• 介紹一下自己，為什麼選擇出來看看機會？
• 聊項目，警報怎麼做的，統一接入監控項怎麼做的？
• 聊項目，配置中心項目，問實時配置推送怎麼做？
• 讨論為什麼選擇所有的元件依賴放在配置中心中控制？

• 我現在要做一個限流功能，怎麼做？

  令牌桶。

• 這個限流要做成分布式的，怎麼做？

  令牌桶維護到 Redis 裡，每個執行個體起一個線程搶鎖，搶到鎖的負責定時放令牌。

• 怎麼搶鎖？

  Redis setnx。

• 鎖怎麼釋放？

  搶到鎖後設定過期時間，線程本身退出時主動釋放鎖，假如線程卡住了，鎖過期那麼其它線程可以繼續搶占。

• 加了逾時之後有沒有可能在沒有釋放的情況下，被人搶走鎖

  有可能，單次處理時間過長，鎖洩露。

• 怎麼解決？

  換 ZooKeeper，用心跳解決。

• 不用 ZooKeeper 的心跳，可以怎麼解決這個問題呢？

  每次更新過期時間時，Redis 用 MULTI 做 check-and-set 檢查更新時間是否被其他線程修改了，假如被修改了，說明鎖已經被搶走，放棄這把鎖。

• 假如這個限流希望做成可配置的，需要有一個背景管理系統随意對某個 API 配置全局流量，怎麼做？

  在 Redis 裡存儲每個 API 的令牌桶 key，假如存在這個 key，則需要按上述邏輯進行限流。

• 某一個業務中現在需要生成全局唯一的遞增 ID，并發量非常大，怎麼做？

  snowflake（這個其實答得不好，snowflake 無法實作全局遞增，隻能實作全局唯一，單機遞增，面試結束後就想到了類似 TDDL 那樣一次取一個 ID 段，放在本地慢慢配置設定的政策）。

• 算法題，M*N 橫向縱向均遞增的矩陣找指定數？

  隻想到 O(M+N) 的解法，補充：這幾天刷 leetcode 碰到這題了，240. Search a 2D Matrix II[4]，辦法是從左下角或右下角開始查找。

• 有什麼想問我的？

限流，分布式鎖，UUID 都屬于後端的經典面試題，這輪面試的參考價值挺大的。

二面

• 平時用的工具鍊和技術棧是什麼？

• Golang 踩過坑嗎？

  答了之前 PingCAP 面試時面試官問的 for-range 裡的 go-routine 閉包捕獲問題。

• 這段 Golang 代碼有沒有 bug（還是一個 for-range 的坑）？

  有 bug，for-range 的 value 引用拷貝問題。

• Java 中 HashMap 的存儲，沖突，擴容，并發通路分别是怎麼解決的？

  Hash 表，拉鍊法（長度大于8變形為紅黑樹），擴容*2 rehash，并發通路不安全。

• 拉鍊法中連結清單過長時變形為紅黑樹有什麼優缺點？

  優點：O(LogN) 的讀取速度更快；缺點：插入時有 Overhead，O(LogN) 插入，旋轉維護平衡。

• HashMap 的并發不安全展現在哪？

  拉鍊法解決沖突，插傳入連結表時不安全，并發操作可能導緻另一個插入失效。

• HashMap 在擴容時，對讀寫操作有什麼特殊處理？

  不知道。

• ConcurrentHashMap 是怎麼做到并發安全的？

  segment 分段鎖。

• Java 有哪些鎖機制，分别有什麼特點？

  Synchronized、可重入鎖。

• 知道 CAS 嗎？Java 中 CAS 是怎麼實作的？

  Compare and Swap，一種樂觀鎖的實作，可以稱為“無鎖”（lock-free），CAS 由于要保證原子性無法由 JVM 本身實作，需要調用對應 OS 的指令（這塊其實我不了解細節）。

• MySQL 的存儲引擎用的是什麼？（InnoDB）為什麼選 InnoDB？

  幾乎所有公司用 MySQL 都用 InnoDB，降低踩坑成本；聚簇索引，MVCC。

• MySQL 的聚簇索引和非聚簇索引有什麼差別？

  聚簇索引的葉子節點是資料節點（比如定義了主鍵時的主鍵索引），非聚簇索引葉子節點是指向資料塊的指針。

• B+樹和二叉樹有什麼差別和優劣？

  B+樹是多叉樹，深度更小，B+樹可以對葉子節點進行順序周遊，B+樹能夠更好地利用磁盤扇區；二叉樹：實作簡單。

• 針對一個場景設計索引，具體場景忘記了，反正考察的是聯合索引與列選擇性的知識。
• 現有一個新的查詢場景, 要怎麼解決？

• 假如要查 A in () AND B in (), 怎麼建索引？

  隻給選擇性高的一列建索引，這裡因為兩個都是範圍查詢是以另一個是走不到索引的（這裡答的不好，其實也可以建聯合索引然後用 （A,B) in ((1,2),(3,4)) 的方式去查）。

• 查 A in () AND B in () 時，MySQL 是怎麼利用索引的？

  先走一個非聚簇索引，查詢出行資料後再用另一列回表做篩選。

• 假如查詢 A in ()，MySQL 是針對 N 個值分别查一次索引，還是有更好的操作？

  不知道，有了解的同學可以留言（補充，@BillyLu 貼出了文檔 equality-range-optimization[5]，大意是對非唯一索引 MySQL 會使用 index dive 的方式估算這個 range index 涉及的行數，結合 where optimization[6] 中說明的在走 index 時假如涉及行數過多會走 full table scan，那麼假如 estimation 認為這次 IN 不夠好，是會走全表掃描的。不知道除此之外，面試官還有沒有想考察的點）。

• 用過 Redis 的哪幾種資料結構？（都用過）ZSET 是怎麼實作的？

  跳表。

• zrange start，stop，總長度為 n，複雜度是多少？

  O(logN)（答得不好，實際是 O(M+log(N))， M 是結果集基數 stop-start）。

• Kafka 的消費者如何做消息去重？

  MySQL 去重、Redis 去重、假如場景量極大且允許誤判，布隆過濾器也可以。

• 介紹一下 Kafka 的 ConsumerGroup

  挺長的，略。

• Kubernetes 和 Docker 用得怎麼樣？（我：在公司推行布道）
• 給它們貢獻過代碼嗎？（我：沒有……）

• 時序型資料庫的存儲結構是怎麼樣的？

  講了 Prometheus 1.x 和 2.x 的存儲結構。

• LSM 樹了解嗎？是一種什麼存儲結構？

  Log-Structured Merge Tree，犧牲讀性能換取性能，RocksDB、HBase、Cassandra 都在用，結構有點忘了，隻說了先寫 memtable 再刷盤成 sstable。

• 在生産中用過 Cassandra 和 RocksDB 嗎？量有多大？

  用過，Cassandra 存調用鍊，RocksDB 做 flink 和 Kafka Stream 的本地狀态存儲。

• Cassandra 的墓碑機制是什麼?

  不知道，對 Cassandra 停留在使用階段。

二面問了好多中間件的基礎知識，最後都沒有時間問算法了。面完之後心裡就想：頭條的面試真是耿直啊，Java 的 HashMap、鎖機制、CAS 到 MySQL 的索引，Redis 的 zset，再到 LSM 樹，全都是後端或中間件相關的熱門面試題。當然這些問題熱門也是有原因的，即使候選人準備過，多扣一點細節也能很快就能看出來候選人是真的了解還是僅僅隻是看了相關資料。

三面

• 聊項目和工作經驗。
• 用 Kubernetes 的過程中踩過哪些坑？

• 考慮一個業務場景：頭條的文章的評論量非常大，比如說一篇熱門文章就有幾百萬的評論，設計一個後端服務，實作評論的時序展示與分頁。

  我：需不需要支援頁碼直接跳轉？

  面試官：支援和不支援兩種場景都考慮一下。

  我：不需要支援頁碼翻頁就傳評論 id 用 offset 翻頁

• 假如用 id 翻頁的方式，資料庫表如何設計？索引如何設計？

  （文章id，評論id）建聯合索引，評論 id 需遞增。

• 假如量很大，你覺得需要分庫分表嗎？怎麼分？

  需要分，分表有個權衡，按文章 id 分表，讀邏輯簡單，但寫有熱點問題；按評論 id 分表，讀邏輯複雜，但寫壓力就平均了。寫是要首先保證的，而讀總是有緩存等方案來折中，是以按評論 id 分表好。

• 分庫分表後怎麼查詢分頁？

  每張表查 N 條資料由 client 或 proxy merge。

• 分庫分表後怎麼保證主鍵仍然是遞增的?

  講了 TDDL 的辦法：有一張專門用于配置設定主鍵的表，每次用樂觀鎖的方式嘗試去取一批主鍵過來配置設定，假如樂觀鎖失敗就重試。

• 現在需要支援深分頁，頁碼直接跳轉，怎麼實作？

  不能做精準深分頁，否則壓力太大，找産品進行妥協，在 50 或 100 頁後資料分頁是否可以不完全精确，假如可以，那麼緩存深頁碼的起始評論 id。

• 瞬時寫入量很大可能會打挂存儲，怎麼保護？

  斷路器。

• 斷路器内部怎麼實作的？

  可以用 ringbuffer。

• 斷路器會造成寫入失敗，假如我們不允許寫入失敗呢？

  先寫進消息隊列，削峰填谷異步落庫。

• 算法題：N 場演唱會，以 [{startTime, endTime}…] 的形式給出，計算出最多能聽幾場演唱會？

  先講了思路，按 endTime 升序排列，再順序取最多場次。

• （講完思路之後）螢幕共享給我，用你最熟悉的語言把這個算法實作

  用 Go 實作了一版。

• 你用了貪心法，貪心可能會存在什麼問題？

  局部最優，在這個問題裡，隻能找到一個可能解，無法找到所有排列方式。

我覺得三面這個架構設計問得還不錯，一個問題把後端的工程能力考的很全面了。

HR 面

大同小異，問經曆，問離職原因，問職業規劃，問待遇，問期望。

小結

• 面試難度：正常
• 面試體驗：挺好
• 問題偏向：架構設計，算法

頭條面試流程很專業：每輪都會提前約好時間，面試時長都在40~50分鐘，按時開始面，每輪之後發回報短信邀請候選人評價面試，精準地過兩天再約下一輪。整個像一台精密運作的機器。頭條的面試我個人挺欣賞的，考察得比較全面，面試官會抓住你沒有說清楚的地方來深入或者變換場景讓你應變，大家可以試試看去面一下，即使不打算去也可以作為一次免費的能力評定。

再說說面試官，每位面試官都聽得出來是在一線寫代碼的，而且很認真地在聽我說話（這當中有視訊的功勞，我可以看到面試官在認真聽），感覺工作中也都會是好相處好合作的類型。

PingCAP

面試前

PingCAP 的履歷響應是最快的，内推之後第二天 HR 小姐姐就聯系了我。電話接通之後先是簡單聊了一下人生，然後就是社招三問 [“為啥離職啊？”，“現在待遇咋樣啊？”，“期望待遇咋樣啊？”]，天知道這通電話是我開始投履歷之後的第一通電話面試，之前還完全沒有準備過類似的問題，隻能稀裡嘩啦用[“現在自己的技術成長有點碰到瓶頸，加上一直對您公司欽慕有加”，”我現在待遇是xxx但我司除了 base 之外還有xxx以及我馬上要提薪了”，“其實比起待遇我更看重平台和挑戰（狗頭），但是基本的薪資需求我還是希望能xxx”]這樣和稀泥應付過去。内心稍稍平靜之後小姐姐跟我講了講我意向部門的結構和主體業務，然後交代了一下接下來的面試流程，約了“一面”并且加了微信。

“一面”加了引号，這是因為“一面”其實是在微信上布置了一個小項目，然後約定好時間驗收。

這裡要特别感謝一下 PingCAP 的 HR 小姐姐，加了微信之後全程幫助我協調面試時間并不厭其煩地回答我各種奇奇怪怪的問題，最後談 offer 的時候還給我準備了一個驚喜。面試體驗直接滿星<3!

一面

早就聽說 PingCAP 一面要寫小項目，我自己心裡其實是躍躍欲試的。面試官給的項目要求大體是這樣：

Kubernetes 容器化之後應用容器裡幾乎沒有什麼可用的調試工具，可以利用容器 Namespace 共享的思路，啟動一個包含各種調試工具（比如 netstat，gdb）的容器，加入到 Pod 的 pid、net 等 Namespace 中， 實作對任意 Pod 的 debug 功能。現在希望利用 kubectl plugin 機制實作一個插件，用于 debug 任意一個 Pod 裡的容器，達到 kubectl exec 的使用體驗。

當時因為工作日抽不出時間，就隔了幾天到周五晚上開始寫，周六晚上寫完并且把項目位址[2]分享到了 Reddit[3] 上。沒想到運氣不錯收了 100 多個 star，這下我就覺得“哦豁，這輪應該穩了吧！”（結果後來發現這幾乎是我唯一一把覺得自己“穩了的”面試……）

二面

二面是一位 Cloud 方向的前輩面我，全程大概微信語音聊了50多分鐘：

• 問項目經曆，聊了兩個項目。

• 對 Kubernetes 了解怎麼樣，看過源碼嗎？

  Kubernetes 的代碼我以前其實隻看過 kubelet，臨陣磨槍的時候把 apiserver、scheduler、controller-manager 都看了一遍，笑容漸漸出現。

• Kubernetes 的 Service 是什麼概念，怎麼實作的？
• 你剛說到 Informer，Informer 是怎麼實作的，有什麼作用？
• StatefulSet 用過嗎？有什麼特點？
• StatefulSet 的滾動更新是如何實作的？

• 現在我們希望隻更新 StatefulSet 中的任意個節點進行測試，可以怎麼做？

  這題沒有思路，隻好強答用“兩個 StatefulSet”，後來一想起一個新的 StatefulSet 那 PV 裡的資料就丢了，其實正确辦法是利用 partition 機制，笑容漸漸消失。

• Kubernetes 的所有資源約定了版本号，為什麼要這麼做？

  第二個拿不準的問題，我面試前就反複告訴自己“不要強答”以及“不知道的題就講思路”，于是就說這塊代碼确實沒看過，但是根據微服務 API 的設計理念，版本号的作用有巴拉巴拉。答完似乎面試官還算滿意，于是又往下挖了一句：

• 假如有多幾個版本号并存，那麼 Kubernetes 服務端需要維護幾套代碼？

  這題完全不知道，内心逐漸焦灼，立馬走老套路“這我沒看過 Kubernetes 代碼怎麼寫的無法确定（想表達自己真正看過代碼才會确認，凸顯自己嚴謹……我的媽呀），但假如由我來寫這份代碼（裝作非常自信），我會隻會維護一份最新的 Model，然後設計對應一個版本段的 Adpater 将老版本的 Model 轉化過來巴拉巴拉”。到這裡我已經虛的不行了。

• OK，那接下來我們聊聊 Golang （我：長舒一口氣)
• 看一下這段代碼有沒有問題（一段 golang for-range 裡 goroutine 閉包捕獲的代碼），為什麼?
• goroutine 是怎麼排程的？
• goroutine 和 kernel thread 之間是什麼關系？
• 有什麼想問我的？

面完之後感覺答得一般，心裡有點忐忑。結果第二天 HR 小姐姐就來安排三面了，長舒了一口氣。

三面

三面是和整個大部門的 Leader 聊，面試官很能聊（聲音還很好聽！）而且技術非常全面，全程大概微信語音聊了80多分鐘：

• 給我介紹 PingCAP 相關團隊的職責與挑戰。
• 聊為什麼出來看機會，以及未來的職業規劃。
• 聊我之前做的一個資料同步的項目，大概内容是訂閱 MySQL Binlog，sink 到搜尋索引、分庫分表以及業務事件訂閱流中。
• 為什麼資料同步裡選擇了 xxxx 開源項目，優勢在哪？
• 訂閱分庫分表的 Binlog 怎麼訂閱？
• 分庫分表的資料源中假如存在主鍵沖突要怎麼解決？
• 怎麼保證下遊對 Binlog 的消費順序？
• 如何在下遊保證消費時的事務原子性？

• 描述了一下 TiDB 的 Binlog 架構，問這種場景下怎麼保證 Binlog 順序

  聊一個上了 Kubernetes 的項目，問了一些細節和坑。

• 用 Kubernetes 之後，解決了哪些問題？
• 聊我之前做的監控警報項目，問背景和産出。
• Prometheus 單執行個體資料量級 hold 不住了，有什麼解決方案？
• 有什麼想問我的？

履歷裡的“資料同步”這個項目我是好好複習過自己當年寫的調研文檔和架構文檔的，也做了被問的準備（換位思考，是我我也問。這個其實就是我專門希望面試官來挖細節的項目）。最後确實被問最多的就是這個項目，運氣真的不錯。

四面

四面到了現場面，有兩位面試官一起跟我聊，大約聊了 40 多分鐘：

• 聊“配置中心”項目的細節。

• 為什麼不用 ZooKeeper，要自己再寫一個“配置中心”？

  這個問題讓我措手不及，我隻好坦白：當時年輕，想刷經驗，事後才領悟到不要重複造輪子，當然最後系統的産出也不錯（後面這兩句是我臨時加的，不能讓面試官覺得我是一個不看全局隻顧自己刷經驗的人）。

• 配置中心怎麼做服務發現的？怎麼做 failover 的？
• 用 Kubernetes 碰到過哪些坑？
• 對 Prometheus 做了哪些改動？
• 對 Alertmanager 做了哪些改動？
• 監控系統怎麼做“自監控”？
• 跨機房的網絡問題怎麼監控？
• 有什麼想問我們的？

四面是純項目，裡面的經驗就不太通用了。但這裡面有個細節，就是到中途的時候兩個面試官互相對了一下“還有什麼想問的嗎？”我意識到面試官們想問的問題不多了，可時間大約才過了20分鐘（面試時間過短是一個 bad smell）。于是之後幾個監控的問題我都盡量說得很細，同時順便提一下“還有一個方面我們當時也做了挺多工作”，暗示面試官往下挖的線索。不知道這招有沒有奏效，反正這一面算是有驚無險過啦。

五面

技術面到四面就結束了，五面是創始人面（有幸和崔秋大佬聊了20多分鐘人生），面完之後就是 offer call 了。

PingCAP 小結

一些主觀評價：

• 面試難度：正常
• 面試體驗：我給滿分
• 問題偏向：項目經曆、工程能力

這裡真的想誇一下 PingCAP（因為面試體驗超棒呀！）。投 PingCAP 的初衷是覺得這個團隊的工程師文化非常濃，大牛雲集，同時 TiDB 夠牛逼，項目開源的模式我内心也很認可。隻是挂羊頭賣狗肉的公司也不少，好多 JD 上寫着工程師文化濃郁，其實很多根本不是那麼回事兒。但是經過 PingCAP 的五輪面試之後，我實打實地感受到了工程師文化：面試裡沒有任何一個“刁難人的問題”，每一位面試官感興趣的是我的工程思維、學習能力、技術見解，同時還非常熱衷于與我讨論和深挖一些坑與技術決策。這種感覺就很爽：面試官是懂我的，我作為工程師的思維能力與技術見解得到了認可與尊重。這種氛圍是口号喊不出來的，因為它的硬性名額就是這其中的每一個人要熱愛技術并且工程經驗豐富。

總結

回頭看面試的過程，有好多不盡如人意的地方，不過最後能夠拿到三家的 offer 還是很幸運。最後再做一些補充性的小結：

一些經驗：

• 履歷裡寫了的項目，以及熟練程度在“掌握”以上的領域與中間件要好好準備，當面試官問你一個偏門的問題時，他内心其實也沒希望你能答上來。而當面試官問你履歷上涉及的問題時，假如你答不上來，那面試官就覺得這個人要麼是眼界太低，會了一點就覺得自己掌握了，要麼是履歷造假在胡吹，這兩種都非常不利；
• 在上一條的基礎上，可以準備一個最得意的項目，在履歷上和面試過程中引導面試官往這塊聊；
• 面試前心裡可以準備一個方法論：明确面試官想招怎樣的人有哪些特質，在面試過程中努力表現出這些特質。這聽起來是句正确的廢話，但面試的過程不可控因素太多，有一個清晰的目标在腦子裡能幫你在手足無措時想到說什麼。舉個例子，有一輪中面試官問我有什麼問題時，我就問貴司的對應崗位會面臨哪些技術挑戰（當然要先說清楚這不是在質疑他們沒有挑戰，隻是自己渴望挑戰）。

一些各領域的資料與心得：

• System Design Primer，入門架構設計必看的一篇資料。看完之後提醒自己始終記得：架構設計的本質是深入了解業務場景之後用工程經驗做出最佳權衡。面試時的一個套路是先提綱挈領地把舍棄什麼來換取什麼講明白；
• 雲原生相關，Kubernetes Concepts[8] 部分建議再看一遍，源碼部分推薦看 apiserver 中的 CRD 部分與 aggregation layer、kubelet 的 pod 狀态同步、scheduler 的排程部分以及 Sample Controller[9] 如何寫一個自己的 controller
• 語言方面，推薦看書《Effective Go》《Effective Java》，都很薄。這兩本書我是以前看的，面試前沒有專門準備語言相關；
• 還有公衆号網際網路架構師裡面的文章，對我的幫助也挺大的，建議各位好好讀一下；
• 算法相關，這部分我純鶸，說實話我覺得大學裡那本教材《資料結構與算法分析》就寫得很不錯……至于 leetcode，面試前沒有刷過，最近為了練習 Rust 刷了60多題，并沒有碰到面試裡出現過的題目，看起來要刷 leetcode 的話就得走量多刷點，刷的少純拼強運了；
• Golang for range的坑，有兩輪面試都涉及到了這個話題，這裡貼一下。

到這裡就全寫完了，感謝您耐心地看完全文！

感謝您的閱讀，也歡迎您發表關于這篇文章的任何建議，關注我，技術不迷茫！小編到你上高速。

    · END ·

最後，關注公衆号網際網路架構師，在背景回複：2T，可以擷取我整理的 Java 系列面試題和答案，非常齊全。

正文結束

推薦閱讀 ↓↓↓

1.不認命，從10年流水線勞工，到谷歌上班的程式媛，一位湖南妹子的勵志故事

2.如何才能成為優秀的架構師？

3.從零開始搭建創業公司背景技術棧

4.程式員一般可以從什麼平台接私活？

5.37歲程式員被裁，120天沒找到工作，無奈去小公司，結果懵了...

6.IntelliJ IDEA 2019.3 首個最新通路版本釋出，新特性搶先看

7.漫畫：程式員相親圖鑒，笑屎我了~

8.15張圖看懂瞎忙和高效的差別！

一個人學習、工作很迷茫？

點選「閱讀原文」加入我們的小圈子！