入职微软一月后的感悟，谈谈面试经历及入职体验

前司是一个典型的互联网公司，提倡短平快的工作节奏。彼时的我，负责一个不大不小的项目，却遇到瓶颈，怎么也做不大。在我面前有两个选择：吃老本 or 跳槽。

我选择后者，因为在一个人分饰多角的项目中，我察觉到了我的能力短板：不够专业。这又导致了我想好好做成一件事的话必须加班来完成（开会、沟通用户、梳理需求、设计项目架构、编写代码、测试、上线和运维、技术支持和 oncall），而这又让我失去了业余时间去提升我的能力短板，最后的结果往往达不到专业的水准，从而继续恶性循环。

在环顾了一圈市场上的企业后，我选择尝试微软，因为在我看来，它有至少以下三点我非常渴望拥有的东西：

1. 全英文环境，锻炼英语技能

2. 坐拥多个大型项目，可以学习到专业的项目开发流程

3. 可以体验 wlb 的工作节奏

面试

–

在某一天，我在某 App 上被一个微软的陌生人勾搭，简单地电面后一拍即合，我向他投递了简历。

正式的面试一共有四轮，三轮技术面 + 一轮 AA 面（大老板），每轮持续时间一个小时左右。

除了最后一面聊了聊人生、理想、逻辑推理等非技术内容。其他三面基本上是项目算法各半小时。

算法

算法基本落在 leetcode 前两百道题非 hard 范围内，有个别题在原题的基础上进行了变式。（我被考察的是数组、树、图、递归类型的题目）

与某些公司对算法题的考察不同，我的面试面板没有 AC 要求，换句话说就是白板编程，面试官提供的只是一个空白的在线编辑器。

他们似乎更注重和你的沟通而不是仅仅得到答案，每一轮算法部分我都是先向面试官确认测试用例的形态，也就是输入什么得到什么输出。然后才开始做，做的过程中面试官会提醒你，然后如果做快了，面试官会添加限定条件，将这个题的难度提升一些（类似 leetcode TwoSum -> ThreeSum）。

项目

项目基本上就是我将自己简历上的项目背景以及实现亮点介绍清楚后，他们从他们的视角进行提问，比如为什么使用 XX 技术方案？权衡的原因？如何衡量哪个方案好？怎么用数据驱动项目做的更好？

最后一般就引出类似系统设计的问题，比如如何设计一个组件库、设计一个状态管理层、设计一整个应用（比如 office online 版本）。

看到这的读者可能也明白了，这个团队是偏前端的，所以没有问太多关于后端的东西。当然，换个团队面可能就不是这样了。

英语

因为我面试前说明了自己英语不太好，所以面试全部采用中文进行。

其他

面试完成后第二天我就收到了通过的通知，接着就是发 Offer，接受背调，约定入职。薪资方面总包大概降了 30% 左右，这主要看个人取舍了。

会议

–

入职后我第一个想说的部分就是关于会议。前司我每周的必参加会议只有一个，那就是小组周会，时长也就半小时。其他会议都是按需加载。

但在这，每周有 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 沟通，再到部署。特别是依赖别人的项目或者产品基础上做事情时。

1. 邮件沟通，邮件沟通在微软起到了一个非常重要的环节。因为大家可能在不同的时区工作，所以异步且正式的邮件方式成了官方推荐的沟通环节。这样的好处就是每个人都可以按照自己的节奏安排工作。

2. IM 或口头沟通，这种属于非正式沟通，比较高效，但是基本定不下结论。而且 Teams 经常出 bug，大家稍微正式点的沟通还是用邮件，和前司 IM 为主的模式不同，这里的 IM 看起来是辅助邮件而存在的。

3. 会议沟通，这种一般是针对特定的议程得到特定的结果。有的是工程师们针对技术方案的讨论，有的是工程师、pm、设计师对项目和产品的讨论。还有的是跨团队沟通。

4. code review 沟通，这种就是提交代码后全组的同事来挑你代码的毛病了，几十行代码得到几十条 comments 是常事，有时候因为大佬的一个 comment 推翻重写也是常有的事。

20% 的时间用来设计：

1. 做的事影响的范围。如果影响范围较大需要拉相关的同事一起来讨论。

2. 可维护性，有的技术方案虽然可以解决问题，但是可能会对提高同事后续的维护成本。（所以要应用各种设计模式的时候很容易被人说过度设计）

3. 性能。包大小、应用加载速度、服务稳定性等都是被考量的因素。毕竟这些可以被量化。

4. 安全，此处细节略过。

5. 用户隐私，此处细节略过。

6. 可访问性，微软还是很重视残障用户的需求的，对于视障听障或者运动障碍等的用户也照顾到。

7. 兼容 IE…

20% 的时间用来测试：

1. 自测，自己测功能看是否达到预期

2. 内测，组内同事帮忙测功能是否达到预期，以及一些边界情况。这需要单独组织个会议。

3. 单测。主要集中在数据处理和 ui 组件上。

4. e2e 测试，还没接触到，但有人在维护。你提交的代码一定要通过这些用例。

10% 的时间用来总结和分享：在会议上总结自己的工作，同步给参与的同事。如果这段经验复用价值比较高的话，还需要做 PPT，举办一场分享。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

由于篇幅限制，pdf文档的详解资料太全面，细节内容实在太多啦，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！有需要的程序猿（媛）可以帮忙点赞+点击【学习资料】即可领取！

备注：前端）**

最后

由于篇幅限制，pdf文档的详解资料太全面，细节内容实在太多啦，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！有需要的程序猿（媛）可以帮忙点赞+点击【学习资料】即可领取！

[外链图片转存中…(img-bYYpU7oA-1712622839315)]

[外链图片转存中…(img-BPJw9f2i-1712622839315)]