微软苏州实习生2019春招面试经历


I. 简历投递

寒假回来后开始准备春招的事情,虽然心仪公司是微软苏州(钱还行、不加班、离家近、发展空间好),但是考虑到自身水平不是很突出,所以还是海投了简历,此处不表。

3月1号简历制作完之后进行了投递,并请梁神帮忙来了一波内推。过了很久觉得没有希望了,终于在12号微软宣讲会当天收到了面试邀请。话说这一波内推实际上是很重要的,如果不内推的话,就要做微软那个据说很可怕的笔试题(四道题据说做出一道能进面试),而且不走内推对于时间还有很大影响,今天2019.4.4我走完了所有的流程,而有的同学昨天刚做了笔试。(wrh手撕了两道半之后就关了,而mmz说很简单…)


II. 第一次现场面试

3月19号去微软苏州进行了前两轮面试,从两点到四点,两场一个小时,虽然没有亲自确认,但是应该是两场分别打分,只要两个面试官中有一个给Positive就可以进入最终面。我大概十二点多到了微软苏州办公楼,在下面复习了一段时间后,大约快到两点面试官会下楼叫人,跟着进到九楼,在一个单独的小房间面试。第一场结束后隔壁的面试官来给我做第二面。


2.1 第一面

2.1.1 自我介绍

第一面的时候,面试官让我来段自我介绍,而他在这个时间段读简历,于是我就顺着简历上的聊了聊自己做的项目,其中重点聊了下我寒假里模仿Forest做的一个iOS应用FocusHour(垃圾Apple不给我上架,xxx,为什么)。第一个面试是做移动端outlook的开发的,面试时候拿的也是一台Mac,所以他对这个很感兴趣,也讨论了一些实现上的东西。

2.1.2 手撕代码

之后就问了一道滑雪场的算法题。我一开始觉得这个问题可以有很巧妙的解决方法,试图使用动态规划,但是发现处理不了问题的复杂性,然后面试官让我先写个暴力,就递归一下。然后问我怎么优化,怎么优化?不就是加个字典保存结果吗?就这么和他说了,然后就是改了下代码,问题就这么结束了。

然后面试官让我问他几个问题,就问这题最好的解法是什么,答曰就是深搜加记忆;此外大概问了下work-life balance和面试进程安排等。说实话答题过程有点微妙,题目本身不难,但是我自己加了太多戏,导致过程有点尴尬,此外这道题感觉很“脏”,就是说有很多边界条件要判断,很容易写错或者忽略点的位置和值等细节,做起来不是很舒服。

2.1.3 算法题

一个二维数组表示滑雪场,每一个点的值表示高度,你可以从某一个点滑到它上下左右四个点(注意只能从高的点滑到低的点,且不能超出滑雪场)。求你能滑的不同路程中,最长那条路程的长度。

2.1.4 解法

对于每一个点,对上下左右四个点中各个点能滑的最长距离进行比较,从中取得最大值,自己这个点能滑的距离就是这个最大值+1,用字典保存出现过的数据。


2.2 第二面

第一面结束后马上第二面,类似的一上来自我介绍和项目经历,之后开始手撕代码题,对点分组。

2.2.1 手撕代码

一开始写了一个解法,只要遍历输入的点的列表一轮,被面试官指出这个算法可能类似如下错误:如果A和B距离合法,B和C距离合法,但是A和C距离不合法,这时如果以A、C、B的顺序遍历,C就会被认为是不合法的。于是开始改。最终写出来是联想到这个和Leetcode上一道叫做“朋友圈(circle number)”的题目很类似,就按照回忆起来的实现重写了代码,然后花了很多口舌和他解释清楚,最后也因为这个这场稍微拖了一点时间。其实出来后想到代码里好像一个地方有几圈无用的循环。

2.2.2 算法题

输入点的列表,每一项是一个点,点包括x和y两个属性,两个点的距离小于D可以被认为是一组(D已知)。此外如果A和B两个点距离小于D,B和C距离也小于D,但是A和C距离大于D,ABC仍然算一组。输出点分组结果。

2.2.3 解法

结果数组是一个二维数组result。

遍历输入的点集,pop一个点出来,并以这个点自己形成一个组group(用数组表示),时候对于这个组group做如下操作:只要组group中仍然有点,就pop2一个点出来,并遍历输入的点集,对于和pop2中的这个点距离小于D的点全部删除,并添加到到group当中,重复此步骤直到group为空。

