面試前
頭條每次面試前會有 HR 約時間，並提前發一個 zoom 地址過來，三場技術面與一場 HR 面全都是視頻面試。不得不說視頻面試體驗比電話面試好很多（尤其是對我這種很關注面試官反應的），假如有 HR 同學看到這篇文章，推薦考慮一下用視頻面試取代電話面試，效率會更高。
頭條的三場技術面風格都很類似：
- 問項目，抓出一些你擅長的領域或場景
- 問系統設計題，每題都會不斷深化需求讓你應變和權衡
- 問一道算法題(不難不偏)，先看思路，再要求寫一下偽代碼看邊界條件能不能一次過
這個面試流程我自己也一直在用，尤其是系統設計加上不斷的需求變更，能比較全面地考察後端的基本功和工程思維。因此頭條的面試套路很對我胃口，甚至好多類似的問題我自己也都問過候選人。
一面
- 介紹一下自己, 為什麼選擇出來看看機會
- 聊項目, 警報怎麼做的, 統一接入監控項怎麼做的
- 聊項目, 配置中心項目, 問實時配置推送怎麼做
- 討論為什麼選擇所有的組件依賴放在配置中心中控制
- 我現在要做一個限流功能, 怎麼做? 令牌桶
- 這個限流要做成分佈式的, 怎麼做? 令牌桶維護到 Redis 裡，每個實例起一個線程搶鎖，搶到鎖的負責定時放令牌
- 怎麼搶鎖? Redis setnx
- 鎖怎麼釋放? 搶到鎖後設置過期時間，線程本身退出時主動釋放鎖，假如線程卡住了，鎖過期那麼其它線程可以繼續搶佔
- 加了超時之後有沒有可能在沒有釋放的情況下, 被人搶走鎖有可能，單次處理時間過長，鎖洩露
- 怎麼解決? 換 zk，用心跳解決
- 不用 zk 的心跳, 可以怎麼解決這個問題呢? 每次更新過期時間時，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. 辦法是從左下角或右下角開始查找.
- 有什麼想問我的?
限流，分佈式鎖，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, 大意是對非唯一索引 MySQL 會使用 index dive 的方式估算這個 range index 涉及的行數, 結合where optimization 中說明的在走 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分鐘，按時開始面，每輪之後發反饋短信邀請候選人評價面試，精準地過兩天再約下一輪。整個像一臺精密運作的機器。頭條的面試我個人挺欣賞的，考察得比較全面，面試官會抓住你沒有說清楚的地方來深入或者變換場景讓你應變，大家可以試試看去面一下，即使不打算去也可以作為一次免費的能力評定。
再說說面試官，每位面試官都聽得出來是在一線寫代碼的，而且很認真地在聽我說話（這當中有視頻的功勞，我可以看到面試官在認真聽），感覺工作中也都會是好相處好合作的類型。
總結
回頭看面試的過程，有好多不盡如人意的地方，不過最後能夠拿到offer ，還是很幸運。最後再做一些補充性的小結：
一些經驗：
簡歷裡寫了的項目，以及熟練程度在"掌握"以上的領域與中間件要好好準備，當面試官問你一個偏門的問題時，他內心其實也沒希望你能答上來。而當面試官問你簡歷上涉及的問題時，假如你答不上來，那面試官就覺得這個人要麼是眼界太低，會了一點就覺得自己掌握了，要麼是簡歷造假在胡吹，這兩種都非常不利；
在上一條的基礎上，可以準備一個最得意的項目，在簡歷上和麵試過程中引導面試官往這塊聊；
面試前心裡可以準備一個方法論：明確面試官想招怎樣的人有哪些特質，在面試過程中努力表現出這些特質。這聽起來是句正確的廢話，但面試的過程不可控因素太多，有一個清晰的目標在腦子裡能幫你在手足無措時想到說什麼。舉個例子，有一輪中面試官問我有什麼問題時，我就問貴司的對應崗位會面臨哪些技術挑戰（當然要先說清楚這不是在質疑他們沒有挑戰，只是自己渴望挑戰）；
讀者福利：私信筆者 【888】 即可免費領取筆者整理的Java後端面試題及Java架構師成長路線圖！！！
閱讀更多 Java肖先生 的文章
