← 上一章 下一章 →

01 - 自我介绍、职业叙事与技术管理

章节定位：面试的“黄金第一印象”与综合软实力考察。本章涵盖标准自我介绍、9年“安全→管理→AI全栈”职业转型逻辑、“重回一线”动机的深度防御、团队敏捷管理与跨部门协作实战，以及三面总监面与反问环节的高质量答辩策略。

Q1：请先用 1-2 分钟做个简单的自我介绍。

追问场景：一面开场（最常见），面试官刚坐下，手边放着您的简历。

面试官你好，我叫李至君，33岁，本科毕业于三峡大学计算机科学与技术专业，有 9 年的后端与全栈开发经验。

我把这 9 年分成三个阶段来介绍：

第一个阶段是前 4 年（2015-2019），我在深圳的两家安全公司做研发，主要用 Python、Go 和 PHP 做 Web 应用防火墙和漏洞修复相关的产品开发。这期间我打下了比较扎实的网络安全功底，对 OWASP 的各类攻击原理、SDL 安全开发流程都比较熟悉，也养成了比较好的安全编码习惯。

第二个阶段是 2020 年到 2024 年底，我在北京知道创宇武汉分部担任技术经理，大概有 3 年多的管理经验。这个阶段我主要负责核心产品的全周期研发管理，从需求调研、架构设计到任务拆解和交付验收都在做。同时我自己也一直在一线写核心代码，比如用 Go 去构建边缘网关的控制面。另外我还推动了 SDL 落地、CI/CD 流水线搭建和 Code Review 规范，带团队完成过高标准的项目交付，也拿过公司的服务之星奖项。

第三个阶段就是去年 3 月到现在，我在武汉中科坤程做后端开发，但这其实是我主动选择「重回一线」的一个关键节点。我独立全栈交付了「政务小灵通」这个 AI 应用，以 RAGFlow 和 LangChain/LangGraph 为底座，让政务政策问答和任务助手真正落地。这个项目让我把之前的工程化积累、安全底子和最新的 AI 技术栈串了起来。

所以我现在的定位非常清晰：我不想做纯管理，我想做深度参与架构设计和核心编码的攻坚型技术骨干，尤其希望在 AI 应用落地 + 高并发后端这个方向上持续深耕。以上就是我的基本情况。

Q2：你的职业经历跨度挺大的，从安全研发到技术经理，再到现在的 AI 全栈。这个转变背后的逻辑是什么？是刻意规划的还是随机的？

追问场景：面试官对您的履历产生好奇，想考察职业规划能力和自我认知。

表面上看跨度确实大，但回头看，其实有一条很清晰的主线，就是 「往业务价值更近的地方走」。

最早做安全研发，比如 WAF，我的工作更多是围绕漏洞特征、规则引擎、攻击拦截来做。那时候我就在想，我的代码能不能离最终用户更近一些，能不能直接解决业务问题，而不是躲在流量中间做一个拦截节点。所以我在绿盟做动态 WAF 管控面的时候，就开始有意往后端架构和业务侧靠拢。

后来在知道创宇做技术经理，表面上是转了管理，但本质上是我在倒逼自己提升 「架构视野」和「端到端交付能力」。因为做管理逼着我去看全局：需求从哪里来、系统该怎么拆、团队怎么协同才能保证上线质量。这些能力如果不做管理，单纯写代码是很难快速习得的。而且我带团队期间也一直在一线写 Go 的核心控制面代码，从没彻底丢掉编码。

到了 2024 年底，我观察到 AI 尤其是 RAG 和 Agent 技术到了真正可以落地的阶段，不再只是概念。我当时想，如果我再不重回一线扎进去，我可能就错过这波技术浪潮了。所以我很主动地选择了「降级」——从技术经理回到后端开发岗位，去中科坤程亲手做一个 AI 项目，从 RAG 知识库搭建到 LangGraph 编排再到 React 全栈，全部自己走一遍。

