创作后记

邹欣

现任微软亚洲研究院技术创新组研发主管。他从1996年至2003年在微软Outlook产品团队从事开发工作，2003年至2005年，在微软Visual Studio Team System产品团队负责软件质量管理工具的开发。加入微软前，邹欣从事过商用Unix系统、GPS/GIS软件开发以及软件测试工作。他在2007年出版了《移山之道——VSTS软件开发指南》一书。

于1991年获北京大学计算机软件专业学士学位。1996年获美国Wayne State University（韦恩州立大学）计算机软件专业硕士学位。

春节长假的最后一天晚上，我把最后一批修改过的稿子通过电子邮件发给了编辑们，当时觉得心情非常轻松——终于RTM（Release To Manufacturer）了。

除了对其他作者、审阅者、编辑们的再次感谢，我不想多说什么，倒是想贴一幅图展示这一本书的创作过程，图中的两条曲线，一条是我和其他作者交流的E-mail数量；另一条则是我和编辑们就这本书交流的E-mail通信数量。

还有一条曲线是我们在Team Foundation Server上修改的次数，但是线太多了觉得不美。这两条足以说明问题。

谚语说，一幅图胜过一千句话，不同的人有不同的一千句话来解读这些曲线。我只想说明一下为什么曲线在2007年10月左右会有大幅度的下降。一个原因是，那时候，我们写了不少题目，自己觉得该写的都写了，但是题目中很难看出来“美”，大家得喘口气，我也不能继续发邮件去“drive”其他人。另一个原因是，编辑们也看出来书稿的质量并不像原来想象的那么好，有人建议干脆去掉“美”，封面直书“面试心得”或“我是如何打入微软的”即可——市面上质量一般的面试书也卖得很好，我们不如也乘势赚一笔算了。我们原定11月份出版，如果这时，大家扛不住，稀里糊涂出了书，我想这一定不是一件美事。这的确是项目比较黑暗的时期，后来责任编辑之一也离开了。

后来呢？从图上可以看出来，我们经过10月份的喘息后，增加了人手，奔向了一个新的里程碑（milestone），大家针对一些难题紧咬不放，从办公桌讨论到餐桌上；砍掉一些不够“美”的题目；请了三位同事给我们专门挑错；我的“drive”也升级到“hard drive”——以请吃午饭为名，和每一位作者逐句复审，如果E-mail没有回复，就打电话……

当年背诵的古文里有“骐骥一跃，不能十步，驽马十驾，功在不舍”这样的话，也许开始大家都自以为是骐骥，蹦跶蹦跶，搜罗一些题目，辅以伪代码，并掺杂若干幽默，就大功告成。没想到后来才发现我们都是一群驽马，一匹马蹦跶不出什么名堂，要团结协作，长途跋涉，中途还要歇息几次，方能到达目的地，关键在于“功在不舍”这一句话。

软件开发有一个阶段很少有人提及，叫“death march”。就像军队攻城，一队队士兵冒着炮火出击，伤亡无数，但是敌人还是那么强大，火力看似依旧那么猛，但是指挥官还是下令新的士兵继续出发，开始新的march。在软件开发中，这个阶段就是你每天都加班写程序，改bug，但是bug不见少，第二天，第三天，下一周，下一个月……还是这样。经过“death march”，最后，有些军队破城而入；最后，有些软件成功发布；最后，这书到底这么样，还得读者说了算——我相信群众。

刘铁锋

湖北仙桃人。2006年毕业于华中科技大学机械科学学院，获工业工程硕士学位。现就职于微软亚洲研究院搜索技术中心，从事搜索引擎软件开发工作。他醉心技术，以抽丝剥茧、揪出问题为平生快事。工作之余，以读书自娱为乐，然杂而不精。相信天道酬勤，笨鸟终能先飞。

实在很难相信，我这个不容易坚持持续做完且做好一件事情的人，竟然坚持花了近一年的时间和大家一起创作出了一本书。

历经重重修改、审阅，这本《编程之美——微软技术面试心得》的修改已经接近了尾声。

这一年的时间，也正是我到微软工作的第一年，刚刚经历了从一个求职者、软件工程师到面试者的角色转变。而这个过程，也伴随了整本书的出版过程。

