前言
今年暑假有幸在微软苏州 M365 团队实习了三个月，实习结束后，就想到写篇文章记录下实习经历，以及个人的一些感受和想法，希望能给将要来微软实习的同学一些参考。注意，这篇文章对于整个实习过程的描述可能比较琐碎，所以大家把它当成个人向的流水账日记就行。本文的描述基于我在短短三个月内的实习体验，无法覆盖代表整个 MSFT，仅供参考！
简历投递与面试经历
我投递简历的经历还是比较有戏剧性的…
我在寒假开始时就一直关注着微软的春招岗位，所以在一月末就找好了内推。但是我在当时并没有继续提交个人信息。我最初的计划是：先苟到开学再提交申请，等待面试的期间刷刷题。在此之后整个寒假，我基本上把全部精力放在了重构 Cloudreve V3 上，并没有想起来要准备春招，所以当二月末意外的收到面试邀请邮件后，留给我的只有 5 天的时间准备面试，当时真的超级后悔没在寒假期间好好准备。
微软等外企的面试风格非常强调现场 Coding 能力，面试中 90% 的时间都是在做题，剩下 10% 是自我介绍环节，是帮你放松的。没有任何算法竞赛经历、LeetCode 只刷了 50 题的我，抱着破罐子破摔的态度参加了第一轮技术面试。面试官的面试逻辑还是十分清晰的，首先让我介绍了递归与迭代的概念、区别、优劣，然后由此出发写了一道有关二叉树的题。磕磕绊绊写完后，面试官让我分别从空间、时间复杂度的角度优化，这也就回到了最初的那两个概念 - 递归与迭代。面试官的意图之一就是让我把递归改写为迭代。最终在纸上画了20多分钟，头脑中还是一片空白，只剩下面试官敲键盘的声音。面试快结束的时候，我直接主动投降，面试官来了句 “没事没事，已经比很多社招的同学都强了”，当时我很怀疑他是不是把我挂了然后安慰我。
第二轮面试的安排会根据第一轮表现而定。如果第一轮过了，第二轮就直接是最后的 “Lead 面”；否则第二轮是另一轮平行面，相当于第二次机会，所以无论如何都会有第二轮。第二轮一开始，面试官让我英文自我介绍，然后自选一个自己的开源项目进行介绍，我简单介绍了下 gameboy.live ，随后开始写题。具体的题目我记不太清了，只记得第二题是面试官看不下去了，主动降低难度后我才写出来….
两轮面试过后，就再无后续消息。当时的我十分确定自己挂了，所以转而继续投递其他公司的实习岗位。三月份某天早上突然收到了 HR 的邮件，我以为是 Thank You Letter，直接点开了，当发现是恭喜面试通过的邮件后，激动到午饭都没吃。
实习经历
实习项目
我所了解到的实习项目可归纳为 “工程型” 和 “研究探索型” 两种。工程型项目就是实现一到两个 Feature；研究探索型的项目可能是帮组内探索某种新方案的可能性，亦或是与 MSR 合作，协助他们的研究成果落地并评估表现。研究探索型的项目可能不会有太多的编码成分，最终只要产出一个总结报告就行。不管是哪种项目，组里其实都不会太 Push 你Mentor 甚至曾吐槽我 “做的太快了，不用那么着急”。实习开始时分配给你的任务，实习期的三个月内完成就行。这些项目完成后还有剩余时间的话，才会视情况分配新的任务。
从技术栈的角度来看的话，前端与后端的界限不会很明显。如果有涉及到 Web 开发的话，大概率前后端都要自己来做。前端的技术栈基本上就是 React + TypeScript，后端是 .NET Core ，比较老的项目可能还是 .NET Framework。
开发工作流
整体的开发流程在不同组、不同项目之间的区别可能比较大，但基本上都是在 Azure DevOps 上完成的。整体上体验还是比较舒适的，M365 这边还有专门的 Engineering System 团队，致力于改善工程师的开发工作流程体验。
我们组在我实习中期开始尝试使用 Scrum 敏捷开发模型。我们需要将任务分解成多个 Work Item ，Work Item 之间、Work Item 与 Commit 或 PR 之间都可以进行关联，整体上呈树形结构。组内每周会通过看板追踪任务进度、同步当前 Sprint 的每个任务的状态。这些工作全部在 Azure DevOps Boards 上完成。
在一个比较大型的 Feature 或项目开始前，首先需要编写 Design Doc，详细阐述需求目标、初期可行性调查、具体的技术设计思路等等。Design Doc 完成后会由同事来进行 Review，不断地改进，直到可以以此为依据进行编码设计。
实际编码时，各种 lint 已经配置成了开箱即用，大部分代码质量、风格上的问题都能在 commit 前解决。得益于微软大刀部的功劳，大部分组都没有专门的测试部门，所以我们在完成业务代码后还要自己写测试，甚至还要负责上线后的运维。写测试向来是一个比较枯燥、乏味的过程，但是这么做的优势之一是自己比较清楚自己代码的结构，写测试时的思路也更清晰，消除了测试人员与开发人员之间沟通成本。因为没有专职测试，单元测试质量与覆盖率在微软内部还是十分重要的，有的组会将 100% 覆盖定为 check-in 的强制条件；部分比较老的项目也会通过逐步提升 check-in 覆盖率要求的方法提升项目整体的覆盖率；我们大组每周还会通报表扬上周总体覆盖率前三的同事。
编码工作完成、创建 PR 后，CI 会构建项目并运行测试，Azure DevOps 平台会根据项目策略进行一些前置的自动检查，包括覆盖率要求、合并冲突、变更范围等等，然后会根据变更范围以及项目策略下发 Code Review 要求。比如，如果你修改了其他团队下的代码，这个团队就会被加到 Required Reviewers 之中。
你可能会有疑问，为啥不同团队之间的代码会在一个仓库里… 一种情况是这个项目是一个平台向的项目，不同团队会来开发扩展与本团队相关的 Feature；另一种情况是你的项目在一个巨大的 Monorepo 里
比如大名鼎鼎的 300GB 的 Windows 仓库。所以控制、审计变更范围就比较重要了。
Code Review 流程还是比较严格的，包括但不限于代码风格、复用程度、语句简化、语句逻辑、与外部业务关联等等。我的第一个 PR 前前后后就被 Review 了一个星期，总共产生了 60 多条修改意见… 不过我个人还是挺喜欢被 Review 的过程的。当然，我们能从 Code Review 中学到很多新知识、技巧，不断提升自己的代码质量；除此之外，Code Review 能带给我们这些“后端向”开发人员一些鲜有的“成就感”。对于偏向后端的工程师，尤其是 Infra 方向的工程师，我们无法体会到像前端工作那样由“直接被用户接触使用”而产生的成就感，大部分代码都只是在外部用户不可见的地方发挥作用，甚至很可能日后读过这些代码的人只有自己。而 Code Review 就给了我们一个短暂的“展示自己作品”的机会，因为你的代码会被除开自己之外的人一行一行的仔细阅读。
PR 合并后，Azure Pipelines 会对项目进行构建，并按既定的日程，分阶段部署到逐步扩散的环境中。
纵观整个实习的开发流程，沟通交流的占比要比我想象的高很多。需求的确认、内部工具的咨询、各种权限批准、演示等等流程都涉及到了与同事的沟通。对于苏州 M365 团队，大部分组在美国总部都有与其对应的组，大家需要深度合作、跨国沟通。但是由于时区的问题，两个组很难找到共同的工作时间使用 Teams 实时交流，所以大部分的交流都是通过邮件进行的。有些每周固定的同步会议需要两组人员一起参加，一般会在是苏州的早上，雷德蒙德的傍晚举行。对于苏州组内的沟通，大家一般选择使用 Teams 或者当面交流，但是邮件沟通占比仍然不小。比如，需要咨询某个内部服务相关问题，但又不知道要找哪个具体的同事，大家一般会把问题整理好，直接给对应的邮件组发邮件咨询。
内部工具与 Dogfood
微软曾在上个世纪八十年代提出了 “Eating our own Dogfood” 的提议，也就是自家的员工尽可能使用自家的产品，以此提高产品的质量和客户对产品的信任。在实习工作期间，员工所使用的各种工具软件甚至是硬件，几乎全部是微软自家的产品。我在实习后简单回顾了下，我在工作过程中常使用的非微软的工具产品，也就只有 Google 搜索憋问我为啥不用 Bing ( 和 Postman 了。员工账号身份下访问的微软产品都是处于开发阶段的“内测版本”，很多产品的新特性都能第一时间体验到。
对于日常交流、会议，Teams + Outlook 的组合体验很棒。只要是只是 Exchange 协议的邮件客户端，都可以在日历中直接看到后续会议安排，并可以直接选择参与意向并反馈给组织者。某个人、某个会议室，甚至是某台 Surface Hub ，他们的空闲时间段都可以被直观的看到。
对于日常的开发活动，Azure DevOps 是最主要的平台。我在此之前一直以为它和 Travis CI 类似，是专注于 CI/CD 服务的平台。不过实际接触到企业版本后，才知道它和 GitHub 类似，包含了一整套开发流程所需的工具，包括任务追踪、代码托管、CI/CD、测试、私有包托管等等，并且可扩展性很强。
其他开发过程中用到的工具，比如预警处理、监控、权限控制、服务数据检索等等，都会有专门的团队负责维护，大部分平台的完成度还是挺高的，感觉稍微修饰下就可以作为对公产品发布了。大部分内网的资源都可以通过 Bing@Work 检索到，其结果涵盖了所有拥有可读权限的文档、内部网站、SharePoint 站点、企业 Stack Overflow，甚至是员工信息。平时遇到的大部分问题都能通过 Bing@Work 搜索到答案。遇到不懂的缩写词，也有专门的网站可查询其含义。
开发过程中使用的构建大部分都是微软自家的产品或者是内部的轮子，外部比较流行的开源产品基本都能对应到某个或某组内部组件上，但是内部轮子的“好用程度”差别挺大的。这也许就是微软被诟病“技术栈封闭”的重要原因之一吧。
工作环境
由于 COVID-19，我实习期的前两周是远程办公的形式，第三周后有幸能到苏州现场实习。但是由于苏州二期办公楼开建，隔壁临时租用的 B18 栋又还没准备好，所以一期办公楼的工位十分紧张，很多新入职的 FTE 只能临时挤到会议室、Focus Room 里；而实习生就更惨了，大部分实习生被安排到了一楼 Training Room 临时改建的“工位”上。
除开工位的遗憾外，其他方面的体验还是很棒的。苏州这边正式工位都是统一的，不论职位大小，大家都坐在一起。工位的布置类似于半开放的形式，每个小组的十来人会坐在一起，组与组之的空间相互连通，但又会有墙壁隔开。不同规格的会议室、可自由使用一小时以内的 Focus Room 分布在各个区域不过今年夏天都被塞满了FTE（。茶水间供应零食水果、咖啡花茶啥的也算是互联网公司标配了。因为疫情的原因，每周三固定的 “Cake Day” 暂停举办了，不过运气好赶上了夏季限定的 “Ice Cream Day”，每周三阿姨都会送来不同口味的冰激凌其中一周吃到了“鱿鱼味”冰激凌，味道至今难忘🤧。RE&F 也会时常举办一些符合时令的活动，比如端午节的划船机大赛，垃圾分类问答比赛，情人节巧克力，熏香手工课程等等。
针对实习生的活动也是比较丰富的，但是因为 COVID-19，所有的活动都只能线上进行了。STCA 这边针对实习生开设了不同种类的 Club，最受欢迎的应该就是 Coding Club 了，毕竟可以带薪刷题打卡，还有奖品拿。
Hackathon 与公关危机
微软每年都会在员工内部举办为期一周的 Hackathon 活动，你可以在这一周里暂停工作上的事，自由组队、实现你平时没时间去实现的想法。
今年的 Hackathon 在七月末线上举行，我也带着某个 Idea 报名了这场 Hackathon，最终团队人数达到了 30 人左右，全部都是实习生；但是最终参与项目本身的只有 3 人，其他人只是来注册领个 T-shirt 和贴纸。在与 Beta 版 Graph API 以及其附属的不完善文档斗争三天后，我们最终还是勉强实现了当初预想的功能。因为社交媒体的使用不当与文案措辞问题都是我的锅QAQ，这个项目在完成后的当天晚上“意外走红”，甚至第二天早上在电梯、食堂里都能听到同事在讨论这个项目。但是接踵而来的是被媒体添油加醋、曲解本意的二手报道，最终造成了一定程度上的“公关危机”。
跟 Manager 解释事情经过后，Manager 的意思大概是“当作教训学习就行，其他的不用担心”。这件事在大组里最终被当作 “Lesson Learned” 处理了，也没对团队成员产生什么影响我甚至还在后面转正面试时被意外地抬了一手。
白嫖
感谢四楼的 IT，他把往年活动库存的周边全部发给实习生了，白嫖真的很快乐hhhh
除了微软周边账号意外，拿到工作账号后能做的事还是很多的，这里简单总结一下，留给未来的 MS 实习生看吧。MS 工作账号的主要羊毛、特权有：
-
FTE Visual Studio 订阅
前往 my.visualstudio.com 可自由领取，其中包含的主要权益：
- 索取微软几乎所有软件的序列号，离职后序列号仍可使用；
- Microsoft 365 E5 订阅；
- 部分无序列号产品可登录工作账号直接使用；（比如 Visual Studio 2019 企业版）
- Azure 个人账号每月 150 美金额度。理论上离职后就无法使用了，但是据前辈说这个激活后就是终身的，暂未测试。
-
Xbox Game Pass Ultimate
Bing@Work 搜索关键词就能找到领取网站，可以直接领取一年的礼品码，一年后还在职的话就能重新领取新的。
-
(非大陆地区) Company Store
以折扣价购买微软的硬件、软件产品或是周边。可惜的是邮购不对大陆地区的办公地点开放。
-
微软相关认证考试折扣
前往 examregistration.microsoft.com 验证工作账号，能以折扣价报名微软相关的技能认证考试。
-
华住会企业会员
使用华住会 APP 验证工作邮箱，可以获得企业会员，每个订单可享受八五折优惠、延迟退房、两份免费早餐。
-
加入微软在 GitHub 的组织
前往 aka.ms/opensource 使用工作账号登录，可自由加入微软旗下的 GitHub 组织、创建项目等。据页面描述，离职后会自动将你移出组织。
-
aka.ms 短链
前往 aka.ms 可创建 aka.ms 短链接，注意阅读使用规范、服务条款。
我探索到的暂时只有这么多，肯定有不少还没发现的东西，后面找到的话再补充。
吐槽
虽然实习的体验总体上很舒适，但还是有几点要吐槽的地方。
文档管理
就我的体验来说，内部文档的管理比较混乱。很多面向组内的文档直接写在一个 OneNote 里了，用 OneNote 写技术文档这种事我是真的做不出来。而对于面向其他组的公共文档，不同组又会又不同的方案：有的直接用 Azure DevOps 里的 Wiki 模块；有的自己搭了个 MediaWiki； 有的是 docs.microsoft.com 同款 DocFX… 更要命的是很多文档站并没有被 Bing@Work 检索，大概率只能靠同事相传才能找到。如果能有一个统一的文档系统的话，新人的体验应该会更好。
苏州 Site 的食堂
苏州的食堂环境没得说，但我要吐槽的是食堂的承包商。比起上海和北京办公室的食堂，苏州的食堂比较拉跨，整体上菜品算得上“能吃”的水平，但是价格偏高、种类少、盐油用量大、菜品花样少，基本上不到一个月就会吃腻，而且我实习的两三个月内就听说到了数次吃出异物的事件… 实习后期我基本就投奔到了周边小店+外卖了。
苏州
在苏州的两个月里，每到周末就无聊到自闭，所以我尽可能用乘公交的方式把苏州想去的地方逛了个遍。总体上，苏州的主城区和微软所在的工业园区完全是两种画风：主城区保留了传统的建筑风格、街道布局，整体上很有生活气息，街道旁的新老建筑也统一的是白墙青瓦；工业园区则是现代城市该有的样子，围绕金鸡湖沿岸的商圈、公园、建设发展都很完善，园区的整体规划也很棒，很多地方都有新加坡的影子，比如邻里中心、花园、建筑风格，尤其是北部商圈，给人一种强烈的坡县既视感。后来听说园区是跟新加坡政府合建的，那这也就解释通了。
规划建设完善的同时，园区的房价也在飞速攀升，比较好的地段基本上可以追赶一线城市了…这也使得微软苏州逐渐失去了前几年的较强竞争力，毕竟我听说 2015 年那会儿很多人是奔着低房价来微软苏州的。
转正
微软的转正考核由两大部分组成：Manager & Mentor 的评价、一轮 AA 面试。在实习期接近尾声时， Mentor 和 Manager 会根据你实习期间的表现给出评语和转正推荐意见，转正推荐意见大概分为 Not Recommend、Recommend、Strong Recommend，拿到后两个等级就可以参加最终的 AA 面试了。AA (As Appropriate) 面试是微软的一种特殊的面试轮次，理论上每个入职微软的员工都经历过一轮 AA 面试，并且面试结果终身有效。不同于传统的技术面试，AA 面通常还会额外考察公司文化、价值观等非硬性指标；AA 面试官都是在微软有资深经历的人，大部分都是 Principal Group Mgr. 级别的大佬，面试的风格也很大程度上取决于面试官：有的全程聊人生聊理想；有的还会有传统的写题环节。
因为在 Hackathon 上制造了“公关危机”，我一直担心这件事会不会影响我的转正。不过 Manager 一直跟我强调“不会有影响”，Mentor 还在我 AA 面试前塞给我一些微软价值观、企业文化的资料，以便用于应对面试官问题这件事的回答。最终 AA 面试官看起来年纪挺大，但是思维十分敏捷；整场面试都在他的掌控之中，而且他还挺幽默的。直到面试结束，面试官并没有提起 Hackathon 的事，不过这也在意料之中，因为我在面试中没有主动说，Manager 也说过他在谈论这件事的时候没有跟别人指名道姓。正当我准备离开时，面试官突然叫住我：“之前那个 Hackathon App 是不是你们做的？”我心里一震，正准备把“Diversity & Inclusion”搬出来解释时，面试官立马补充道“别担心，没事的，我挺欣赏你们的，有自己的想法、善于把想法实现出来，不甘于做『码农』，挺不错的！”听到这话我如释重负，顺便问面试官是怎么知道我参与了这个项目，面试官说是根据我在面试中说的内容，以及我的 Manager 的名字推测出来的。
根据我的体验与理解、与其他实习生的交流，我把转正整个环节主要考察要素按照优先级大概列了一下：
-
学习能力
能否快速学习上手新的技术栈、完成分配给你的基本任务，很大程度上决定了你能否能拿到推荐 AA 面试的资格。但是就我的体验来说，只要不是特别划水、消极的那种，基本大部分实习生都能完成并拿到推荐。
-
沟通与表达能力
在实习期间，避免不了要向同事请教问题、交流设计实现方案，甚至要直接与总部的美国同事交流。交流方式包括但不限于当面、IM、邮件、视频会议，清晰、准确的阐述自己的想法能够极大的提升交流的效率。沟通交流与表达能力在最终的推荐评价中占有不少的比例，甚至可能会超出技术能力本身。
在最终 AA 面试中，面试官大概率会让你详细阐述自己的实习项目，这其中也包含了对沟通表述能力的考查：清晰、准确的阐述自己项目是做什么的，能够回答面试官对于项目细节（不局限于技术上）的提问。
-
主动性
虽然 Mentor 不会在进度上太 Push 你，但是不要因此把自己放在被动的状态中。很多情况下项目的进度是要自己主动推进的，有什么其他组的外部因素阻塞了进度，也要尽量自己设法寻求解决。千万不要只是机械地服从 Mentor 的指令、没有指令了就开始划水。
-
算法向 Coding
听起来有点不可思议，但在转正 AA 面试时，很大概率还是会有写题环节的，题目的难度大概和 IC 面类似。
保研与工作
虽然按照我的 GPA 以及奖项加分，拿到保研资格是没啥问题的，但我最终还是选择放弃保研、直接工作。做出这一选择还是十分艰难的，虽然我打心底里更喜欢直接工作，但是周边关于硕士学历重要性的言论氛围、大家拼命争取保研资格、考研的氛围，让我着实不敢迈出放弃保研的这一步。来到微软实习后发现竟然有不少人跟我有一样的困扰，我们还私下建了个“保研工作纠结群”。通过其他实习生的交流，跟其他同事、 Mentor 以及 Manager 的交流，我更加坚定了放弃保研的决心。
我把做出这一决定的主要因素列了出来。请注意，这些都是非常个人向的思考，仅供读者参考。
-
工程与科研方向的兴趣选择
我个人是一个十分偏向“工程向”的人，满足于将各种想法的实现造出来，而非从事理论上的研究。我在学校期间尝试过了解科研生活的日常，最终得出结论：这个真的做不来，甚至有种十分抵触的心情。在导师选择上，相比于热门的机器学习方向，我更偏向于传统的研究方向，但这些传统方向的导师真的挺难找的，比较好的也都在我保不上的实验室😪
-
得失的权衡
如果保研了，我想通过读研得到什么？我是肯定不会读博的，读研的最终目标无非是找到一个好工作，工程向而非算法
国内语境下可等同于机器学习算法向的工程师岗位，最好是在外企，能够有时间做自己的事的工作。如果在本科毕业能够实现这些的话，那为啥还要读研呢？短短三年甚至两年的研究生生涯，能对专业知识有多少提升呢？不可否认，肯定会有提升，但绝对不值得花费两年甚至三年的时间。除去专业知识，剩下的对科研能力、思维方式、视野的提升则更不值得一提了。 -
学历问题
除开上一条提到的知识上的回报，读研能够带来的更重要的回报是硕士学历本身。但是在互联网行业，学历本身并没有那么重要，不论是对于招聘还是日后的晋升，个人能力是首要因素。我也考虑过中年危机跳槽传统行业被学历限制的可能性，但是这些都是 20 年后的事，20 年之间能发生太多变动了。往前看 20 年，那个时候搜索引擎都是稀罕事，主流的 AOL 电子邮件和资讯网站还都是收费的订阅制呢，20 年对于 CS 行业来说是能跨越了几个年代的了。以现在的行业眼光考虑 20 年后的后路，在我看来是大可不必的。