所以概括起来就是：安全给了我深度，管理给了我广度，而现在的 AI 全栈是我把深度和广度融合起来、做真正有价值落地的选择。它不是随机的，是我有意为之。

Q3：（追问）你之前在知道创宇已经是技术经理了，带团队也拿了奖，现在为什么愿意回到一线做普通开发岗？不会觉得心理有落差吗？

追问场景：这是您简历中最敏感的“雷区”。总监面或 HR 面大概率会追问，以验证您是否真的愿意踏实写代码。

这个问题我坦诚讲，我在做决定之前反问过自己很多遍，答案是：不仅没有落差，反而有一种释放感。

说直白一点，我做技术管理的 3 年，其实有大量的时间是在开会、对齐需求、排期、写周报、处理团队人员情绪。这些事不是没价值，但它挤占了我深入钻研技术的空间。我属于那种对着代码调优到凌晨反而觉得充实的人，但做了管理之后，我可能一整天都没打开过 IDE，那段时间我其实是焦虑的。

另外还有一个很现实的判断：现在的 AI 技术迭代太快了，这种窗口期如果我只是「管人」而不是「编码」，我很快就会被淘汰。LangGraph、Agent、RAG 这些新东西，我不亲手写一遍，根本不懂它的坑在哪，日后就算想做技术决策也是空中楼阁。

所以我选择在 33 岁这个节点主动降下来，不是因为我做不好管理，而是因为我判断 「接下来 5 到 10 年，技术一线才是最能创造价值的地方」。我有管理经验，带过团队，知道怎么把事做成，这个能力不会丢；但如果我现在不去补 AI 和深度编码的课，后面就真的补不上了。所以对我来说这不是降级，是 「换挡加速」。

Q4：那你离开上一家公司（武汉中科坤程）的原因是什么？

追问场景：HR 面或一面收尾，面试官需要排除职业稳定性风险。

主要有两个层面的考虑，我分开说：

第一是业务体量与场景的局限。 我在中科坤程做的政务小灵通，从 0 到 1 跑通了政务 RAG 和 Agent 的完整链路，这个项目本身我是很有成就感的。但它本质上是一个面向特定政务客户的项目型交付，系统的并发规模和业务复杂度相对有限。我做完 0 到 1 之后，发现后续更多是运营维护和同类项目复制，技术深度上很难再往上走了。而我个人更希望在 高并发、高复杂度的系统架构 场景中持续打磨。

第二是平台属性的差异。 中科坤程偏政务系统集成方向，而我的技术底色和兴趣点更偏向于 「技术产品型」平台——比如像贵司这样以自研产品为核心、对架构和工程化有高要求的团队。我希望在一个技术驱动、有持续演进压力的环境里，把我在 AI 应用、高并发 Go/Python 后端上的积累真正发挥出来。

所以离职原因简单讲就是 「项目完成了阶段性目标，我个人需要更大的技术纵深和平台」。我在中科坤程做的是从 0 到 1 的突破，现在我希望做从 1 到 N 的规模化演进。

Q5：如果用一句话总结，你觉得你相比于其他后端 / 全栈候选人，最核心的差异化优势是什么？

追问场景：一面收尾或总监面，面试官想快速抓住您的核心卖点。

我觉得我的差异化优势可以概括为三个关键词的叠加：AI 落地 + 多语言工程底座 + 安全基因。

现在很多候选人要么只懂传统后端（高并发做得好但不懂 AI），要么只懂调用 AI API（能调通但不懂底层工程和安全）。而我的履历恰好是 「把 AI 应用落地扎在扎实的工程化地基上」：

  • AI 层：我亲手用 RAGFlow + LangGraph 落过政务级 RAG 和 Agent，懂检索、懂编排、懂流式，也踩过知识库治理和工具调用熔断的坑。
  • 工程层：我横跨 Python、Go、Java、Node 四种语言，做过微服务、写过控制面、搭过 CI/CD，能在高并发场景下做架构决策。
  • 安全层：我有 6 年的安全研发背景，从 WAF 到 SDL 到 OWASP，我写出来的代码天然带着安全直觉——这在当前 AI 应用容易产生 Prompt 注入和数据泄露的背景下，是一个很重要的隐性优势。