作为一个曾经的求职者，当时自己能够做的，就是搜集和整理能够在网络上搜刮到的所有题目。算法题、智力题以及各种面经。把各种题目做到让自己条件反射为止。而这本书的创作过程之初，也同样如此。把自己经历过的、网络上看到的、同事们讨论过的题目统统都拿过来，进行分类和研究，作为撰写书籍的原材料。虽然美中不足的是有些题目的分类略微牵强，但是，从分类的结果来看，也基本上代表了微软面试会经常探测面试者的几个方面：Problem Solving，Coding Skills，Algorithm Analysis Skills。

而作为一个软件工程师，编写程序是本职工作。每个新人必受的打击，就是Code Review。在这个Review的过程中，你能够体会到多年的编程经验表现在什么地方。你会发现Review之后，就算是短短的几十行代码可能会一行都不能用。的确如此，当你的产品发布出去之后，你希望它能够稳定使用，不出任何问题（当然，这是理想情况）。你会发现需要考虑的，实在有太多的问题。

在完成了第一个项目之后，回过头来再看看同事们的解答，以及中间附上的代码，就能够清楚地从自己写的代码中看出编程的功力。自己工程的实践、同事们在Code Review过程中对代码提出的种种质疑，以及处理种种程序在实际运行中碰到的问题，也为我积累了更多的思考，并且会更加了解应该通过题目给读者传递怎样的信息。

而当自己开始面试求职者的时候，还是有更多的收获。在面试的高峰期，一周之内大概会有3个电话面试，3个On Site面试。在HR统计的结果中，我手上的通过率不到20％。在面试的过程中，我也会直接拿书稿中的题目来挑战面试者，希望能够看到有精彩的解法。同时，也是对题目的一个有益的补充。不仅如此，怎样的面试题目才能挑选出一个合格的软件工程师？反过来，换到读者的角度，这个问题应该是，微软到底会出怎样的题目来甄别求职者？

以我个人的经验来看，分析问题的方法更加重要。这也是在书中努力想传达给读者的重要信息。

从分析的套路上来说，作者们也都是通过先提供一个简单的方法，然后试图找出一个更好的办法，这样不断地挑战自己的智力来分析题目。

而这个过程，也正是面试者和求职者的互动过程。这种套路也是通过解每一道题目想教会读者如何分析问题的一个套路。

正所谓“无招胜有招”、“万变不离其宗”。题目只是一个表象，面试的过程中希望看到的是面试者真正的实力。

所以，也真心盼望读者能够在阅读本书的过程中，体会到面试者到底想通过题目考察出哪些方面的能力。

在本书的创作过程中，我从邹欣老师身上学到了不少东西。他也让我明白了一个道理：不怕慢，就怕站。方向确定后，只要天天有行动，最终一定能够有结果。计划一定是要以执行为依托的。

限于作者们的水平，每一道题目的解答绝非尽善尽美，甚至还会有潜在的bug。也切盼能够得到读者的反馈。

莫瑜

2006年毕业于中山大学计算机科学系，获硕士学位。他热爱编程，曾多次参加ACM程序比赛，现为微软亚洲研究院搜索技术中心软件开发工程师。

转眼一年过去了，《编程之美——微软技术面试心得》就要出版了。

回想大家一起合作的日子，我自己学到了很多东西。当初，看到邹欣老师的倡议，觉得创作这样的一本书还是挺有意义的，并且抱着跟其他优秀同事学习的想法，有幸成为了一位“作者”。其实，我觉得把我的名字挂在书上，有点尸位素餐的感觉。在编写《编程之美——微软技术面试心得》的过程中，我贡献甚微。相反，伴随着我从学生到软件开发工程师的角色转变，其他作者无形中给我上了一堂课。

最开始，我们收集题目，大家一起讨论改进各个问题的解法，然后去掉一些面试时并不合适的问题，手头也有了不少草稿。我一度认为，一切进展得都很“顺利”，应该很快就“大功告成”了。但很快地，我发现这些草稿离“书”的要求还很远。后来，事实也证明后面的工作才是最重要的。其实我是一个不太会表达的人，写作文对我来说从来都是一件头痛的事情（写这篇文章的时候也不例外）。刚开始，我总是三言两语就写完自己的想法，有时甚至是不成熟的想法，然后就以为差不多了。相反，其他同事在这方面就做得很好，更懂得如何去把一个问题描述清楚，写得有条理、通俗易懂。

如何进行版本维护？如何保证写作风格尽可能地统一？如何把一件看似简单的事情做好？这些问题，我压根就没有考虑过。

