1. 別急著罵“八股文”先想想它為什么存在這兩年只要聊到技術(shù)面試幾乎繞不開一個詞八股文。你去脈脈、牛客、掘金隨便刷一刷滿屏都是“面試造火箭工作擰螺絲”“背了一個月八股結(jié)果問的全是源碼”“這年頭不會背JVM調(diào)優(yōu)都不好意思說自己是Java程序員”之類的吐槽。作為既當(dāng)過候選人、也當(dāng)過面試官的人我對這些吐槽太有共鳴了。但說實話罵歸罵我反而覺得“八股文”這三個字被嚴(yán)重污名化了。技術(shù)面試?yán)锏乃^八股本質(zhì)上是一套行業(yè)沉淀下來的公共知識題庫。它包含計算機(jī)基礎(chǔ)、語言特性、框架原理、系統(tǒng)設(shè)計常識甚至包括一些“這題我背過”的典型算法題。它之所以存在不是因為面試官水平差而是因為技術(shù)招聘這個場景里信息極度不對稱面試官需要在1個小時內(nèi)判斷一個人過去幾年積累了怎樣的技術(shù)功底候選人需要通過有限的問題展示自己的深度和廣度。你指望不靠一套相對標(biāo)準(zhǔn)化的題庫來完成這種判斷那才是真正的碰運氣。我自己做過一個粗略統(tǒng)計在擔(dān)任面試官的三年里面過兩百多個候選人其中約70%的面試結(jié)論可以在前30分鐘就基本確定。為什么因為前30分鐘里基礎(chǔ)知識題答得怎么樣幾乎直接暴露了這個人平時寫不寫代碼、看不看書、遇事追不追根究底。八股題不是目的它是一個探測信號的工具。真正重要的不是候選人有沒有背出答案而是他在回答過程中展現(xiàn)出來的思維方式——是死記硬背的復(fù)讀機(jī)還是真正理解背后邏輯的工程師。所以這篇文章想聊的不是“八股文該不該存在”這種口水仗而是更實際的問題什么才是好的技術(shù)面試從候選人的角度看怎么準(zhǔn)備才不白費力氣從面試官的角度看怎么設(shè)計才能精準(zhǔn)識人我會結(jié)合自己多年被面、面人的經(jīng)驗把技術(shù)面試這件事拆開揉碎順便聊聊華為OD這類大廠標(biāo)準(zhǔn)化面試流程里的門道。這中間有些話可能不太好聽但都是大實話。2. 先看清游戲規(guī)則技術(shù)面試到底在考什么技術(shù)面試之所以讓人焦慮很多時候是因為候選人根本不知道這場考試的考綱是什么。你以為是在考“會不會背HashMap源碼”實際上是考“有沒有在復(fù)雜工程環(huán)境里用對HashMap的能力”你以為是在考“算法題能不能AC”實際上是在看你在壓力下的問題拆解能力。先搞清規(guī)則你才知道勁兒往哪使。2.1 技術(shù)面試的三層漏斗基礎(chǔ)、深度、潛力我把大廠和中小廠比較成熟的技術(shù)面試流程都?xì)w納成三層漏斗。第一層是基礎(chǔ)層。這一層考的是“你作為工程師是否合格”內(nèi)容覆蓋數(shù)據(jù)結(jié)構(gòu)與算法、操作系統(tǒng)、網(wǎng)絡(luò)、數(shù)據(jù)庫、語言特性、常用框架。它就像駕照考試的科目一過不了這一關(guān)后面的能力展示根本沒機(jī)會。現(xiàn)實中很多候選人折在這一層不是因為他們不會而是因為他們太久沒復(fù)習(xí)基礎(chǔ)知識點都還給了大學(xué)老師。第二層是深度層。這一層考的是“你有沒有真正鉆研過某個方向”。常見的方式是順著一個點往深里問連環(huán)追問直到你答不上來為。比如你說自己熟悉Spring面試官就會問Bean的生命周期再問循環(huán)依賴怎么解決再問三級緩存為什么是三級而不是兩級再問如果讓你自己實現(xiàn)一個IoC容器你會怎么設(shè)計。這個過程不是要難倒你而是在摸你技術(shù)深度的邊界在哪里。第三層是潛力層。這一層看的是你的學(xué)習(xí)能力、解決問題的能力、溝通表達(dá)的能力甚至包括你的職業(yè)規(guī)劃是否清晰。典型的手段有系統(tǒng)設(shè)計題、場景題、開放式問題比如“如果讓你設(shè)計一個短鏈接系統(tǒng)你會怎么做”“線上服務(wù)突然CPU飆高你怎么排查”。這三層不是獨立的而是逐層遞進(jìn)的關(guān)系。基礎(chǔ)層不過關(guān)面試官沒動力浪費時間問深度深度層表現(xiàn)平平潛力層問題也就不會拋出。2.2 面試官的視角1小時里他在收集什么信號換位思考一下面試官坐在你對面他腦子里其實在運行一套“信號收集”的流程。他關(guān)注的信號大概有這幾類一是真實性信號。簡歷上寫的項目經(jīng)驗是不是真的有沒有深度參與還是僅僅掛名面試官會通過追問技術(shù)細(xì)節(jié)來驗證比如“你們這個系統(tǒng)QPS多少”“數(shù)據(jù)庫量級多大”“緩存和數(shù)據(jù)庫一致性怎么解決”。簡歷可以包裝但細(xì)節(jié)很難偽裝。二是結(jié)構(gòu)化信號。候選人能不能把復(fù)雜問題講得條理清晰能不能用“總—分—總”的方式表達(dá)會不會用類比來解釋抽象概念。這個信號在系統(tǒng)設(shè)計和項目深挖環(huán)節(jié)尤其重要。三是成長性信號。候選人面對不知道的問題時是什么反應(yīng)是坦誠說不會還是絞盡腦汁地胡編遇到提示之后能不能快速吸收并聯(lián)想好的技術(shù)面試本質(zhì)上是在有限時間內(nèi)盡可能收集這些信號然后形成一個判斷。而不好的面試是面試官全程低頭看簡歷、偶爾拋出一道題然后等一個標(biāo)準(zhǔn)答案——這種面試無論對候選人還是對面試官都是浪費生命。2.3 華為OD技術(shù)面試給我們的啟示標(biāo)準(zhǔn)化不等于死板之前華為OD技術(shù)面試上過熱搜很多人在討論這個面試流程到底難不難、公不公平。我身邊也有朋友走過這個流程包括德科等外包公司招聘后外派到華為工作的模式。坦率地說華為OD的面試流程的標(biāo)準(zhǔn)化程度在行業(yè)內(nèi)是比較高的。它通常包含機(jī)考算法題 性格測試 兩到三輪技術(shù)面 HR面 綜合面。機(jī)考主要篩算法和編碼能力技術(shù)面會考察項目經(jīng)歷和基礎(chǔ)知識綜合面則關(guān)注邏輯表達(dá)和穩(wěn)定性。我對這套流程的看法是標(biāo)準(zhǔn)化本身不是問題問題是不要因為標(biāo)準(zhǔn)而丟掉了對人的判斷。華為OD這套流程里有一個值得借鑒的地方它的每一輪面試都有明確的考察側(cè)重點面試官不會問海闊天空的問題而是圍繞崗位要求逐層展開。這種設(shè)計保證了不同候選人之間的可比性也降低了面試官個人偏好對結(jié)果的影響。如果你正在準(zhǔn)備類似OD這樣的大廠標(biāo)準(zhǔn)化技術(shù)面試我的建議是把流程研究透把每輪考察什么搞清楚然后針對性準(zhǔn)備。這比你盲目刷一兩個月題庫要高效得多。后面我會專門講這套流程里每個環(huán)節(jié)的具體應(yīng)對方法。3. 深度拆解好的技術(shù)面試長什么樣前面聊了理論層的邏輯這一節(jié)落到實操直接拆解一場“模范級”技術(shù)面試應(yīng)該包含哪些環(huán)節(jié)、每個環(huán)節(jié)怎么設(shè)計才合理、背后又是什么原理。3.1 開場破冰不是閑聊是信息確認(rèn)一場好的技術(shù)面試前5分鐘不是從算法題開始的。有經(jīng)驗的面試官會先做這些事自我介紹說明面試流程和時間安排然后讓候選人簡單介紹自己最熟悉的一個項目。這個環(huán)節(jié)看似簡單其實信息量巨大。我面過一些候選人上來就是“我做了個電商系統(tǒng)用了Spring Cloud微服務(wù)架構(gòu)Redis做緩存MySQL存數(shù)據(jù)”——這種回答等于什么都沒說。好的回答應(yīng)該包含項目背景和規(guī)模、你負(fù)責(zé)的具體模塊、你遇到的最大技術(shù)挑戰(zhàn)、你做了什么決策、最后取得了什么結(jié)果。給候選人的實操建議提前準(zhǔn)備好兩個項目的“60秒版本”和“5分鐘版本”。60秒版本用于自我介紹重點講清項目背景和個人角色5分鐘版本用于面試官追問時詳細(xì)講技術(shù)方案和攻堅過程。按這個框架準(zhǔn)備的候選人在面試官心里第一印象分會高很多。我見過最舒服的一個開場候選人是這么介紹項目的“我上家公司做了個面向B端的訂單管理系統(tǒng)日均訂單量大概50萬我負(fù)責(zé)訂單狀態(tài)機(jī)模塊。這個模塊最麻煩的地方是狀態(tài)流轉(zhuǎn)場景特別多退款、撤單、超時關(guān)單各種分支我用了狀態(tài)機(jī)模式重構(gòu)把原來2000行的if-else壓到了不到300行。”——你看背景、規(guī)模、角色、難點、方案、成果六個要素全齊了面試官想不往下追問都難。3.2 熱身題難易有梯度的原因是建立基準(zhǔn)線開場之后面試官通常會拋一兩個比較簡單的基礎(chǔ)題比如“HashMap的底層結(jié)構(gòu)是怎樣的”“TCP三次握手為什么是三次不是兩次”。這類題目有時候會給人一種“就這我背過”的感覺所以很多候選人會掉以輕心簡單答完就等著下一題。這里我要特別提醒熱身題不是走流程而是在建立你的能力基準(zhǔn)線。面試官拿這些簡單題當(dāng)“標(biāo)尺”觀察你回答的基礎(chǔ)水平后續(xù)再拿難題來跟這個基準(zhǔn)作對比。如果你熱身題回答得很流暢后面難題即使沒完全答對面試官也可能給你“基礎(chǔ)扎實深度略欠”的評價但如果熱身題就支支吾吾后面就算答對了一道難題面試官也會懷疑你是不是碰運氣。所以正確的策略是熱身題不要只背結(jié)論要把推導(dǎo)過程也講出來。比如面試官問HashMap你不僅要答“數(shù)組加鏈表加紅黑樹”還要解釋“為什么鏈表長度超過8轉(zhuǎn)紅黑樹”“為什么加載因子是0.75”“擴(kuò)容時為什么是2的冪次”。把面試官想追問的話提前說了你就在對話節(jié)奏上占了主動。3.3 核心追問連環(huán)問法的設(shè)計邏輯當(dāng)面試官進(jìn)入核心追問階段你會發(fā)現(xiàn)他開始追著你話里的技術(shù)點往下問。你在講項目時提到“我用Redis做了緩存”他會順著問緩存穿透怎么處理緩存擊穿和雪崩怎么區(qū)分分布式環(huán)境下緩存一致性怎么保證你答完了他可能又來一句如果讓你極致優(yōu)化緩存命中的Java堆外內(nèi)存方案你會怎么做這種連環(huán)追問的底層邏輯是什么是在尋找你知識樹的邊界。面試官不怕你把問題答得不夠全面怕的是你根本沒有邊界意識——什么問題都能扯兩句但每個問題都說不深。恰恰是那些能清晰說出“這個方向我了解到這里再深我就不太確定了”的候選人反而更容易獲得認(rèn)可因為這意味著他有技術(shù)敏感度和自知之明。我自己當(dāng)面試官時最喜歡用一種“追到底”的問法先問一個基礎(chǔ)概念然后不管候選人答得如何都用“為什么”追三次。比如為什么MySQL選B樹做索引——因為樹高矮、IO次數(shù)少為什么樹高矮I(xiàn)O就少——因為B樹非葉子節(jié)點不存數(shù)據(jù)一頁能存更多索引為什么兩個因素都重要——因為機(jī)械磁盤隨機(jī)IO是性能瓶頸。能扛住三輪追問不倒的候選人我基本會給他“基礎(chǔ)扎實”的結(jié)論。給面試官的建議連環(huán)追問不是要為難人每追一層都應(yīng)該有一個明確目的。第一層問定義考察是否了解第二層問原理考察是否理解第三層問取舍考察是否有工程判斷力。如果你自己都不知道追問的終點在哪里那這種追問就是純粹的面官之威毫無意義。3.4 算法題從“背模板”到“展示思維過程”算法題是技術(shù)面試?yán)餇幾h最大的環(huán)節(jié)了。大量候選人吐槽我工作三年CRUD寫得好好的你讓我手寫紅黑樹、KMP、LRU這合理嗎這個吐槽有一定道理但我也得為算法題說句公道話算法題考察的從來不是你會不會背這道題而是你在面對一個未知問題時有沒有一套清晰的思維方法論。舉個真實的例子。我面過一個候選人遇到一道“尋找數(shù)組中第K大的元素”的題。他沒直接寫快排模板而是先說這個題我想到兩種思路一種是排序后取下標(biāo)時間復(fù)雜度O(nlogn)另一種是維護(hù)一個大小為K的最小堆復(fù)雜度O(nlogK)。如果數(shù)據(jù)量不大第一種反而更好因為實現(xiàn)簡單、不容易出錯如果K很小或者n很大第二種更合適。說完他還補(bǔ)了一句其實還有一種基于快排partition的思路平均可以做到O(n)但最壞情況會退化要看輸入分布。你看同樣一道題有的候選人寫出來的是一個AC代碼有的候選人展示的是完整的技術(shù)決策過程。面試官想要的是后者。那實際刷題怎么準(zhǔn)備我的建議分三步走。第一步是按高頻題單刷每個類型數(shù)組、鏈表、樹、DP、貪心、圖至少做20道把核心套路吃透。第二步是刷完一道題要復(fù)盤想清楚這道題考的是什么基礎(chǔ)知識點能不能歸類到某種模式比如“看到“最值”就往DP或貪心上想”。第三步是模擬面試環(huán)境練表達(dá)給自己定個20分鐘倒計時邊做題邊把思路說出來強(qiáng)迫自己養(yǎng)成“先講思路、再寫代碼、最后自測”的習(xí)慣。4. 實操指南技術(shù)面試的六個關(guān)鍵步驟流程版這一節(jié)我們聊一個有實操價值的流程框架。我把一輪完整的技術(shù)面試拆成六個關(guān)鍵步驟按時間順序排列。這個框架對候選人和面試官都好用候選人可以據(jù)此規(guī)劃自己的表現(xiàn)節(jié)奏面試官可以據(jù)此設(shè)計面試流程。4.1 步驟一明確崗位畫像很多面試聊崩了根源在于面試官和候選人對崗位的理解不一致。面試官想要一個能扛生產(chǎn)環(huán)境穩(wěn)定性的人候選人卻以為這是在招research崗全程大談算法創(chuàng)新。這個錯位在面試一開始就埋下了雷。面試官在做技術(shù)面試之前第一件事一定是明確崗位畫像這個崗位的核心技術(shù)棧是什么候選人入職后三個月要交付什么技術(shù)難點主要在哪些模塊團(tuán)隊當(dāng)前最缺的是深度還是廣度。把這些問題想清楚面試題的設(shè)計才會有方向。站在候選人的角度你接到的面試邀請上通常有JD職位描述一定花時間逐字讀把里面的關(guān)鍵詞拎出來。如果JD里反復(fù)提到“高并發(fā)”“分布式”那么面試大概率會圍繞這些展開如果寫的是“數(shù)據(jù)平臺”“ETL”那你準(zhǔn)備的側(cè)重點就得在數(shù)據(jù)棧上。很多候選人面完才后悔“我準(zhǔn)備的方向和面試問的完全不在一個頻道”這種虧吃得實在太冤。4.2 步驟二設(shè)計考察路徑明確畫像之后面試官就要設(shè)計具體的考察路徑。注意我說的是“路徑”不是“題庫”。好的技術(shù)面試不是從題庫里隨機(jī)抽幾道題而是有一個遞進(jìn)的邏輯鏈。比如要招一個后端開發(fā)考察路徑可以是先問Java語言基礎(chǔ)HashMap、并發(fā)、JVM再問Spring框架原理Bean生命周期、事務(wù)傳播機(jī)制再進(jìn)入項目深挖緩存方案、DB設(shè)計、性能優(yōu)化最后來一道系統(tǒng)設(shè)計題短鏈接、秒殺系統(tǒng)。這樣一個流程下來候選人的技術(shù)全貌基本就清晰了。這中間有個技巧每道題的難度要略高于上道題形成一個上升階梯。面試官在前期可以通過熱身題摸底然后動態(tài)調(diào)整后續(xù)難度。如果候選人熱身題都答得吃力那就沒必要上系統(tǒng)設(shè)計題了重點應(yīng)該放在檢驗基礎(chǔ)是否達(dá)標(biāo)。4.3 步驟三環(huán)境搭建與時間控制環(huán)境搭建這個細(xì)節(jié)很多面試官不重視但實際影響非常大。線下面試還相對簡單線上視頻面試問題就多了共享屏幕能不能正常用、瀏覽器是否兼容在線IDE、麥克風(fēng)有沒有雜音、網(wǎng)速夠不夠穩(wěn)定。去年我線上遇到過一個候選人代碼寫到一半共享屏幕崩了折騰了五分鐘才恢復(fù)這種突發(fā)狀況對候選人的心態(tài)影響遠(yuǎn)超于面試官的想象。面試官要提前檢查在線coding工具是否準(zhǔn)備妥當(dāng)是白板手寫還是共享屏幕編輯器面試時間分配是否合理我通常按“5分鐘開場20分鐘基礎(chǔ)20分鐘項目或算法15分鐘反問”來分配。候選人這邊也要做好預(yù)案提前測試視頻工具、準(zhǔn)備好一個可用的編程環(huán)境、甚至找一個安靜的房間。技術(shù)面試的臨場發(fā)揮水平很多時候是由這些“場外因素”決定的。4.4 步驟四信息記錄與判斷依據(jù)我觀察到一個現(xiàn)象不少面試官面試時不做任何記錄全程靠腦子記面完三個人之后就混成一團(tuán)漿糊了最后打分全憑“印象分”。這是技術(shù)面試的大忌。好的做法是邊面邊記用一套簡單的記錄模板每個問題后面標(biāo)注候選人的表現(xiàn)等級A非常流暢有加分項、B基本答對稍有遲疑、C有偏差需要提示、D完全不會。面試結(jié)束時翻一遍記錄對照崗位畫像逐項打分寫下面試結(jié)論和依據(jù)。這樣就算兩輪面試之間有分歧溝通時也有據(jù)可依。候選人也可以反向利用這一點你回答問題時可以主動幫面試官“記筆記”。比如每道題答完加一句“這個問題我從兩個層面來回答第一是使用層面第二是實現(xiàn)原理層面”。這種結(jié)構(gòu)化的表達(dá)方式天然利于面試官記錄也向?qū)Ψ絺鬟f了你“條理清晰”的信號。4.5 步驟五追問行為面試題技術(shù)面試不能完全只看技術(shù)還要考察候選人在真實工作場景中的行為模式。行為面試題就是干這個用的常見形式是“你過去有沒有遇到過和同事因為技術(shù)方案吵架的情況最后怎么解決的”“如果產(chǎn)品經(jīng)理非要上一個你覺得技術(shù)上不合理的需求你會怎么辦”候選人回答行為面試題我推薦用STAR原則Situation背景、Task任務(wù)、Action行動、Result結(jié)果。比如“上家公司有個項目測試環(huán)境穩(wěn)定一上線就OOMSituation。當(dāng)時我是項目核心開發(fā)負(fù)責(zé)排查這個問題Task。我先拉取了線上GC日志發(fā)現(xiàn)老年代持續(xù)增長懷疑有內(nèi)存泄漏然后用MAT分析了堆轉(zhuǎn)儲文件定位到是一個靜態(tài)Map只增不減導(dǎo)致Action。最后修復(fù)之后線上穩(wěn)定運行了兩個月沒有復(fù)現(xiàn)我還把排查過程寫成了團(tuán)隊技術(shù)分享Result。”最差的回答方式是“我們”“大家”“團(tuán)隊”用得特別多聽完整段不知道“你”到底干了什么。面試官關(guān)心的是你的個人能力不是你們團(tuán)隊的集體榮譽(yù)。4.6 步驟六候選人反問與雙向選擇面試最后還有一個環(huán)節(jié)經(jīng)常被浪費候選人反問。很多候選人覺得反問環(huán)節(jié)只是走個過場隨便問一句“公司加班多嗎”就結(jié)束了。實際上高質(zhì)量的反問不僅能幫你獲取關(guān)鍵信息還能給面試官留下“這人有想法”的正面印象。我給候選人推薦幾個優(yōu)質(zhì)反問問題一、“這個崗位入職后最核心的目標(biāo)是什么三個月內(nèi)希望達(dá)到什么產(chǎn)出”——這是在確認(rèn)工作預(yù)期二、“團(tuán)隊目前最大的技術(shù)挑戰(zhàn)是什么”——這是展示你愿意直面難題三、“請問你在這個團(tuán)隊工作最滿意和最不滿意的地方分別是什么”——這個問題能問出真實信息面試官的真話往往藏在后半句。反過來面試官也要重視反問環(huán)節(jié)。候選人的提問質(zhì)量本身就是觀察他思考深度和求職動機(jī)的窗口。只關(guān)心“加班多不多”“薪資范圍多少”的候選人未必不好但完全不提問的候選人通常對這次機(jī)會的熱情也就一般。5. 兩個真實案例復(fù)盤同樣面“秒殺系統(tǒng)”不同思路不同結(jié)局理論講再多不如拿真實案例拆解一遍。我選兩個我實際經(jīng)歷過的面試片段來復(fù)盤都是關(guān)于“怎么設(shè)計一個秒殺系統(tǒng)”這個經(jīng)典場景題但兩個候選人的表現(xiàn)天差地別正好說明“好的技術(shù)面試到底是怎樣煉成的”。5.1 案例A背了一堆組件但沒想清楚為什么候選人A的工作經(jīng)驗兩年多面試開場表現(xiàn)不錯基礎(chǔ)知識答得流暢。進(jìn)入系統(tǒng)設(shè)計題環(huán)節(jié)我拋出那道最簡單的秒殺問題如果讓你設(shè)計一個商品的秒殺系統(tǒng)你怎么做候選人A的反應(yīng)很熟練很快就列出一套方案用Nginx做負(fù)載均衡Redis預(yù)減庫存消息隊列削峰接口限流用令牌桶數(shù)據(jù)庫用樂觀鎖防超賣。這套術(shù)語流利得讓人懷疑他是不是剛背過答案。但是當(dāng)我追問“Redis預(yù)減庫存和DB最終扣減不一致怎么辦”時他開始含糊其辭再問“如果Redis掛了怎么辦”他沉默了幾秒說“可以加集群”。問題就出在這他的回答里全是組件的名字但沒有形成一條邏輯鏈。他不知道秒殺系統(tǒng)的核心矛盾是什么也不清楚每個組件在他架構(gòu)里解決的是哪個具體問題。這種“只知道在哪個場景用什么工具但不知道工具背后原理”的狀態(tài)在真正的工程實踐里是很危險的因為線上問題永遠(yuǎn)不會按你背過的場景發(fā)生。5.2 案例B從問題定義出發(fā)逐步推導(dǎo)候選人B同樣被問到秒殺系統(tǒng)。他花了幾分鐘沉默思考然后把問題重新定義了一遍秒殺場景的核心挑戰(zhàn)是瞬時的流量脈沖帶來三個層面的壓力——入口網(wǎng)關(guān)的壓力、庫存扣減的一致性問題、以及訂單創(chuàng)建鏈路被擊穿的風(fēng)險。然后他給出的回答不是直接報組件而是帶著推導(dǎo)過程第一入口層需要限流把絕大多數(shù)請求在網(wǎng)關(guān)就擋掉這個用令牌桶或滑動窗口都可以關(guān)鍵是拒絕消息不要打到下游第二庫存扣減要保證不能超賣方案是在Redis里用原子操作預(yù)扣比如DECR指令扣減成功的請求才允許進(jìn)入下單流程剩余的請求直接返回“搶購失敗”第三為了避免Redis和DB最終數(shù)據(jù)不一致可以在DB層做校驗——真正下單時用樂觀鎖版本號CAS更新庫存如果影響行數(shù)為0說明庫存已經(jīng)被扣完訂單回滾。在這套方案的最后他還主動補(bǔ)充了風(fēng)險點這個架構(gòu)里Redis是關(guān)鍵路徑一旦Redis不可用整個秒殺就掛了所以還需要一個降級預(yù)案——極端情況下直接把請求全部打到DB靠數(shù)據(jù)庫行鎖來保證不超賣雖然性能差但至少不超賣。聽完他的回答我給了一個明確的正向結(jié)論。不是因為他的方案多完美——實際上他有幾處取舍可以商榷——而是他展示了一個工程師面對未知問題應(yīng)有的思考方式先定義問題、再逐層拆解、每個技術(shù)選型都有明確的目的、最后還主動說風(fēng)險。這種能力恰恰是“背答案”給不了的。5.3 這兩個案例告訴我們什么樣的面試才是好的把兩個案例放一起看你會發(fā)現(xiàn)好的技術(shù)面試有一個共同的底層邏輯面試官關(guān)注的不是“你會不會做這道題”而是“你遇到這個問題的思考路徑是否合理”。候選人A的失敗不在于他不懂秒殺而在于他只會復(fù)述知識結(jié)構(gòu)不會自己構(gòu)建解決方案候選人B的成功不在于他的方案更高級而在于他展現(xiàn)了對問題本質(zhì)的理解和取舍能力。所以候選人朋友們別再花大量時間背“標(biāo)準(zhǔn)答案”了。技術(shù)面試的最高境界是把知識內(nèi)化成你思考的一部分讓答案從你嘴里說出來時像“你自己想出來的”而不是像“從別人那里抄來的”。這條路沒有捷徑但有方向多做“不按套路出牌”的模擬訓(xùn)練強(qiáng)迫自己在不知道答案的情況下用第一性原理去推理。6. 面試官的自我修養(yǎng)好面試不是為難人是幫人發(fā)揮前面說了很多站在候選人角度的經(jīng)驗但這一行的水深不深面試官自己心里也有數(shù)。說實話我見過太多不合格的面試官了——有人全程冷臉只會低頭念問題有人問出自己都不會的問題只為看到候選人答不出來獲得滿足有人不看簡歷上來就出一張hard算法題面完三分鐘就把人掛了。這些行為真的配不上“面試官”這三個字。6.1 面試官的能力是被低估的專業(yè)要求在企業(yè)里面試官通常只是“工作經(jīng)驗夠久”就被推上去沒有經(jīng)過系統(tǒng)的面試方法訓(xùn)練。這導(dǎo)致面試結(jié)果高度依賴面試官個人水平同樣的候選人可能在這個組被掛、在那個組過全憑運氣。我認(rèn)為一個合格的技術(shù)面試官至少需要具備四種能力。第一是準(zhǔn)確提問的能力——問題要具體、可回答、有區(qū)分度而不是開放式到讓人無從下手第二是深度傾聽的能力——不要只顧著自己下一個問題要真的聽懂候選人每一句話背后的技術(shù)含義第三是客觀評估的能力——克服首因效應(yīng)和暈輪效應(yīng)不用一個優(yōu)點掩蓋缺點也不用一個缺點否定全部第四是情緒管理的能力——面試過程要盡量讓候選人放松因為只有放松狀態(tài)下展現(xiàn)出的技術(shù)水平才是接近他真實水平的狀態(tài)。我身邊很多面試官朋友不認(rèn)同最后一點他們認(rèn)為“面試就是要給壓力抗壓能力也是考察項”。這話部分對但關(guān)鍵在于“壓力應(yīng)該來自問題本身的難度而不是來自面試官的態(tài)度”。問題難能篩出技術(shù)邊界態(tài)度差只能篩出誰臉皮厚。這兩者天差地別。6.2 如何設(shè)計一套“讓人舒服但不放水”的面試體驗分享一套我總結(jié)出來的面試節(jié)奏。開場前兩句先閑聊一個小問題——“今天路上堵不堵”“你們那邊下雨了嗎”——不是為了套近乎而是通過閑聊觀察候選人平時的語速和狀態(tài)基線。正式開始時花一兩分鐘介紹面試結(jié)構(gòu)和時間安排減少不確定性帶來的焦慮。進(jìn)入正題后每一輪問題之間留幾秒鐘的安靜時間不要搶著填補(bǔ)沉默給候選人思考的余地。面試中最容易被忽視的是反饋意識。候選人答完一道題之后面試官可以給一個簡單的點頭或者說一句“明白”讓他知道自己的回答被接收到了。如果候選人卡住了不要立刻跳到下一題而是給一個遞進(jìn)式的提示——先問“你是不是可以從某個角度想一下”再給一點更具體的方向。當(dāng)提示能幫助候選人答出來的時候你收獲的信息量其實遠(yuǎn)大于他自己完全答出來的情況。6.3 避免“我比你懂”的面官心理陷阱技術(shù)面試?yán)镉幸粋€非常普遍的心理陷阱叫“我要證明我比你懂”。很多面試官問問題不是因為這個問題能區(qū)分出候選人能力而是因為這個問題“我懂”。你面Java的問一堆JVM底層行JVM是Java工程師應(yīng)該懂的你明明面后端業(yè)務(wù)方向非要問一道ACM難度的線段樹這個就動機(jī)不純了。要克服這個陷阱有一個簡單的心法問每一個問題之前先自問一句“這道題的答案對崗位的核心工作有什么直接關(guān)聯(lián)”。如果關(guān)聯(lián)度不高哪怕這個問題很酷、很深也不要問。面試官的時間很寶貴20道不相關(guān)問題的信息價值可能不如5道精準(zhǔn)且深挖的問題。另外還要提醒面試官朋友一句面試評價里的負(fù)面視角要謹(jǐn)慎寫。你的一句“基礎(chǔ)不扎實”如果不標(biāo)注具體是哪個基礎(chǔ)、哪個問題、答到什么程度后面環(huán)節(jié)的面試官和HR都會產(chǎn)生誤讀。負(fù)面的評價越具體對招聘流程的幫助越大。7. 候選人避坑清單這些細(xì)節(jié)決定了你的面試下限聊完面試官我們把鏡頭拉回候選人這邊。這一節(jié)我不講知識準(zhǔn)備因為知識面是長期積累短期補(bǔ)不上去。我講的是那些“明明可以提前準(zhǔn)備、卻總有人踩坑”的細(xì)節(jié)問題。這些細(xì)節(jié)不決定你的上限但決定了你的下限。7.1 簡歷上的每個字都會被追問別給自己挖坑簡歷是面試的“劇本”但你寫的每一句話都可能成為面試官的發(fā)問起點。我見過太多候選人簡歷里寫了“精通JVM調(diào)優(yōu)”結(jié)果被問到G1和CMS的區(qū)別時支支吾吾寫了“熟悉分布式事務(wù)”被問到兩階段提交的缺陷時只能說個大概。我的建議是簡歷上寫到的技術(shù)點至少要能做到“能講清楚一個應(yīng)用場景、能說清一個核心原理、能舉出一個真實案例”。達(dá)不到這個標(biāo)準(zhǔn)的技術(shù)點要么不寫要么花時間補(bǔ)齊。技術(shù)面試的時間就那么長與其讓面試官在你不熟的地方挖出窟窿不如讓他在你扎實的地方多停留一會兒。還有一個容易被忽視的坑簡歷上的項目時間線。面試官可能會追問“2019年到2021年這段工作經(jīng)歷為什么只待了兩年”“項目A和項目B之間有沒有空窗期”。倒不是面試官八卦而是職業(yè)穩(wěn)定性確實是技術(shù)團(tuán)隊招聘的考量因素。提前準(zhǔn)備好對這些問題的回答比臨場瞎編要穩(wěn)得多。7.2 線上視頻面試的三件套準(zhǔn)備現(xiàn)在技術(shù)面試越來越多地采用線上視頻形式但很多候選人依然把它當(dāng)成“線下面試的替代品”忽略了線上場景的特殊性。我復(fù)盤過幾十場線上的面試總結(jié)出三個高頻翻車點。第一個是備好用順手的編程環(huán)境。面試官讓你共享屏幕寫代碼結(jié)果你現(xiàn)場打開IDE等待初始化或者你平時用IDEA結(jié)果電腦上只有VSCode還配置一團(tuán)糟這種尷尬誰經(jīng)歷誰知道。提前裝好一個配置完善的開發(fā)環(huán)境打開就是可以用這是線上面試最基本的要求。第二個是準(zhǔn)備好紙和筆。線上面試時很多候選人想畫圖講思路但發(fā)現(xiàn)沒有紙筆只能用鼠標(biāo)在共享屏幕上畫歪歪扭扭的圈。一張白紙、一支筆放在手邊遇到系統(tǒng)設(shè)計題或者講數(shù)據(jù)結(jié)構(gòu)的時候拿起來就寫整個人的專業(yè)感會提升一個檔次。第三個是網(wǎng)絡(luò)和設(shè)備的雙保險。手機(jī)開熱點做備用提前測試耳機(jī)麥克風(fēng)把視頻軟件升級到最新版本。別指望面試官能接受你“喂喂喂你聽得到嗎”的溝通損耗。技術(shù)面試的問題難度已經(jīng)夠高了別再讓這些場外因素繼續(xù)拉高難度。7.3 面試結(jié)束后的復(fù)盤方法很多人面試結(jié)束就是等結(jié)果根本不復(fù)盤。但在我看來面試是一項可以通過刻意練習(xí)持續(xù)精進(jìn)的技能。每次面試結(jié)束花30分鐘做一個復(fù)盤長期積累的效果會非常驚人。我的復(fù)盤方法是三問一記第一問今天的面試中哪些問題答得特別順暢是因為自己準(zhǔn)備充分還是恰好撞上了熟悉領(lǐng)域第二問哪些問題答得特別差差在知識盲區(qū)、表達(dá)不清晰、還是緊張導(dǎo)致思路混亂第三問面試官的追問風(fēng)格是什么他是喜歡往深挖還是往寬問自己應(yīng)該如何調(diào)整應(yīng)對。最后一記是把所有沒答上來的問題記錄下來無論最終是否通過面試都在一周內(nèi)把這些問題逐一搞懂。這套方法堅持下來你會發(fā)現(xiàn)一個很有趣的規(guī)律你怕的題目類型其實高度集中你的知識盲區(qū)也往往集中在某幾個領(lǐng)域。針對性地補(bǔ)強(qiáng)比漫無目的地刷題有效得多。8. 關(guān)于技術(shù)面試我最后想多說幾句寫到這里回到標(biāo)題那三個字——“八股文”。我見過太多候選人把八股文當(dāng)成敵人覺得只要題目問得常規(guī)面試就沒有意義。但我更愿意把它看作一套行業(yè)通用的“接口協(xié)議”它讓面試官和候選人在陌生的情況下能快速建立溝通的語言基礎(chǔ)讓技術(shù)能力這個很難量化的東西有了一個相對可比的維度。問題的關(guān)鍵從來不是“考不考八股”而是“怎么考、怎么答、怎么用這套題目來識別真正的工程師素養(yǎng)”。同樣一道“HashMap原理”的題目背出來的答案和一個真正因為排查線上問題而深入理解HashMap的答案表面上也許差不了幾句話但追問三層之后高下立判。從我個人的體會來說做了這些年面試官我從來不會因為候選人某道題沒答上來就掛掉他但我一定會因為“候選人面對不會的問題時的態(tài)度”而做出判斷。技術(shù)知識總有邊界誰都有不會的東西但一個工程師是否具備自查自驅(qū)、迎難而上的品質(zhì)往往比當(dāng)下會多少知識點更重要。最后再分享一個我自己面試前必做的小儀式面試前一天晚上把簡歷重讀一遍把每個項目里的“為什么”再問自己一次然后早睡。面試本質(zhì)上是一次技術(shù)溝通而溝通的最佳狀態(tài)來自于清醒的頭腦和從容的心態(tài)。希望這篇文章里拆出來的思路、方法和避坑清單能幫你把下一次技術(shù)面試變成一場你自己也享受的技術(shù)對話。