所以如果贵团队需要一个 「既能带团队把 AI 产品从 0 推到 1，又能亲自下去写核心代码、保障系统高可用和安全合规的人」，那我和这个画像的匹配度是相当高的。

Q6：你的简历上写熟练 Python / Go / Java / Node.js，那你现在最擅长哪个？如果让你选一个作为主力语言，你选哪个？

追问场景：一面技术面开场，考察技术定位与真实能力深度。

这个问题我分两个维度回答。

从当前项目实战来看，我最顺手的是 Python 和 Go。

Python 是我做 AI 应用的主力，因为整个 AI 生态（LangChain、FastAPI、RAGFlow 的底层接口）基本都在 Python 上，它的敏捷性和丰富的库支持让我在做 RAG 和 Agent 原型时效率非常高。政务小灵通的后端就是用 FastAPI + Python 3.11 构建的。

Go 则是我做高并发、高性能后端系统的首选。在知道创宇做边缘网关控制面时，我用 Go 处理多路探针数据汇聚和近实时选路调度，它的 goroutine 和 channel 模型在处理 I/O 密集型任务时非常干净。如果让我做一个高吞吐的 API 网关或数据管道，我会毫不犹豫选 Go。

如果说「主力语言」，我会选 Go，但理由可能有点不一样。

因为我给自己的定位最终是 「AI 应用架构师」 而不仅仅是 AI 算法调包侠。AI 应用做到后面，真正卡脖子的往往不是模型本身，而是 RAG 管道的吞吐量、Agent 工具调用的延迟、多租户隔离下的资源控制——这些恰好是 Go 的强项。所以我未来的规划是：用 Python 做 AI 原型和业务胶水层，用 Go 做核心高并发底座，两者结合。

Java 和 Node 我都有项目经验（WAF 定制版和之前的一些全栈项目），但如果现在让我选，我不会把它们作为第一主力，更多是「能看懂、能维护、能在遗留系统改造中平滑接手」的储备能力。

Q7：你 2015 年毕业，到现在 9 年了。你对未来 3-5 年的职业规划是什么？

追问场景：三面总监面或 HR 终面，考察稳定性和成长性。

我未来 3-5 年的规划非常清晰，可以用两个关键词概括：「纵向扎根」和「横向赋能」。

纵向扎根：我要在 「AI 应用落地 + 高并发后端」 这个交叉领域做出真正的技术纵深。具体来说，我希望在 RAG 的检索效果优化、Agent 在复杂业务场景下的确定性编排、以及大规模流式对话系统的架构设计这三个方向上持续深耕，成为这个细分领域能解决疑难杂症的技术骨干。我不追求 3 年升 P8 这种虚的 title，我更在意我能不能在系统扛不住的时候冲上去定位问题，能不能在技术选型时给出让人信服的判断。

横向赋能：我不会放弃我带过团队的经验。当我的技术深度足够之后，我希望能以 「技术 Lead 兼核心编码」 的角色去带一个小而精的团队，把我的安全编码规范、架构设计方法和 AI 落地经验复制给更多人。但我有一个底线：不管到什么阶段，我必须保持一定比例的编码时间，不做纯管理。

所以落实到这次求职上，我选平台的标准就是：技术上有挑战、能让我持续写核心代码、业务上有 AI 或高并发场景。只要满足这些，我至少可以稳定投入 4-5 年，和团队一起把一个产品从成长期做到成熟期。

Q8：在带团队期间，你做过最难的团队管理决策是什么？你怎么处理的？

