美国微软总部SDET实习面经

来美留学已经过去两个多月了，生活一直马不停蹄的过着，曾经就听说过美国的大学作业极多，来了之后发现比我想象中还多。在来美之前知道了一亩三分地论坛，是我所见过的最专注计算机专业及留学和面试的地方，看了上面几篇关于技术这条路怎么走的文章，加上本人工作了几年，如醍醐灌顶，也更加了解面试的本质。最早从论坛里知道像微软谷歌这样的大公司在秋季一开学不多久就开始招聘暑期实习，不了解这个信息的人大概做梦都想不到（消息灵通的重要性啊！）。这两个月里，由于时间实在太紧，退了一门课剩下两门，专心准备面试，leetcode online judge上的题目一口气做了四十多道，代码越写越快，能看到自己的进步是再开心不过的事了。

          先说说当天面试的情形，总共四轮，每轮一小时，分别是test lead， dev lead， test lead 和最后一轮test manager，manager是比lead高一级的。四轮之后当天就得到结果说被录取了，激动的跟面试官说“I wanna shout”。我面试的情况是，前两轮主要是技术面，后两轮没有问技术题，只有behavior question和聊项目聊见解。

          本文只谈技术面，聊项目谈想法小弟不敢妄议，毕竟做的项目都不同，很难有通法，不可能你所有的项目都让面试官有胃口，这个是肯定的，退一步讲，也只能看你怎么挑他感兴趣的说了，这里我就不班门弄斧了。

          说句实话，SDET的技术面真的是简单到一种境界，我曾经一度因为看不懂动态规划的算法题而焦虑万分，但事实是SDET面试其实走向了另外一条路：考察思维严密性。技术面第一题，让从一个链表里删除重复的元素，原话即是如此，简单吧？且慢，得分点来了，先问面试官“你能解释一下，你说的duplicate是什么意思？”，其实大多数人用常识想都知道八成是节点的值相等，结果也跟我想的一样。但是，考官不会这么想，如果你直接jump to the code，那你就危险了，如果你的假设是错误的，基本一条腿也就在悬崖外面了。这些是在我面试之前就想到了，所以十分注意，在技术面之后的提问环节，我的想法也得到了验证，我问面试官我的performance如何，他们告诉我，很多人都是一听题目很快就开始想怎么把代码写出来，写着写着发现错了，又倒退回来重新想，这样特别不好。 

           其实微软在它的面试tip里就明确的写道“Don't make assumption”，在没完全弄清题目和可能存在的trick之前就开始想怎么实现，是面试一大忌。这个道理是在我面试Bloomberg第一轮电面被拒之后幡然醒悟的。当时的情况是面试官让我判断两个字符串是否是anagram，我第一次听这个词，所以不知道他说的是什么，当他给我解释了一遍之后，我以为我懂了，以我这几个月看过的算法题，这太简单了，于是噼里啪啦说完了，结果他说anagram不是这个意思，是什么什么意思，我打开词典赶紧查了一下，是回文构词法，也怪这坑爹的词典，判断回文字符串又是多么简单的题目，又噼里啪啦一阵，结果他又告诉我不是这个意思，其实就是字符的任意排列，我当时听了之后，几乎是条件反射似的就想到ascii数组解这题，事实确实我做对了，而且后来我写的代码也是bug free的。面完之后，我还一度以为理解错题没什么大不了，甚至觉得可能这说明你懂得很多。但后来发现“莫名其妙”被拒了之后，在cracking in the interview 这本书里也找到了类似的提醒，不要在interview的时候rush，步步为营比速度更重要；不要做任何假设，无论是tester还是engineer。

           在题目开始之前，我又问了个问题，1.对时间和空间复杂度有没有什么要求？（这个问题的目的，是我想到用HashSet了，但我想这尼玛也太简单了，必须得问）他的回答是，暂且不考虑这个问题，于是我就放心大胆的提到了HashSet，他说OK。之后我就严丝合缝的把代码写完了。（bug free这个确实要多练，平时千万不要借助IDE的查错功能，在纸上写最好，这样在白板上写的时候才不会感到不自在。）本以为这只是个naive solution，他会让我再优化，没想到就直接转入test case的设计了。这大概就是SDET 和SDE招聘的区别吧，侧重点不同。test case的设计有一个非常重要的概念，equivalence class（等价类），这要感谢面试前看过一位仁兄的面经。test case的设计是有规律的，不然你如何用有穷的case 测试无穷的input，后来事实又印证了我的想法。面试官听到我设计test case时谈到equivalence class之后（其实我也只是面试前抱佛脚复习了一下等价类，设计test case也没有那么容易，写test case的时候还是心有些虚），和我讨论起什么是等价类，我就拿了最经典的测试计算器的例子说事，于是这关就算是过了。

           第二轮的技术面，在一长串的谈天之后才开始，顺便说一句，微软面试聊天的成分真的很多，尤其当面试官说一些与面试关系不是特别大的事，我至今也猜不透其本意到底是推销微软还是考察你的反应，maybe both吧。第二题同样没什么难度，实现int atoi(char * str)函数。我想说的不是char - ‘0’ = int， 而是这题的真正考察点在于你怎么把这个函数所有的异常输入都考虑进去，才是得分点。考虑如下几个问题：1. 如果输入不是数字？ 2.如果有小数点怎么办？ 3. 如果部分是数字，部分不是数字? 4. 可能是负数吗？  5. 如果字符串超长超过了int的上界？当把这些问题都抛给面试官待他一一解答之后，你才能开始编程。事实上，当你问完这些问题，很有可能面试官都不需要你写程序了，因为这就是他的考点啊！都被你看透了就没什么好写的了。还有一道题是打印一个字符串数组的anagram，细节我就不详细讲了，这道题有很多种解法，时间空间复杂度可以差很多，有空间换时间，时间换空间，我事先也是问过了这方面有没有要求之前才开始说的思路，我说判断anagram最基本的思路就是按字母排序后比较相等，如果不要求空间复杂度就用哈希表包着链表，这样时间复杂度是线性的，如果不能使用额外空间的话，那也只能反复遍历数组，把每次找到了anagram的字符串标记一个flag，下次就不再遍历它，直到最后全部打上flag为止。这样的时间复杂度最坏情况也就是O（n^2），那就是一个都不是anagram的时候，所以平均情况应该比这好很多。

          由于还有几年的工作经验，我明白projects耗时的环节很有可能不在主功能上，至少经常发生在大家没想到的事上，因为主功能在项目开始之前大家都会十分积极的开始想，在讨论项目可行性时就把实现方案给出来了。事实上耗时的都是那些开始没想到的异常或者边界条件会把人整的崩溃，按下葫芦浮起瓢是最常见的情况。所以面试考察一个人思维的完备性是非常合情合理的。

          好久没写文章了，写了这么一大堆，中心思想无非是面试的坑是很多的，即使这种没什么特别深算法的面试，也要仔仔细细的走完全过程。