类似地，在软件开发方面，可能也有不少跟我一样的微软新员工，觉得自己大大小小的程序也写了一些，软件开发也就是写写几行程序，没太大问题。以前自己写程序的时候，可以随意地按自己喜欢的方式做，不会考虑变量名的命名，也不用考虑函数的接口，反正整个程序都在自己心里。这就有点像是我们自己随意记录的草稿和笔记，也只是给自己看，不考虑会有其他人阅读。因为这草稿和笔记别人根本看不明白。这样想来，做软件开发和写一本书还真是有很多相似之处。写书，希望相关的读者能读懂；而写软件也希望能让用户用的明白。一个团队合作开发软件，就像一伙人一起写一本书。因为你的代码需要维护，因为多人合作开发，而不是“单兵作战”，如何设计和定义模块接口，管理维护代码？我们再也难以做到整个程序都在自己的掌控之中。还有，如何写可靠安全的代码呢……这些是软件开发中经常碰到的问题，也是面试时应聘者容易忽略的问题。

当年，我被微软面试的时候，曾碰到一个问题：完成下面归并排序函数，将有序数组arrX和arrY归并排序的结果存到arrZ数组中。

Bool MergeSort(int^＊ arrX, int nX, int^＊ arrY, int nY, int^＊ arrZ, int nZ)

在面试房间的白板上，我很快就把整个程序写完了，然后开始想后面有些什么难题呢？但，面试者简单的几句话就让我无言以对——“你有没有考虑数组指针arrX和arrY是否为空？它们的分配空间是否可能重叠？”那时，我还认为这些太苛刻了吧。

但在实际软件开发的时候，若疏忽了这些细节，可能会带来潜在的bug。以前，我觉得一个出错的可能性为百万分之一的程序尚可忍受，但在类似搜索引擎这种每天被大量用户使用的软件系统上，这样的错误却是无法容忍的。

对我个人来说，参与创作《编程之美——微软技术面试心得》，给了我与其他同事合作及一起学习的机会。虽然读者们不能像我一样亲历写书过程中受到的启发，但相信读者们也可以从书中或难或易的问题里得到一些启发。一本书的出版，就像一个新的软件系统的发布和上线。出版（发布）前的心情总是很复杂，既兴奋却多少也有些担心。兴奋，是因为我们的努力可能会带给读者帮助，希望大家能从中得到一些启发，即使在面试的时候并不一定会碰到这些具体的问题；担心，则当然是害怕由于我们的疏忽，时间和水平的有限而存在潜在的bug，希望读者们多指正。

李东

重庆大学软件学院研究生，微软亚洲研究院实习生。

他来自闽东屏南县路下乡方圆村，喜爱足球，认为足球与编程都是富有激情的。他在写书之余，参加了七个公司的面试，有五个公司向他发出了邀请，目前他正在考虑中。

2008年春，我们创作的《编程之美——微软技术面试心得》即将出版了！

回想《编程之美——微软技术面试心得》的诞生和成长，感慨颇多。应该是在2007年4月的某一天，与邹老师一起吃饭的时候，就听邹老师说想编写一本关于编程算法方面的书。其实在此之前，邹老师隔三差五就会发些算法题Challenge我们全体TTG的Intern，大家的热情也很高涨，其中有道控制CPU占用率曲线的题，据说邹老师用此题“干掉了”不少人。有实习生经过努力，用几行程序就画出了很平滑、很美的正弦曲线。

几天后，邹老师发信问我和张晓是否愿意加入创作小组，我大喜，生平第一次能搭上写书的边，而且秋季就要找工作了，应该很能锻炼自己，于是欣然答应。小组很快成立起来了，铁锋负责收集题目，莫瑜负责解题，张晓、陈远和我负责Review莫瑜解的题。邹老师则负责统筹全局。后来梁举、胡相继加入创作小组，随着书稿越来越厚，参与的人也越来越多，包括研究院的众多研究员和博文视点编辑部的众位老师。这里不再一一列出，详见此书致谢

