求职与面试分享

写在前面：这篇文章还会继续更新

这篇文章不是一份已经完善的求职指南，而是我对求职、面试准备和反向提问的一些阶段性整理。它会随着后续投递、面试反馈、岗位理解和个人选择继续更新，所以现在更像一个持续打磨中的 blog，而不是最终版本。

我目前更关心的问题不是“怎么拿到任意一个 offer”，而是怎样把自己的经历、能力和目标岗位尽可能对齐。求职本质上不是单向被筛选，也不是简单地把简历投出去等待结果，而是在有限信息里不断确认：我想做什么、我适合什么、这个机会是否真的值得投入，以及进入团队之后我能不能持续成长。

求职前先确认方向

求职前最好先有一个大致的整体规划。比如先想清楚自己更希望进入工业界还是继续走学术路线，再据此决定简历重点、项目讲法和投递策略。不同方向对经历的解释方式并不一样：工业界更关注你能否解决真实问题、能否协作交付、能否把技术放进业务流程；学术路线则会更关注研究问题、方法创新、论文产出和长期研究潜力。

目标定位也不应该只看岗位名称。一个岗位是否适合自己，通常要一起考虑行业、城市、薪资、成长空间、专业匹配度，以及企业文化是否符合自己对工作节奏和加班强度的接受度。很多岗位名称看起来相似，但实际工作可能完全不同；同样是算法、数据、后端或者 Agent 开发，有的更偏研究探索，有的更偏业务交付，有的则更接近工程平台和工具链建设。

当然，规划不是一次性决定。外部机会、市场需求和个人状态都会变化，真正有用的规划应该允许自己根据投递反馈、面试反馈和兴趣变化不断调整。

怎么筛选机会

我现在更倾向于先找到适合自己的定位，为自己的技能找到合适的市场，而不是看到岗位就海投。海投可以带来数量，但如果岗位和经历长期不匹配，后续准备、沟通和面试复盘都会变得很低效。

机会来源可以尽量铺开，包括朋友推荐、企业宣讲会、猎头、公众号、官网和招聘平台。关键不是依赖某一个来源，而是多收集信息，再判断岗位定位是否真的匹配。一个机会是否值得投入，不只取决于“能不能投”，还取决于它是否能让自己的项目经历、技术栈和职业目标形成比较自然的解释。

筛选时也不要只盯着“能不能拿 offer”。如果一份工作和自己接下来几年的能力发展路径完全错位，即使短期看起来不错，也可能带来长期成本。求职里比较难的部分，往往不是找到信息，而是判断哪些信息真的和自己有关。

怎么判断一个机会值不值得去

我会把机会拆成几个维度来看：收入、方向、成长、匹配度和团队氛围。薪资当然重要，但它不是唯一指标。如果更在意长期前途和能力增长，就要重点看团队方向、业务质量、岗位能提供的锻炼，以及自己能不能在里面接触到真正有价值的问题。

方向是否匹配尤其重要。一个岗位如果短期待遇不错，但实际工作和自己长期想做的事情关系很弱，就需要认真评估它会不会把自己带到一个并不想深入的路径上。反过来，有些机会短期不一定最优，但如果团队问题足够真实、技术栈足够贴近自己的长期方向，也可能值得考虑。

团队氛围同样不能忽略。日常协作方式、决策机制、对技术债的态度、是否允许个人成长和探索，都会直接影响工作体验。很多问题只有在面试反问阶段才能逐渐看出来，所以反向提问不是流程末尾的客套，而是求职决策的一部分。

面试准备不只是背答案

面试准备不能只理解成背八股或者背标准答案。对技术类岗位来说，Coding 基础和常见问题当然重要，它们决定了能否顺利通过筛选和技术面。但项目经历本身也需要提前整理，否则很容易在面试时讲成流水账。

我会尽量把每段经历整理成几个问题：当时要解决什么问题，难点在哪里，我具体承担了什么角色，用了什么方法，最后产出了什么结果，这件事的价值和边界分别是什么。这样组织之后，面试官更容易理解项目，也更容易判断我在其中的真实贡献。

前期积累也不只是堆经历。科研项目、企业合作项目、解决实际问题的论文、比赛经历和实习经历，只有被整理成清晰的问题链条，才会真正变成面试中的有效材料。否则经历再多，也可能只是简历上的几个名词。

