浏览同学的Spaces，发现这个太有用了，记录下来，呵呵……
引用
[原创]微软亚洲研究院电话面试面经！
今天下了班，回到住的地方，正在做创业课的作业，突然接到微软亚洲研究院的电话，说是要电话面试。我一看表，都快9点了，这么晚了，那帮人居然还有心情在公司里搞电话面试，心想面就面吧，无所谓。他就让我告诉他一个座机号码，可我这没座机，就用手机聊吧，反正也没怎么用手机打过电话，心里怪觉得对不起联通的。。。。。
他先问我对c和c++熟不熟，我说熟，尤其是对c很熟，他就问我第一个问题，把模板和虚函数进行对比，让我说说相同点和不同点。我心里就想，模板和虚函数能有什么相同点，就解释一下二者的概念算了，于是就给他解释什么是模板，模板的用途，就拿模板链表的例子解释用模板写函数的优势（大三时，学数据结构用的教材就是C++版的，书上的所有数据结构都是用模板写的，对我来说，这还不算难），解释完模板就解释什么是虚函数（大家注意了，虚函数的概念很重要，因为多态的核心是虚函数，而多态是OO和面向过程的语言最本质的区别，一定要搞懂，我面试了这么多次，好几次都要求解释什么是虚函数），也拿那个图形基类和draw方法的例子（C++编程思想第一卷上解释虚函数的经典例子，大三上C++课时用的就是这本教材，现在居然全用上了）来举例。
他又问我对设计模式熟不熟，我只是了解设计模式，并不熟，就说不是很熟，他就让我找一种设计模式，解释一下，我心想，幸亏暑假开了设计模式这门课时，我听了一下，要不然，这个题肯定答不上来，龚老师的课讲的真是不错。
我先是说解释代理模式，想了一下，发现自己把代理模式给忘了，解释不出来，就说换一个，他就接着问为什么会有设计模式，设计模式是解决设计的还是解决编码的，我就说，设计模式当然是解决设计问题的。设计模式是人们实践的结果，人们再长期的实践中，发现很多问题都有共同点，时间久了，就形成了解决这些问题的统一办法，这就是设计模式，是人们对问题抽象的结果。他就接着问，那为什么这些问题会有共同点？这让我怎么回答，他们就是有共同点吗！我就说很多问题，看起来是不相关的，其实是有共同点的，只要抽象就可以找到共同点。这时正好想起MVC模式，这可是经典模式，就拿它做例子，说比如MVC模式，只要是涉及到元素显示问题的，都可以用MVC模式解决。他就继续问我，MVC模式的好处在哪里？我就说，MVC的优势就在于它把元素的存储与管理和元素如何显示恰当的分开，也就是说MVC使元素的显示、存储与其显示之间的界面很明显，他就说既然MVC做到了模块的低耦合性，就问我在模块耦合性方面有没有经验，我说有，我编了很多代码，强烈的感受到，工程越大，保持模块间的低耦合性就越重要。
问题答完后，他就问我对数据库熟不熟，其实我数据库很差，于是我就说不是很精通，他就说问我简单的问题，就是如果有下面的SQL语句：
select a，b，c
from database
where id＝5
执行起来顺序是怎样的，这个确实不难，我就告诉他，先是找到数据库database，再从中找到 id＝5的元组，再进行select操作，总之执行顺序就是先from，再where，再select。回答完毕后，他就接着问，那数据库是怎么从查找到id＝5的元组的？这就不好说了，我就说，数据库是通过一定的方式存储数据的，查找的过程是通过搜索得到的，比如用二分搜索等方法得到结果，我一提到二分搜索，他就问我那二分搜索的复杂度是多少？我说是log（n），最快了，没有比这个更快的了，他就问我，“那你想想有没有更快的方法？”，我当时没有想到更快的方法，就说没了，他就又问我那存储元素的时候如何索引？我这才想到如果用散列表的话，只要O(1)就可以查到，更快，于是回答可以用散列表存储，他就再问，那散列表的复杂度是多少？我说是O(1)，更快，如果出现碰撞，并且散列表是用链表的方法解决问题的话，可能时间会稍微长些，但复杂度还是O(1)。提到碰撞，他就接着问，如说元素很多的话碰撞几率就变得很大，那么散列表的优势将不明显，如何解决这个问题？这个问题我以前从来没遇到过，这可难到我了，想了一会儿就说可不可以扩大散列表的容量？，后来我觉得这样做不行，又改口说不行，不能简单的扩大散列表的容量。他见我改口，就追问我为什么不能扩大散列表的容量？我就解释说，假如原来的散列表容量是1001，后来改为2001，那样的话散列计算式就会改变。这样当你用散列表做查询时，就不知道该用哪个散列计算式计算。因为作索引时，有的元素是用1001那个式子计算的，有的是用2001那个式子计算的。他就说那你是认为，当数据量很大时，散列表就不适合作索引了？当然不是，我赶紧回答：不是的，散列表可以用于大容量数据的索引，上面提到的问题肯定有解决办法，只不过我还没想出来，让我再想想。又想了一会儿，我就告诉他一个折中方案，也是扩大散列表的容量，但是后来用2001的散列计算式索引的元素都要作个记录，就是记录哪个元素是用2001的式子计算的，以后查询时先查询一下元素是不是用2001那个式子计算的，然后根据结果选择合适的散列计算式进行计算。听到我的答案，他就说那样的话查询时就要多查询一次，就让我想一下可不可以重新生成一个大的散列表，然后把原来的散列表中的元素移植到新的散列表中，我当时就说，这个恐怕不行吧？元素很多时，移植的代价会很高，这个恐怕不行，复杂度会很高，他就问我那复杂度具体会是多少？让我再想一下，我想，假如原来的有n个元素，散列表的复杂度是O(1)，那么就算移植，复杂度也不过O(n)，不算高，于是又赶紧改口，说复杂度不高，可以这样做。
这个问题总算问完了，他就说再问我一个简单的算术题，不用笔就可以算出来。就是：有8个球，外观一样，但有一个球比其他的球中，有一个天平，只能秤出哪边重，让我用这个天平最少秤几次可以把那个重的秤出来，这个题，听了1000遍了，可是我没把结果记住！晕啊，于是就这样回答他，首先，三次肯定可以秤出来，就是先4个一组，秤一次，把重的那一组拿出来，再两个分成一组，秤一次，再把重的那一组拿出来，分成两组，再秤一次。他说三次是可以，但是我问的是最少几次，2次可不可以？我说，让我想以下，这一想，还真想出来了，先拿两个出来，把剩下六个分成两组在天平上秤，再从重的那一个重拿一个出来，把上下的两个放到天平上秤，这样就可以两次秤出来。结果我又说，让我想一下一次可不可以秤出来，想了一会儿，想不出来，就说，不行，一次秤不出来，他就说那你觉得一次秤出来的概率是多少？这可难住我了，一是没有想到这个题还有这种问发，另外就是我早把概率忘光了！我先说，可能是64分之一，或是56分之一，后来又改口说是8分之一，因为第一次取到重球的几率是8分之一，第二次的几率是7分之一，又好像还是8分之一，两次取球的过程，好像应该相乘，好像又不应该相乘，早就忘光概率了。他说不对，就让我从总的取球次数，和取出又重球的次数方面想，我就说，从8个球中取两个球的取法是C82，可是我却忘了C82是如何计算的！p82，就是8×7，C82我给忘了！他就问我C32是多少，不用计算，我也知道是3，后来在它的循循善诱下（这哪里是循循善诱，简直就是调戏！），终于想到了C82就是P82除上2的阶乘，是28，这样取出两个球，其中有一个球是重的方法总共有7种，所以几率就是7/28，4分之一，总算答上来了。
谁知他还抓住这个题不放，问我第一次回答这个题的那种方法应该如何算，在他又是循循善诱（真是有耐心）下，我终于想到，第一次取出重球，第二次取出普通球的概率是1/8×1，是8分之一，第一次取出普通球，第二次取出重球的概率是7/8×1/7，还是八分之一，两次相加仍是四分之一，终于答出来了，心想该结束了吧。他又说，这些概率是初中的内容，你是不是都忘了？我赶紧说，这些是高中的内容，是高三的，不是初中的。他笑笑问我数学怎么样，我说，高中时不错，数一数二，大学时就是中等了，因为我大学前两年学的不是计算机，对数学要求不高，他问我，那我如何弥补，我就说，学啊，补数学，还说其实我读研究生的第一个学期，还专门买了一套英文版的微积分，看了一遍，但是没深入的看。我还举了一个例子，说我有一个同学的数学很强，国际数学建模大赛上都拿过奖，我比不上他，但是我很勤奋。终于，他说，面试就到这了，问我有什么问题，我就问，如果我去你那的话，主要作什么方面的工作？他说是web方面的。就到这了，终于结束。
面试中间我的手机没电，断了线，我赶紧换了块电池，按号码打过去，是微软亚洲研究院的总机，心想，完了，没戏了，后来他又打了过来，这才松了一口气，前前后后差不多有一个小时。唉，累死我了。
