Java編碼
共 1 條筆記
2026-03-19 11:08
您的瀏覽器不支援 audio 元素。 📑 智慧總結 錄音資訊 時長 ：約 0小時 47分鐘 參與人數 ：約 2 人 內容型別 ：技術面試 錄音總結 本次是一場時長45分鐘的技術面試，分為35分鐘技術環節與10分鐘候選人提問環節，面試官Jeremy考察候選人Java編碼能力與系統設計能力，最終完成全部考核，結束面試。 面試流程與規則說明 * 面試環節劃分 ：總時長為45分鐘，其中實際技術考核佔35分鐘，開頭5分鐘與最後5分鐘留給候選人提問。面試分為編碼與系統設計兩個部分，主要考察候選人多維度技術能力。 * 工具使用規則 ：允許候選人使用Google搜尋技術文件，但禁止使用任何AI工具完成面試。 * 面試官背景介紹 ：面試官Jeremy已經在相關公司工作超過4年。 Java編碼面試：批次URL請求功能實現 * 初始需求說明 ：要求編寫Java方法，輸入為URL列表，輸出對應URL的GET請求響應體，允許候選人使用任意HTTP類庫。 * 開發過程調整 ：候選人遇到Java原生HTTP介面開發的除錯問題，面試官建議直接模擬響應，不用花時間除錯原生類庫。 * 併發最佳化調整 ：候選人最初為所有URL建立單個執行緒處理，面試官提醒如果處理10000個URL需要最佳化，候選人改為使用固定執行緒池，執行緒數量可根據CPU核心數動態計算。 * 編碼面試收尾 ：候選人調整後完成需求，面試官對程式碼截圖，編碼部分正式結束。 系統設計面試：生產級URL獲取服務設計 * 設計需求說明 ：要求將已驗證功能的POC（概念驗證）改造為可面向客戶、支援每天百萬級請求的生產API服務，客戶呼叫介面提交URL列表獲取對應響應，使用者來自全球各地。 * 基礎分層架構設計 ：候選人設計分為API層、快取層、資料儲存層：API層接收客戶請求，使用Redis做熱點URL快取加快響應速度，使用PostgreSQL儲存URL的訪問熱度統計，還可引入Elasticsearch支援搜尋功能。 * 流量控制方案 ：針對單使用者濫用場景，候選人提出對單個使用者設定請求速率限制，比如限制每分鐘最多10個請求，可採用滑動視窗或漏桶演算法實現。 * 突發流量最佳化方案 ：針對多使用者同時在峰值內發請求的場景，候選人提出透過Redis快取複用相同URL請求結果，降低後端負載，同時採用多機器叢集部署應對高吞吐量需求。 * 儲存內容說明 ：PostgreSQL中儲存URL本身以及該URL的訪問計數，用於統計熱門URL排序。 候選人向面試官提問環節 * 崗位日常工作諮詢 ：該崗位為通用後端崗位，還未分配到具體團隊，公司全公司採用敏捷開發模式。 * 日常工作內容說明 ：團隊採用Sprint迭代，每日站會同步進度，資深工程師需要驅動專案、解決阻塞問題、指導初級工程師，對接經理和資深工程師同步技術問題。 * AI工具使用政策諮詢 ：公司允許日常工作使用AI工具，並且在AI工具上投入大量資源，自研了Level Dev相關大模型，也允許使用GPT、Gemini等其他外部模型工具。 📅 章節概要 00:01:02 面試開場與基本情況溝通 雙方互相打招呼，候選人目前居住在悉尼，提前為可能出現的寵物狗干擾提前致歉。面試官對候選人的參與表示感謝。 00:01:50 面試流程與規則說明 面試官介紹本次面試分為編碼和系統設計兩個部分，總時長45分鐘，其中技術考核佔35分鐘，開頭和最後各留5分鐘給候選人提問。面試官詢問候選人偏好的程式語言，確認候選人選擇Java。面試官說明規則：允許Google搜尋文件，禁止使用AI工具，隨後介紹自己是Jeremy，已經在公司工作超過4年，要求候選人共享螢幕開始面試。 00:04:18 編碼需求釋出與初步開發 面試官提出編碼需求：編寫Java方法，輸入URL列表，返回對應GET請求的響應體，允許使用任意HTTP類庫。候選人提出需要Google搜尋HTTP相關類的用法，面試官表示允許，並且提出如果實現太複雜，可以模擬HTTP請求的響應，不需要真的傳送請求。候選人確認後開始編寫程式碼。 00:06:27 編碼開發與除錯調整 候選人開始編寫方法，依託IDE提示逐步開發，過程中遇到HTTP介面引數配置、語法的問題，面試官再次提醒如果實現太複雜，可以直接模擬響應，不需要糾結底層庫的除錯。候選人繼續完成原生HTTP請求的開發，完成後執行程式碼遇到協議不支援的錯誤。 00:15:33 調整為模擬實現並完成編碼 面試官提出不需要除錯底層庫問題，讓候選人自定義一個模擬的HTTP客戶端，返回對應URL的虛擬響應即可。候選人按照要求調整程式碼，完成模擬實現。面試官提出需求修改：要求支援輸入URL列表輸出響應列表，候選人確認後開始調整。 00:18:32 併發方案調整與編碼收尾 候選人考慮到併發需求，最初計劃為所有URL建立單個執行緒處理，面試官提問如果有10000個URL，單執行緒無法滿足效能要求，候選人意識到問題，改為使用Java執行緒池處理。候選人選擇固定執行緒池，提出執行緒數量可根據CPU核心數動態計算，完成程式碼調整。面試官讓新增兩個測試URL執行，隨後對程式碼截圖，編碼部分正式結束。 00:27:53 系統設計需求釋出 面試官進入系統設計環節，提出設計需求：將已經驗證可行的POC批次URL獲取功能，改造為面向客戶的生產API服務，要求支援每天百萬級請求，客戶呼叫介面提交URL列表，獲取對應URL的響應，使用者來自全球各地。候選人確認需求細節後開始設計。 00:32:22 候選人闡述基礎架構設計方案 候選人設計分層架構：最上層為API層，首先使用Redis快取熱點URL，加快響應速度，提升快取命中率；使用PostgreSQL儲存URL訪問統計資料，用於計算熱門URL；還可以引入Elasticsearch提供搜尋功能。候選人確認需求細節：客戶只需要獲取指定URL的響應，不需要後續其他操作。 00:35:23 流量控制與突發流量最佳化方案 針對單使用者濫用系統的問題，候選人提出採用滑動視窗或漏桶演算法做速率限制，可對單個使用者設定每分鐘最多10個請求的限制。針對多使用者同時在峰值傳送合法請求的場景，候選人提出透過Redis快取相同URL的請求結果，減少後端重複請求，同時採用多機器叢集部署提升整體吞吐量，Redis還可以作為叢集共享的快取中心，保證多節點快取一致性。 00:41:02 架構細節確認與面試考核結束 面試官詢問PostgreSQL中儲存的內容，候選人回答儲存URL和URL的訪問計數，用於統計熱門URL排序。面試官確認所有技術問題考察完成，留出時間給候選人提問。 00:43:33 候選人提問環節 候選人首先詢問該崗位的日常工作內容，面試官回答該崗位是通用後端崗位，暫時未分配到具體團隊，公司全公司都採用敏捷開發，日常會做Sprint迭代、每日站會，資深工程師需要驅動專案、解決阻塞、指導初級工程師，對接管理者和資深工程師。候選人接著詢問公司是否允許日常工作使用AI工具。 00:46:08 AI工具政策解答與面試結束 面試官回答公司允許日常使用AI工具，並且在AI工具研發投入了大量資源，自研了名為Level Dev的大模型工具，同時也允許員工使用GPT、Gemini等其他外部AI工具。候選人表示沒有其他問題，雙方致謝後結束面試。 ✨ 金句精選 “從設計點的檢視，我們應該 leverage 每種技術的優勢，然後儘量避開它的劣勢。” (執行策略) “資深工程師需要驅動專案，解決自己和團隊的阻塞，還要指導團隊裡的初級工程師。” (戰略洞見) 📋 待辦事項 無