追问场景：考察带人经验，面试官想看您是否有“管人”的真实经历而非“挂着title写代码”。

答：

最难的是在知道创宇期间，遇到一位 “技术能力很强但协作意愿很差” 的核心开发。

背景：这位同事是团队中Go水平最高的人，一个人能顶两三个普通开发。但他的问题是：不愿意写文档、不愿意做Code Review、有需求变更时习惯性抵触、甚至有一次直接在项目群和PM吵了起来。其他团队成员私下跟我反馈“和他合作压力很大”。

处理过程（不是直接辞退，而是做了一次“软硬兼施”的沟通）：

  1. 私下1v1沟通（承认价值+指出问题）：先肯定他的技术贡献，然后明确列出三次具体的协作冲突事件，告诉他：“你的技术水平我很认可，但现在的问题是，你的输出质量在被协作成本对冲。你一个人写100分的代码，但需要周围3个人花50分的精力来配合你，整体效率是负的。”
  2. 明确底线（硬的部分）：我告诉他Code Review和文档是团队的硬性规范，不是“可选项”。如果不配合，我会在绩效上体现，未来项目核心模块的分配也会重新考虑。但同时也给了他一个“出口”——如果他不愿意遵守团队规范，我可以在公司内部帮他推荐一个更适合“独狼”模式的团队。
  3. 给他“赢”的空间（软的部分）：我让他负责一个技术难度最高的模块，并公开承诺“该模块的技术方案由他主导，PM和我的需求变更优先和他对齐”。这给了他一定的技术自主权，作为他遵守协作规范的交换。

结果：沟通后他改进了很多——开始写文档了，Code Review虽然话不多但至少参与了。虽然最后他因为个人原因离职了，但离职前他说过一句让我印象很深的话：“你是第一个把‘技术好’和‘团队合作’分开跟我谈的Leader。”——我当时就意识到，我之前作为技术管理者的沟通视角有了实质性突破。

Q9：你负责过任务拆解和进度把控。如果项目进度落后了，你怎么处理？

追问场景：项目管理能力考察，面试官想听“落地的过程”而非“我催他们加班”。

答：

我处理进度落后的逻辑是 “先诊断再开药，三步走”：

第一步：判断落后原因（1小时内完成诊断）

进度落后有四种可能，对应的解法完全不同：
- 需求变更：如果是频繁变更导致，我会把变更集中起来，与PM协商“需求冻结期”或“批量变更窗口”。
- 技术难点：如果是某个技术难题卡住了，我会亲自参与技术攻关（写demo、调研方案），而不是只在旁边催。
- 资源不足：如果是人手不够，我会重新评估优先级，砍掉非核心功能或向公司申请临时支援。
- 执行力问题：如果是个别成员效率低，我会启动1v1沟通，了解原因（是能力不足还是动力不足），针对性帮扶或调整分工。

第二步：制定“止血方案”并明确新的里程碑

在诊断出原因后，我会重新调整发布计划，把“必须做”和“可以延后做”划清界限。然后在团队里公开宣布新的里程碑（而不是私下悄悄改），让大家对节奏有共识。如果必须压缩时间，我倾向于 “砍功能，不砍质量”——少做一个模块可以后续补，但上线一个质量低劣的版本会严重消耗团队后续的迭代效率。

第三步：增加“过程可见性”

进度落后往往是因为风险发现得太晚。我在知道创宇期间养成了一个习惯：每天站会只问三个问题——“昨天做了什么？今天打算做什么？有卡点吗？”如果某个人连续三天都说“在调试”而没有进展，我会在站会后单独沟通，提供实质性的帮助或调整任务。同时，进度看板（Jira/Trello）上的卡片状态必须实时更新，每周五发一次进度周报给干系人（产品、测试、客户对接人），让所有人对“落后多少”有透明认知。

Q10：讲一次你跨部门协作的成功案例。你是怎么推动其他部门配合你的？