以前总觉得只要是个人他就能够写书，但从来没有想到过创作一本书这么难。众位作者绝不想让这本书成为一本习题集，我们尽自己最大的努力，去努力呈现编程和算法世界中的美。在创作过程中，我们采用微软敏捷开发和TFS（Team Foundation Server）来管理文档和进度。每一个题都作为一个独立的工作项（Task）存在。打开每一个工作项，你都会发现，其中都有10多个的文档，每一个文档都是一次更新后的版本，也就是说，每一个题都经过众多作者的10多次迭代编写而来。而高霖作为本书的装帧设计师（Designer），为本书设计了全套的封面、封底和众多插图，而这些画也都是在被大家“枪毙”了N次（N＞＝10）之后才最终定稿。该书凝聚了大家多少的心血，由此可见一斑。在编写的后期，邹老师和铁锋等人继续带领着我们对文稿进行字斟句酌的修改，不轻易放过任何一个有瑕疵的地方。

我有幸成为本书的创作者之一，其实我也是本书的受益者之一。我今年研三，正如前面所提，投入了2007年秋季的招聘大军，正是编写《编程之美——微软技术面试心得》，为我在激烈的竞争中取胜增添了很重要的筹码，今年7月我将前往微软上海Windows Live Mobile就职，担任的职位是SDET。本书的作者中，不乏像莫瑜这样的ACM大牛，我常常直接杀到他的位置上与他讨论问题，正是由于有着众多作者激烈的讨论，才常常有令人拍案的想法迸出，而我在这一过程中也学习到了很多知识。在去年秋季的应聘过程中，我常常会被问到《编程之美——微软技术面试心得》中的题目，可能有人说，那就是你运气好了，但我在这里绝不是说大家将看到一本面试秘籍或者说大家把这里面的题都背下来就万事大吉了。其实即使我在被问到书中的题目时，都会很坦诚地告诉面试官，这个题我做过。我想说的是，《编程之美——微软技术面试心得》希望呈现给读者的是解题的思路和过程，也就是说，当你遇到一个问题时，该如何去分析和解决问题，这才是本书努力想与读者分享的地方。也只有懂得了如何分析问题和如何解决问题，才能够真正体会到编程和算法的美。希望读者在阅读本书的时候，能够抱着一颗寻找美的心，先自己独立思考每一个题目的解法，再阅读书中的思路和解法，比较自己的思路和书中思路的差异，努力从中掌握分析问题和解决问题的方法。最后，我想告诉大家，近期，微软亚洲研究院将每周在官方网站上连载《编程之美——微软技术面试心得》中的题目，欢迎大家到网站上参与题目的讨论和解答，也希望《编程之美——微软技术面试心得》能够将美的享受带给每一位读者。谢谢。

张晓

清华大学高等研究所博士生，微软亚洲研究院实习生。他在天津度过了18年快乐的时光，又在清华电子系学习了4年。本科期间，参加过不少科技活动。虽然没有多少拿的出手的成绩，但一直在努力。他在一群喜欢计算机、热爱编程的同学们和老师的熏陶下，对计算机技术产生了浓厚的兴趣，并在本科毕业时决定来到微软亚洲研究院实习，投身于软件行业。张晓在工作之余，喜欢阅读高科技企业的传记，梦想以技术服务社会，让高质量、个性化的信息触手可及。

《编程之美——微软技术面试心得》创作组的正式成立是2007年6月初，但其实我和《编程之美——微软技术面试心得》的缘分在4月份就已经开始了。

那时我刚到IEG组实习，有一天收到了邹老师的邮件，说是为了提高IEG实习生的编程能力，让我们解一个编程的趣味题，解得好有奖励。从这天起，邹老师就经常给我们发类似的编程题目。这些题目有些本身就很有意思，比如与下棋、游戏有关的。有些问题还包括很多扩展问题，由浅入深，越到后面问题越有挑战性。在那段时间里如果你看到希格玛大厦四层西南区有几个人围着几张纸坐在一起作冥思苦想状，那多半就是在想这些题的解法。我也经常会在宿舍“卧谈”时跟室友聊这些题目，室友们也很感兴趣。每次和公司同事或室友讨论，总能让我领悟一些新的东西。这些题目就是《编程之美——微软技术面试心得》的前身。

到了6月初的时候，《编程之美——微软技术面试心得》创作组就正式成立了。我被分配的任务是理解牛人给出的解法，并用易于理解的语言叙述出来。这个任务让我有两方面的收获，一方面书中的问题很多都有一定的难度，牛人给出的解法虽然简短但并不很直观，但一旦理解这些算法的内涵就往往能够让我对编程有新的认识。另一方面，用读者易于理解的语言描述技术问题也不容易，这也锻炼了我的写作能力。

