编程之美：微软技术面试心得 [Beauty of Programming]

　　《编程之美：微软技术面试心得》收集了约60道算法和程序设计题目。作者试图从书中各种有趣的问题出发，引导读者发现问题，分析问题，解决问题，寻找更优的解法。《编程之美：微软技术面试心得》的内容分为下面几个部分：
　　游戏之乐：从游戏和其他有趣问题出发，化繁为简，分析总结。
　　数字之魅：编程的过程实际上就是和数字及字符打交道的过程。这一部分收集了一些好玩的对数字进行处理的题目。
　　结构之法：汇集了常见的对字符串、链表、队列，以及树等进行操作的题目。
　　数学之趣：列举了一些不需要写具体程序的数学问题，锻炼读者的抽象思维能力。书中绝大部分题目都提供了详细的解说。 每道题目后面还有一至两道扩展问题，供读者进一步钻研。书中还回答了读者关于IT业面试，招聘，职业发展的疑问。这《编程之美：微软技术面试心得》的很多题目会出现在IT 行业的各种笔试、面试中，但这《编程之美：微软技术面试心得》更深层的意义在于引导读者思考，和读者共享思考之乐，编程之美。

　　邹欣，现任微软亚洲研究院技术创新组研发主管。他从1996年起在微软Outlook产品团队从事开发工作，2003年到2005年，在微软VisualStudioTeamSystem产品团队负责软件质量管理工具的开发。加入微软前，邹欣从事过商用Unix系统、GPS/GIS软件开发以及软件测试工作。2007年出版了《移山之道——VSTS软件开发指南》一书。他1991年获北京大学计算机软件专业学士学位。1996年获美国WayneStateUniversity(韦恩州立大学)计算机软件专业硕士学位。

　　梦想改变世界，据说编程的人都怀揣着一个改变世界的梦想：编程神奇而充满力量。无数的年轻人投身其中，用梦想和思考改变世界。《编程之美：微软技术面试心得》是来自微软技术人员的杰作，他们和你有同样的梦想。

