一個15行的除法循環(huán)，能讓多少面試者當場卡殼？

我見過太多簡歷光鮮的候選人，在"求一個數(shù)的所有因數(shù)"這道題上栽跟頭。不是不會寫，是寫得太繞。今天這5個基礎(chǔ)數(shù)字算法，來自一位谷歌工程師的自動化學習筆記——全是面試高頻題，但90%的人學錯了順序。

因數(shù)問題：為什么新手總愛用嵌套循環(huán)

求15的所有因數(shù)，最干凈的寫法只需要6行：

循環(huán)從1跑到15，每次檢查"15除以i有沒有余數(shù)"。余數(shù)為0，i就是因數(shù)。

核心就一句：user % i == 0。取模運算（%）在這里扮演的是"整除探測器"——能整除就放行，不能就跳過。

很多新手第一反應(yīng)是寫兩層循環(huán)，或者先分解質(zhì)因數(shù)再組合。面試官想看的不是數(shù)學功底，是你能不能一眼看穿：因數(shù)和整除判斷，本來就是一回事。

輸出結(jié)果：1、3、5、15。四個數(shù)，零廢話。

計數(shù)器模式：從打印到統(tǒng)計的思維躍遷

上面那道題的變種：不問因數(shù)有哪些，只問有幾個。

代碼幾乎沒變。把System.out.println(i)換成count++，最后打印count。輸出4。

這個"打印變計數(shù)"的套路，是算法面試的隱藏考點。我見過候選人能寫出因數(shù)分解，卻在統(tǒng)計環(huán)節(jié)多開一個數(shù)組存儲，再遍歷數(shù)長度——面試官的表情當場就變了。

計數(shù)器模式的價值在于：復用核心邏輯，只改輸出方式。這種"最小改動"思維，寫業(yè)務(wù)代碼時同樣救命。

數(shù)位拆解：除以10的魔法

12345有幾位？別轉(zhuǎn)字符串。用數(shù)學：

第一次除以10，12345→1234，計數(shù)1；

第二次，1234→123，計數(shù)2；

……直到變成0，一共5次。

循環(huán)次數(shù)=數(shù)字位數(shù)。這個等式比任何字符串操作都快，且不占額外內(nèi)存。

進階版：求各位數(shù)字之和。123→1+2+3=6。

這里要同時用兩個運算符：%10取末位，/10去掉末位。像剝洋蔥，一層一層往里剝。

代碼結(jié)構(gòu)：取末位→累加→削末位→循環(huán)。三步一個周期，直到剝光。

回文判斷：反轉(zhuǎn)數(shù)字的陷阱

121是不是回文？最穩(wěn)妥的做法是反轉(zhuǎn)后比較。

但反轉(zhuǎn)有坑。int類型反轉(zhuǎn)可能溢出，雖然這道題限定正整數(shù)，但面試時提一句"大數(shù)場景下建議用字符串或long"，是加分項。

核心公式：reverse = reverse * 10 + digit。

拆解：每次把已有的反轉(zhuǎn)結(jié)果左移一位（乘10），再把新取到的末位塞進去。121的反轉(zhuǎn)過程：0→1→12→121。

最后比較original和reverse，相等即回文。

非回文例子：123反轉(zhuǎn)成321，比較失敗，輸出"Not Palindrome"。

這5道題的隱藏主線

從因數(shù)到回文，看似零散，實則共用兩套武器：取模運算拆數(shù)字，整除運算縮規(guī)模。

%10取末位，/10去末位，%i判整除——這三句話能覆蓋80%的數(shù)字基礎(chǔ)題。剩下的20%，不過是排列組合。

那位谷歌工程師在筆記里埋了個細節(jié)：所有代碼都用了user作為變量名，而不是n或num。理由是"可讀性優(yōu)先，哪怕多敲幾個字母"。