AI/ML求职必须刷LeetCode吗？算法与AI能力的真实权重

一个AI工程师的真实困惑

最近Reddit上一篇帖子引发了大量AI/ML从业者的共鸣。发帖者坦言："我可以花5个小时调试RAG管道，却过不了30分钟的LeetCode。"这句自嘲式的吐槽，精准戳中了当下无数AI工程师求职时的痛点。

这位开发者对AI技术有着近乎痴迷的热爱——机器学习、深度学习、Transformer、LLM、RAG、AI Agent、向量数据库、模型部署，这些他都能沉浸其中钻研数小时。当RAG管道出问题时，他甚至享受排查故障的过程。但一坐到LeetCode面前，"大脑就直接离场了"。

这里值得展开说说RAG管道的复杂性，因为它恰恰代表了现代AI工程的核心挑战。RAG（Retrieval-Augmented Generation，检索增强生成）是当前大语言模型应用中最重要的架构模式之一。其基本原理是在LLM生成回答之前，先从外部知识库中检索相关文档片段，将其作为上下文注入到提示词中，从而让模型基于真实数据生成更准确、更可溯源的回答。一个完整的RAG管道涉及文档解析、文本分块、向量嵌入生成、向量数据库存储与检索、重排序（Reranking）、提示词工程以及最终的LLM调用等多个环节。调试RAG管道之所以复杂且耗时，是因为每个环节的参数选择（如分块大小、嵌入模型、检索策略、Top-K值）都会影响最终输出质量，且问题往往不是代码报错，而是"回答不够好"这种模糊的质量问题，需要工程师具备对整个系统的深度理解。能在这种复杂度中游刃有余，本身就是极高的工程能力证明。

reddit原帖

他的核心疑问非常现实：如果目标是成为AI/ML工程师，数据结构与算法（DSA）到底有多重要？一个AI能力极强、能真正构建和部署系统的人，如果DSA只是中等水平，还有机会进入顶级产品型公司吗？还是说，DSA是一道"守门人"，不通过算法轮，你甚至没有机会展示自己的AI实力？

DSA是绕不过的门槛吗？

必须承认一个"不舒服的真相"：对于大多数产品型大厂（如FAANG及类似公司）的ML Engineer和Software Engineer-ML岗位，DSA确实是硬性筛选环节。

大厂坚持考算法的底层逻辑

这背后的逻辑并非刁难。数据结构与算法作为技术面试的核心考核内容，可以追溯到Google在2000年代初期建立的面试体系。当时Google面临从海量候选人中快速筛选顶尖工程师的挑战，选择了算法题作为标准化评估工具。这一模式随后被Facebook、Amazon、Apple、Netflix等科技巨头采纳，形成了所谓的"FAANG面试范式"。LeetCode平台的兴起则进一步将这种面试模式制度化——该平台目前拥有超过3000道编程题目，形成了一个庞大的备考生态系统。

ML工程师岗位在很多公司的本质仍然是"具备ML专长的软件工程师"。你不仅要会训练模型，还要写生产级代码、优化数据流水线、处理大规模系统的性能问题。算法能力被视为工程基本功的代理指标（proxy）。此外，标准化的算法面试便于横向比较大量候选人，是一种规模化招聘的效率工具。对于校招和初级岗位，DSA的权重往往更高，因为面试官缺乏其他维度来评估你的工程能力。

近年来，关于DSA面试是否真正能预测工作表现的争论从未停止。批评者认为算法面试更多测试的是"解谜能力"和应试技巧，而非实际工程能力；支持者则认为它至少能验证候选人的逻辑思维能力和代码功底。无论争论结果如何，现实是：这套游戏规则短期内不会改变，我们能做的是在规则内找到最优解。

岗位类型决定考核重心

你可能没注意到，不同岗位对DSA的要求差异极大。理解这些角色的边界，对于制定精准的备战策略至关重要：

Software Engineer-ML / ML Engineer：DSA权重高，通常需要通过1-2轮算法面试。在Google、Meta等大厂，ML Engineer本质上是Software Engineer的一个专业方向（通常标记为SWE-ML），其核心职责包括将研究团队的模型原型转化为生产级服务、构建和维护特征工程管道、优化模型推理延迟和吞吐量、以及搭建A/B测试和模型监控基础设施。日常工作中大量时间花在写分布式系统代码、优化数据管道性能、处理数据倾斜等纯工程问题上，而非调参或读论文。正因为如此，这类岗位对DSA的要求与普通SWE几乎一致。
Applied Scientist / Research Scientist：更看重ML理论深度、论文和项目经验，DSA相对次要，但仍可能考基础算法。Research Scientist更偏重算法创新和论文发表，Applied Scientist则介于工程与研究之间。
AI Engineer（偏应用）：在初创公司和部分产品团队，实际项目能力和系统设计权重更高，DSA可能只是入门筛选。这类岗位更关注你能否快速搭建一个可用的AI应用并持续迭代。

