一位阿里校招生分享了三年工作经验与感悟，涵盖业务理解、沟通技巧、项目管理及个人成长等非技术层面，值得借鉴。
原文标题：校招阿里这三年，聊点非技术的
原文作者：阿里云开发者
冷月清谈：
业务与技术方面，作者认为，尽管初入职场时可能会面临“面试造火箭，入职拧螺丝”的落差感，但深入理解业务并将其转化为技术实现是至关重要的。业务知识的积累和技术能力的提升相辅相成，最终都会成为宝贵的职业财富。
沟通方面，作者强调了积极提问和寻求帮助的重要性，尤其是在面对不熟悉的领域或遇到瓶颈时，要勇于向同事、领导以及业务方寻求帮助，提高学习效率和解决问题的能力。
项目管理方面，作者建议预留时间缓冲以应对未知风险，并及时与相关方沟通，确保项目按时交付。即使在时间紧迫的情况下，也要及时汇报进度并管理预期，避免意外发生。
个人成长方面，作者提倡乐于助人，传承经验，并持续学习，提升自身技能。同时，要关注业务发展，从全局角度思考问题，并勇于承担责任。
适应变化方面，作者认为变化是不可避免的，要积极适应新环境，快速学习新业务和技术，并从中寻找新的机会。同时，要认识到业务离开任何人都可以运转，持续学习和快速适应变化才是关键。
心态调整方面，作者建议通过外部评价体系来定位自己，并保持对新技术的学习和了解，例如当前热门的大模型技术。同时，要保持积极乐观的心态，接受自己的不足，并努力提升自己。
怜星夜思：
2、作者强调了沟通的重要性。在实际工作中，你有哪些提升沟通效率的技巧？
3、文章最后提到了“拥抱变化”。在快速变化的互联网行业，你如何保持学习的动力和适应能力？
原文内容
阿里妹导读
作者总结了在阿里的三年时间中所收获的宝贵经验和成长感悟。
二零二一年的七月九号，我以校招生的身份入职了阿里，开启了一段十分有意思、有意义的阿里旅程。
这三年，我从企业金融技术部，到ICBU技术部，中间还借调到1688技术部一段时间。整个滨江园区的业务我好像都经历了一遍。
在这三年里，换过N个小组。中间经历过很多好的坏的、各种闹心奇葩的坑爹事。但是幸好周围的各位大佬对我不厌其烦帮助、孜孜不倦地教诲，让我感受到了阿里人温暖，在这里收获了友情，成长和感动。
在阿里有句俗语，三年成人，在这个时间点，我小小地做个总结，欢迎拍砖～
搞业务与做技术
“面试造火箭，入职拧螺丝”。
在越来越卷的当下，面试的难度越来越高，HR先筛选一下简历，非985的不要，没项目的不要。面试阶段，大部分阿里的面试官一上来先来几道八股文练练手，再结合简历项目看看实力，最后问几道高并发完美收场。面试官的这套组合拳打完后，面试者真的会以为将来工作的场景会和这些高并发高可用休戚相关，拳打千万并发、脚踢亿级流量，一想到亿级用户将通过在下手中的代码完成一次次交易与支付，激动之情就难以言表，喜不自胜。
但是入职之后却发现，面试时候信手拈来的各种高性能、高可用、高性能的奇技淫巧暂时没有用武之地， 取而代之的是被PD各种虐，CURD就是干，每天在N年前古人写下的深山中猜测各种古老的业务细节。
很多人入职都会进入业务团队，他们就会后发现，自己日常接触的代码，或许因为业务迭代的压力，或许困于前任设计的缺陷，几乎没有任何“技术”的设计可言，一言不合加机器、升配置，是最常见、也可能是唯一的处理所谓高并发的手段。
至于高可用，中间件平台已经够完善了，根本不可能出现之前面试所说的极端问题——即使出现，也不在业务场景的考虑范围内，因为数据流量太小，离线核对订正往往是最常见的解决方案。
所以，入职业务技术团队后，相信大部分校招同学，在开发一段时间业务需求之后，轻则怀疑公司，生出“阿里就这？”的感叹，然后麻木地被业务需求往前赶；重则道心破碎，开始怀疑自己的当初的梦想，最后要么被干要么跑路换行。
我刚入职后就属于前者，看着周围一些同学CURD一把梭，不禁陷入了迷茫，开始怀疑自己在学校钻研了三年技术的意义。我常常想，难道我每天CURD就能解决问题了吗？
纯粹的CRUD当然是解决不了问题的。随着工作的深入，我发现事情远没有我想象的那么简单。虽然是增删改查，但是在写增删改查的前提一定是对业务有相当程度的了解和熟悉。只有通过技术完成对真实业务的抽象和建模，才能写出来高扩展性的代码。而随着承接越来越多和越来越大的需求，我们所了解的业务知识也会慢慢变成自己的壁垒。在这个过程中，我们也会写出越来越健壮、可读性越来越高、扩展性越来越强的代码，我们掌握了对应业务知识，以及当前业务需要的性能和稳定性指标，都会成为我们宝贵的职业财富。
业务技术团队和纯技术团队最大的不同是解决不一样的问题。业务团队负责解决真实世界的业务问题，纯技术团队则负责解决技术问题。某种程度上来说，科班出身的计算机同学更容易受到geek风的影响，认为毕业将来一定会做很多技术相关的工作，再加上面试过程中各种硬核问题，拉高了面试者的工作预期，才会导致大家投入工作后产生很大的割裂感。
在业务团队，对于技术人来说，很大的忌讳就是硬秀肌肉，大家都想尝试新的技术，更高难度的技术挑战。但是，既然低并发能够解决业务问题，为什么还要处理高并发的各种问题自讨苦吃呢？尤其是在现在经营责任制的环境下，技术要做的就是服务业务，最小代价的解决业务的问题。
其实处处留心皆学问，虽然很多硬核技术在日常的业务场景中用不到，但如果实在喜欢钻研技术，进入阿里后，还是有很多机会学习的。抽时间看中间件的源码、应用中间件的设计模式、解决日常遇到的各种诡异问题（maven排包、类加载）、线上问题的响应与处理，等等。只要抽出身来，即使在业务团队拧螺丝，但只要多花点时间准备，为业务造火箭的机会可能就会到来。
草船借箭的勇气
写这篇文章的时候，通过GPT搜索了下，程序员中的I人会占到60%甚至更高，这种性格固然会使得大家在开发的时候更专注，但是往往也会导致开发同学在与人的沟通上不那么积极。
很多人刚入职的时候，无论是学习业务，还是开发需求，在遇到问题的时候，都不好意思问师兄。甚至有些同学在师兄问项目进度的时候，支支吾吾地说快完成了，结果等到联调的时候才发现，自己写的代码和业务预期的代码，还是有相当大的出入的。
所以，对于校招生来说，为了保证自己进步的速度，在合适的时机，多向周围的师兄、老板、业务方咨询问题，是一件非常有必要的事情。但是，大家往往缺少问问题的勇气，结合我自己和身边的例子，大概统计了下，一般有以下原因：
-
和被咨询的人没打过交道不熟悉，不知道怎么开口；
-
担心问题太简单，害怕被咨询的人嘲笑或者看低自己；
-
大家都很忙，害怕影响到被咨询人的工作
之前另外印象很深刻的一个例子，几年前，隔壁组一个刚入职的校招生在工位熬夜搞到11点，刚好我也在处理些事情，看他一直没走，就上前搭了几句话，得知他正在处理一个非常经典的Spring启动的问题。所以我就顺手帮他解决了。后来才知道，这个问题他已经看了快3个小时了。如果他能找机会向其他同学寻求帮助，那天晚上11点他就可以直接在床上原神启动了。
不只是问别人，阿里有太多的技术资产了。遇到问题，搜索语雀、ata往往就有50%的概率解决问题。学会使用工具，也是成长的一部分。
不像古代男耕女织、几乎一个家庭就能完成从生产到消费的全链路，现在的社会是以分工合作为基础的，所以我们必不可免的要和其他人打交道。甚至很多时候，我们自己的工作需要主动或者被动的依赖别人的帮助才能完成。
新同学刚进入工作的时候，一定要多向师兄和同事借力。在新手保护期的阶段，大家会更容忍你有更多的“不知道”，所以，一定要在最懵懂的时候，尽可能的获取更多的知识。
项目遇到卡点的时候，一定要多向老板借力。业务方工期紧？合作方不配合？这些涉及到更高层级沟通的地方，一定要向老板汇报，让老板站在更高的视角帮我们推动项目的执行。不过，在找老板之前，不能只把问题抛给老板，还有给出一定的解决方案和预期时间，这样在后续争取资源或者撕逼扯淡的时候，老板才会不至于那么被动。
作为业务开发，业务的知识也是开发必须要掌握的基础之一。在遇到业务问题的时候，要多向业务借力。想业务咨询问题背景、可能的方案以及原因。多与业务沟通，不仅能掌握更多的业务知识，从功利的角度讲，也算是和业务方刷刷脸。大家更熟悉了，后续合作需求的gap也会越来越小，工作起来也会越来越顺心。
草船借箭，不仅需要勇气，更需要智慧。聊之前准备好草船，也要注意时间和场合。完事之后表达感激也是必不可少的。至于是一句thanks，还是一杯咖啡，抑或是一顿饭，这个见仁见智吧～～～
预期与项目管理
无论是写代码，还是PM技术项目，核心都是保障事情按时交付。在这个过程中，一定有自己不了解的地方，所以如何平衡好未知的坑和确定的交付时间，是我入职之后做技术PM最痛苦的点之一。
如果遇到一个自己有超过30%都不熟悉的项目，建议此时一定要给自己多留一点buffer。这样做的原因有两点，一方面是面对未知的坑，运气好一点可以直接跳过去；运气差的话，直接陷进去一周都出不来。无论项目大小，作为项目负责人，我们不能让项目的交付时间跟随运气的好坏而波动。这样不仅会使得自己陷入被动，项目的对外放声，前线运营也会受到影响。
给自己留buffer，不仅仅是帮助自己有更多时间踩坑，也是给自己留更多地和业务方聊排期的空间。如果一上来和业务聊了一个很紧张，加班后勉强才能做完的时间，后面这个项目大概率是要延期的。这么一搞，自己在合作方中的印象分就会很低。鲁迅大爷说过：“中国人的性情总是喜欢调和，折中的。譬如你说，这屋子太暗，须在这里开一个天窗，大家一定不允许的，但如果你主张拆掉屋顶，他们就回来调和，愿意开窗了。”所以，刚开始估一个留buffer的排期，后面到底是拆屋顶还是开天窗，就有很大的活动空间了。
但是有的时候，项目的排期并不是我们这些小P能够决定的。930、330前要上线的项目一大堆，各个项目问就是P0、第N增长曲线，必须要做。没有留buffer的空间，这个时候该怎么办？
过去的经验告诉我，在不断发现风险，解决风险的项目过程中，遇到难以解决的风险一定同步老板。及时让老板了解项目的进度，适时地管理项目参与方对项目的预期。这样才不至于在项目的各个里程碑中给各位大佬一个惊喜的SURPRISE。
独乐乐不如众乐乐
在阿里这三年，发现了太多大牛前辈，他们中的大部分人在我阿里的历程中都给予过非常重要的帮助。当我不解问及他们为何要在工作如此繁忙的时候还会抽出时间来给我答疑，他们的答案出奇的相似：
“因为当时淋过雨，才知道做这些无聊的事情有多痛苦”
“这些概念性的东西，知道后会少走很多弯路，没必要让你们把时间浪费在这些没有价值的事情上”
我听了之后甚是感动，在我看来，这是阿里师兄文化最好的体现。从实习到校招，我的每一任师兄和每一任老板，都在尽力帮我landing，教我了解技术原理、告诉我如何学习和成长、如何管理项目、如何控制风险，感谢这三年与他们相处的每一个瞬间，与他们相处的日子是我这辈子最宝贵的财富（之一，哈哈哈哈）。
所以如果有时间，不妨多去帮助那些新来的朋友们，在他们成长起来之前，少一点PUA，多给予力所能及的帮助。这样自己开心，大家也高兴，无形之中团队的氛围就会慢慢变好，阿里的文化也会一点点的传承下去。
其实帮助他们成长，对我们自己来说，又何尝不是一种成长？
万物是否皆可卷
我是2020年入职阿里实习，以本科生身份校招转正的漏网之鱼。互联网公司在20、21、22这三年校招扩招的校招生非常多，站在现在的角度，以当下的招聘标准，作为一个普通本科生，我是无论如何也不会被招进来的。现在部门的校招生研究生起步、985打底，卷学历，作为开发，我已经输在了起跑线上。
如果不能卷学历，那还能卷什么？卷加班时长？卷代码量？还是卷aone的工时？
我觉得这些都是一些过程指标，卷这些东西除了能够安慰和缓解下上次管理者的焦虑之外，是很难明显地解决其他问题的，对于自身的成长和提升更是没有一点帮助。
互联网头部大厂作为人才的蓄水池，周围随处可见的都是优秀的人才，技术能力高，业务sense强，甚至每个人都有一套为人处事的方式方法。作为刚进入职场的菜鸟小白，我们应该努力卷我们自身的技能，向周围的大佬看齐，提升技术，学习业务，然后再将学习到的东西进行实践，从模仿到超越，实现学习、理解、实践、提升的闭环。
在具备基础的技术和业务能力之后，作为业务开发，不要只盯着自己技术域的一亩三分地，而是慢慢地开始去卷业务，了解自己开发业务的背景、发展和规划，学着站在全局的地方去考虑问题。阿里对新人还是有容错的，校招生快速试错，然后不断成长，等待机会，承担更大的责任。
不妨慢一点，给自己一点时间，找到一两个自己在工作中和生活中真正想做的事情，然后坚持做下去。不要去卷各种无谓的指标，校招生，从卷自己开始。
踩坑了，然后呢
作为新人，在刚入职的时候，一定有很多不懂的地方，甚至有些同学之前没有使用过部门常用的开发语言，这都是很正常的事情。在刚来的一年时间里，大家总是会踩各种各样的坑，印象中，我踩了很多坑：
-
dts任务批量调用导致下游报警
-
奥创发布上线不生效
-
某些租户缺少配置导致NPE，等等
有些还导致了P5故障，在复盘的过程中，老板和师兄们帮我总结经验，让我收获了很多。很多人把这些当做工作履历的黑点不想面对，但是对于校招生来说，正相反，只要问题不大，都是改错的大好时机。俗话说，好记性不如烂笔头，像高中写错题笔记一样，将之前踩过的坑记录下来。一定会有一天，在第二次遇到类似的问题后，脑海中突然闪过第一次踩坑的场景，然后把记录的问题翻开，成功跳过这个坑，继续前行。
大家对校招生的容错度是很高的，新同学一定要利用这个时间区间来试错和学习。记得我刚实习的时候，师兄给我review代码提了一些建议但是当时我没有放在心上，并没有改正，师兄很严厉的指出了我在回复comments过程中的问题，耐心教育我，“有人帮你CR指出错误，一定要有回应、讨论或者改正，这体现了对reviewer的重视。如果不回复的话，以后找相同人CR就很难获得高质量的comments”。这个建议我一直很受用，后续正式入职后，在师兄组织大面积CR的时候，在得到一些高质量的CR时候，我就会立刻提patch修复，其实，修复的越早，上线的风险也就越低。
同时，踩坑之后，不仅要记得防止自己踩坑，如果能形成公开文档或者知识库，防止别人踩坑，或者是顺手把坑修复掉，这就更加功德无量了。（当然，如何让别人知道你把坑修复掉，这是一门艺术 //v//）
听得懂、讲明白
作为程序员，虽然在日常的开发中与机器打交道的比较多，但是在项目管理的过程中，与人的沟通也是必不可免的。信息墒在传递的过程中一定是有损失的。所以，在交流的过程中，我们要通过各种方式来尽可能地保证信息的正确和完整传递。
沟通是一个需要长期锻炼的技巧，有两个比较重要的点，一个是耐心，一个是细心。在听的时候，能够给伙伴足够多自我表达的空间，正常情况下，不要着急去否定和打断对方，正如你讲话时也不希望别人打断一样。此时我们需要做的就是细心去听，然后分条分点地把对方要表达的观点记录下来并消化。同时，在回答别人问题之前，可以用几句话把对方刚才的语言复述下来，尽量降低两个人沟通之间的GAP。
同样的，在表达自己观点的时候，尽量也分条分点，像写作文一样，用总分总的方式，开篇和结尾表达问题关键点，中间分条分点论述。除此之外，一定要注意交代好上下文和背景。否则，很容易造成接受者的信息紊乱，形成驴头不对马嘴的尴尬场景。尤其是咨询问题的时候，如果直接问某一个具体的细节点，可能对方很难一下子get到意思，如果背景交代清楚，沟通起来就可能顺畅许多。
但是，一切的技巧终归是点缀，自己的影响力足够高，很多事情就迎刃而解了。
拥抱变化
拥抱变化作为新六脉，每一位同学都不陌生。在公司，拥抱变化不仅体现在口号上，更是在行动上表现的淋漓尽至。
作为校招生，刚开始对变化这两个词其实感知是不深刻的。第一次感知到变化的时候，是我入职5个月后整个组被通知换到了另一个BU，因为只是换了组织关系，周围合作的同学和老板没有变化，所以对于这次的变化只是有一个感性的认识。第二次感知到变化的时候，是22年从实习就开始带我的老板毕业之后，整个团队都陷入了一场漩涡之中，那次我就陷入了思考。第三次感知到变化，则是我自己的选择，选择了换个环境继续工作。
在这几次变化中，我有几点感触：
第一，很多校招生在刚进入工作的时候，思想可能有一个误区，认为自己一定要做自己专业强相关的事情，狠狠地钻研技术，开发代码。但是进入工作后，我认为这种学生思维可能要稍微发生点变化。做技术当然是要持续精进的，但是核心的点更应该关注需求，关注组织的需求，把自己的技术或者能力应用到需求上去。中间商赚钱的本质就是供需匹配，有时候做做报表、思考下业务，也是一种成长。
第二，变化是一体两面的，它不仅代表着自己离开了原来的舒适区，更代表自己面临着新的环境，可能会有更大的机会。当自己从一个组织换成到另一个组织之后，不适应、不习惯，是刚开始融入时候必须面对的困境。可能有人在刚开始面临变化的时候会想，“为什么变化他而不变化我？”。我个人感觉，不要对组织抱有太大的恶意，可能我们也没发现，自己从原来的地方被变化走已经代表了自己在原来领域的发展已经受限，所以，不如用更积极的态度去拥抱这次变化，在新的领域重新开始。
第三，塞翁失马，焉知非福。有些变化，从短期来看可能让我们有所损失，但是长期的事情谁能说的准。短短三年间，我就见到过很多例子，刚开始以为是好的变化，结果后来的发展又偏离了自己预想的方向；还有刚开始变化完天崩开局，结果后面柳暗花明。所以面对变化的时候，用积极的心做好自己的事，守正出奇，静待花开。
我们一定要承认一个事实，就是业务离开谁都可以转。大多数开发都没有那种技术能力强到令人望尘莫及的地步，刚开始我还会天真地想，这个大佬这么懂这块技术，他变化了业务可怎么办？后来工作时间久了慢慢发现，人变了，事情才有可能发生变化，没有需求是加代码、加人日、上重构解决不了的。虽然所谓的重构有可能也是把之前的feature又实现了一遍，你就说能不能用吧，哈哈哈。
所以，学习的能力很重要，在面对变化的时候，我们要学会迅速融入环境，这是一件非常重要的事情。学会快速学习业务，快速接手新的代码逻辑，整理一套自己的方法论。要知道，再也没有校招入职时候连给2个月熟悉代码的快乐时光了，如何在不熟悉的代码中交付业务需求、不出现风险，甚至还能保证架构的统一，是作为程序员，在我司的大环境下拥抱变化的基础能力。
接雨水和修屋顶
虽然说并不是啥都能卷，但是在当下这个卷的环境下，很多时候我们会不得不陷入内卷的困境里，麻木地做着一成不变的事情。刚进入工作时候的那种激情和勇敢，就会在这种不断承接被动需求的环境下慢慢地被消磨殆尽。
甚至有时候，我们可能会因为同事的负面看法而每天患得患失；可能会因为工作中的一点小疏漏而彻夜辗转反侧；可能会因为项目未完成而闷闷不乐，封闭自我。“他人即地狱”，工作久了之后，我们往往会陷入周围的评价体系里面，成为他人语言的奴隶，而不再是自己的主人。这个时候，向外求索，可能会是一种解法。
公司的光环和个人的能力是有区别的。不妨在公司内部的评价标准上，尝试通过外部的评价来更确切地定位自己。空闲时多接接雨水，未雨绸缪，方才能让自己在暴雨如注之时独善其身。
未雨绸缪，晴天修屋顶也是十分必要的。在需求少的时候，身体上放松，精神上重视。多了解对手公司的竞品动态，反思自己在工作中的优与劣。时刻掌握本领域业界的趋势，反哺自己领域的业务和技术。用积极的态度，为自己建立一个更加全面的评价体系，清晰的定位自己，进而针对性提升。说句题外话，现在大模型这么火，公司的每个部门都希望通过大模型来缓解眼前问题，画大饼、讲新故事，如果作为大头兵的我们还不了解这些东西，一味的curd，看似是处在舒适区，其实是自己把自己推向了深渊。雪崩的时候，没有一篇雪花是无辜的。
海阔凭鱼跃，天高任鸟飞。
无论如何，这也只是一份工作，因为工作导致抑郁，实在得不偿失。珍惜身边的每一位朋友，尝试与自己和解，接受自己做不到的，争取自己能得到的，坦然面对结果，做人生的朋友。
山穷水复疑无路，柳暗花明又一村。
新的开始
本来想在三周年之际发表这篇文章，没想到中间经历了一系列的事情，这一耽搁就是半年。不过虽然拖拉了这么久，但是好在发布出来了:)
悟以往之不谏，知来者之可追。以此，来祭奠我的阿里三周年，迎接在阿里的新挑战^_^。
高效防护 web 应用
随着网络技术的不断发展，您的Web应用如果没有流量入口的防护，会面临诸多风险。本方案以ECS实例接入WAF为例，推荐您使用Web应用防火墙（WAF）开启应用防护，避免网站服务器被恶意入侵导致性能异常等问题，保障网站的业务安全和数据安全。同时，为您节约开发成本，满足行业合规要求。
点击阅读原文查看详情。