经历相关
更新: 6/20/2025 字数: 0 字 时长: 0 分钟
为什么本科没有选择工作
首先，我非常感谢我的本科教育。作为软件工程专业的学生，它给了我非常扎实的编程能力和工程化思想，让我掌握了如何去构建一个可用的软件系统，理解了软件的整个生命周期。这四年是我成为一名合格开发者的基础。
不过，在本科的学习和项目实践中，我逐渐发现了一个让我更着迷的方向。在开发中，我在软件工程方面学到的是如何把房子盖起来，但我缺少如何把它建成一座坚固、安全的堡舍的系统性知识。我当时对网络攻防、加密算法、系统底层安全的原理了解得不够深入，很多时候只是知其然，而不知其所以然。
因此，我做出了读研的决定。对我来说，这并不是一个逃避就业的选择，而是一个非常明确的自我投资和能力聚焦的过程。我希望能够：
- 构建体系化的安全知识：我渴望能在一个顶尖的学术环境中，系统性地学习网络空间安全的底层原理，比如密码学、逆向工程、安全协议分析等。这能让我从更高的维度去理解安全问题，而不是停留在“使用某个工具”的层面。
- 提升自己的平台和视野：我相信，进入一个顶尖院校，能够让我接触到更前沿的科研方向、更优秀的导师和同学。这种环境和资源的提升，对于我想深入的、技术门槛相对较高的安全领域来说，是至关重要的。
就业方向和规划
我的就业方向定位
首先，关于未来的就业方向，我非常明确。我希望成为一名在云安全与智能安全领域的后台开发工程师。
这个方向的选择主要基于三点：
- 兴趣驱动：我的本科学的是软件工程，它教会了我如何“构建”系统；而我的研究生专攻网络空间安全，它教会了我如何“保护”系统。我发现，将这两者结合起来，在安全这个攻防对抗最激烈的领域，去构建稳定、可靠、智能的防御体系，是让我最有热情和成就感的事情。
- 知识背景匹配：我的研究生方向是“基于大模型的安全应用”，并且深度参与了容器安全Agent和告警平台的开发。这与云鼎实验室的业务方向，如云原生安全、内部安全应用开发、利用AI提升安全效率等，高度契合。我希望把我所学的知识，应用到最大规模、最前沿的真实场景中。
- 行业前景：我相信，随着所有企业都在加速上云、智能化转型，云安全和AI安全将是未来十年最具挑战和发展前景的技术领域之一。我希望投身于这个主航道。
我的未来职业规划**
基于以上的方向定位，我为自己设定了一个分阶段的规划，主要分为短期（1-3年）和长期（3-5年）。
近期规划 (1-3年)：深度学习与扎实贡献
作为一名新人，我认为前三年是打下坚实基础、快速成长的黄金时期。我的核心目标是“沉下去，学得深，做得稳”。
- 技术扎根：我希望能在之后入职后，尽快融入团队，并投入到核心业务中。我不只想停留在“会用”Go或K8s的层面，我更渴望能深入理解一个大规模、高可用的DoS防护平台背后的架构设计。我会主动学习和吸收具体业务场景下的最佳工程实践。
- 成为可靠的贡献者：我的目标是在第一年内，能够独立负责一个功能模块的开发、测试和上线，做到代码扎实、交付可靠，成为一个让团队和导师信赖的工程师。我会认真对待每一次Code Review，将团队的规范和标准内化为自己的习惯。
- 理解业务场景：我会积极地去理解我所做的技术是如何服务于业务的，它解决了什么安全问题，为公司带来了什么价值。只有理解了业务，才能做出更好的技术决策。
远期规划 (3-5年)：提升影响与扩展视野
在打好坚实基础之后，我希望自己能从一个可靠的执行者，向一个能为团队带来更大价值的角色转变。
- 成为领域专家：我希望能在3到5年内，在我所负责的细分领域，比如我非常有兴趣的“大模型在安全领域的工程化应用”，形成自己的技术深度和影响力。我希望届时我不仅能完成复杂的开发任务，还能为团队的技术选型和方案设计提供有价值的见解。
- 承担更复杂的职责：我希望能有机会参与到一些更具挑战性的项目中，承担更重要的职责，比如一个新安全服务或工具的早期架构设计，或是一次重大的性能优化攻关。
- 分享与成长：技术是需要分享和传承的。我希望到那时，我能将自己的学习和实践经验总结出来，通过技术分享、写文档、或者指导新同学等方式，为团队的技术氛围和知识沉淀做出自己的贡献。
总而言之，我的职业规划是清晰且专注的。我希望成为一名在云安全与智能安全领域有深厚积累的专家型工程师。而腾讯安全云鼎实验室，无论是其在云原生安全的前沿探索，还是在内部海量业务场景下的安全实践，都为我提供了一个实现这个规划的、独一无二的理想平台。我非常渴望能在这里开启我的职业生涯，并与团队共同成长。
自我介绍
自我介绍
尊敬的面试官，您好，我叫黄宗敖，目前在华中科技大学网络空间安全专业读研二，明年毕业，我的研究方向是基于大模型的安全应用。在研究生期间，我主要参加了3个项目和2个创新大赛。在项目中为主要开发，包括后端和部分前端的开发工作，主要使用Go/Python。这里主要介绍一下收获比较大的两个内容。
第一个是关于校内创新文章平台的设计与实现项目，基于Go-zero微服务架构和高并发理念进行设计，同时集成了ChatGPT的部分功能。该项目中，我主要负责文章微服务的构建，构建过程中使用了kafka和canal等中间件，完成后使用wrk进行压力测试满足高并发的需求。
第二个是去年参加的研究生网络安全创新大赛，课题是基于大模型的网络侧告警降噪研判系统，目的是利用大模型来帮助特定企业提升告警研判的效率。整个系统研判侧主要包括两部分，首先是告警的降噪和聚合，然后再对聚合后的告警利用大模型进行研判。在实际部署运营后，降噪率可以达到98%，大模型可研判部分可以达到82%
我的自我介绍完毕，谢谢。
1分钟自我介绍核心优势
好的，面试官您好。我认为我的核心优势可以总结为三个相互关联的方面，这也是我区别于其他候选人的地方：
第一，我具备扎实的后端工程能力。我的本科学的是软件工程，并且在项目中独立负责过基于Go-zero的微服务开发，对构建高并发、高可用的后端系统有非常深入的工程实践。我不仅能写代码，更能从系统稳定性和性能的角度去设计和实现。
第二，我拥有体系化的安全知识与攻防视野。 我研究生的专业是网络空间安全，这让我不仅知道如何‘构建’系统，更懂得如何从攻击者的视角去‘保护’系统。无论是容器安全Agent的开发还是安全告警平台的实践，都让我具备了专业的安全思维，能更好地理解业务背后的安全需求。
第三，也是我最具特点的优势，是我具备前沿技术的落地能力。 我将我的研究方向——大模型，成功应用到了告警研判的实际场景中，并取得了可量化的成果。这证明了我具备快速学习和应用新技术来解决复杂安全问题的能力。我相信这种将AI与安全工程相结合的能力，在未来的安全领域会非常有价值。
所以，如果用一句话总结我的优势，那就是：‘工程为基，安全为用，AI为器’。我相信这三者的结合，能让我快速融入团队，并为云鼎实验室在前沿安全领域的探索做出切实的贡献。
为什么选择TX云
我选择贵部门，是基于我对行业赛道、公司平台和团队方向三个层面综合考量的结果。
首先，从行业赛道层面来说，我坚信云安全与智能安全是未来的主航道。
我自己的研究方向就是基于大模型的安全应用，我深刻地感受到，随着所有企业加速上云和智能化转型，传统的安全边界正在消失。未来的安全攻防主战场一定是在云上，而决胜的关键，则在于如何利用AI等智能化手段去应对海量、复杂的威胁。我非常渴望能投身于这个最具挑战和发展前景的领域，而不仅仅是做一个通用的后端开发。
其次，从公司平台层面来说，我认为腾讯提供了世界级的平台和独一无二的挑战。
腾讯拥有国内乃至全球最复杂、最多样化的业务场景，从数亿用户使用的社交、游戏产品，到服务千行百业的产业互联网，再到底层的腾讯云基础设施。
- 保护这样的平台，所面临的攻防挑战是世界级的，它能给予工程师的成长空间和技术视野，是其他公司无法比拟的。
- 同时，我也一直非常关注腾讯在技术领域的开源贡献和工程文化分享，我了解到公司对于技术有着极致的追求，这对我这样希望在技术上不断精进的新人来说，非常有吸引力。
最后，也是最关键的，是贵部门——腾讯安全云鼎实验室，与我的技术背景和职业规划高度精准地匹配。
在前两轮技术面试中，通过和老师们的交流，我了解到贵部门的业务方向，这让我感到非常兴奋，因为这几乎就是我一直在准备和努力的方向：
- 在容器安全方面：我在实习中深度参与过容器安全Agent的开发，对容器运行时安全、镜像漏洞扫描等有扎实的实践经验。而贵部门的核心业务之一就是针对腾讯云的容器安全开发。这让我感觉，我之前的积累可以在这里立刻发挥价值，并且能接触到在单一企业内部无法想象的、更大规模和更复杂的真实云原生安全场景，这是我非常渴望的。
- 在内部安全应用和智能化方面：我的研究生课题和比赛项目都聚焦在“基于大模型的安全应用”上，我主导开发了告警研判系统并取得了可量化的成果。而我了解到，贵部门也在负责腾讯云内部的安全应用和DoS平台开发，并将AI技术用于提升安全效率。这与我的研究方向和实践经验不谋而合。我非常期待能和团队的前辈们交流学习，将我的想法和实践应用到腾讯级的海量数据和复杂场景中去。
总结来说， 我选择这里，是热情、平台和匹配度三重因素的叠加。
- 热情：我对云与AI安全这个赛道充满热情。
- 平台：腾讯提供了世界级的平台和挑战。
- 匹配度：云鼎实验室的业务方向又与我的个人技能和职业规划完美契合。
为什么GAP
首先，在本科临近毕业时，我对自己的未来方向做了一次深入的梳理。
我的本科学的是软件工程，这给了我非常好的工程技术基础。但在学习和实践中我发现，相比于单纯地实现业务功能，我对于系统背后的安全问题——比如如何抵御攻击、如何保护数据——有着更浓厚的兴趣和热情。我意识到，虽然我能“写”出可用的代码，但要想真正进入顶尖的安全领域，我当时在安全领域的理论深度和知识体系还不够系统和扎实。我的目标不仅仅是尽快找到一份工作，而是希望能在自己热爱的领域有一个更高的起点和更强的竞争力。
其次，我为自己设定了一个清晰且有挑战性的目标。
这个目标就是考取华中科技大学这样的顶尖院校的网络空间安全专业。我知道，对于一个普通院校的本科生来说，这是一个不小的挑战，它需要破釜沉舟的决心和百分之百的投入。如果我一边工作一边准备，很可能两边都做不好。因此，我决定给自己一年的时间，专注地、心无旁骛地去完成这一件事。
在那一年里，我的生活非常规律和专注，同时我也把它看作是一次“自我集训”。
除了系统性地复习备考的专业课和公共课，我并没有完全脱离技术实践。
- 我会带着“安全”的视角，去重读《计算机网络》、《操作系统》这些经典教材，思考其中的协议缺陷和安全隐患。
- 我也会利用一些在线的CTF靶场平台来锻炼自己的攻防实践能力，这让枯燥的备考过程变得有趣，也让我始终保持着对安全技术的热情和动手能力。
最终，我很幸运地达成了自己的目标。但对我来说，这次经历最大的收获，远不止一纸录取通知书。
- 第一，它极大地锻炼了我的抗压能力和自驱力。 我学会了如何为了一个长期、明确的目标，去制定详细的计划并日复一复一日地坚持执行。
- 第二，它让我深刻理解了“延迟满足感”的重要性。 我相信，为了一个更远大的目标，付出时间和努力，沉下心来打好基础，是非常值得的。
所以，对我而言，这一年不是职业生涯的“空窗期”（GAP），而是我为了实现从通用软件开发到安全开发的职业转型、为了能精准进入云安全这个赛道而进行的一次至关重要的、高强度的“自我投资”。它让我变得更加专注、坚韧，也为我之后在研究生阶段的学习和项目实践，打下了非常坚实的心态和知识基础。
项目相关
更新: 6/20/2025 字数: 0 字 时长: 0 分钟
针对校内创新文章平台项目的最大的收获
这个项目对我来说，最大的收获主要在两个层面：技术工程的深化和团队协作的实践两个方面。 这个项目有5名同学参与： 后端3名同学：后端主要有6个微服务模块：文章、用户、消息、问答、关注、聊天，我主要负责文章和用户。 前端1名同学 leader+前后端串联1名同学
首先，在技术工程层面，我完整地掌握了如何构建一个高可用的现代化后端服务。
- 一是微服务架构的实践。 使用Go-zero框架让我深刻理解了微服务不只是简单地拆分服务，还包括服务发现、RPC通信、API定义（Protobuf）等一系列工程问题。这让我思考如何在保证服务独立性的同时，维持它们之间的高效通信。
- 二是高并发设计的核心思想。 我学到的不仅仅是使用Kafka和Canal这两个工具，更是理解了它们背后的设计哲学。比如，引入Kafka就是用异步化来换取系统的高吞吐和解耦，这是应对流量洪峰的关键；使用Canal则是让我接触到了数据同步模式。最后通过压测验证，也让我学会了如何用数据驱动性能优化，而不只是凭感觉。
其次，在个人和团队层面，我锻炼了作为一名后端开发者在团队中的“闭环”能力和协作意识。
- 我作为文章微服务的模块负责人，需要对这个模块的交付质量负全责。这意味着我不仅要写好自己的代码，还要主动向上游（比如负责前端的同学）提供清晰、准确的API文档，并向下游（比如依赖我服务数据的其他后端同学）保证服务的稳定性和性能。
- 这个过程让我深刻地理解到，团队协作中，每个人的可靠性最终汇聚成了整个项目的可靠性。 一个稳定、文档清晰的服务，是对队友最大的负责，也是项目成功的基础。
- 这个过程让我学会了如何与团队成员进行有效的技术对焦，确保我们各自开发的服务能够无缝集成。这比一个人写所有代码需要更多的前期沟通，但最终保证了并行开发的高效和系统的可维护性。
针对大模型告警降噪的体会
整个项目分为5个人：
- 导师作为leader
- 前端1名同学
- 后端2名同学，后端分为告警的降噪/聚合和大模型的微调和应用，我主要负责告警降噪和微调，参与了部分大模型的实际应用设计
- 前后端串联1名同学
这个比赛对我来说意义非凡，因为它完美地将我的研究方向和实际安全场景结合了起来，我的收获也超越了纯粹的技术层面
首先，我学会了如何将一个前沿的AI技术，转化为一个可落地、有价值的工程解决方案。
- 我最大的体会是，用大模型解决问题，算法本身可能只占30%，而数据处理和工程化占了70%。我主要负责后端工程化和架构，而团队里有同学更擅。在进行告警降噪和聚合时，我们共同设计算法；在进行利用大模型应用的时候，也是要进行协调合作
第二，我深刻体会到了在高压下，高效的团队协作机制是成功的关键。
- 比赛的周期很短，任务很重。为了确保我们能按时交付有竞争力的作品，我们建立了一套高效的协作机制：
- 明确分工与日站会：我们每天早上用很短的时间开站会，同步进度和遇到的困难，确保信息透明，及时互相帮助。
- 文档驱动与版本控制：我们使用共享的在线文档来管理任务列表和记录关键决策，所有代码都通过Git进行规范的版本控制和Code Review，避免了混乱。
- 数据驱动决策：当我们在技术路线上产生分歧时，我们会快速进行小规模的原型验证（PoC），用数据和实验结果来做决策，而不是无休止地争论。
- 这种以解决问题为导向、专业且高效的协作方式，让我明白了如何在一个快节奏的团队中贡献自己的力量，这也是我认为比获奖本身更宝贵的财富。
遇到的分析和解决办法
情景 (Situation):
当时我们已经完成了前期的告警数据清洗和聚合工作，需要将聚合后的告警信息发送给大模型进行分析，让它判断告警的真实性、风险等级并给出处置建议。
任务与分歧 (Task & Disagreement):
我们的任务是设计一个高效、准确且成本可控的方案来与大模型API进行交互。
我的初步方案： 我当时作为主要负责后端工程的同学，更倾向于“性能和效率优先”。我建议将“元告警”的所有信息（如源IP、目标IP、触发规则、关联的原始告警等）进行一次性地、结构化地组装，然后单次调用大模型，获取一个综合性的研判结果。这样做的好处是响应速度快，API调用成本低且可控。
队友的方案： 负责算法的同学则倾向于“准确性优先”。他建议设计一个更复杂的“多轮对话式”的研判链（Chain-of-Thought）。比如，先向大模型提问“这是一个什么类型的告警？”，得到初步判断后，再根据结果追问“这个源IP的历史行为是什么？”，最后再综合多次问答的结果，得出一个更详尽、更准确的结论。
分歧点很明确：是选择单次调用的效率，还是选择多轮调用的极致准确性？
我的行动 (Action):
面对这个分歧，我没有直接否定他的想法，因为我非常理解他的出发点是追求极致的研判效果，这同样是项目的核心目标。我的处理方式是：
- 充分沟通，互相理解： 我首先肯定了他方案的优点，即通过追问和推理，确实可能挖掘出更深层次的信息，提高复杂告警的判断准确率。然后，我也冷静地、用数据量化的方式，提出了我的顾虑：这样的多轮调用链可能会导致单个告警的研判时间从1-2秒增加到10秒以上，并且API的Token成本也会成倍增加，在大规模部署时可能会成为瓶颈。
- 提议用数据说话，而非争论： 我建议，我们不应该只停留在理论讨论上。我们可以设定一个明确的评估标准，比如“研判准确率”、“平均研判耗时”和“单次研判成本”。然后，我们针对一小部分有代表性的、真实的告警样本，同时实现我们两个人的方案作为原型（PoC），进行一次小规模的对比测试。
- 分工协作，共同验证： 我们很快达成了共识。他负责设计更复杂的、用于多轮调用的提示工程（Prompt Engineering），我则负责将两个方案都快速工程化，并搭建了一个简单的测试框架，确保我们能公平地衡量每个方案的各项指标。
结果与收获 (Result & Learning):
测试结果出来后，我们的分歧就迎刃而解了。
- 结果：数据显示，同学的多轮调用方案在某些非常复杂、模糊的告警上，准确率确实能比我的方案高出约10%，但平均耗时是我的方案的5倍以上。而我的单次调用方案，已经能高效、准确地处理超过80%的常规告警。
- 最终的解决方案：基于这个数据，我们一起设计出了一个远比我们各自最初方案更优秀的“分级研判”策略。系统默认使用我提出的快速单次调用模型来处理绝大多数告警。但如果模型返回的置信度较低，或者告警本身的初始风险评级就非常高，系统会自动将该告警“升级”，并触发他设计的深度多轮研判流程。这个方案兼顾了效率、成本和准确性。
这次经历对我来说是一次非常宝贵的收获：
- 第一，我学会了技术决策不是非黑即白的，很多时候需要在多个目标（如性能、成本、效果）之间做权衡（Trade-off）。
- 第二，我深刻体会到，面对分歧，最好的解决方式不是说服对方，而是和对方一起找到一个共同的、客观的评判标准，然后用数据和实验结果说话。
- 第三，也是最重要的，我发现有建设性的讨论和基于事实的妥协，往往能催生出比任何个人最初想法都更优秀的“第三种方案”。这让我对团队协作的力量有了更深的理解。
项目突发风险，评估维度和解决路径
我的评估维度（如何思考问题）
在采取任何行动之前，我会先保持冷静，并从以下几个维度对风险进行快速、全面地评估，搞清楚“这是什么问题”以及“它有多严重”。
**1. 风险定性与定位 (What & Where)
- 风险性质是什么？ 我会首先明确风险的根本类型：
- 技术风险？ 是不是某个第三方库有重大Bug、某个核心技术方案被验证行不通、或者出现了无法解决的性能瓶颈？
- 需求风险？ 是不是新的需求与现有架构产生了根本性冲突、或者需求的描述存在歧义导致无法实现？
- 依赖风险？ 是不是我们依赖的另一个团队的接口无法按时提供、或者某个外部服务（如云服务、API）突然宕机了？
- 资源风险？ 是不是缺少必要的硬件资源，或者团队缺少掌握某项关键技术的成员？
- 风险影响点在哪？ 我会精确定位到这个风险具体影响了项目的哪个模块、哪个功能点。
2. 影响范围评估 (Scope of Impact)
- 对项目进度的影响： 这个风险是“阻塞性”的吗？它是否会卡住整个项目的关键路径，导致所有人都无法继续工作？还是只影响一个次要功能，主体开发仍可进行？
- 对团队成员的影响： 这个风险是否只影响我一个人，还是会影响到与我协作的前端、测试或其他后端同学？
- 对最终用户/业务的影响： 如果这个问题不解决，最终上线时会对用户造成多大的影响？是核心功能无法使用，还是体验上的小瑕疵？
3. 紧急性和优先级评估 (Urgency & Priority)
- 结合项目的时间节点（如即将到来的版本发布、Demo演示），我会判断解决这个风险的紧急程度。我会给它一个初步的定级，比如：高（必须立即中止当前工作来解决）、中（需要尽快处理，但可以并行其他任务）、低（可以记录下来，在当前版本周期末尾或下个周期再解决）。
4. 资源与依赖分析 (Resources & Dependencies)
- 解决这个问题需要哪些“外力”？是需要我的导师/主管的技术指导？需要产品经理重新澄清需求？还是需要协调另一个技术团队的资源？明确解决问题所需要的人和资源，是推动解决的下一步关键。
我的解决路径（如何采取行动）
在完成上述评估，对问题有了清晰的认识后，我会按照以下路径去推动解决：
步骤一：快速同步，暴露问题 (Communicate & Expose)
我的第一反应不是自己一个人埋头苦干，试图隐藏问题或独立解决。而是立刻、主动、透明地将问题在团队内部进行小范围的同步。
- 同步对象：首先是我的直接导师或团队负责人，以及与该模块最相关的几位同事。
- 同步内容：清晰地说明我评估出的风险性质、影响范围和紧急性，确保大家对问题有共同的认知。关键是，要让问题从“我一个人的问题”变成“团队共同面对的问题”。
步骤二：深入分析，提供备选方案 (Analyze & Propose)
在暴露问题的同时，我不会只做一个“问题的提出者”，我更希望成为一个**“解决方案的推动者”**。
- 提出Plan B/C：基于我的分析，我会尽可能地提出几种备选的解决方案，并阐述各自的利弊。例如：
- 技术绕过方案 (Workaround)：“如果我们依赖的A服务短期无法修复，我们是否可以先开发一个B方案（比如一个临时的模拟接口），来保证我们主流程的开发不被阻塞？”
- 需求调整方案 (Requirement Adjustment)：“这个需求以现有技术实现，性能损耗会非常大。我们能否和产品经理沟通，将需求从‘实时计算’调整为‘准实时’，通过异步任务来完成，以保证系统稳定性？”
- 资源求助方案 (Resource Request)：“这个问题涉及到XX领域的专业知识，超出了我的能力范围，我建议我们需要向公司的XX专家团队寻求帮助。”
步骤三：升级决策，并跟踪闭环 (Escalate & Follow-through)
作为一名实习生或团队成员，我清楚我的职责是提供专业分析和建议，但最终的决策权在项目负责人手中。
- 移交决策：在提供了备选方案和我的专业建议后，我会将决策权清晰地交还给我的导师、项目经理或产品经理，由他们根据整体的排期、成本和业务目标来做出最终决定。
- 积极执行与跟踪：一旦团队做出决策，无论最终选择哪个方案，我都会立刻投入进去，积极地执行。并且，我会持续跟踪这个风险的解决进展，直到它被彻底关闭，项目回到正轨。
- 复盘与总结：在风险解决后，我会对这次事件进行复盘，思考它发生的原因，以及在未来的流程中，我们如何能更早地预见和规避类似的问题
反问
更新: 6/20/2025 字数: 0 字 时长: 0 分钟
- 是否有转正HC，可以透露有多少名额吗
- 您觉得转正的人需要具备哪些特点和优势
- 部门的组织架构
- 后面的流程有哪些大概还需要多久