到底需要多好的DSA水平？

发帖者问了一个非常关键的问题："需要真正精通DSA，还是掌握常见模式、能解中等难度题就够了？"

对绝大多数AI/ML岗位而言，后者足矣。你不需要成为竞赛级选手，目标应该是：

现实的能力基准

掌握核心数据结构：数组、哈希表、栈/队列、树、图、堆。
熟悉常见解题模式：双指针、滑动窗口、BFS/DFS、动态规划入门、二分查找。
能稳定解出Medium难度题目：这是大多数面试的实际难度上限。Hard题偶尔出现，但通常不是决定性的。

换句话说，你不需要"精通"，而是需要"通过"。把DSA当作一项需要清关的考试，而非需要终身钻研的学科，这个心态转变很重要。

80% AI + 20% DSA是合理的备战策略吗？

发帖者提出的"80% AI/ML + 20% DSA"分配，方向是对的，但需要根据求职阶段动态调整。

分阶段的时间分配建议

日常积累期：可以采用80/20甚至90/10的比例，深耕AI能力，构建真实项目，这是你区别于其他候选人的核心竞争力。深厚的AI/ML实力才是你拿到offer、通过技术终面和拿高薪的根本。

面试冲刺期（面试前1-2个月）：应该反转比例，投入50%甚至更多时间集中刷题。DSA是一项"考试型技能"，短期高强度突击的效果远好于细水长流。集中练习150-200道高频题（如LeetCode的Blind 75或NeetCode系列），足以应对绝大多数面试。

这里有必要介绍一下结构化刷题的方法论。Blind 75是由一位前Facebook工程师在Blind论坛上分享的75道LeetCode精选题目列表，被广泛认为是算法面试准备的"最小可行集"。这份列表覆盖了数组、二分查找、滑动窗口、链表、树、图、动态规划、回溯等几乎所有面试高频考点，且题目按类型分组，便于集中训练特定模式。后来NeetCode在此基础上扩展为NeetCode 150，增加了更多覆盖面。结构化刷题的核心理念是：算法面试考的不是你见过多少题，而是你是否掌握了有限的几种解题范式（pattern）。例如，"双指针"模式可以解决至少十几道不同的题目，"BFS/DFS"模式覆盖了几乎所有树和图的遍历问题。因此，按模式分类、集中突击的效率远高于无序地刷上千道题。

差异化生存策略

如果你的DSA确实是短板，可以采取以下策略降低其影响：

优先瞄准初创公司和AI-first团队：这类公司更看重你能否立刻交付价值，面试往往是项目深挖+系统设计，DSA环节较轻。
强化系统设计和ML System Design：这是AI工程师的"第二战场"，也是你AI经验能直接变现的地方。ML System Design（机器学习系统设计）是近年来AI/ML岗位面试中权重快速上升的环节，也是AI工程师相比普通软件工程师最具差异化优势的考核维度。典型的ML系统设计题目包括：设计一个推荐系统、设计一个实时欺诈检测系统、设计一个大规模文档搜索引擎等。与传统系统设计不同，ML系统设计要求候选人同时展示对机器学习全流程和分布式系统架构的理解。一个完整的回答通常需要涵盖：问题定义与指标选择（离线指标vs在线指标）、数据收集与特征工程、模型选择与训练策略、服务架构（在线推理vs批量推理）、以及监控与迭代机制。对于有实际项目经验的AI工程师来说，这个环节是将日常工作经验直接转化为面试优势的最佳机会。
用作品集说话：可部署的RAG系统、开源项目、技术博客，能在简历筛选和终面环节大幅加分，甚至弥补算法环节的不足。一个在GitHub上有星标的RAG项目或AI Agent框架，比LeetCode上的解题数更能证明你的工程交付能力。

不舒服但诚实的结论

回到最初的问题：该咬牙刷DSA，还是把它当次要技能？

答案是：如果你想进大厂，就必须咬牙过这一关，但不必把它当成事业重心。 DSA是敲门砖，不是护城河。它决定你能否进门，但决定你能否拿到offer、走多远的，永远是你真正的AI/ML工程能力。

对这位热爱调试RAG的开发者来说，好消息是：他所热爱和擅长的，恰恰是这个行业真正稀缺、真正值钱的能力。在大模型应用爆发的今天，能够端到端构建、调试和优化一个RAG系统的工程师，其市场价值远超一个只会刷题的算法选手。DSA只是一道需要短期突击、限期通关的关卡。把它当作一次性成本，而非持续投入，才是最理性的求职策略。

别让30分钟的LeetCode，挡住你5小时调试RAG的热情。 咬牙刷完，然后回到你真正热爱的战场。