为了管理写作的进度和保存历史数据，我们还在邹老师的主持之下设立了有“微软特色”的沟通机制。那就是在Visual Studio Team Suite（VSTS）上把所有计划要写的题目做成Work Item，给每个Work Item设置3种状态：Active、Peer Review和Editor Review。每一道题最开始都处于Active状态，在经过答案的产生和润色之后进入Peer Review阶段。在这个阶段，会有其他作者来检查这道题目的解答中是否存在漏洞。如果该答案在Peer Review中出现过多问题，会被退回给原作者，并重新设置为Active状态；如果通过，则会设置成Editor Review的状态，也就是送交编辑们编辑校对了。到了本书创作的后期，可以看到每一道题对应的Item下都有很多的附件，最初的版本、改过第一遍的版本、改过第二遍的版本……而每一篇文档中都会有很多Comment，从格式到内容，从语言到算法，密密麻麻地布满了整个文档。甚至于可以看到在一篇文档的某一处有多种颜色的Comment，那是几位作者在为一种解法而辨论。

在VSTS上“文斗”不过瘾的时候，作者们也会相约去“武斗”。武斗的场所一般是冰箱旁或者鱼缸边，武器限于牙齿和纸笔，武斗的结果一般是武斗双方都对问题认识得更深了，而且有时一些新的idea也会在“武斗”中产生。我建议读者在阅读本书时，为了达到更好的效果，多和周围的朋友动嘴动笔切磋讨论。

另外，虽然书中的题目比较多，而且从题干上来看也没有什么联系。但是当我接触了一定数量的题目之后，发现它们之间在解法上还是有很多内在联系的。比如变量的设置、对数组的遍历方式等等。希望读者在阅读时，能把不同题目之间的解法联系起来思考，这样更有可能抓住问题的本质。

陈远

西北工业大学计算机系研究生，微软亚洲研究院实习生。

他自认为性善讷言，敏于思而疏于行。天性乐观，兴趣甚广，喜怒易形于色。少尝立志博览群书，通晓万术。奈何天资愚钝，虽勤奋有余，然灵巧不足，岁月蹉跎，终仅习得一长技在身，曰：“专业做网站”，遂以此技为安身立命之本。他热衷技术，善举一反三，学以致用，以追求极致卓越为己任，坚信编程与生活一样，都是严肃而富有艺术性的。

我应该算是最早知道将要编写《编程之美——微软技术面试心得》这本书的几个人之一。那时邹欣老师正在对《移山之道——VSTS开发指南》进行最后的润色，而我还在学校里上研究生课程，生平第一次接受正统的计算机专业教育。当邹老师问我要不要参与编写时，作为一名自诩的“文学青年”而不是“计算机高手”，我毫不犹豫地答应了。

我本科读的是航空学院，在大二时闲得无聊抱着玩的心态才开始自学编程，凭着热情和兴趣就一头扎了进来。但是，我心里一直有种隐隐的痛，我可以熟练使用ASP.NET、AJAX很快地做出一个网站来，却对一些基本的数据结构、算法一知半解。唯一一次认真去读《数据结构》那本书还是保研机试前一夜临时抱佛脚，通宵看了排序、树、图之类常考的重点。虽然最后考出来成绩不错，但自己斤两多少，自己最清楚。所以实际上我对许多公司偏重算法的面试一直以来都抱有一种畏惧感和神秘感，而且非常仰慕那些受过ACM、ICPC训练过的同学，尤其是那些能很快分析出问题复杂度的人。

但是毕竟我不是科班出身，而且只在学校里面做过一些简单的网站项目，这让我在很长一段时间里都抱有一种误解，即认为工程能力和算法解题能力是不相干的两回事，佐证就在于有些人可以很轻松地解出一些算法题却无法用C#写一个真正可用的软件；而像我一样的人可以轻车熟路写出一个“看上去很美”的CMS系统，但面对一些课本上的算法题时却手足无措。而且更要命的在于，简单的网站做多了，我逐渐认为做工程不需要所谓的算法，算法好只能让人拿到更高的课程分数或是竞赛奖项，而在计算机科学这一非常讲究实践的领域中，只有良好的工程能力才有办法真正实现某个项目。于是，在很长一段时间里，我对那些能通过解出很难的算法题拿到很好的offer的人都嗤之以鼻，并对那些公司的招聘标准感到疑惑不解——明明是我更能干活，实践经验和能力上更强，凭什么不要我而是他们呢？

