本文来自 酷壳 – CoolShell.cn 陈皓 撰写的文章：

算法面试可能是微软搞出来的面试方法，现在很多公司都在效仿，而且我们的程序员也乐于解算法题，我个人以为，这是应试教育的毒瘤！我在《再谈“我是怎么招程序员”》中比较保守地说过，“问难的算法题并没有错，错的很多面试官只是在肤浅甚至错误地理解着面试算法题的目的。”，今天，我想加强一下这个观点——我反对纯算法题面试！（注意，我说的是纯算法题）

我再次引用我以前的一个观点——

能解算法题并不意味着这个人就有能力就能在工作中解决问题，你可以想想，小学奥数题可能比这些题更难，但并不意味着那些奥数能手就能解决实际问题。

好了，让我们来看一个示例（这个示例是昨天在微博上的一个讨论），这个题是——“找出无序数组中第2大的数”，几乎所有的人都用了O(n)的算法，我相信对于我们这些应试教育出来的人来说，不用排序用O(n)算法是很正常的事，连我都不由自主地认为O(n)算法是这个题的标准答案。我们太习惯于标准答案了，这是我国教育最悲哀的地方。（广义的洗脑就是让你的意识依赖于某个标准答案，然后通过给你标准答案让你不会思考而控制你）

功能性需求分析

试想，如果我们在实际工作中得到这样一个题 我们会怎么做？我一定会分析这个需求，因为我害怕需求未来会改变，今天你叫我找一个第2大的数，明天你找我找一个第4大的数，后天叫我找一个第100大的 数，我不搞死了。需求变化是很正常的事。分析完这个需求后，我会很自然地去写找第K大数的算法——难度一下子就增大了。

很多人会以为找第K大的需求是一种“过早扩展”的思路，不是这样的，我相信我们在实际编码中写过太多这样的程序了，你一定不会设计出这样的函数接口 —— Find2ndMaxNum(int* array, int len)，就好像你不会设计出 DestroyBaghdad(); 这样的接口，而是设计一个DestoryCity( City& ); 的接口，而把Baghdad当成参数传进去！所以，你应该是声明一个叫FindKthMaxNum(int* array, int len, int kth)，把2当成参数传进去。这是最基本的编程方法，用数学的话来说，叫代数！最简单的需求分析方法就是把需求翻译成函数名，然后看看是这个接口不是很二？！

（注：不要纠结于FindMaxNum()或FindMinNum()，因为这两个函数名的业务意义很清楚了，不像Find2ndMaxNum()那么二）

非功能性需求分析

性能之类的东西从来都是非功能性需求，对于算法题，我们太喜欢研究算法题的空间和时间复杂度了。我们希望做到空间和时间双丰收，这是算法学术界的风格。所以，习惯于标准答案的我们已经失去思考的能力，只会机械地思考算法之内的性能，而忽略了算法之外的性能。

如果题目是——“从无序数组中找到第K个最大的数”，那么，我们一定会去思考用O(n)的线性算法找出第K个数。事实上，也有线性算法——STL中 可以用nth_element求得类似的第n大的数，其利用快速排序的思想，从数组S中随机找出一个元素X，把数组分为两部分Sa和Sb。Sa中的元素大 于等于X，Sb中元素小于X。这时有两种情况：1）Sa中元素的个数小于k，则Sb中的第k-|Sa|个元素即为第k大数；2） Sa中元素的个数大于等于k，则返回Sa中的第k大数。时间复杂度近似为O(n)。

搞学术的nuts们到了这一步一定会欢呼胜利！但是他们哪里能想得到性能的需求分析也是来源自业务的！

我们一说性能，基本上是个人都会问，请求量有多大？如果我们的FindKthMaxNum()的请求量是m次，那么你的这个每次都要O(n)复杂度的算法得到的效果就是O(n*m)，这一点，是书呆子式的学院派人永远想不到的。因为应试教育让我们不会从实际思考了。

工程式的解法

根据上面的需求分析，有软件工程经验的人的解法通常会这样：

1）把数组排序，从大到小。

2）于是你要第k大的数，就直接访问 array[k]。

排序只需要一次，O(n*log(n))，然后，接下来的m次对FindKthMaxNum()的调用全是O(1)的，整体复杂度反而成了线性的。

其实，上述的还不是工程式的最好的解法，因为，在业务中，那数组中的数据可能会是会变化的，所以，如果是用数组排序的话，有数据的改动会让我重新排序，这个太耗性能了，如果实际情况中会有很多的插入或删除操作，那么可以考虑使用B+树。

