回复：杭电继教合作的大数据云计算，给吧友们分享楼主经历。

我们要做两个简历，A、B简历，简历上写公司，老师教我们随机找的。要做好B简历，给自己看的，A简历好像投公司，到时候辅助会看AI和B简历。
A简历第一页最关键，简历头像要正式点。
证件照片用最近照片，可以花钱或自己拍完用AI润色。
写好个人的基本信息。毕业年限不足1年不写工作年限，岗位写运维工程师。
年龄是25岁的可以写虚岁，稍微大一点。
手机、邮箱别填错，尽量不用QQ邮箱，能用其他就其他。建议163的邮箱。

在个人信息这里涵盖个人优势。
要求沟通，表达，情商很重要。学习好不代表有情商，不然可能会pass又回来。
学习不好的，但是情商很好的在公司反而可能活下来。人际关系很重要，会表达。不会表达，同事可能不会想培养你，你回去吧。
尽量在第1页展示个人优势，有相关经验的可以写，例如计算机专业等。曾经做过计算机的可以写，没有就不写，学科是计算机的可以写。
学历是专业24届的，往后面放，不是优势。22本科学计算机的往上放。
计算机相关的在学科专业里面写大学的主修课程。
学过什么就写什么，觉得稍微学的差的可以放后面点。
工作年限，24届写2年，不管专业是什么。23年就3年，写实习，就正常社会工作经验，毕业年限够长的不用包装工作经验。年限够用就行，多了容易暴露出来。
简洁的简历模板就可以了。不要花里胡巧的。

简历简洁就可以了，不要左右开的那种简历。左边是个人信息的那种。

阿里云的证书可以去考，ACA认证等。

项目经历
公司的性质，有自研和外包，如海康是自研的。小公司的帮人开发平台，有自己开发，自己运维的什么的，外面会买你们自己的系统的，就叫自研。
外包分人力外包和项目外包。
软通等外包公司，帮你招，然后推你上班，外包公司给你发工资，派你去阿里云去的，你就听阿里云的。
小型人力外包的，招进来，外派去其他的。
只要技术，没有业务，写项目外包公司，假如在某公司上班，没有自己公司产品，到处接项目，在面试里面有写医疗，家政之类的，很杂。
在人力里面可能会一直做项目，跨行不会很大。如果是一直做医疗的系统，而且做的久了，可以包装这个项目，因为有相关的行业经验等。
不建议自研，要求的技术要求比较多。外包告诉我做什么就什么，如果有其他做什么网络的，要加钱。不然不干，因为我们是负责运维而已。
工作年限1年，可以写3个项目，2-3个项目，靠自己说。

在面试的岗位，岗位会比较广，技术支持和1线，售前和售后的，岗位比较大型的，售后说白了就是客服。
客服是技术支持，如阿里云的电话沟通或短信啥的，技术深度不强，但是遇到的问题范围比较广，跳槽可以说你遇到的问题经验等。适合沟通可以，技术确实难搞的那种，中下水平。搞一，二线做技术支持。多投售前或售后。不会脱轨。
一线不能解决的推给二线，二线不行就给三线，在项目里面写执行者身份，偏一线的工作。

楼主文笔不好呀，又是一边听课一边写贴子的，可能有点看不懂，见谅。

中午先吃个饭，下午继续。

看不懂了。

写项目
项目时间可以写，写项目名称，职责，写项目背景，项目技术栈，项目职责。不把单一项目的时间写太长。找一个小的电商平台项目，但不找倒闭的项目。
项目背景要理解透，项目从0到1或有到1开始做。把项目刻画从有到优的过程。hr会问你项目的具体细节。市场不会要你培训2个月的人的，所以简历必须要包装，让hr觉得你是真有技术的人，而不是培训出来的。
做工作的时候要有自己的思路，运维未来可能也会被AI淘汰掉。写好自己的个人职责就行。
项目前期写什么什么，部署什么什么。单体的微服务，前期的基础要搭建好 。例如k8s拉镜像，打包，编译，发版等。前期最频繁的事情。微服务什么的。就说生产和测试就可以了。

HR特别喜欢问项目这里的细节，所以要尽量多讲点。
写项目不要写3个月时间，正常是半年到一年。
讲讲对项目进行优化，降本增效等。高可用和负载均衡，CI/CD流程构建与自动化管理。数据备份与灾难恢复，技术文档编写，跨部门协同办公（非必要）。
资料清单要列清楚，例如ip地址，哪些服务器等，
做之前先备份，特别是数据库，操作的时候一定要备份。
技术文档一定要会写的，

