頭條每次面試前會有 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 踩過坑嗎?
- 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 還是很幸運，最后再做一些補充性的小結：
一些經驗：
- 簡歷里寫了的專案，以及熟練程度在”掌握”以上的領域與中間件要好好準備，當面試官問你一個偏門的問題時，他內心其實也沒希望你能答上來，而當面試官問你簡歷上涉及的問題時，假如你答不上來，那面試官就覺得這個人要么是眼界太低，會了一點就覺得自己掌握了，要么是簡歷造假在胡吹，這兩種都非常不利；
- 在上一條的基礎上，可以準備一個最得意的專案，在簡歷上和面試程序中引導面試官往這塊聊；
- 面試前心里可以準備一個方法論：明確面試官想招怎樣的人有哪些特質，在面試程序中努力表現出這些特質，這聽起來是句正確的廢話，但面試的程序不可控因素太多，有一個清晰的目標在腦子里能幫你在手足無措時想到說什么，舉個例子，有一輪中面試官問我有什么問題時，我就問貴司的對應崗位會面臨哪些技術挑戰（當然要先說清楚這不是在質疑他們沒有挑戰，只是自己渴望挑戰）；
最后：
我把學習資料都整理在網盤了，獲取方式：點擊鏈接《Java面試BAT通關手冊》，覆寫了Java核心技術、JVM、Java并發、SSM、微服務、資料庫、資料結構等等，
獲取方式： 我把學習資料都整理在網盤了，獲取方式：點擊鏈接《Java面試BAT通關手冊》，覆寫了Java核心技術、JVM、Java并發、SSM、微服務、資料庫、資料結構等等，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/585.html
標籤：其他
上一篇：增長黑客招聘條件 JD