工程式的解法有以下特点：

1）很方便扩展，因为数据排好序了，你还可以方便地支持各种需求，如从第k1大到k2大的数据（那些学院派写出来的代码在拿到这个需求时又开始挠头苦想了）

2）规整的数据会简化整体的算法复杂度，从而整体性能会更好。（顺序的处理很容易进行各种处理）

3）代码变得清晰，易懂，易维护！（学院派的和STL一样的近似O(n)复杂度的算法没人敢动）

可能的争论

你一定会和我争论，

• 如果程序员做这个算法题用排序的方式，他一定不会像你想那么多。是的，你说得对。但是我想说，很多时候，我们直觉地思考，恰恰是正确的路。因为“排序”这个思路符合人类大脑处理问题的方式，而使用学院派的方式是反大脑直觉的。反大脑直觉的，通常意味着晦涩难懂，维护成本上升。

• 就是一道面试题，我就是想测试一下你的算法技能，这也扯太多了。没问题，不过，我们要清楚我们是在招什么人？是一个只会写算法的人，还是一个会做软的人？这个只有你自己最清楚。

• 这个算法题太容易诱导到学院派的思路了。是的这道“找出第K大的数”，其它可以变换为更为业务一点的题目——“我要和别的商户竞价，我想排在所有竞争对手报价的第K名，请写一个程序，我输入K，和一个商品名，系统告诉我应该订多少价？（商家的所有商品的报价在一数组中）”——业务分析，整体性能，算法，数据结构，增加需求让应聘者重构，这一个问题就全考了。

• 你是不是在说算法不重要，不用学？千万别这样理解我，搞得好像如果面试不面，我就可以不学。算法很重要，算法题能锻炼我们的思维，而且也有很多实际用处。我这篇文章不是让大家不要去学算法，这是完全错误的，我是让大家带着业务问题去使用算法。问你业务问题，一样会问到算法题上来。

小结

看过这上面的分析，我相信你明白我为什么反对纯算法面试题了。原因就是纯算法的面试题根本不能反应一个程序的综合素质！

那么，在面试中，我们应该要考量程序员的那些综合素质呢？我以为有下面这些东西：

1. 会不会做需求分析？怎么理解问题的？
2. 解决问题的思路是什么？想法如何？
3. 会不会对基础的算法和数据结构灵活运用？

另外，我们知道，对于软件开发来说，在工程上，难是的下面是这些挑战：

• 软件的维护成本远远大于软件的开发成本。
• 软件的质量变得越来越重要，所以，测试工作也变得越来越重要。
• 软件的需求总是在变的，软件的需求总是一点一点往上加的。
• 程序中大量的代码都是在处理一些错误的或是不正常的流程。

所以，对于编程能力上，我们应该主要考量程序员的如下能力：

1. 设计是否满足对需求的理解，并可以应对可能出现的需求变化。
2. 程序是否易读，易维护？
3. 重构代码的能力如何？
4. 会不会测试自己写好的程序？

所以，这段时间，我越来越倾向于问应聘者一些有业务意义的题，而且应增加或更改需求来看程序员的重构代码的能力，写完程序后，让应聘者设计测试案例。

比如：解析加减乘除表达式，字符串转数字，洗牌程序，口令生成器，通过ip地址找地点，英汉词典双向检索……

总之，我反对纯算法面试题！

（全文完）

导语：美国科技博客Business Insider周六刊文称，Facebook股价自3个月前IPO(首次公开招股)以来已下跌近一半，低于过去18个月中大部分员工获得公司股权的价格。 这意味着Facebook员工的财富较几个月前大幅缩水。这已对Facebook的士气造成打击。10月和11月，大部分Facebook员工持股将解 禁，而员工很可能希望将所持股份变现，用于买房等多种目的。

Business Insider列出了Facebook员工应当了解的关于股价的事实。

以下为主要内容：

– 股价下跌与Facebook作为一家公司的质量无关

Facebook股价下跌是由于，投资者大幅下调了对Facebook未来财务业绩的预期。外界对Facebook“合理价值”的看法有很大差异。根据Facebook近期公布的财报，投资者发现3个月前对Facebook的估值过高。

– 市场基于3方面原因重新评估Facebook

1)营收增长正在减速；2)用户向移动设备的转移；3)为了推动未来的增长，Facebook进行了大量投资，影响了利润率。

