Java程序員兩年經驗斬獲頭條 Offer，技術槓槓的

 

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

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

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

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

一面

• 介紹一下本身, 爲何選擇出來看看機會
• 聊項目, 警報怎麼作的, 統一接入監控項怎麼作的
• 聊項目, 配置中心項目, 問實時配置推送怎麼作
• 討論爲何選擇全部的組件依賴放在配置中心中控制
• 我如今要作一個限流功能, 怎麼作?
• 令牌桶
• 這個限流要作成分佈式的, 怎麼作?
• 令牌桶維護到 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、微服務、數據庫、數據結構等等。