前言
提到微软，你首先会想到什么？外企？Windows Or Office？还是 955·WLB？
我在前司待了快三年，自觉到了一个打工人的黄金跳槽点，于是就想出去试试不一样的工作环境。
前司是一个典型的互联网公司，提倡短平快的工作节奏。彼时的我，负责一个不大不小的项目，却遇到瓶颈，怎么也做不大。在我面前有两个选择：吃老本 or 跳槽。
我选择后者，因为在一个人分饰多角的项目中，我察觉到了我的能力短板：不够专业。这又导致了我想好好做成一件事的话必须加班来完成（开会、沟通用户、梳理需求、设计项目架构、编写代码、测试、上线和运维、技术支持和 oncall），而这又让我失去了业余时间去提升我的能力短板，最后的结果往往达不到专业的水准，从而继续恶性循环。
在环顾了一圈市场上的企业后，我选择尝试微软，因为在我看来，它有至少以下三点我非常渴望拥有的东西：
全英文环境，锻炼英语技能
坐拥多个大型项目，可以学习到专业的项目开发流程
可以体验 wlb 的工作节奏
面试
在某一天，我在某 App 上被一个微软的陌生人勾搭，简单地电面后一拍即合，我向他投递了简历。
正式的面试一共有四轮，三轮技术面 + 一轮 AA 面（大老板），每轮持续时间一个小时左右。
除了最后一面聊了聊人生、理想、逻辑推理等非技术内容。其他三面基本上是项目算法各半小时。
算法
算法基本落在 leetcode 前两百道题非 hard 范围内，有个别题在原题的基础上进行了变式。（我被考察的是数组、树、图、递归类型的题目）
与某些公司对算法题的考察不同，我的面试面板没有 AC 要求，换句话说就是白板编程，面试官提供的只是一个空白的在线编辑器。
他们似乎更注重和你的沟通而不是仅仅得到答案，每一轮算法部分我都是先向面试官确认测试用例的形态，也就是输入什么得到什么输出。然后才开始做，做的过程中面试官会提醒你，然后如果做快了，面试官会添加限定条件，将这个题的难度提升一些（类似 leetcode TwoSum -> ThreeSum）。
项目
项目基本上就是我将自己简历上的项目背景以及实现亮点介绍清楚后，他们从他们的视角进行提问，比如为什么使用 XX 技术方案？权衡的原因？如何衡量哪个方案好？怎么用数据驱动项目做的更好？
最后一般就引出类似系统设计的问题，比如如何设计一个组件库、设计一个状态管理层、设计一整个应用（比如 office online 版本）。
看到这的读者可能也明白了，这个团队是偏前端的，所以没有问太多关于后端的东西。当然，换个团队面可能就不是这样了。
英语
因为我面试前说明了自己英语不太好，所以面试全部采用中文进行。
其他
面试完成后第二天我就收到了通过的通知，接着就是发 Offer，接受背调，约定入职。
会议
入职后我第一个想说的部分就是关于会议。前司我每周的必参加会议只有一个，那就是小组周会，时长也就半小时。其他会议都是按需加载。
但在这，每周有 8-9 个小时必参加会议（5 - 6个），如果按标准工时一周 40 小时计算的话，每周 20% 以上时间都在开会。如果可选的会议多的话，每周占到 35% - 50% 也不是不可能的（比如我的 manager）。
如果仅仅是参加会议倒也还好，对我来说最有挑战的是，它们几乎是全英文的（除了我和 manager 的 1：1），而且我还必须要发言。
英语
这场面有点出乎我的意料了，我原以为只是邮件等书面材料需要用英文，没想到除了口头沟通（仅限中国同事）之外全部采用英语形式。
有的同事说的很快，有的口音千奇百怪。每天我到公司上班，就好像出国了一样。
针对这种情况，除了制定学习计划并执行下去，好像没什么好办法。
对于我这种典型的 “哑巴英语” 用户而言，
读的优先级最低，因为可以随时用工具翻译（浏览器的划词插件，office 的翻译工具等）。
写其次，主要要考虑单词量和语法，这个可以用机器翻译 + ai改作文（语法、词语替换等，如 grammarly、微软爱写作）解决。
而且读写是异步的，用工具后效率大大提高，但听说是实时的，是工作中最可能成为阻碍的部分。
目前听的话我每天抽出 1-2 小时来听写了，找自己感兴趣的美剧、播客等先 0.75 倍速听写，然后对照字幕标出错误的地方，然后换正常倍数听，再换到 1.25 倍。
说的话报了某 APP 上的一个班，每天通过课程练习半小时左右。每周再抽空去参加英语角和类似水平的中国同学用英语交流一个小时。
做了以上学习计划后，每次开会轮到自己发言，还得提前打草稿，只要不遇到复杂问答的问答环节，基本可以应付了。
目前的英语水平评测结果：
希望半年后可以全面达到 C1 level~
如果读者有什么更好的英语学习方法，欢迎和我一起交流~
coding
由于我目前还在新人 （ramp up ）阶段，所以没有分很大的活给我。
不过小需求，在这里不一定代表着简单。
看似增删改查传参数的逻辑，代码不足百行。
但其实 code review 的时候就被吊打，反反复复删改代码几十遍，才合入了主分支。
一部分是因为代码不够优雅，没有遵守最佳实践（比如函数设计、变量命名、注释、排版）。
另一部分其实是因为实现方案的权衡，如果有更好的方案（性能更优，成本更低，风险更低）就需要重构来达到。而这部分其实需要大量 coding 之外的工作。
非 coding
可以说一个需求的上线里，coding 其实只占用了 10% 的时间。
40% 的时间用来沟通：
在微软，想一个人做成某件事是非常难的。从提交代码时，就有技术同事帮你把关，到上测试环境和产品、qa 沟通，再到部署。特别是依赖别人的项目或者产品基础上做事情时。
- 邮件沟通，邮件沟通在微软起到了一个非常重要的环节。因为大家可能在不同的时区工作，所以异步且正式的邮件方式成了官方推荐的沟通环节。
这样的好处就是每个人都可以按照自己的节奏安排工作。 - IM 或口头沟通，这种属于非正式沟通，比较高效，但是基本定不下结论。而且 Teams 经常出 bug，大家稍微正式点的沟通还是用邮件，和前司 IM 为主的模式不同，这里的 IM 看起来是辅助邮件而存在的。
- 会议沟通，这种一般是针对特定的议程得到特定的结果。有的是工程师们针对技术方案的讨论，有的是工程师、pm、设计师对项目和产品的讨论。还有的是跨团队沟通。
- code review 沟通，这种就是提交代码后全组的同事来挑你代码的毛病了，几十行代码得到几十条 comments 是常事，有时候因为大佬的一个 comment 推翻重写也是常有的事。
20% 的时间用来设计：
- 做的事影响的范围。如果影响范围较大需要拉相关的同事一起来讨论。
- 可维护性，有的技术方案虽然可以解决问题，但是可能会对提高同事后续的维护成本。（所以要应用各种设计模式的时候很容易被人说过度设计）
- 性能。包大小、应用加载速度、服务稳定性等都是被考量的因素。毕竟这些可以被量化。
- 安全，此处细节略过。
- 用户隐私，此处细节略过。
- 可访问性，微软还是很重视残障用户的需求的，对于视障听障或者运动障碍等的用户也照顾到。
- 兼容 IE...
20% 的时间用来测试：
- 自测，自己测功能看是否达到预期
- 内测，组内同事帮忙测功能是否达到预期，以及一些边界情况。这需要单独组织个会议。
- 单测。主要集中在数据处理和 ui 组件上。
- e2e 测试，还没接触到，但有人在维护。你提交的代码一定要通过这些用例。
10% 的时间用来总结和分享：
在会议上总结自己的工作，同步给参与的同事。如果这段经验复用价值比较高的话，还需要做 PPT，举办一场分享。
一个例子
一个 sdk 升级引来的惨案。
我接到一个活，是修一个 bug ，但它其实是第三方库 A 的问题，然后我引了个另一个第三方库 B 来修它，不过这样做会让整体的代码 gzip 后大概大了40 k，即使我用了懒加载。然后大佬 code review 评论别用 B 了，直接升级 A，改代码升完了，告诉 PM，又说很多地方用了 A，我要是升级的话得同步一堆人先讨论这个变更是否值得，ROI 高不高。然后又是一通邮件 + 会议，现在还没个定论...
wlb
整体公司大环境还是慢的，提倡 wlb，排期也不会特别紧。但是我这个组氛围比较 push，主动加班的人也多。
每晚八九点打开 Teams，一定有人在提 pr，再晚一点甚至周末也有同事在干活，估计我过了新人期（这边叫 ramp up），也不会比前司轻松。
当然，没有加班费。自愿的。
manager 的管理风格属于那种 MicroManager，需要进行日常汇报（可能也解释了为什么会议那么多），现在已经哪天不汇报进展和问题就心慌了，每天高（jin）效（zhang）地工作，不存在摸鱼。
如果轮值成 oncall，需要 7x24 待命，那应该是最忙的时候，不过要半年后才轮到我。只能期望那时候已经熟悉了整个项目和相关的合作同事了吧。
总结
再回顾一下我最初来微软所追求的三样目标：
锻炼英语技能 ✔️ 但是难度超过预期了，需要额外付出精力提高
学习到专业的项目开发流程 ✔️ 倒是很享受这个痛苦而又满足的过程
体验 wlb 的工作节奏 ❌ 业余时间用来学习英语或者了解项目
我只想说，微软其实并没有想象的那么轻松。
