入职微软一月后的感悟，谈谈面试经历及入职体验，web前端开发入门学习

作者：很楠不爱3 | 2024-04-17 04:13:38

踩

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

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

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

全英文环境，锻炼英语技能
坐拥多个大型项目，可以学习到专业的项目开发流程
可以体验 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 沟通，再到部署。特别是依赖别人的项目或者产品基础上做事情时。

邮件沟通，邮件沟通在微软起到了一个非常重要的环节。因为大家可能在不同的时区工作，所以异步且正式的邮件方式成了官方推荐的沟通环节。这样的好处就是每个人都可以按照自己的节奏安排工作。
IM 或口头沟通，这种属于非正式沟通，比较高效，但是基本定不下结论。而且 Teams 经常出 bug，大家稍微正式点的沟通还是用邮件，和前司 IM 为主的模式不同，这里的 IM 看起来是辅助邮件而存在的。
会议沟通，这种一般是针对特定的议程得到特定的结果。有的是工程师们针对技术方案的讨论，有的是工程师、pm、设计师对项目和产品的讨论。还有的是跨团队沟通。
code review 沟通，这种就是提交代码后全组的同事来挑你代码的毛病了，几十行代码得到几十条 comments 是常事，有时候因为大佬的一个 comment 推翻重写也是常有的事。

20% 的时间用来设计：