与此同时这些从group中pop2的点保存到一个新的数组group2中,这个group2就是一个完整的分组,然后就是把group2添加到result当中。

上面这一堆做完后就是循环中的一次结束了,之后继续从输入点集pop点并进行类似操作,当把输入点集弄成空的时候就结束了。

值得注意的是,每一组形成的group2中,已经把可能在这个组中的点全部拿过来了,之后输入点集pop的新的点肯定和之前的组没有关系。


III. 第二次现场面试

二面结束之后,21号星期四收到过了的通知,之后和HR约定4月4号也就是今天再去苏州进行leader面。

四号和cjd一起到苏州,今天还有很多别的学校的同学,好像大多数是来做一面二面的,要是positive的话下午直接leader面。托梁神的福,我们的进展算是很快了。HR把我们一堆人带到五楼的会议室,然后等着面试官叫你。


3.1 leader面

3.1.1 英文会话

11点半,leader面试开始。这个面试官是做office 365的。一上来就要我英文自我介绍,喵喵喵?好久没说嘤语了,至少简单介绍名字,学校和意向后把话题切到项目上,还是FocusHour,用英文介绍了feature,之后聊了下实时切换应用程序内语言的实现和可能的弊端(iOS启动app的时候会一口气加载资源文件,即Bundle.main,这导致即使切换了语言偏好,也得等下次启动才会加载新的语言资源包,可以使用自定义的BundleEx类,以及OC的set_object方法来解决)。话说除了计算机相关的英文,别的都还给老师了。

3.1.2 手撕代码

之后开始手撕代码,文章标签问题,一开始一口气写完了,然后他说你这个有问题啊小火汁。仔细看了一下,是和二面一样的问题,淦。

于是凭借着对于二面和朋友圈的印象(三者有一些共同之处,说明微软很喜欢这类搜索的题目),写了和二面类似的解法,然后他提出这个时间复杂度太高,我也承认了。

他说能不能一次遍历,我想了想说可以用字典和树来做,维护一个表示父子关系的树形结构,用字典根据tagid来查找对应的树节点。写完后他说我这个方法会被调用多次,你有什么优化方法吗?我说要不在这整个方法外部来个字典?他说希望减少空间使用,可以增加时间复杂度,我说可以在构造树的时候用节点保存文章…

这一段写的不太清楚,感觉我有点微妙地偏离了他要求的点,因为时间问题这个问题没展开。然后他又问了输入数据可能有什么错误,我说要么是重复,要么有环,重复的话将树节点的children属性由list改成set,环的话在dfs中保存访问过的点…时间也到了,就大致说了一下,然后就结束了。

结束时已经超时了几分钟。出来时还舔了一波面试官,要是您觉得可以还麻烦给个过什么的…

3.1.3 算法题

系统中有很多个tag,tag间存在父子关系,如“iOS”和“Android”这两个tag都是“编程”这个tag的孩子。一篇文章会包含多个tag,给一个tag,输出包含这个tag以及其子tag的文章的列表。

  • 输入tag_record,这其中的每一项都是一个 (父tag,子tag) 的二元组

  • 输入tag_article,这其中的每一项都是一个 (文章tag,文章id)的二元组

  • 输入tag,即查找的tag

  • 输出符合的文章名列表

3.1.4 解法

用字典和树,用字典根据tag来查找树中的节点,书中的某个节点对应一个tag,节点保存了tag值,以及children这个属性,children存了所有直接子tag的id。一遍遍历tag_record后就维护了这个有父子关系的树结构,然后就可以很方便地查到输入tag以及它的子tag们,然后和tag_article中的记录比较来查找即可。


IV. 后续

中午HR叫我出去,告知发放口头offer,正式offer争取在四月底之前发放。cjd也是这样,不过HR和他说是两周内,是加急了吗?

然后下午去了趟苏博,人太多要买票回学校时发现没票了,最后搞了半天买汽车票回南京,于是在车上写文章….四点半出发,最后九点多才到南京,长途客车环境很脏,空气也很闷,感觉很难受…所以凡事预则立,对于形成的安排还是早做打算的好。

4月8日,收到了告知即将发放offer的邮件。


4月25日更新,之前问了HR,说部门的Manager没有批,必须和后面的候选人比较,到月底有结果….然而同去的cjd在一周前已经拿到了,可能凉了吧….


5月27日更新,收到了HR的电话,虽然Office365的人满了,但是别的部门有空缺,然后我从waiting list到了offer list,傍晚收到了offer email…

我らは所詮運命の糸によって操られた人形に過ぎん。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×