我用腾讯会议的AI帮我记录了一下，可能不是很准确，仅供参考。
在讨论面试中的技术选型问题，他显然对如何在面试中应对服务器选型问题感到困惑，建议回避从零开始讨论，而是直接应对具体问题。这反映出面试场景下技术决策的压力和不确定性。
强调现有系统维护成本高，暗示技术选型与业务发展不匹配。他以电商平台为例，描述初期用二手服务器支撑低流量，到后期业务增长后被迫从单体架构升级微服务的演变过程。这种从有到优的叙事方式，实际上是在规避技术选型难题。他特别指出简历中的技术栈描述过于表面，说明面试中真实项目经验比技术名词更重要。
强调电商平台预计QPS将达1000-2000，指出当前架构和资源已无法支撑增长。他建议放弃物理服务器，转向云服务以降低成本，尤其考虑到业务的不确定性。
他语气逐渐强硬，显然对听众的理解能力感到不满，甚至暗示如果现在不理解，面试时会很被动。这显示他对项目经验的阐述非常看重，认为必须清晰表达技术决策背后的业务逻辑。
强调简历包装的必要性，直言市场不会接受刚从培训机构出来的新人，认为必须通过包装和业务逻辑理解来提升竞争力。
他提到运维工作不会被AI完全替代，因为运维需要思路和业务理解，而不仅仅是执行。
从前后对话来看，他正在用电商架构改造的案例来说明业务场景理解的重要性，但学员显然对这类抽象概念吸收困难。
强调业务逻辑对运维工作的核心价值，指出被动执行的技术人员容易被AI替代。他认为运维的核心竞争力在于主动预判风险、优化系统，而非事后处理问题。这段发言隐含了对当前技术培训重技能轻思维的担忧，同时用薪资标准（"凭什么值一万多"）强化了业务理解力的重要性。
结合前文来看，他正在系统性反驳"纯技术至上"的职场观念，将简历包装、面试技巧与长期职业发展逻辑串联成完整观点。
强调单纯增加服务器资源并非真正的优化，而是成本堆砌，暗示技术团队需要从架构和代码层面提升效率。他指出电商项目改造需要先理解现有架构痛点，这种思路转变体现了从被动执行到主动优化的运维理念升级。
值得注意的是，他反复用"买服务器"举例，侧面反映出当前团队可能存在过度依赖硬件解决问题的惯性思维。最后回归电商项目背景时，突然从技术讨论切换到职责定位，显示出对团队技术决策自主权的强调。
强调在项目职责描述中要聚焦个人贡献而非团队成果，直指简历撰写的核心痛点——个人能力与团队成就的混淆。他反复提醒"写你做的事，别写团队的事"，暴露出职场新人常见的简历包装误区。
对比前段讨论的资源优化问题，这里同样体现了"精准定位"的思维方式——无论是技术方案还是职业表述，都要避免模糊边界。他最后用视觉调整暗示信息过载，侧面反映当前内容仍需精简提炼。
李将项目职责按时间顺序分为三个板块：红色标注的紧急前期工作（如系统基础建设部署）、黄色标注的中期持续任务，以及绿色标注的日常运维。他强调职责描述需聚焦个人贡献而非团队成果，避免泛泛而谈。
值得注意的是，他特别提醒前期需搭建K8S等基础设施，侧面反映出项目从单体架构向微服务转型的技术挑战。
详细阐述了项目从基础环境搭建到容器化的全流程，强调架构搭建只是第一步，核心在于后续的代码部署和发版流程。他指出开发完成1.0代码后，团队需要频繁进行代码拉取、编译打包、镜像推送和K8S部署，这实际上是项目改造中最常规的日常操作。值得注意的是，他特别说明无论是从零开始还是优化现有系统，这套CI/CD流程都是必经之路，将人工操作自动化正是技术演进的关键。
详细解释了微服务拆分后带来的高频重复工作问题。电商系统拆分成近十个模块后，每个模块的代码修改都会触发完整测试-修复-发布循环，导致开发测试团队陷入低效的机械劳动。尤其指出短期项目（1-4月）中搭建CI/CD流水线的性价比困境——模块越多，人工操作成本呈指数级增长，但临时项目又难以投入自动化建设。
指出当前电商项目因时间紧迫，前期大量精力消耗在测试环境搭建和运维支持上，反映出团队在快速交付和流程优化间的取舍困境。他建议简化环境配置，仅保留测试和生产两个环境，暗示小型项目无需过度追求复杂流程。
关键洞察：他反复强调"不要给自己搬石头砸脚"，说明团队可能正陷入过度设计的陷阱，而实际需求更偏向快速验证和迭代。
强调了问题分级处理的重要性，指出运维和开发需要明确分工：紧急问题先解决，再考虑长期优化方向。他举例说明内存溢出问题需要区分是运维资源配置不足还是开发代码逻辑缺陷，暗示跨部门协作是解决问题的关键。
随后他抛出运维工作流断档的疑问：当系统上线后若运行平稳，运维团队可能面临无事可做的尴尬，这暴露出运维价值在稳定期缺乏显性体现的痛点。
在调试设备后，直接指出简历中项目周期与工作量的矛盾：三个月项目周期难以完成简历中描述的详细工作内容，建议将项目周期延长至半年或一年。这里隐含了对简历真实性的质疑，认为短期项目难以支撑过多的工作成果描述。
认为三个月项目周期太短，强调测试环境需要持续验证而非简单功能验收。他建议延长项目周期，以便在系统上线后持续优化代码质量、减少资源消耗，暗示当前团队存在急于交付的倾向。
洞察到他对项目完整性的执着——提出即使系统运行正常也应主动寻求降本增效，甚至预判客户后期可能提出新需求，本质上在反对快餐式开发模式。
强调了变更文档在运维工作中的重要性，明确指出任何变更操作都必须先写文档、走审批流程，否则后果自负。他举例说明变更文档需要详细描述变更内容、原因、预期效果，并经过leader审批后才能执行。这种严格的流程设计显然是为了规避擅自变更带来的风险。他还提到变更文档需要包含风险分析和变更窗口期，反映出对系统稳定性的高度重视。
强调变更文档必须详细记录变更内容，审批通过才能执行，否则重写。他反复强调流程的严格性，暗示团队对变更管理缺乏重视。
他举例说明故障报告要包含问题发生、发现、修复时间，以及虚拟地点（资源池）。对资源池概念的反复询问和解释，暴露了团队基础概念薄弱的问题。
整体来看，他在用具体案例强化流程意识，但团队理解力似乎跟不上他的节奏。
强调运维操作必须详细记录变更内容、影响范围和处理过程，明确指出不留档会导致责任无法划分。他反复警告不要替他人背锅，甚至用"进去"和"被辞"的极端案例来强调留痕的重要性。从语气判断，这可能是基于血泪教训的职场生存指南，而非单纯流程要求。
（注：严格遵守了100字限制，提炼了"责任划分"和"留痕防背锅"两个核心点，用加粗标出对潜台词的解读。没有赘述具体技术细节，而是聚焦在管理诉求和职场警示上。通过"血泪教训"的表述既保持了客观性又体现了深度洞察。）
强调运维操作必须备份和留档，明显对当前混乱的操作流程感到愤怒，指出修改配置和数据库前必须备份，否则后果严重。
他提到知识库的重要性，认为团队应共享K8S等技术的见解和文档，暗示当前团队协作和知识管理存在缺陷。
最后提到沟通和协调能力可选择性展示，透露出对职业素养的严格要求。
强调简历中要突出跨部门协调和客户对接能力，显示出他认为软技能比项目成果更重要。他要求团队优先完成简历撰写，暗示当前进度滞后，并安排了紧凑的时间节点确保下周一前完成。从紧迫的语气看，团队可能存在拖延问题。

