2024年最新入职微软一月后的感悟，谈谈面试经历及入职体验，美团前端一面

最新推荐文章于 2024-10-04 13:18:14 发布

2301_82243626

最新推荐文章于 2024-10-04 13:18:14 发布

阅读量374

点赞数 3

分类专栏：程序员文章标签：前端面试学习

本文链接：https://blog.csdn.net/2301_82243626/article/details/138900184

版权

程序员专栏收录该内容

176 篇文章 0 订阅

订阅专栏

css

1，盒模型
2，如何实现一个最大的正方形
3，一行水平居中，多行居左
4，水平垂直居中
5，两栏布局，左边固定，右边自适应，左右不重叠
6，如何实现左右等高布局
7，画三角形
8，link @import导入css
9，BFC理解

js

1，判断 js 类型的方式
2，ES5 和 ES6 分别几种方式声明变量
3，闭包的概念？优缺点？
4，浅拷贝和深拷贝
5，数组去重的方法
6，DOM 事件有哪些阶段？谈谈对事件代理的理解
7，js 执行机制、事件循环
8，介绍下 promise.all
9，async 和 await,
10，ES6 的 class 和构造函数的区别
11，transform、translate、transition 分别是什么属性？CSS 中常用的实现动画方式,
12，介绍一下rAF(requestAnimationFrame)
13，javascript 的垃圾回收机制讲一下,
14，对前端性能优化有什么了解？一般都通过那几个方面去优化的？

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

读的优先级最低，因为可以随时用工具翻译（浏览器的划词插件，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 待命，那应该是最忙的时候，不过要半年后才轮到我。只能期望那时候已经熟悉了整个项目和相关的合作同事了吧。

总结

–

再回顾一下我最初来微软所追求的三样目标：