实习经历
实习开始前有一个有意思的小插曲，我申请过一次换组。微软暑期实习分组和项目本身是开盲盒，算法分到开发的也大有人在。可能是因为我上一段实习主要做客户端开发的工作，最开始发邮件给我分到的组主要是做前端的。于是我发邮件问组里有没有后端的项目能让我去做，对方虽然答复我说组里主要做前端没有后端项目，但是愿意帮我去向大老板申请能不能给我换组。于是后来我成功换到了我后来实习的组。我的manager也知道我想要做后端于是让我的mentor给我安排了相关的任务。
我得到的经验是还是需要尽力去争取，说不定就成了呢。这件事还给我的manager留下了我”明确知道自己喜欢什么并且勇于争取“的印象。算是一种肯定（？）
我们组是一个新组，文档有，但是要么基于其他组，要么不够完善，所以基本只能看个大概有所了解。更直接的方式是问mentor和同事们，比如我在第一天参加站会的时候就请大家介绍了一下组里在做的产品，有了个大概的认识。可以说作为新人，我是在和大家一起成长的。但好在同事之间非常欢迎互助，不止一个不是我mentor的同事鼓励我多多提问。
对于有点自闭社恐的人来说，还有一个了解组里技术背景的方式是站会。一个能对新人暴露足够多信息的站会在我看来需要包括以下要素：
- 每个人需要提到自己的block和进度，详细到技术名词
- 谈到自己的任务的时候会提及上下文，即任务的上下游部门是哪些，采用了什么技术，达成什么目标，正在与谁协作
- 提到的技术工具 组里有文档或者群聊记录有提及
我重构信息的方式是，先不求甚解，尝试通过大家讨论block的时候的信息在脑子里画一个依赖图，对于能查到文档的或我自己的项目也用到的技术，去看看文档；听到新的技术名词的时候问问自己，猜想这是用来解决什么问题的，必要的时候直接问。经过大概两周的时间，我就能描述出组里做什么，每个同事做什么模块。这对定向求助以及理解自己在组里的位置非常有帮助。
组里主要是基于Scrum流程来安排工作的。除了每天的站会之外。每周会有一些固定会议，大家一起讨论当前遇到的问题，基于Azure DevOps看板盘点当前大家的任务进度并分配新的任务；还会安排专门的knowledge sharing和happy hour供大家交流学习和团建。
和学校里非常不同，工作当中沟通讨论的时间和写代码的时间可以说是对半。写代码的时候为了写代码而准备的时间有时候又比写代码本身要长。所以，写代码很重要，但是不是工作的全部。
个人成长
对新人来说最重要的是学习，又可以分为基于任务的快速学习和系统学习。
基于任务的快速学习的关键是模仿、学习和从少到多的实践。一开始mentor给我安排的是debug的任务，让我可以了解组里现有的代码架构，学习有经验的同事的代码写法。之后再通过阅读类似任务的代码和工具手册来设计自己任务的方案，不会的就多查多问。看到一个观点，说小成功才是成功之母，人对自己的信心是从一点一滴开始建立的。如果能看懂原有的代码，简单的任务能够上手，那么面对新工作自己是否能胜任的担忧也会慢慢消失的。
二八法则在这里再一次适用了。尽管大部分时间花在快速学习，大部分问题都能通过快速学习解决，但是系统的学习仍然是非常重要的部分。我自己在实习期间没有能系统的学习感兴趣的技术和话题，但是我的同事有谈到自己的经验，系统学习能让人在关键时刻抓到重点。比如，由于我在学校学习过Java（和C#很多机制类似，包括微服务的部分），而我有一位新入职的校招同事以前主要使用的是C++，我发现自己过去系统学习的知识能够在一些关键点上促进理解。我猜这就是为什么大组每个月都会空出一个周一给工程师们做Learning Day。
转正面试趣闻
面试官似乎很看重对产品逻辑、用户需求的理解，引导我往这方面思考和讨论了很多。印象最深的是被问到，To B产品在用户规模扩张的时候，随之需要投入的各种资源增长的速度比To C的快很多——比如羊了个羊游戏，用户增加的时候需要增加的可能只是服务器资源，但是对于ToB产品来说会复杂很多——那么有什么办法能压平规模增长下成本随之增长的曲线？（这个问题真的很难，我到现在都还没有很好的想法）
实习小结我因为种种原因拖了将近两个月才写完。转正虽然挂了，但是还是依旧感谢这三个月的时间。我意识到原来每天早上可以因为期待去上班而不赖床速速起身，原来工作可以是一件有成就感的事情。想要带着这份珍贵的回忆继续前行。