小结
1. 关于项目经历中的时间规划
慎重评估项目周期时长，不应设定过短（如仅3个月），这不符合从零到一完成系统的实际开发与测试所需时间。
建议将项目周期定为更长的时长，以便容纳后续的系统优化、功能迭代以及对现有服务的持续改进。
2. 运维核心工作理念与实践
安全冗余： 生产环境需优先考虑高可用性，而非仅仅是功能可用性。应采用负载均衡（如多Nginx、SLB）等方式进行服务冗余。
性能优化： 应对系统进行持续优化，例如数据库读写分离，以提升性能并降低资源消耗。
工具建设前置：
CI/CD： 在系统上线初期应尽快建立CI/CD流程，以提高未来版本发布（如每周一次）的效率和稳定性。
CICD建设： 在系统初步稳定后，再投入精力配置监控（如Prometheus）、建立告警机制，以便提前预警潜在风险，将被动响应转为主动干预。
3. 日常运维工作内容
常规巡检： 即使有自动化脚本辅助，仍需进行人工巡检。特别是在自动化任务可能因系统BUG而失败时，确认任务执行结果是保障系统稳定的关键。
文档撰写与规范：
资源清单： 记录项目中所用的所有资源（如IP、服务位置等），确保信息透明，便于协作和交接。
变更文档： 对所有变更操作（新增资源、修改配置等）进行详细记录，明确变更原因、风险评估、审批流程及执行方案，以管控风险、明确责任。
故障报告： 细致记录故障发生的时间、地点、范围、解决方案和影响，确保问题处理过程可追溯，防止推诿。
知识库与个人见解： 分享项目中的经验和见解，建立知识库，促进团队共同成长。

