编程之美：微软技术面试心得(博文视点出品)

《编程之美》小组 著

• 出版社： 电子工业出版社
• ISBN：9787121337826
• 版次：1
• 商品编码：12450668
• 品牌：博文视点
• 包装：平装
• 外文名称：Beauty of Programming
• 开本：16开
• 出版时间：2018-11-01
• 用纸：胶版纸
• 页数：332
• 字数：400000
• 正文语种：中文

点此购买

编辑推荐

适读人群 ：本科或研究生应届毕业生 同时也适用本科大三以上对编程有兴趣的同学

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

内容简介

　　《编程之美：微软技术面试心得》收集了约60道算法和程序设计题目。作者试图从书中各种有趣的问题出发，引导读者发现问题，分析问题，解决问题，寻找更优的解法。《编程之美：微软技术面试心得》的内容分为下面几个部分：

　　游戏之乐：从游戏和其他有趣问题出发，化繁为简，分析总结。

　　数字之魅：编程的过程实际上就是和数字及字符打交道的过程。这一部分收集了一些好玩的对数字进行处理的题目。

　　结构之法：汇集了常见的对字符串、链表、队列，以及树等进行操作的题目。

　　数学之趣：列举了一些不需要写具体程序的数学问题，锻炼读者的抽象思维能力。书中绝大部分题目都提供了详细的解说。 每道题目后面还有一至两道扩展问题，供读者进一步钻研。书中还回答了读者关于IT业面试，招聘，职业发展的疑问。这《编程之美：微软技术面试心得》的很多题目会出现在IT 行业的各种笔试、面试中，但这《编程之美：微软技术面试心得》更深层的意义在于引导读者思考，和读者共享思考之乐，编程之美。

作者简介

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

目录

面试杂谈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

精彩书摘