– 各种因素表明，Facebook不太可能成为“下一个谷歌(微博)”

这与Facebook上市时投资者的看法有很大不同。这是投资者的失误，而非Facebook的失误。

– 相对于Facebook的利润增长预期，当前股价仍然很贵

假定Facebook明年每股收益为0.65美元，在20美元的股价水平上，Facebook的2013年前瞻市盈率仍达31倍。作为对比，苹 果和谷歌的前瞻市盈率都不超过15倍。Facebook股价的市盈率很容易下降至20至30倍，这一估值仍然合理。因此Facebook股价还将继续下 跌。

– 只有在满足3个条件后，Facebook股价才会触底

1)营收增长重新加速；2)利润率停止滑坡并反弹；3)股价下跌至“便宜”的水平，促使投资者重新买入。不过Facebook当前股价距离这一水平还有很远。

– 即将到来的受限股解禁将对股价造成更大压力，除非Facebook营收增长突然加速

许多Facebook员工都希望出售公司股份，这可以理解，而市场也意识到了这一点，并据此进行调整。如果所有Facebook员工都不出售股 份，那么 Facebook股价将出现一定程度的反弹。不过从长期来看这不会带来太大影响。因此如果想要售股，那么就去做。尽管不会获得较好的价格，但除非 Facebook股价彻底崩盘，否则员工仍能获得一笔不错的收入。

– LinkedIn和亚马逊有较高的市盈率，但不能据此推断Facebook的股价低估

LinkedIn和亚马逊市盈率较高是因为两家公司目前利润率较低，但未来会快速提升。这将带来较高的利润增长率。与此同时，Facebook的利润率很可能仍将下降，这意味着利润增长将落后于营收增长。

– 对于股价问题，近期Facebook没有任何办法

Facebook股价就是这样，与IPO当天的股票交易故障也没有太大关系。Facebook CEO马克·扎克伯格(Mark Zuckerberg)在招股书中明确表示，将专注于长期的产品开发，并牺牲短期的财务利益。这一决定令人钦佩，同时也很聪明。许多美国公司只专注短期股 价表现，从而走向了消亡。不过可以确定，Facebook股价短期内不会有什么起色。

– Facebook正经历的情况与大部分成长型公司相比没有太大差别

Facebook正在经历从“爆发式增长”向长期增长的转型。爆发式增长往往带来极高的估值，但长期增长不会。在两种模式之间的转型将导致股价在许多年中处于较低水平。

– Facebook员工应当研究亚马逊的股价表现

亚马逊股价曾连续3年上涨，但随后大幅下跌，近年来又出现了更大幅度的上涨。需要指出的是，当亚马逊专注于顾客而非财务表现时，其股价不但涨回 了原先水平，还创下历史新高。这就是专注于长期增长的公司所能取得的成就：在多年时间中，它们的股价可能表现低迷，但只要实现目标，那么股价将快速上涨。

未来，Facebook股价可能会在20美元左右波动，并持续较长时间。除非Facebook营收重新加速增长，否则股价不可能涨至更高水平。 由于股价仍不便宜，并面临解禁股压力，一些长期投资者暂时也不会买入Facebook股份。不过明年，股份解禁问题将不存在，影响Facebook股价的 主要因素将是Facebook未来2至3年的发展，以及营收增长是加速还是减速。

总而言之，Facebook股价下跌是由于投资者错误地认为Facebook将成为“下一个谷歌”。在创业公司的爆发式增长阶段，投资者很容易做出这样的误判，因为他们愿意相信所听到的一切。但当看到现实情况时，估值将会受到巨大压力。对此，任何人都无可奈何。

作者：Cliff Bleszinski

到今年夏天，我从事职业游戏设计就到第20个年头了。我曾领导团队设计平台游戏、FPS、单机游戏、多人游戏等等。我曾和一些最令人叹服的程序师、美术人员、动画师、写手和制作人共事。这20年以来，我注意到创意人员经常使用的交流方法。

我知道虽然开发人都非常高明，但有时候他们并不敢肯定与同行相比自己能有多聪明。我曾看到开发者在留言板上对百万美元的游戏大作、独立游戏宠儿等过 度分析、吹毛求疵。我们总想证明自己比其他人有先见之明，或者引用一个例子，说明那个创意已经被尝试了、能成功、会失败或行不通等。