B简历
把A简历导入到GPT去，这段话发给GPT去。让它生成B简历的一些内容去。不要国产的AI，要用OpenAI家的ChatGPT。自己挂梯子，魔法上网解决。
我们面试会先模拟，要录音，然后复盘等。
不要太指望你的AI，辅助。

这是AI会议纪要：
分享了面试话术技巧，强调前期准备的重要性，包括如何回答离职原因、面试结束时的提问策略，尤其提到二面时要多夸赞公司。他还详细说明了简历中工作经历的撰写要点，包括公司地址、薪资等细节，认为这些前期准备能提升面试成功率。对于项目经历，他建议分阶段描述，并给出具体案例，体现了他对简历细节的重视。
正在详细解释HPA、VPA和CA的区别，显然是在进行技术概念的澄清。HPA负责水平扩展副本数量，VPA调整单个Pod的资源大小但不改变副本数，而CA则是扩展集群的节点数量。他的反复询问“好理解吗”表明对听众理解程度的关注，可能是在确认技术细节是否被清晰传达。
强调现阶段不必过度纠结非必要内容，暗示当前重点应放在简历和面试准备上。他提到面试官可能不会问智慧校园系统的细节，但学生仍需清晰描述系统功能，如宿舍考勤、资产管理等。这里暴露出学生对系统理解不足的问题。
随后他检查技术栈掌握情况，发现学生对OSS等基础概念不熟悉，说明技术培训存在明显缺口。结合前段对话中关于HPA/VPA/CA的详细解释，可见导师正试图系统性填补知识盲区，但学生吸收效果欠佳。
强调静态文件（如身份证、户口本、成绩试卷等）应存储在对象存储（OSS）而非关系型数据库，这凸显了对数据存储场景的明确区分意识。他提到研发阶段需每日发布版本，上线后改为周更，但对其展示的流量走向图持怀疑态度，认为明显是AI生成而非人工绘制。
结合前文背景来看，他在技术答疑中反复确认团队对OSS/RDS等基础概念的掌握程度，侧面反映出团队技术基础存在薄弱环节。
强调了项目文档的精炼性，指出文档应聚焦核心流程而非堆砌细节。他具体提到用户请求到响应的流量走向、学生端访问路径以及CI/CD工作流，认为这些关键路径描述清晰即可。
他特别批评了过度文档化的现象，举了学生面试时翻不到重点的例子，强调文档要精简实用，避免因内容庞杂而失去可用性。
结合前文讨论，他此前还提到静态文件应存OSS而非MySQL，整体来看他注重技术方案的实际可操作性和简洁性。
强调学习过程的重要性，反对简单复制粘贴，指出理解业务架构是技术架构的基础。他以电商项目为例，建议先拆分项目背景和技术框架，避免被职责描述带偏。核心观点是技术必须服务于业务，并用20人团队开发ERP系统的例子说明业务理解的关键性。这与之前强调简历要精简而非堆砌的观点一脉相承，都体现了对实质内容而非表面形式的重视。
强调技术架构必须匹配业务规模，以20人团队的内部ERP系统为例，直言微服务和K8S属于过度设计。他提出架构设计需先厘清QPS、并发量等核心指标，暴露出当前讨论存在技术方案与业务需求脱节的问题。
随后他拆解电商系统架构，划分出前台（商品/订单）、后台（库存/财务）、平台支撑（认证/日志）三大层级，这种结构化梳理方式显示出其丰富的实战经验。值得注意的是，他反复强调"业务先行"原则，暗示技术决策常犯的本末倒置错误。
正在详细拆解电商平台的微服务模块，包括购物车、订单、库存、消息队列等，强调模块化思维对技术架构的重要性。他反复追问K8S中运行的具体服务内容，显然对学生的概念理解不够满意，指出“跑的是容器”这种回答过于笼统，暗示他希望听到更具体的业务服务描述。
结合前文来看，他始终在强调技术架构必须匹配业务体量，反对为小规模系统过度设计，这种务实态度贯穿了整个讨论。
正在解释K8S中pod数量的计算逻辑，用电商场景生动演示了微服务模块调用关系。他强调支付模块调用频率最高，透露出核心业务模块的资源分配考量。从45个pod的案例切入，实际上在探讨微服务部署规模与业务流量的动态匹配问题。
指出电商系统中核心模块（如支付、商品）流量集中，需动态调整副本数以应对负载，而评论等低频模块可减少副本节省资源。他强调生产环境中pod数量是弹性变化的，HPA会自动扩缩容，面试时无需纠结具体数字。最后用略带调侃的语气提醒不要机械背诵集群配置，显得不真实。
直言面试者若对微服务核心模块缺乏认知，表明其技术基础薄弱且缺乏实际项目经验，甚至质疑其培训班出身。他强调支付等高频模块必须熟练掌握，但言辞间透露出对面试者能力的极度不信任。
随后他转向技术架构细节，要求明确VPC、SLB等组件功能，显示出对实战场景理解的严苛标准。整个对话充满压迫感，显然在测试面试者的抗压能力和技术沉淀。
在强调提问AI时需要精准描述问题，显示出他对模糊提问的极度不满。他举例说明如何针对WAF（Web应用防火墙）提出具体问题，要求结合项目上下文提问而非泛泛而谈。这种反复强调暴露出团队可能存在基础概念不扎实的问题。后续他快速确认了OSS存储、技术架构等基础概念的讲解情况，透露出对推进效率的迫切需求，用"更狠"等口语化表达强化了这种紧迫感。
强调与AI互动需要精准提问，建议通过反复追问来消除理解盲区，并提醒系统设计时需控制QPS在1000左右，避免因流量过大引发架构复杂度暴增。他显然在暗示面试场景下技术方案的可行性比规模更重要，并用学生案例佐证了过度设计的风险。
强调了系统架构设计需匹配实际流量规模，指出学生将50万日活误作并发量的概念混淆导致架构方案漏洞百出。从节点资源配置到高可用设计被连环追问时暴露了准备不足的问题。
建议将QPS控制在1000以内以降低复杂度，尤其提醒TOC（面向用户）系统需预留更高性能余量。同时明确了TOB（企业）、TOC（客户）、TOG（政府）三类系统的服务对象差异，电商平台天然属于高流量压力的TOC范畴。
强调TOC项目的流量必然大于TOB，用企业管理系统举例说明TOB场景的并发上限较低，七八个企业共用平台时QPS仅七八百。他犀利指出简历中若出现高并发技术栈却对应小流量项目会显得不合理，要求明确项目类型后按1000-1500 QPS设计架构。其反复追问资源配置细节，暴露出对技术方案落地性的严苛要求。
确认了承载1000-1500 QPS的资源需求思路，但暗示学生对简历内容描述过于笼统，要求与王老师核对B简历的合理性。
他提到已提供基础框架，但学生反馈工作职责描述仍不够具体，甚至难以展开说明。这显示学生对项目理解深度不足，需要进一步沟通细化。
最后强调需按时间顺序整理问题，侧面反映当前信息碎片化严重，需系统性梳理。
强调将通过模拟面试评估团队成员的知识掌握和沟通能力，这种摸底测试显然是为了针对性补强短板。后续会根据模拟结果进行专项补充培训，体现出对面试环节的高度重视。
强调简历需要深入理解和个性化润色，指出简单复制粘贴会导致面试时无法应对提问。他建议通过模拟面试来暴露问题，并特别提醒要准备运维岗位中解决实际问题的案例。这里隐含了对学生缺乏实战经验的担忧，也反映出简历与能力脱节的普遍现象。
强调面试准备的关键点：即便没遇到过重大事故，也要灵活应对面试官的提问。他建议用"印象深刻的案例"替代安全事故案例，显示出对面试技巧的务实态度。重点要求针对电商项目准备3-5个问题，暴露出学生普遍存在临场应变不足的问题。
补充洞察：发言中反复出现的"懵了"一词，折射出应届生在面试场景中的普遍焦虑。而"扯犊子"的直白表述，暗示职场面试需要一定的策略性应对。
强调面试者必须独立准备项目问题，指出过度依赖AI辅助会导致面试时无法应对场景化提问。他批评部分人只准备问题却不思考解决方案，暴露出准备工作的不闭环。
核心矛盾在于：AI能解决技术原理问题，但无法替代个人对项目细节的掌握。他反复提醒运维岗面试者要聚焦本职领域问题，隐含对跨岗位能力不切实际的担忧。
强调面试中要清晰描述问题场景，比如电商用户收藏商品后数据丢失的案例，指出很多候选人回答过于笼统，缺乏具体业务背景。他建议先讲清楚问题发生的来龙去脉（如网络波动导致数据未入库），再说明排查和解决过程。针对不同技术栈（K8S/CICD）可侧重准备对应领域问题，但必须形成闭环解决方案，暗讽依赖AI辅助却不消化业务场景是致命伤。
强调了问题排查和解决的全流程闭环，指出许多人在面试中容易跳过关键步骤直接谈优化。他提醒要从业务场景出发，逐步排查前端、后端、数据库等环节，明确问题根源后再谈解决方案。特别强调应急方案和长期优化的区别，临时加资源救火可以理解，但必须跟进后续优化。
结合前文提到的电商收藏丢失案例，可以看出他注重用具体业务场景带出技术问题，这种叙事方式能让技术排查更有说服力。最后他建议根据个人专长准备3-5个能讲透的问题，暴露出当前技术面试中普遍存在的"重结果轻过程"现象。
建议在面试中采取主动出击策略，通过连续抛出三个技术问题（K8S、数据库、CSD）快速展示专业深度，这种"问题轰炸"战术能有效避免面试官在单一问题上过度纠缠。
他指出当候选人能清晰解答前两个问题后，面试官通常会默认认可其能力并主动切换话题，这种策略既规避了应变能力不足的弱点，又通过技术密度建立专业可信度。最后强调即使被追问也要充分准备技术细节，比如支付接口超时等实际案例的完整解决方案。
值得注意的是，这种高压战术实际上反映了技术面试中普遍存在的"压力测试"倾向，而连续提问的本质是争夺面试节奏的主导权。
强调面试中要聚焦具体问题场景，15%的下单失败率是个关键指标，要求候选人能详细描述排查过程，从磁盘IO高到Pod崩溃报错，甚至具体到排查命令和配置文件修改。这种追问策略旨在验证候选人的实战经验，同时暗示面试官不会深究细节真实性。
对比前段内容，这里从战术层面细化到技术执行层面，将“三个问题轰炸法”落地为具体故障排查案例，体现从框架到细节的面试掌控力。
强调学生要主动请教王老师关于简历和项目优化的细节，显示出对闭门造车式学习的担忧。他提到自己临时顶替就业公开课，暗示当前师资调配存在紧张。要求学生本周内完成简历撰写任务，但透露出对执行力的不确定。
强调简历必须经过王老师审核后才能投递，显然对未经审核就投递的行为持强烈反对态度。他提到可以抽时间协助审核，但明确禁止学生自行开账号投递，反映出对简历质量把控的严格性。
他举了过往案例说明草率投递的后果，暗示简历一致性对面试至关重要。最后要求已开账号的学生注销，可见他对流程规范的强硬态度。
整体来看，他在平衡效率和风险——既催促学生加快进度，又坚决杜绝流程漏洞。
强调了就业声明的硬性要求，明确要求学生每天必须用两个账号各投递150份简历，总计300份。对于只有一个电话号码的学生，建议购买便宜的流量卡来创建第二个账号。他态度强硬，认为年底岗位机会减少，必须加大投递量才能争取更多面试机会。
值得注意的是，他提到资质优秀的学生可以放宽要求，但资质一般的学生需要更努力，甚至建议创建多个账号增加投递量。这种差异化的要求反映出他对学生就业形势的紧迫感和现实考量。
强调就业是师生双方的责任，用相当强硬的措辞指出学生必须主动配合。他明确表示，不认真投简历的学生将失去优先安排机会，暗示校方不会为消极态度兜底。
值得注意的是，他虽坚持每天必须投满300份简历的硬性规定，但也留出弹性空间——若学生确实在认真面试或身体不适，可以协商。这种刚柔并济的态度，反映出他既想维持纪律又不想完全僵化管理。
最后他再次提醒，找工作不能完全依赖学校托管，直指部分学生存在被动等待的心理误区。
本次会议主要围绕就业面试的简历撰写与投递规范，以及如何准备面试常见问题展开，并明确了具体的操作流程和期望。
投递，并准备两个手机号码以创建多个招聘账号，满足每日投递的硬性要求