我觉得我最大的幸运在于，随后的一些经历让我很快走出了这个误区。在本科的最后一个学期，我幸运地获得了一个前往微软亚洲研究院实习的机会（面试时考了我一道智力题而不是算法题）。在实习过程中，我才“真正”地做了一个软件项目，并且通过和其他实习生的交流，“耳濡目染”地看到了许多现实中的研究性软件的开发过程，这些经历带给了我许多前所未有的体验。在现实的软件开发中你会看到各种形式各异的需求，比如在一定数量的帖子中找出发帖最多的“水王”，在这之前我开发过的网站最多也不过几千条记录，所以我即使用最简单的遍历也能很快实现这一功能，但是当你面对的是十万甚至百万级别的现实数据时，问题就从最基本的“实现”变成了“更快更高效地实现”了！令我汗颜的是，我往往只能用效率最低的复杂度实现类似的功能，而如何更优雅更高效地实现它，我常常感到力不从心。

这些经历让我逐渐意识到，我所沾沾自喜的工程实践能力实际上只是一种“实现”的能力，而在解决现实世界的实际问题时，更需要的是一种“优美的实现”，因为只有在可接受的时间或空间约束条件下的实现才是真正能解决问题的答案。而如何找到所谓的“优美的实现”，一个人的算法能力在这里就起到了决定性的作用。算法实际上是对现实问题的抽象，因为现实问题是复杂的，我们可以把它抽象成模型。寻找合适的数据结构表示问题模型，并通过分析，寻找到对应的解决算法，这种抽丝剥茧的思维方式将会使得开发者事半功倍。那句著名的“软件＝算法＋数据结构”并非空穴来风，我也从这些经历中逐渐理解了微软等公司的招聘标准实际上没有错，因为他们需要找的是能真正通过分析来解决实际问题的人。如果把工程实践能力比作一辆车的轮子，那只能说明这辆车具有了移动的能力，而让这辆车能又快又稳地运行，则需要算法分析能力这台强劲的发动机驱动，这两种能力是相辅相成的。

我觉得自己更大的幸运在于，在我逐渐明白了这些道理后，参与创作了《编程之美——微软技术面试心得》这本书。编书的过程也是我自己动手解里面一道道有趣题目的过程，期间我对一个个优美、巧妙的解法拍案叫绝，在遇到难题或想不通的时候，就通过与其他编者一起讨论解决，这些经历都让我不断体会到“解法之美”和“问题之美”。《编程之美——微软技术面试心得》里的许多题目实际上都来源于现实项目中所遇到的具体问题，它们或是实际问题的简化，或是改头换面以其他有趣的场景表示出来。但是万变不离其宗，通过把问题抽象化，并运用算法分析寻找解决方案将是解题的利器。这种思考方式也是我们希望通过本书传递给读者们的。祝大家能在阅读的过程中体会到“美”的无处不在。

梁举

2007年毕业于北京大学考古文博学院，获得文物保护专业历史学学士及计算机软件专业理学学士学位（双学位），目前在微软亚洲研究院搜索技术中心从事开发工作。

在很久以后才意识到BOP原来是“Beauty Of Programming”的缩写——在我设置了outlook里bop puzzle目录接收bop组的邮件很久以后。

BOP，《编程之美——微软技术面试心得》，虽然标着“面试心得”有些落俗，但或许会让更多的人在看到副书名时受到较强的阅读刺激（我是倾向于“编程之美”这一书名的）。

接触BOP于2007年8月——来微软入职一个月后。而大约在一年前，我还在为找工作做准备：写简历，在网上看笔试面试题，也包括面经，似乎也在图书馆的新阅览室里读过一本简历／面试相关的书（后来也证明，这些确有帮助）。

2007年7月入职，然后是很多的Training。邹欣是其中一个Engineering Training的Coach。一次，他在邮件中给了一个有趣的Stone Quiz，而偶给了一个数学解，就幸运地来到BOP创作小组了。