开发者们为了“赢得”得谈话，经常会使用一些讨论、争论和辨论方式。本文要介绍的就是这些常用手段。

以下说法和绰号没有恶意地针对谁；事实上，有几个方法确实是因为有理有据才被使用的。例如，样式对比可以避免制作出派生产品；边界案例有时候可以抹杀可靠的想法。以下就是我所谓的交流“技巧”。

“样式对比”

这是指开发人为了否绝一个创意，立刻在他的头脑中检索他的游戏/流行文化库，然后找出最接近的想法作为比较对象（常常是糟糕的或失败的案例）。

以《阿凡达》为例，“你想制作一部关于蓝皮肤的人在丛林中对抗坏人类的军队和机器？什么，蓝精灵丛林大战外星人？”不恰当地类比，《战争机器》可以 看作是80年代的低级恐怖电影《C.H.U.D》（游戏邦注：在电影《C.H.U.D》中有一种生活在城市底下的基因突变人，以食人肉为生，而《战争机 器》中也存在类似的怪物）。

“边界阻塞”

这是指用一个边界情况来否绝可能很了不起的想法。例如，举出边界情况的人可以否定在《天际》中创造一个大世界的想法，因为担心玩家要走回原来的地方，且步行太老套。清楚明确的修改方法如“快速旅行”的可以轻易地解决这个大世界问题。

边界阻塞有变体：

“交际人”：这是指因为某个想法在边界情况或特定的合作模式中不成立就否决它——这是边界阻塞的变体。“《英雄本色》的慢动作怎么可能在合作模式中起作用？不可能！”

“完美主义者”：类似于边界阻塞。这是指开发者发现在某种情况下，一个很不错的设定可能看起来并不完美。比如，格斗动作有时候会导致角色发生微小的变化。

“从来没见过做得好的”

这句话的意思也就是“我以前从来没见过这种想法行得通或做得好的。所以，我们不应该这么做。”这是一种相当不言自明的论断，事实上，这也可能是为什么应该执行某个想法的理由。按这种逻辑，所有创意都只能是雷同的。

比如，在《战争机器》中设定了一种生活在地下的Locust人，这个设定行得通的原因有很多，但我们仍然对它持保留意见。毕竟，这个设定使该游戏从其他带有常规外星人的游戏中脱颖而出。

“故意唱反调的人”

为了保全颜面，大多数开发人经常故意唱反调，甚至在他们自己也相信这个想法时候。律师经常使用这一招。

“不过是X+Y罢了”

这是指开发者怀着酸葡萄心理贬低其他成功的作品，因为他可以轻易地看出其中的原理。事实上，正是因为游戏原理非常简单明显，才使游戏如此成功。

例如，《Words with Friends》：“不过是异步拼字游戏罢了。”是的，正是如此，所以它成功了。

“以后再说”

当开发者听到一个想法——无论好坏，就说这个想法很适合之后的版本或续作。这句话的真实含义是，“我认为这个想法不值一试，所以我们放弃吧，我说以后再说是为了让你不难受。”

“通天塔”

这是当开发者在一个本来很简单的设定上堆砌太多额外的小东西时，但这些小东西最终危及整个设定。这座“通天塔”是被自己的重量压跨的。

“雪崩效应”

之所以用这个方法否绝一个想法，是因为这个想法需要许多其他部门（游戏邦注：如动画、UI或美术）做更多工作。通常，有趣或值得尝试的特点都会牵涉到更多部门，因为涉及多个学科的知识。

“过度分析”

这个常用的词是指过分考虑某个想法，以致于一事无成。

“试什么试？”

换句话说，“我们怎么跟别人比？”因为在某个方面面临激烈的竞争，开发者就这么问，以免尝试。

“他们有N个开发者啊！”

当开发者说到某个竞争团队的规模有多大时就会这么说，说完这句话以后紧接的就是上面那句。为了高效地工作，Epic公司总是让最好的人从事同一个任务，用最好的工具。

“保守主义者”

“但是我们一般都是这么做的啊！”在娱乐行业，特别是与技术有关的行业，为了生存，创意和反思是非常必要的。自满和墨守成规必然导致失败。

在某个常规行业工作20年可能是个优势，但在技术行业，这可能会成为你的绊脚石。作为开发者，越要保持眼界开阔，要活到老学到老。

“但我们是XXX（“XXX”指工作室名称）