　　面试杂谈
　　背景
　　每年从金秋九月起，校园里的广告栏中、BBS上的招聘信息就逐渐多了起来。小飞是一名普通高校的应届计算机专业硕士毕业生，他勤奋好学，成绩中上，爱好广泛。看到身边的同学都在准备精美的简历，参加各种各样的招聘会，笔试、面试，他也坐不住了。他在BBS上看了各式各样的“面经”，也挤过招聘会上的人潮，长叹：“行路难，行路难，好工作，今安在？”
　　小飞从网上了解到了有关招聘的各种术语，他整理了一个列表：
　　名词解释
　　面经面试的经历。
　　默拒投了简历，进行了面试，但是公司从此再也没有消息，询问也不回答。
　　Offer公司给学生发的入职邀请。
　　群殴通常指一群人一起参加面试，一般以多对多的形式同时进行，最后总是会有人被不幸淘汰，这一过程就叫做“群殴”。
　　听霸凡校内招聘演讲会都出席旁听的。
　　投霸凡公司招人都投简历的。
　　笔霸凡投出简历都能得到笔试机会的。
　　面霸凡参加笔试都有面试通知的。
　　巨无霸在招聘过程屡屡被拒、机会全无的，江湖人称“巨无霸”！
　　霸王面“霸王面”指没有获得面试资格，却主动找用人单位，要求面试的人，源自吃饭不给钱的“霸王餐”，即“没机会面，创造机会也要面”。
　　小飞获得了一个在微软亚洲研究院实习的机会，在工作中认识了一位有丰富招聘经验的研发经理。他对经理进行了非正式的采访，希望能得到第一手的“内幕”消息。下面就是小飞整理出来的问答。小飞的问题用Q来标注，经理的回答用A标注。
　　典型面试
　　备注：在本文中，应聘者（英文为：candidate,interviewee）指应聘公司职位的学生或其他社会人士；面试者（英文为：interviewer）指公司里进行招聘和面试的人员。
　　Q：经理，您好。我就开门见山，能否分享一下当年您第一次去面试的故事？
　　A：好，大学毕业后，我进入了学校“产业办”开的公司。有一天，一家美国公司（我们姑且叫它H公司）来招人，这是我的第一次面试。那个公司的代表和我寒暄之后，递给我一道题目，题目大意是“写一个函数，返回一个数组中所有元素被第一个元素除的结果”。我当时还问了一些问题，以确保理解无误，所谓clarification是也。那位面试者简单地解释了一下，然后就在电脑上敲敲打打，也不理我了。我想这也不难，如何能显示我的功力呢？于是我就把循环倒着写for(i=n;i>=0;i--)，因为我当时看到一本UNIX书上是这么写的。
　　代码大概是这样的：
　　voidDivArray(int*pArray,intsize)
　　{
　　for(inti=size-1;i>=0;i--)
　　{
　　pArray[i]/=pArray[0];
　　}
　　}
　　写完之后，他看了看就问我，你为什么要这么写循环？如果不这么写可以吗？我说，也可以呀。他问了两遍，如果正着写循环会出现什么问题。我想，能有啥问题？就把循环正着写。噢，原来陷阱在这里！你知道这个陷阱是什么吗？
　　Q：让我想一想，知道了，如果循环从数组的第一个元素开始，并且不用其他变量的话，在循环的第一步，第一个元素就变成了1，然后再用它去除以其他元素，就不符合题目要求了。
　　A：对，同时还有另一个陷阱——看看你是否会检查除数为零的情况，以及对参数的检查，等等。
　　Q：这不是很简单吗？一会儿就写完了。
　　A：面试题大多数不难，但是通过观察应聘者写程序的实际过程，面试者可以看出应聘者的思维、分析、编程能力。面试者一般还会有后面几招留着。比如，如果你要测试刚才写的这个函数，你的测试用例有多少？或者改变一些条件，能否做得出来？
　　Q：很多人说，面试是一个不公平的游戏，因为信息不对称。比如：面试者知道问题的答案，而应聘者不知道，面试者知道今年公司要招几个人，而应聘者不知道。
　　A：但是，应聘者手头有几个Offer，面试者也不知道。应聘者是否喜欢公司提供的职位和薪酬，面试者也不知道。一方面，应聘者在“求”职，另一方面，面试者也在“求”才。面试也是一个增进双方互相了解的有效途径。
　　既然扯到了“信息不对称”，我再讲一个我的故事。当年H公司来我校面试的时候，我对H公司的了解仅限于H公司捐赠给我们计算机系的一个有些过时的小型机系统。我想，这个H公司是不是还有一些新东西？那时候还没有互联网，于是我就托人借了几本原版的Byte杂志来看，那是很厚的一本杂志，非常多的广告，看了半天，夹在杂志中的小广告掉了一地。我只看到杂志对H公司新出的一个桌面管理软件“NewWave”的评价，我琢磨了半天，大概搞懂了这是一个什么东西，市场上还有什么竞争对手，等等。
　　过了两天，面试开始了，对方端坐在沙发里问“你对我们H公司有何了解？”我先说了H公司的小型机系统，然后说，“Bytheway，我还了解了NewWave”。于是我把看到的东西复述了一下。没想到对方坐直了身子，说这个NewWave就是他曾经领导的项目。于是我就根据杂志上的描述问，“您怎么看某某竞争产品？”他很兴奋地跟我谈了NewWave是如何的领先，等等。后来我们又聊了不少相关的东西。
　　最后所有人面试结束之后，我们的领导说，美方觉得我很突出，知道不少东西，包括NewWave，口语也很好。领导就要求我给所有人都介绍一下NewWave，我只好把看到的东西又复述了一次。不久，H公司过来面试的另一个经理不解地对我们领导说：“为什么你们这么多人知道NewWave？”
　　前不久，我在面试的时候问一位同学，“你对微软亚洲研究院有什么了解？”他说，“没啥了解，昨天打电话叫我来面试，我就来了……”对于这样的同学，信息的确是非常不对称，那他吃亏也是难免的了。还有一位在面试中发挥得很不好的同学跟我说，他特地没有做任何准备，因为他想显示他的“rawtalent”……
　　Q：关于Test（测试）的职位，有没有一些典型的题目呢？
　　A：有哇，典型的题目如给你一支笔，让你说说你如何测试——据说要测试12个方面；再比如判断一个三角形的特性（直角、钝角、锐角、等腰）——据说有20多个测试用例，这是要考察大家思考问题的全面程度和逻辑分析能力（测试用例见4.8节“三角形测试用例”）。
　　Q：网上有些非常流行的问题，都号称是从大公司流传出去的，是真的吗？
　　A：对，是有一些题目比较常见，例如“下水道的井盖为什么是圆的”，还有一个问题一度非常流行，据说早期应聘PM（ProgramManager程序经理）职位的应聘者大多曾碰到这个题目：
　　房间里有三盏灯，屋外有三个开关，分别控制这三盏灯，只有进入房间，才能看到哪一个电灯是亮的。请问如何只进入房间一次，就能指明哪一个开关控制哪一个灯？传说在晚上，微软一些会议室的灯忽明忽灭，就是一些还没有搞懂的同事们在实地钻研。
　　Q：我大概了解了Dev/PM/Test这三种工作的典型面试题，那么这些题目的答案别人都知道了，还怎么面试呢？
　　A：对，会有不少题目流传出去，这本来无妨。但是一些人知道答案之后，就开始背诵，或者原封不动地拿它去面试应聘者，忘了“知道答案”和“能做一个好员工”的关系。知道了题目的答案，就能做一个好的开发人员、项目经理，或者销售经理吗？一个极端的情况会是：公司里每一个人都知道哪盏灯是由哪一个开关控制的，如何测试三角形的类别等，但是这个公司真能从此开发出更好的软件吗？
　　一句话：关键不在于答案，而在于思考问题的方法，这也是我们没有“题库”的原因。
　　研发职位的选择
　　Q：微软及很多其他软件公司都有不少研发职位，名称不尽相同，而且还是缩写，能不能讲解一下？
　　A：不少同学对微软公司的各种研发职位（Discipline）并不太了解，我们在面试进行到一半的时候，经常发现一个应聘者其实更适合做其他类型的工作。当然这时我们可以调换面试的方向，但是对应聘者来说总不是一件好事。我刚好在BBS上看到了一篇文章，这篇文章从个人的角度出发，非正式地讲了R&D各个方向的特点，虽然并非完全正确，介绍也不一定全面，但是我们不妨看看。
　　aR：AssistantResearcher，助理研究员，也可以叫研究员助理，主要在“R&D”的“R”这一端，工作是读论文，提想法，被否决后再提想法（如此反复N次），赶在截止时间之前提交论文。aR的想法得到初步验证之后，还要跟其他部门推销自己的想法，争取把想法变成产品。aR的乐趣是能在一个领域中深入研究，发表论文，申请专利，每个专利申请（无论是否批准）都能让自己得一块黑色立方体石头（如图1所示）。好多人的桌面上堆了不少石头，好像他们没什么苦恼。aR有时做的事情和RSDE差不多。aR以后会成长为AssociateResearcher（副研究员）、Researcher（研究员）、高级研究员，等等。总之，最后就成了大家小时候特别梦想做的“科学家”。
　　图1申请专利得到的石头
　　Dev：正式的名称叫SDE（SoftwareDevelopmentEngineer），这个职位和aR相对，是在“R&D”的“D”这一端。他们在一个产品团队中，按照严格的流程开发产品。MS的一个产品发布之后，所有成员会得到一小块铁皮（学名叫“Ship-itAward”，如图2所示），上面写着产品的名字和发布日期，资深的Dev会收集到不少，他们会认真地把这些小铁皮整齐地贴起来，摆在办公桌最高的位置上。Dev的乐不少，这里就不列举了。但是苦也有不少，比如产品的周期有时非常长，过程定义得非常完备（有时不免觉得太完备了）；比如要维护老版本；比如要用比较成熟的技术，而不是用最时髦的东西来开发产品。另外，Dev要负责一个或几个模块，这些模块不一定和最终用户打交道，未必是整个产品的核心模块。做一个好的Dev要生活在代码中，对代码和平台的各种细节要非常熟悉，掌握非常底层的技术，有些人以此为乐，有些人则未必。Dev的职业发展道路很多，如果只想钻研技术，不乐意做很多管理工作，Dev可以成为非常高级的工程师，直到杰出工程师（DistinguishedEngineer）。当然，Dev也可以成长为开发主管（DevLead），开发总经理（DevManager），等等。
　　Test：正式名称是SoftwareDevelopmentEngineerinTes（tSDET），简称为Test或SDET（读作S-DET）。这个职位看似没有Dev和aR酷，但是很有前途，首先中国的同学由于种种原因（不了解，看不起，做不来）不太愿意做这种工作，因此，公司找人非常急迫，相对容易进入。这一职位所谓的苦（也反映了一些人的偏见和误解）从传统意义上说，SDET得等着上家（PM/Dev）给你东西，你才能“测试”。然而，现代软件工程要求TEST从项目一开始就积极参与项目的规划，了解客户需求，制定测试计划，设计测试架构，实现测试自动化，等等。事实上这些都是开发的工作，所以他们叫SDEinTest。而且SDET能更深入地了解产品的各个模块是如何合作，如何在实际情况下被用户使用的。从代码之外理解程序，这是测试之乐。那种“产品发布前一个星期让测试人员来测一下”的情况在微软是不会发生的。而做软件的功能测试，并报告bug的人员被称为SoftwareTestEngineer（STE）。用足球比赛作比喻，Test就是最后一道防线，如果你没有防守好bug，bug就会跑到顾客那里去，因此Test工作非常重要。Test的职业发展和Dev类似，一直到有专门管Test工作的副总裁（VP）。
　　PM：这恐怕是外界误解最多的行当，简而言之，ProgramManager（程序经理）做的是开发和测试之外的所有事情。有些同学会问“我写程序都不用测试，那么除了开发和测试之外还有什么事儿?”在公司里开发商业软件可没有那么简单，比如有10个Dev和5个Test要在一起开发下一个版本的MSNMessenger，那我们到底要做多长时间才能完成？什么事情先做，什么事情后做？项目进行到一半的时候，领导说我们改名叫LiveMessenger吧，那这一改名意味着什么？如何调整进度？最后还剩下两个月的时候，看起来我们的确完不成全部任务，那要怎么办？你又不是Dev和Test的老板，他们凭什么听你的呢？这也是PM的苦。PM的乐看起来在于，他们可以全盘掌控一个产品，广泛了解一个行业，和用户打交道，代表团队出席各种会议，在公司内部的曝光度也比较高。Dev/Test/PM在产品开发中各负其责，互相协助，为共同的目标努力。产品成功发布之后，他们都会得到Ship-it小铁片儿。
　　RSDE：好了，我们最后看看RSDE（ResearchSDE），这是微软亚洲研究院一个比较特殊的队伍。RSDE的乐趣在于可以接触到各种最新的研究成果，并用它来解决挑战性的问题。RSDE的苦在于项目都是V0.1版，而且做得成功的项目大多数会转化（Transfer）到产品组中，由别人推向市场。RSDE在和研究部门合作的时候，就要负起aR和PM（甚至Test）的责任。刚开始，RSDE既没有R的黑石头，又没有D的Ship-it小铁片。RSDE参与的项目有比较大的风险，经常会不如预期，或者会失败（这也是科学研究的特点）。项目失败后，RSDE掩埋了项目的尸体，擦干自己的血迹，又得找新的领域和新的项目。RSDE还有“创新”的任务，这个词人人都会说，但是要做出来就不是那么容易了，全世界有这么多人在琢磨计算机，你能在什么地方做得比其他任何人都更进一步呢？这也是RSDE的乐趣吧。有些同学能力很强，兴趣广泛，但是一时也拿不准自己要深入研究哪一个领域，这时不妨来做RSDE。做得好的RSDE，他们的工作成果推进了研究，又走向了市场，这样就既可以拿到黑石头，又可以拿到Ship-it小铁片儿。我个人认为能有机会做RSDE是很令人自豪的事情，相当于参军当上了特种兵，很好，很强大。
　　Q：看起来真是眼花缭乱……
　　A：总之，每类职位都很重要，都有存在的理由，都有不错的发展前景，都有自己的苦和乐。微软很大，微软中国研发集团（CRD）内部有很多不同的机构和部门，这也意味着有许多机会，让有能力的同学尝试aR、Dev、Test、RSDE、PM的职位。
　　求职攻略之笔试答疑
　　微软中国每年都会举行几次技术笔试，2006年的笔试结束后，主持笔试的经理回答了学生提出的很多问题，小飞把这些问答整理如下（下文的“我们”指的是策划并批改试卷的技术人员）。
　　Q：笔试的难度是不是有些太高了？
　　A：从分数看，参加笔试的同学普遍得分较低，这说明不少同学大大低估了试题的难度，或者说低估了我们对答案的期望。一言以蔽之，我们希望看到接近“职业”水平的答案。
　　Q：为什么有些人笔试得了负分呢？
　　A：这是因为我们对选择题采用了“不做得零分，做错倒扣分”的判卷策略。公司的大部分同事们认为倒扣分是比较有效的甄别方法。而且我们尽量避免非常偏僻的知识点和有争议的答案。
　　Q：你们是不是只选取了其中一些卷子判分？
　　A：我们对大多数的卷子全部判分，每个部门都会抽调不少工程师加班判卷，同学们写的每一行文字都会被看到，对于一些很难读通的程序，我们还会一起分析，不会因为一眼看不懂就给个0分。对于单项题答得非常好的同学，我们会特别标记。像这样的无绝对标准答案的试卷，判卷是相当累人的活儿。至于是否全部判分，会不会把所有分数都全部告知考生，这由各个部门决定。
　　Q：笔试题目全是英语，这究竟是考英语还是考技术？为什么不用中文出题呢？
　　A：微软公司的工作语言是英语，公司在中国的各个部门（研究院，工程院等）都是如此。我们注意在考卷中不用很生僻的词汇，以免影响同学们的发挥。在有些题目中，我们还增加了一些注释，并且有一些小题目注明可以用中文回答。有些考生英语写得不错，起承转合，很像GRE/TOEFL的作文，可惜只有结构，实质内容不多，得分也不多。
　　Q：笔试的题量为什么这么大？很多人根本没有足够的时间做完！
　　A：每次开发新的软件，我们的时间也不够，这就是做软件项目的特点。我们看到很多同学有些大题一个字也没有写，感到很可惜。其实，如果时间安排得当，至少应该每一道题试着回答一些基本问题。我们的很多监考人员也会提示大家注意时间分配。况且，如何在有压力的情况下最有效地分配时间，这也是一个人非常重要的能力。
　　Q：我觉得我回答得不错，每道题目都差不多做出来了，为什么分数很低？
　　A：有必要解释一下，我们的评分标准可能和学校里不一样。比如说有一道程序改错题，正确的回答要纠正全部5个错误。我们的评分标准是：
　　如果5个错误全部改正，满分。
　　如果找到4个错误，只能得一半分。
　　如果只找到3个错误，得1/3分。
　　如果只找到2个错误，得1/4分。
　　我们的评分标准要拉开“满分”和其他“差不多”的答案的距离。如果你每一道题目都“差不多”，那你的总分将是全部分数的一半以下。
　　Q：我会C#、VB.NET，为什么微软的笔试偏偏要求用C语言答题？
　　A：对于微软的工程师来说，C语言是基本功。
　　Q：为什么我投一个技术支持的职位也要用这么难的题来折磨我？
　　A：因为投同一个位置的人太多了。大家的简历都很优秀，所以只好用笔试来进行一次筛选。
　　Q：考题包罗万象，甚至包括我不熟悉的知识领域，难道微软需要的是“全才”吗？
　　A：我们的考试是想考察在实战中的基本知识和基本技能。考试不是万能的，笔试总分很高的同学，也有在面试中表现得很不如人意的。如果有人在某些题目中有优异的表现，即使总分不高，我们也会考虑的。
　　Q：我申请的职位比较特别，自己的专长没有能够显露，通过这样的一个考试不能真实反映出个人特点，有什么办法呢？
　　A：这一点我们同意，我们考试的主要目的是把所有考生中的优秀学生选出，并安排他们进入下一轮。至于在某一方面有专长的同学，他们应该直接和有关部门联系，或者我们的有关部门应该直接联系这些同学，例如在某些研究领域发表过高水平文章的同学。
　　Q：笔试通不通过是不是还有些运气成分在里面？
　　A：当然有，大家也都知道，一次笔试不能够反映一个人完全的、真实的水平。同学们寒窗十多年，经历了无数闭卷考试，作为一个过来人，我觉得职业生涯和人生不是一次两小时的闭卷考试能决定的，希望这样的笔试是大家人生中倒数第几次的闭卷考试之一。人生是更加开阔、充满更多变数的开卷考试。不管是开卷、闭卷，都是一分耕耘，一分收获。
　　求职攻略之决胜面试
　　经历了笔试、电话面试之后，许多同学接到了微软公司的邀请——来公司进行面对面的考察。
　　Q：既然微软这么重视实际的能力，每一个人都会经过几轮面试的考察，在学校时的学习成绩是否就不重要了？
　　A：也不一定。同样，关键不是在于静态的成绩，而是通过成绩了解成绩取得的过程，了解一个人的特质。曾经有一个面试者详细询问了一个应聘者在学校里的各种表现，最后在面试报告中写道：“我详细询问了她从中学到大学、研究生的情况，她在学校里没有一科的成绩是非常拔尖的，也没有太坏的成绩。她从来没有做过出格的事情，如逃课、自己写一些程序、打工等。我在她身上看不到对卓越的追求，也没有看到她有实现自身价值的想法……所以我认为本公司不应该雇用她。”
　　Q：虽然我没什么想法，但我觉得微软太有名了，我也不用多想了，我就是要进这样的公司，你叫我干什么都可以！
　　A：我们恰恰不太需要没什么想法的人，这也许和企业文化有一些关系。在中国一些企业的文化中，往往是领导安排你做什么，你就做什么。在微软，我们认为每个人都是独立的个体，我们希望雇员能够“在其位，谋其事”，同时能考虑到自己三五年后的发展，并且能自己制定计划去实现事业目标，这是公司的文化。
　　Q：面试的时候要穿什么衣服？
　　A：在没有特别规定的情况下，穿你觉得舒服的衣服就行。我们看到不少应聘者穿着明显不舒服的西装来面试，这样不会给自己加分，当然也不会减分。但是自己太不舒服，会影响发挥。
　　Q：不舒服没关系，只要你们公司觉得舒服，我就舒服。
　　A：我们刚刚说过，微软更看重的是“你”是否觉得舒服，“你”要做什么，以及“你”有什么创意。
　　Q：有没有在面试中作弊的呢？
　　A：说起来，还真有。有一天，我在微软外面的一个中餐馆吃晚饭，这个餐馆很小，大家坐得比较挤，我不得不听到邻座的高谈阔论。原来是一个刚刚在微软面试过的学生在和几个同学聚餐，他很兴奋地谈着当天面试的经历——
　　“他问了那个在链表中找回路的问题了吗？”
　　“问了，我假装思考了一下，稍稍试了试别的解法，然后就把你说的那个解法讲了出来……”
　　对于这种人，我们内部叫“Poser”——摆姿势的人。如果你在面试时恰好被问到了一道知道答案的题目，你可以向面试者提出来。摆姿势的话，万一被戳破，会比较难堪。既然你已经花了时间了解解法，不妨和面试者深入地探讨一下。
　　Q：大家发表在BBS上的面经，公司看不看？
　　A：公司的一些员工也在看，有一次，HR在某BBS上看到一篇很详细的面经，文笔生动，此文章从他看到HRJJ的那一刻写起，直到做了什么题目、怎么做的、说了什么话、最后如何走出了公司大门他都做了详细记录。从描述上看，我们很容易就能推断出这是哪一位应聘者。他似乎发挥得很不错，可惜他忘了在开始面试的时候，HRJJ给他讲的，他也签了自己大名的保密协定。对于这样的同学，我们只能遗憾地放弃了。
　　Q：整个面试过程中我觉得自己答得很不错了，面试者指出的问题我大部分都能回答出来，为什么我还是没有通过？
　　A：一个原因是有比你更厉害的应聘者，另一个大家容易忽略的原因是，应聘者和面试者对于“不错”的定义是不一样的（参见对笔试问题的回答）。
　　对于在校学生，觉得自己写的程序，涂涂改改，大概逻辑能通过就行了，面试者指出的问题能答出来一些就行了。但是对于将来的公司员工，我们要考察：程序设计的思路如何？编程风格如何？细节是否考虑到？程序是否有内存泄露？是否采用了最优算法？是否能对程序进行修改以满足不断变化的需求？是否能举一反三？另外，除了专业技巧，我们在面试中还会考察应聘者的职业技巧（professionalskills,也有人称为softskills）。这个人的交流能力、合作能力如何，对自己的评价和期望是什么？在有压力的情况下，能否发挥水平？是否追求卓越？这些“非技术”的因素相当重要。
　　Q：很多有名的企业面试只要求谈谈就可以了，为什么微软一定要写代码？
　　A：我们的绝大部分工作，都是通过代码而来，很大一部分的问题，也是由代码所导致的。所以我们不能不重视写代码这件事。当然有很多其他工作不需要写代码，但这不在我们的讨论范围内。
　　…………
　　完整前言请见本书。