当时BOP的题库都基本定了，初步的解答也有。接下来需要做的是Review，包括解法的验证、给出新的算法、文字语言润饰、代码规范、标点符号、字体大小颜色等。题目的状态从Active（待修阅）到Peer Review（我们修阅后）到Editor Review（出版社修阅后）再到Active，如此多轮往返，直到大家都满意。这本书不在我们的Commitment之内，没有分配常规的工作时间，所以很多的时候大家会用周末开会，或者晚上在中餐馆小聚，谈下各自的进度，或者中午在日餐馆，一起Review一组题目。在这个过程中，也很是享受，能分享到别人算法的美妙，自己也会在细节处求精（后来因为项目很紧，没能更多的投入，有很多歉意）。

在以往的面试中，我多次被问到，为什么选择计算机。源于兴趣——而这又多是缘于数学。虽然大概小学就喜爱数学的，但真正窥见数学其美是在高中图书馆的书堆里读了《趣味数论》，书里也列举了很多有趣的数论题目，并用通俗简单的语言从多个角度给出了优美的解答。很多年过去了，后来虽没有学数学专业，却仍是记得那本书，以致即使对于学文的人，我也会推荐他们读这本关于数论的书。

现在，对于学计算机的年轻人，我会向他们推荐《编程之美——微软技术面试心得》，对于非学计算机的年轻人，我也会推荐《编程之美——微软技术面试心得》，相信书中用通俗简单的语言解说的优美思想也会吸引他们的兴趣，让他们受益。

希望《编程之美——微软技术面试心得》能让更多的人进入程序世界，感受这个世界中引人入胜的美。

胡睿

浙江人。2006年毕业于清华大学自动化系，获工学硕士学位。现就职于微软亚洲研究院搜索技术中心，从事多媒体搜索研发工作。

"Youth is not a time of life; it is a state of mind; it is not a matter of rosy cheeks, red lips and supple knees; it is a matter of the will, a quality of the imagination, a vigor of the emotions; it is the freshness of the deep springs of life."

——胡睿很喜欢的一段关于青春的论述

很久以前就听说邹欣老师要出一本微软亚洲研究院关于编程艺术的书，但是自己很晚才加入到这个人才济济的编写团队中来，也因此错过了许多的故事。究其原因，大概有两条：一是因为邹欣老师当年是自己的面试者，而且当年他给我出的第二个题目我当时并没有给出很好的结果，想起这个，心里总是有些忐忑；二是自认为对于编程的认识并不能说有多么深刻精辟，自己和印象中的那种大师风范好像还相差非常远，怕在众多的武林高手面前献丑丢脸。因此也就犹豫到今年9月份才真正加入这个队伍做一点事情，“Better later than never”，后来发现，能够有幸加入到这样一个团队做这么一件有意义的事情，机会实在很难得。

自认为不是程序设计天才，但对于那些传奇的程序设计大师境界，“虽不能至，心向往之”。自己看过不少关于计算机和程序设计方面的书籍，面试过一些程序员，也在实际的工作中遇到过很多的编程问题，对于程序设计有了自己的一些体会。程序设计其实本质上是一个知识和能力综合应用的过程。要编写出好的程序来，基础知识很重要，如果基本的数据结构和经典的算法都不知道，很难编出很好的程序来；但是当你有了一定的基础，基本了解了常用的数据结构和算法以后，想象力和思维方式就更为关键，正如爱因斯坦所说：“想象力比知识更重要”。知道什么时候在什么样的问题上采用什么样的算法和数据结构，非常不容易；如果还能够将一些常用的算法和数据结构针对特定的问题做一些优化和修改，甚至创造出一些新的数据结构和算法，就更为难得。

计算机方面的书籍很多，讲述基本算法和常用数据结构的书也不少，《编程之美——微软技术面试心得》的创作思想和一般的编程书籍不大一样，全书并不是给大家讲解一些计算机和程序设计的理论知识，而是通过分析讲解实际生活中的一些问题，来启迪大家的思路，让大家体会程序设计的思维方式。这本书的独特之处就在于，它更强调的是描述程序设计的思维方式，分析的是将实际问题抽象为计算机程序设计问题，并找到最优算法的过程，并且花了很多精力来比较各个算法的优劣，并分析各个算法的复杂度。

参与创作这本书，通过和邹欣老师以及其他作者之间的交流和讨论，我接触到了很多以前从未碰到的新奇问题，学到了很多精巧的解法，更重要的是，开阔了自己的思路，也认识到了程序设计科学和艺术的博大精深，需要用一辈子去学习、提高。我希望，读者朋友们也能通过这本书得到自己的收获。