当工作室准备将自己的名誉押在某个项目的成功上时，就会发出这样的战斗口号，还自认为很强大。当工作室的人这么说的时候，你就知道这个工作室离内乱的日子不远了，因为更年轻的新员工满怀梦想，总是想取代老员工、创造新的辉煌。

“我们以前就试过了”

为了否定旧想法的替代方案（可能行得通），就提出以前尝试旧想法失败的经历。

“太先进了”

你的想法太棒了！事实上，这个想法太前卫太创新了。所以，我们不应该尝试，因为听起来挺费功夫的。

“按我们这行的话说……”

这是指，为了在争论中占上风，开发人抛出只有他自己专业的人才懂的术语，使不同专业的其他开发人不知所云。例如，程序员用代码的原理跟美术人员讨论，设计师用设计行话向动画师解释。

“部落首领”

当开发人固执地信仰自己的专业（美术、编程、设计等），而排斥工作室里其他专业的人的见解。

“不在范围之内”

“这个想法很好，但不在我们的项目范围之内。”很不幸，有时候，最好的想法不会在原本的计划之内。

“测试把戏”

开发人为了否绝某个新设定、新武器，就强烈建议“和谐”它，他的方法是在测试时变更它，这样游戏就按着他的思路设计了。有时候，人们为自己的想法付出了很多努力，结果却被别人破坏了，遇上这种情况，看开了就好。

“学舌”

这是指一类人，他们听到你的想法，反而像从来没听过似的，用自己的话把你的想法当成自己的说出来，还忘记自己是从哪听到这个想法。这从根本上说没什么大不了的，只要这个创意行得通就行了。

“长篇大论”

这类人用三页长的邮件回应设计建议或讨论。

每次都是这样，最终，你得为这个人设一个专门的文件夹。

“邮件盲”

这类人在邮件方面似乎总像个彻头彻尾的傻冒，即使他们并不是故意的。

“哥拉斯”

因为主观地认定一个想法不好，这类人莫名其妙地就叫停所有进程，提出自己全新的想法，最终所有人都不得不重新开始。

“怀疑论者”

这类人没有任何明确的理由就拒绝一个想法，他们的说法是“对此，我不知道……”，却往往很管用。

“先知”

这类人对一个想法怀有一时的冲动热情，但从未站在设计或其他学科的角度考虑它。这类人单纯地希望所有人都相信这个想法会成功，而不是根据它做出原型。这往往是年轻的、没经验的设计师的举动。

“亚哈船长”（游戏邦注：这是小说《白鲸》中的人物，固执地想找白鲸复仇。）

这类人拒绝承认某个想法行不通，同时不断地尝试，不惜浪费珍贵的代码和美术资源，妄想有一天，这个想法会成功。

“数据控”

这类人出现的情况是：“这个表格中的数据客观公正地表明，你的想法永远不会成功，你会使很多人不愉快，这个方向我们不能走。”

“精神期望”

这是指一个程序师拒绝理解被提出来的设想，直到这个设想以程序师自己想的方式被要求执行时。

“无视”

这类开发人有意（或无意）地忽略可能会成功的想法。

“事不关己”

这类设计师口口声声说想要创意，听了别人的想法后又默默地忽略任何不是他自己想出来的东西。

“园丁”

园丁早早地种下了想法的种子，然后多次在会议上提起，甚至与他人闲聊时也不忘说上一句。最后，这个想法开始在其他人心里生根发芽，直到它成为游戏中的一部分，都没有人记得这个想法最初是从哪冒出来的。这确实是个实用的技巧。

“漏洞仔”

当进程中出现一个设定，设计师不考虑这个设定的目的或作用，只顾着指出明显的错误，而这些错误显然是最终能解决的。

“多个头领”

当一个人没有明确的顶头上司，不知道该听谁的发号施令时，他往往会听从多个人的指挥。设计总监、执行制作人和董事可能各有自己的观点，让没有明确上司的员工感到困惑不堪。

“打包票”

这个词是指发言人向媒体承诺某个设定，让团队不得不按他放出的话来做。

“随大流”

创意人员看到最近游戏的游戏中有什么，他就采纳什么，心想这样就可以做出好游戏，也省了想法子创新。

总而言之，以上就是我这些年见识过的开发人的个性的交流“技术”。多谢了在Epic、ChAIR和People Can Fly的同行们为我提供的材料。我希望有远见的开发人可以意识到这些问题，并相应地改正。我也希望此文能让博得创意人员的会心一笑。

英文原文，游戏邦 翻译