Hello，大家好，我是 Sunday。

不少同學都有一個疑惑，那就是：“平時工作的時候也沒有用到過算法，大廠面試咋還一直考算法呢？” 難道僅僅只是為了 面試造火箭，工作擰螺絲 嗎？

那么今天，咱們就嘮嘮這個問題...

考算法的背后，其實是為了“刷人”

很多同學都有類似經歷：

面試正好好的聊著組件封裝、工程化呢。結果面試官畫風一轉就變成了 “要不寫個快排吧”...

那問題來了，大多數開發崗位，日常的工作不就是 寫寫增刪改查，寫寫業務邏輯 嗎？跟算法半毛錢關系也沒有，為啥非得考個算法？

其實答案特別現實：人太多了，得刷一刷。

你想啊，現在競爭多大呀，一個 25K 以上的開發崗位，動不動就好幾十人投遞，并且個頂個的八股文都背的賊溜。

面試官時間也有限，總得有個辦法快速篩掉一波吧？而算法題，剛好具備這幾個特質：

• 出題方便：LeetCode隨便挑一道就是題
• 答案有標尺：對錯一眼能看出
• 最關鍵的：能看出誰思路清晰、代碼基本功扎實

說白了，這跟高考考數學一個道理，不是因為你以后天天用數學，而是看你能不能扛得住難題、邏輯清不清楚。

所以很多時候，面試考算法不是要你成為算法工程師，而是用它來篩出能學、會想、能扛壓的那撥人。

懂一點算法，其實對寫業務真有用

咱們講了算法面試的“篩人”功能，但話說回來：懂算法真的對日常工作一點幫助都沒有嗎？

其實還真不是。

雖然你平時不一定天天寫什么最短路徑、圖遍歷，但一些基礎的算法思想，在實際開發中用得還是挺多的，尤其是在做性能優化、復雜邏輯處理這些環節時，差距就出來了。

舉幾個常見的場景：

1. 數據處理場景

你在頁面中要處理一大堆數據，比如列表分頁、復雜篩選、搜索排序。一個不小心寫成 O(n2) 的邏輯，頁面就開始卡到懷疑人生。

這時候，能不能寫出一個時間復雜度更低的實現，靠的就是你的算法功底。

2. 對象查找和映射

搞定一個“根據ID快速找對象”的需求，是用 filter 還是預先構建個 Map 做索引？有沒有考慮數據規模大的時候的查找效率？這些其實就是哈希表的基本應用。

3. 樹形結構的遞歸遍歷

菜單樹、評論嵌套、權限結構、DOM 操作……哪個不是樹？

如果你能寫出清晰的遞歸或迭代邏輯，很多原本讓人頭大的需求，其實也沒那么難。

所以你會發現，懂算法不是為了炫技，而是讓你面對復雜問題時，不那么慌。

就像修水管的師傅，平時不一定天天用得上電焊，但該帶的工具總得帶齊吧？遇到“疑難雜癥”時，那就是你的底牌。

程序員到底該懂多少算法？

好，咱們現在統一戰線了：面試確實要考，工作里也確實有用（雖然用的可能不算多）。

那問題來了：到底要學到啥程度才算夠？

說實話，這事還真沒標準答案。但根據我的經驗，普通程序員，尤其是做 前端 和 后端 的，掌握「基礎 + 常用」就夠用了。

別追求啥全刷完 LeetCode 題庫、動態規劃寫出花樣來，那是競賽選手干的事。你只要做到以下幾點，就已經能在大多數面試和實際開發中游刃有余：

1. 數據結構別一問三不知

數組、鏈表、棧、隊列、哈希表、樹、圖……這些結構你得知道。

它們具體長啥樣、適合干啥用、操作的復雜度是多少，心里要有個譜。

2. 基本算法得有數

排序、搜索、遞歸、二分查找、滑動窗口、雙指針、貪心、動態規劃……這些套路你得心里有數。

想起來很多學算法的一句經典名言：不求手撕如神，但求每題有解。

好歹可以做到看到題目有個思路，知道為什么這么做比暴力好。

3. 會舉一反三

你不需要記住每道題怎么做，但得理解 它在解決什么問題，用的是什么思路。

面試的時候，可以把思路說出來（很多面試官會給你提示的），總比雙手一攤啥都不知道強。

程序員怎么高效學算法？

說到算法學習，很多同學第一反應是：“好難”“刷不動”“堅持不了”。

這很正常，算法就是那種典型的上手勸退型選手，光看題你可能都不理解它在問啥。

但其實，學算法這事也講究方法，不是一上來就得像打游戲一樣全通關、全成就。

以下是我自己摸索下來覺得比較靠譜的一些方法，分享給你：

1. 先理解，再刷題

有些同學一開始就跳進 LeetCode 刷題海，刷著刷著開始懷疑人生：為啥我連題都讀不懂？

其實最好的方式是：先把基礎數據結構和核心算法套路弄明白，比如你知道“棧”適合解決“括號匹配類”的題，那刷題的時候就不會瞎蒙。

2. 一定要分類練，別亂打一氣

算法題根據難度可以分為 簡單、中等、困難 三類。根據種類可以分為 排序類、遞歸類、動態規劃類... 很多類

建議你 分類刷題！

可以按照難度分類（比如：先刷簡單題），也可以按照種類分類（比如：先刷 DP 題），這樣比你亂刷強的多。