面试反问：我会重点确认什么

反向提问的核心目的，是确认团队真实在做什么、岗位真正需要什么、自己加入后会承担什么，以及这份工作是否符合自己的判断。下面这些问题更偏 AI、Agent 和工程化岗位，主要用来判断团队的技术路线、产品落地方式、工程成熟度和协作方式。

Agent 与工程化方向

我了解到公司在积极布局 Agent。在目前的规划中，咱们的 Agent 应用是更偏向于对内赋能，比如研发提效、内部知识库问答和运营自动化，还是已经有明确的对外商业化产品落地场景？或者说，团队主要在解决什么问题，我进去以后的主要工作会是什么？

p.s. 对内场景的容错相对更高，也更容易推进新技术测试和迭代；对外场景则更需要关注幻觉、稳定性和用户体验。这个问题主要是为了确认核心工作方向和内容。

目前行业里 Agent 的应用百花齐放。咱们团队聚焦的场景，是更偏向于处理明确的结构化任务，比如通过 API 调用执行自动化流程，还是更侧重于对非结构化知识的深度理解与推理，比如基于复杂长文档的结构感知与 Agentic RAG？

p.s. 前者更加侧重自动化 workflow，需要对业务本身有深入理解；后者则更侧重 Agent Dev 相关技术，更高的自主权也更依赖模型能力，以及开发者对安全边界的认知。

关于咱们关注的 Agent 应用场景，目前的系统设计是更多定位在 Copilot 模式，也就是需要频繁的人类反馈和确认，还是致力于在特定垂直业务流中实现高自动化率的闭环工作流？

p.s. Human in the loop 目前来看依旧很重要。如果希望打造高自动化率系统，自动化的高质量校验会是核心问题；如果更多允许人工介入，那么扩展系统功能可能会比打磨极致自动化更值得关注。

考虑到复杂业务场景的需求，咱们目前的重心是在打磨单智能体的复杂任务拆解能力，还是已经开始探索多智能体协作的业务落地？

p.s. 多智能体协作已经从技术报告逐渐进入 Demo 阶段，虽然稳定性依旧堪忧，但它仍然是值得关注的前沿方向。当然，它更偏技术探索而非成熟技术，高自主性的 MAS 很可能会带来和人类协作类似的问题。

团队目前是如何构建 Agent 评估指标的？除了传统的 LLM Benchmark，有没有针对业务建立特定的工具调用准确率、执行轨迹或者自动化评测框架？

p.s. Evaluation 永远是 Agent 绕不开的问题。没有评估，就很难判断系统是真的变好，还是只是 Demo 看起来更顺。

在成本和延迟上的权衡策略是什么？团队更多依赖成熟的闭源大模型，还是已经考虑将不同请求路由给不同层级的模型？是否会系统性评估成本、延迟与性能之间的 trade-off？

p.s. 这是工程化绕不开的问题。从技术 Demo 走向生产，需要认真处理成本、延迟、性能和安全边界之间的关系。生产环境的安全边界不能轻易 trade-off，但慢一点、贵一点，有时反而是可以接受的。

团队、协作与个人成长相关的问题

每个开发者有多大的自由来做决定？团队内部结构、协作方式和日常工作划分是什么样的？如果遇到不同意见，通常会怎样处理？

AI Coding 已经介入了绝大多数程序员的工作流，尤其是 Agent Dev 领域。公司如何看待 AI Coding？是否允许员工在项目中较多使用 AI Coding 来加速迭代？团队是否会提供统一的 AI 工具、账号或使用规范？

你对在这里工作最满意的地方是什么？你为什么选择并留在这家公司？

我可以为开源项目做贡献吗？是否需要审批？

后续会继续补充什么

后续这篇文章还可以继续补充几个部分：简历如何围绕目标岗位改写，项目经历如何串联成稳定话术，不同岗位的常见追问应该怎么准备，以及真实面试之后哪些问题被证明有效、哪些问题需要调整。

目前它还不完善，但我希望它至少先把一个基本思路写清楚：求职不是单纯准备答案，而是持续校准自己的方向、能力、表达和选择标准。面试也不是单向考试，而是双方互相确认是否适合的过程。