追问场景：考察软技能和推动力，面试官想确认您不只是“内部管得好”。

答：

我讲一个在知道创宇推动 “SDL安全流程落地” 时跨部门协作的案例。

背景：SDL涉及研发、测试、运维、安全合规四个部门。研发团队觉得“安全流程拖慢进度”，测试团队觉得“我们没有安全测试能力”，运维团队觉得“上线流程又要加步骤很烦”。各方都有抵触情绪。

我的推动策略（三步）：

  1. 先找到各方的“痛点”而不是“义务”：我没有直接说“大家都要遵守SDL”，而是分别找各部门负责人聊，了解他们的核心诉求。研发想减少上线后的紧急Bug；测试想避免“上线前夜发现安全漏洞导致延期”；运维想减少半夜被叫起来应急。我把SDL的每一步都和这些痛点做了映射——“代码扫描不是为了增加流程，是为了让你们少加班修漏洞。”

  2. 做一个“最小可行版本”而不是“完美方案”：我没有一股脑推全量方案，而是先选了一个低侵入的环节（在MR阶段加入SAST自动扫描）试运行2周。等大家看到了效果（确实拦截了几个SQL注入风险），再逐步推广到DAST、安全验收等环节。

  3. 把“成果”归功于协作方：在向上汇报时，我强调“测试团队配合完成了DAST的用例设计”、“运维团队协助搭建了扫描环境”，而不是“我推动了SDL”。这让各部门感受到被认可，后续配合更积极。

结果：SDL从“我推”变成了“大家想要”，最终沉淀为团队的发布Checklist中的固定环节。

Q11：你带团队时，Code Review推行不下去怎么办？这是很多技术管理者的痛点。

追问场景：面试官也是过来人，知道“推行Code Review”是技术管理中最常见的阻力之一。

答：

关于具体的工程执行措施（如自动化卡点与双签制），在后续第 07 章有详细展开，这里我补充一些 “做思想工作” 层面的经验：

第一步：先承认“Review确实花时间”。我从不否认Code Review会增加工作量，相反我会说：“对，确实会占用你的时间，但我跟你保证，它省下的调Bug时间会是Review时间的3倍。”——先共情，再讲收益。

第二步：降低Review的门槛，而不是提高标准。最开始我允许“看一眼就过”的Review（只要没有明显Bug），不要求“每条注释都要回复”。等大家养成了习惯，再逐步提高要求（比如要求Reviewer必须至少提一个问题）。

第三步：Leader以身作则，而且是最严格的Reviewer。我自己的MR从来没有“跳过Review”过，哪怕是一个一行代码的hotfix，我也找同事Review。同时，我作为Reviewer时，回复非常认真——不仅指出问题，还会附上“建议这样改，原因是…”——这让团队觉得“这个流程Leader自己也在严格遵守”，而不是“Leader用来管我们的工具”。

一个转折点：有一次一个同事发了一个MR，我说“这里有个潜在的并发问题”，他当时不太信。结果他跑了一下压测，果然复现了。从那以后，他对Code Review的态度主动转变了——因为他亲身验证了“Review能发现我自己发现不了的问题”。最好的说服不是讲道理，是让他自己体验到价值。

Q12：如果新公司的技术方案和你之前的认知不一致，比如你习惯用Go，但公司主力是Java，你怎么适应？

追问场景：考察技术包容性和适应性。面试官担心“技术品味高”的候选人“水土不服”。

答：

这个问题我可以用我的实际经历回答。我之所以掌握4门语言，正是因为每到一个新环境，我都在主动适应团队的技术栈：
- 在网安信用PHP/Python，我学。
- 在绿盟用Go和Java，我转。
- 在知道创宇Go是主力，Python用于工具脚本。
- 在中科坤程用Python + TypeScript做AI全栈。