　　推荐序
　　我在卡内基梅隆大学毕业找工作的时候，经常和其他同学一起交流面试的经验。当时令求职者“闻面色变”的公司有微软，研究所有DEC的SRC。每次有同学去微软或SRC面试，回来的时候都会被其他同学追问有没有什么有趣的面试题。我也是那时第一次听说“下水道井盖为什么是圆的”这一问题。
　　我自己申请加入微软美国研究院时被面试了两天，见了15个人，感觉压力很大。至今还记得当有一位面试者不断追问我论文中一个算法的收敛性时，我们进行了热烈讨论。在微软工作的十几年中，我自己也面试了非常多的新员工。特别在微软亚洲研究院的9年，经常感觉很多刚刚毕业的优秀学生基础很好，但面试的准备不足。我非常欣慰地看到邹欣工程师和微软亚洲研究院其他同事们努力编写了这本好书，和大家一起分享微软的面试心得和编程技巧。相信更多的同学会因此成为“笔霸”、“面霸”，甚至“offer霸”。
　　程序虽然很难写，却很美妙。要想把程序写好，需要学好一定的基础知识，包括编程语言、数据结构和算法。程序写得好的人通常都有缜密的逻辑思维能力和良好的数理基础，而且熟悉编程环境和编程工具。古人说“见文如见人”，我觉得程序同样也能反映出一个人的功力和风格，好的程序读来非常赏心悦目。我以前常出的一道面试题是“展示一段自己觉得写过的最好的程序”。
　　编程很艰苦，但是很有趣。本书的作者们从游戏中遇到的编程问题谈起，介绍了数字和字符串中的很多技巧，探索了数据结构的窍门，还发掘了数学游戏的乐趣。我希望读者在阅读本书时能找到编程的快乐，欣赏到编程之美。本书适合计算机学院、软件学院、信息学院高年级本科生、研究生作为软件开发的参考教材，也是程序员继续进修的优秀阅读材料，更是每位申请微软公司和其他公司软件工程师之职的面试必读秘笈。
　　人类的生活因为优秀的程序员和美妙的程序而变得更加美好。
　　沈向洋
　　微软公司杰出工程师
　　微软公司全球资深副总裁
　　2008年春节于香港
　　序
　　一位应聘者（interviewee）在我面前写下了这样的几行程序：
　　while(true){
　　if(busy)i++;
　　else
　　}
　　然后就陷入了沉思，良久，她问道：“那else怎么办？怎么能让电脑不做事情呢？”
　　我说：“对呀，怎么才能让电脑闲下来？你平时上课、玩电脑的时候有没有想过？这样吧，你可以上网查查资料。”
　　她很快地在搜索引擎中输入“50%CPU占用率”等关键字，但是搜索并没有返回什么有用的结果。
　　在她忙着搜索的时候，我又看了一遍她的简历，从简历上可以看到她的成绩不错，她学习了很多程序设计语言，也研究过“设计模式”“架构”“SOA”等，她对Windows、Linux也很熟悉。我的面试问题是：“如何写一个短小的程序，让Windows的任务管理器显示CPU的占用率为50%？”这位应聘者尝试了一些方法，但是始终没有写出一个完整的程序。面试的时间到了，她看起来比较遗憾，我也一样，因为我还有一系列的后续问题没有机会问她：
　　?如何能通过命令行参数，让CPU的使用率保持在任意位置，如90%？
　　?如何能让CPU的使用率表现为一条正弦曲线？
　　?如果你的电脑是双核（dual-coreCPU）的，那么你的程序会有什么样的结果？为什么？
　　自从2005年回到微软亚洲研究院后，我面试过不少应聘者，作为面试者，我最希望看到应聘者给出独具匠心的回答，这样我也能从中学到一些“妙招”。遗憾的是看到“妙招”的时候并不多。
　　我也为微软校园招聘出过考题，走访过不少软件学院，还为员工和实习生做过培训。我了解到不少同学认为软件开发的工作没意思，是“IT民工”“软件蓝领”。我和其他同事也听到一些抱怨，说一些高校计算机科学的教育只停留在原理上，忽视了对原理和技术的理解和运用。
　　写程序真的没有意思吗？为什么许多微软的员工和软件业界的牛人乐此不疲？我和一些喜欢编程的同事和实习生创作编写了这本书，我们希望通过分析微软面试中经常出现的题目，来展示编程的乐趣。编程的乐趣在于探索，而不是在于背答案。面试的过程就是展现分析能力、探索能力的过程，在面试中展现出来的巧妙的思路、简明的算法、严谨的数学分析就是我们这本书要谈的“编程之美”。
　　有时候会有同学问：“你们是不是有面试题库？”言下之意是每个应聘者都是从“库”中随机抽出一道题目，如果答对了，就中了；如果答错了，就bye-bye了。书中有一些关于面试的问答，我想它们可以回答这样一些疑惑。
　　本书的题目，一部分源自各位作者平时想出来的，例如，有一次一位应聘者滔滔不绝地讲述自己如何在某大型项目中进行CPU的压力测试，听上去水分不少，我一边听一边琢磨“怎样才能考察一个人是否真正懂了CPU，任务调度……”，后来就有了上面提到的“CPU使用率”的面试题。有些题目来自于平时的实践和讨论，比如一些和游戏相关的题目。有些题目是随手拈来，比如我看到朋友的博客上有一道面试题，自己做了一下，发现自己的解法并不是最优的，但是，倒是可以作为一个面试题的题目，第2章的“程序理解和时间分析”就是这么得来的。书中有些题目在网上流传较广，但是网上流传的解法并不是正解，我们在书中加上了详细的分析，并提出了一些扩展问题。还有一些题目在教科书和专业书籍中有更深入的分析和解答，读者可以参考。
　　书中的大多数题目都能在45分钟内解决，这也是微软一次技术面试的时间。本书不是一个“答案汇编”，很多题目并没有给出完整的答案，有些题目还有更多的问题要读者去解答，这是本书和其他书籍不一样的地方。面试不是闭卷考试，如果大家都背好了“井盖为什么是圆的”的答案来面试，但是却不会变通，那结果肯定是令人失望的。
　　为了方便读者评估自己的水平，我们还按照每道题目的难度制定了相应的“星级”：
　　一颗星：不用查阅资料，在20分钟内完成；
　　两颗星：可以在40分钟内完成；
　　三颗星：需要查阅一些资料，在60分钟内完成。
　　由于每个人的专业背景、经历、兴趣不一样，这种“星级”仅仅是一种参考。
　　作者们水平有限，书中的题目并不能代表程序设计各个方面的最新进展，虽然经过几轮审核，不少解法仍可能有漏洞或错误，希望广大读者能给我们指正。我们已在微软亚洲研究院的门户网站（www.msra.cn）上开辟专栏（www.msra.cn/bop）和读者交流——初学者和高手都非常欢迎！
　　本书的内容分为下面几个部分。
　　游戏之乐：电脑上的游戏是给人玩的，CPU也可以让人“玩”。这一部分的题目从游戏和作者平时遇到的有趣问题出发，展现一些并不为人重视的问题，并且加以分析和总结。希望其中化繁为简的思路能够对读者解决其他复杂问题有所帮助。
　　数字之魅：编程的过程实际上就是和数字及字符打交道的过程。如何提高掌控这些数字和字符的能力对提高编程能力至关重要。这一部分收集了一些好玩的对数字进行处理的题目。
　　结构之法：对字符及常用数据结构的处理几乎是每个程序必然会涉及的问题，这一部分汇集了对常用的字符串、链表、队列以及树等进行操作的题目。
　　数学之趣：书中还列了一些不需要写具体程序的数学问题，但是其中显示的原理和解决问题的思路对于提高思维能力还是很重要的，我们把它们单独列出来。
　　关于笔试、面试、职业选择的一些问答：微软的面经，各种技术职位的介绍是很多学生所关心的内容，因此我们把一些相关的介绍和讨论也收录了进来。
　　我们希望《编程之美》的读者是：
　　1.大学计算机系、软件学院或相关专业的大学生、研究生，可以把这本书当作一个习题集；
　　2.面临求职笔试、面试的IT从业人员，不妨把这本书当作“面试真题”，演练一下；
　　3.编程爱好者，平时可以随便翻翻，重温数学和编程技能，开拓思路，享受思考的乐趣。
　　《编程之美》由下面几位作者协同完成，如果把这本书的写作比作一个软件项目，它有下面的各个阶段，每个阶段则有不同的目标和角色。
　　1.构想阶段：邹欣。
　　2.计划阶段：邹欣、刘铁锋、莫瑜。
　　3.实现阶段/里程碑（一）：上述全部人员，加上李东、张晓、陈远、高霖（负责封面设计）。
　　4.实现阶段/里程碑（二）：上述全部人员，加上梁举、胡睿。
　　5.稳定阶段：上述全部人员，加上博文视点的编辑们。
　　6.发布阶段：邹欣、刘铁锋和博文视点的编辑们。
　　这本书从2007年2月开始构思，到2007年11月底交出完整的第一稿，花费的时间比每一位作者预想的要长得多，一方面是大家都有日常的工作和学习任务要完成；更重要的是，美的创造和提炼，是一个漫长和痛苦的过程。要把“编程之美”表达出来，不是一件容易的事，需要创造力、想象力和持久的艰苦劳作。就像沈向洋博士经常讲的一句话——Nothingreplaceshardwork。
　　这本书的各位作者，都是利用自己的业余时间参与这个项目的，他们的创造力、热情、执着和专业精神让这本书从一个模糊的构想变成了现实。通过这次合作，我从他们那里学到了很多，借此机会，我对所有参与这个项目的同仁们说一声：谢谢！
　　在本书编写过程中，作者们得到了微软亚洲研究院的许多同事的帮助，具体请参见“致谢”。
　　我们希望书中展现的题目和分析，能像海滩上美丽的石子和漂亮的贝壳那样，反映出造化之美，编程之美。
　　邹欣
　　2007年11月于北京
　　补记
　　一晃《编程之美》已经出版10年了，在10年之后的今天，仍然有机会再次更新序言，唯有感谢和荣幸！
　　重读自己10年前写的文章（http://www.broadview.com.cn/33782），“简化、持续挑战、开拓”，这三个观点依然在持续践行……在过去的10年中，我已离开微软亚洲研究院、创办海豚浏览器、并购退出，并即将开始第二次创业旅程。每一次重大决定，都代表着我的不断挑战和开拓。
　　回想起当年“痛不欲生”地在邹老师的“摧残”之下，一次次迭代改进，似乎暗无天日、永远没有尽头……这段经历，已经成为我用来实证“坚持努力，做足过程，成果自现”的案例。
　　感谢读者的认可，感谢出版社和编辑的不懈努力，才有机会让这本书再次出发！
　　祝每一位读者都能挑战自己的极限，开拓一片天地！
　　刘铁锋
　　2018年8月
　　致谢
　　《编程之美》这本书从构思、编写到最后的出版，得到了许多同事和朋友的帮助。在此作者们要特别感谢以下人士。
　　微软亚洲研究院的多位同事热情地与我们分享了他们觉得有意思的题目，他们分别是：邓科峰、宋京民、宋江云、刘晓辉、赵爽、李劲宇、李愈胜和MattScott。
　　感谢微软亚洲研究院技术创新组的同事梁潇、殷秋丰，他们认真审阅了所有的题目和解答，找出了不少bug1。技术创新组的另外几位优秀工程师李愈胜、魏颢、赵婧还帮助我们解决了书中的几个难题。
　　感谢研究院的同事、著名技术作家潘爱民对我们的鼓励，他审阅了全部稿件，并且提出了不少意见。
　　本书的封面和插图都出自研究院的实习生高霖之手，他在10余个构图都被否定的情况下，坚持不懈，最后拿出了“九连环”的封面设计，得到作者和出版方的一致认同。
　　在本书写作的过程中，作者们各自的“老板”——杨晓松、姚麒、田江森和刘激扬都给予了不少支持，在此特表示感谢。
　　作者们的“老板的老板”，研究院前任院长，微软公司资深副总裁沈向洋博士，现任院长洪小文博士对本书一直很关心和支持。沈向洋博士在百忙之中还亲自为本书写了序。
　　1本书残留的bug都是作者们的责任。
　　微软亚洲研究院市场部的金俊女士、葛瑜女士对本书的推广提供了很大帮助。负责www.msra.cn网站的徐鹏、马小宁、黄贤俊为本书设计了专栏。
　　感谢博文视点编辑团队。感谢在本书写作前期与我们合作过的编辑方舟,在写作后期参与合作的编辑徐定翔和李滟波。特别感谢自始至终和作者们一起工作的编辑周筠、杨绣国。他们和作者们一同构思，耐心修改，没有他们的不懈努力，以及细致的编辑和推广工作，就没有《编程之美》的成功上市。
　　作者
　　2007年11月

前言/序言

　　面试杂谈
　　背景
　　每年从金秋九月起，校园里的广告栏中、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：我们的绝大部分工作，都是通过代码而来，很大一部分的问题，也是由代码所导致的。所以我们不能不重视写代码这件事。当然有很多其他工作不需要写代码，但这不在我们的讨论范围内。
　　…………
　　完整前言请见本书。

点此购买