面试杂谈XVII
第1章游戏之乐——游戏中碰到的题目1
1.1让CPU占用率曲线听你指挥4
1.2中国象棋将帅问题13
1.3一摞烙饼的排序19
1.4买书问题29
1.5快速找出故障机器38
1.6饮料供货43
1.7光影切割问题48
1.8小飞的电梯调度算法53
1.9高效率地安排见面会57
1.10双线程高效下载62
1.11NIM（1）一排石头的游戏67
1.12NIM（2）“拈”游戏分析70
1.13NIM（3）两堆石头的游戏75
1.14连连看游戏设计88
1.15构造数独93
1.1624点游戏100
1.17俄罗斯方块游戏108
1.18挖雷游戏115
第2章数字之魅——数字中的技巧117
2.1求二进制数中1的个数119
2.2不要被阶乘吓倒125
2.3寻找发帖“水王”129
2.41的数目132
2.5寻找最大的K个数139
2.6精确表达浮点数147
2.7最大公约数问题150
2.8找符合条件的整数155
2.9斐波那契（Fibonacci）数列160
2.10寻找数组中的最大值和最小值165
2.11寻找最近点对170
2.12快速寻找满足条件的两个数176
2.13子数组的最大乘积180
2.14求数组的子数组之和的最大值183
2.15子数组之和的最大值（二维）189
2.16求数组中最长递增子序列194
2.17数组循环移位199
2.18数组分割202
2.19区间重合判断205
2.20程序理解和时间分析209
2.21只考加法的面试题211
第3章结构之法——字符串及链表的探索213
3.1字符串移位包含的问题215
3.2电话号码对应英语单词218
3.3计算字符串的相似度223
3.4从无头单链表中删除节点226
3.5最短摘要的生成229
3.6编程判断两个链表是否相交233
3.7队列中取最大值操作问题236
3.8求二叉树中节点的最大距离241
3.9重建二叉树246
3.10分层遍历二叉树252
3.11程序改错258
第4章数学之趣——数学游戏的乐趣263
4.1金刚坐飞机问题265
4.2瓷砖覆盖地板269
4.3买票找零272
4.4点是否在三角形内276
4.5磁带文件存放优化281
4.6桶中取黑白球284
4.7蚂蚁爬杆288
4.8三角形测试用例292
4.9数独知多少296
4.10数字哑谜和回文303
4.11挖雷游戏的概率310
索引311
创作后记315