我的态度是：语言是工具，业务是目标，团队是队友。 我不会因为“我更喜欢Go”就排斥用Java。只要团队选型有合理的理由（比如Java生态、人员储备、遗留系统兼容），我会主动拥抱。

具体的适应方法：
1. 第一周：通读团队的代码规范和已有的核心模块代码，不着急写新代码，先跑通一个最小的“Hello World”并部署到测试环境。
2. 第一轮任务：主动认领一个小的Bug修复或文档完善任务，通过小任务熟悉工具链（构建、测试、部署）和代码风格。
3. 持续输出：当我对语言和框架有一定熟悉度后，我会主动把我的经验（比如多语言并发模型的对比）分享给团队，作为技术交流的贡献，而不是“指手画脚”。

Q13：你对薪资和职级的期望是什么？你觉得自己值这个价吗？

追问场景：HR面或总监面尾声，面试官想看您是否有“合理的自我认知”。

答：

关于职级期望：我不追求特定的“P几”title，我更看重的是“职责边界”和“技术挑战”。我希望能深度参与核心模块的架构设计和编码，而不是边缘的维护工作。如果title能匹配我的经验（9年、带过团队、做过AI落地），那是水到渠成的事；如果title略低但职责符合我的预期，我也愿意接受——我有信心在半年内用产出证明自己。

关于薪资期望：我目前的基础期望是 年薪XX-XX万（结合武汉市场行情和我的资历）。我的依据是三方面的叠加：9年全栈经验 + 3年技术管理 + AI应用落地能力（RAG/Agent）。这个组合在市场上是相对稀缺的，尤其是在武汉。

关于“值不值”：我可以举两个例子来佐证我的价值。一是“政务小灵通”项目，我从0到1独立交付了完整的AI应用，这证明我有独立端到端交付能力；二是我带团队时把上线回滚率从15%降到了5%，这证明我有工程质量的把控能力。所以我期望的薪资是和这些产出匹配的。当然，薪资不是唯一因素——技术挑战和团队氛围同样重要，如果平台足够好，薪资可以谈。

Q14：你有什么想问我们的吗？（反问环节）

追问场景：面试结尾，考察您的“求职动机”和对公司的考察深度。好问题能让面试官记住你。

答：

我会根据面试轮次和面试官的角色，从三个维度选择合适的问题提问：

向技术面试官（架构师/技术Leader）问（选2-3个）：

  1. 关于技术栈：“团队目前在AI/后端方向，最大的技术挑战是什么？是吞吐量、稳定性、还是模型效果？这个挑战也是我入职后可能首要参与解决的问题吗？”
  2. 关于工程文化：“团队的Code Review文化是什么样的？是偏严格还是偏宽松？有没有自动化工具（如SAST）集成到CI里？”
  3. 关于团队定位：“这个岗位是新open的还是前任离职的？如果是新open的，团队期望这个岗位在半年内交付什么？”
  4. 关于成长：“团队内部有技术分享或学习机制吗？公司是否支持参加行业会议或培训？”
  5. 关于项目阶段：“这个产品/项目目前处于什么阶段（孵化期/成成长/成熟期）？技术债务重吗？”

向总监/高阶管理者问（选1-2个）：

  1. 关于业务方向：“未来1-2年，业务上最大的机会和挑战分别是什么？技术团队需要提前储备什么能力来应对？”
  2. 关于团队文化：“您认为在这个团队中，什么样的工程师最容易脱颖而出？是技术深度、业务理解、还是主动性？”
  3. 关于定位：“您希望这个岗位的核心产出是什么？是系统的稳定性、功能的快速迭代，还是技术债的治理？”

向HR问（选1-2个）：

  1. 关于入职流程：“如果面试通过，后续的流程是怎么样的？大概多久能有反馈？”
  2. 关于团队规模：“这个岗位所在的团队目前多少人？是集中办公还是分布式？”
  3. 关于发展路径：“技术岗位的发展双通道（管理/专家）在公司是怎么运作的？”