史上最难的面试谜题
你曾经在应聘一份编程工作的面试中被问及一些解谜类的问题吗？反正我碰到过。我被问到的那个问题是：
你最喜欢的那个牌子的苏打，有多少是在这个州被消费的？
拜托，正确的答案不能是"关我什么事"，除非你不想得到这份工作了。我当时对这个问题毫无头绪，后来才知道这是一个"费米 问题"（Fermi Question）。
谜题作为一种新生事物，在20世纪90年代的程序员面试里风靡一时。这在《如何移动富士山？》（《How Would You Move Mount Fuji？》）一书中有很好的记载，书中还强调微软公司在招聘过程中就使用了谜题。
如果你已经知道你将去应聘的公司会问这类谜题，预先研究一下常见的面试谜题是很明智的。如果你觉得你已经对一般的谜题很在行了，那我就要来考验你一下，看看下面这道史上最难的面试谜题吧：
3个海盗把100名囚犯分别关在100间牢房里，其中一名囚犯将在早上走跳板（海盗处死俘虏的一种办法）。每名囚犯有10瓶葡萄酒，其中1瓶是有毒的；每个海盗有12枚硬币，其中1枚是伪造的，它比真硬币或重或轻。每个牢房里都有一个开关，囚犯可以不碰它，也可以把它翻转过来。在被带入牢房之前，囚犯们都被戴上了红帽子或者蓝帽子；他们可以看到其他所有囚犯的帽子，但就是看不到自己的。同时，一个6位素数这么多的猴子在不停繁殖，直到它们的数字翻转过来，然后所有猴子都要借助一只独木舟横穿过河，而独木舟一次至多只能载两只猴子。不过，半数的猴子总是说谎，而另外一半的猴子总是说真话。现在假设，第N名囚犯知道猴群中有一只猴子，它不知道：第（N+1）名囚犯在知道了哪瓶酒有毒和他所戴帽子的颜色之后，海盗只有知道了这名囚犯是否翻转了他房间里的开关，才能知道1～100之间两个数的乘积。怎么来解这个谜题？
换句话说，我讨厌谜题！（但愿那些谜题狂热者都能解答出来……）在意料之中，我没有通过那次面试。我当时很失望，因为那份工作还是挺酷的！
倒不是说我在"与程序员面谈"一节里给出的建议会更受欢迎，但我确实认为那要好得多！
在前面，我给大家介绍了一种我自创的方法，那也是面试程序员最理想的方式：让候选人在你的团队面前就他们做过的某样东西做15分钟闲聊式的演讲。你当然还可以用一些实际的需要动手的编程测试来作为补充，以确保那位候选人不是在招摇撞骗-尽管我坚信，如果你不是真的理解你正在谈论的东西，你是不可能在一个技术性演讲里糊弄一群同人的。（如果你真能这么糊弄，你现在应该已经成为一家创业公司的CEO了！）
我在这里要强调的是沟通能力。对于大部分程序员来说，在他们通过了"Fizz-Buzz"级别的能力测试之后，他们看起来已经相当不错了。但只会写代码还不够。如果想从优秀发展到卓越，你必须培养起有效沟通的能力：与你的同事沟通，与你的老板沟通，与用户沟通，最终与全世界沟通。
因为我们第一个小孩的出生，我和我的妻子在一家医院里待了5天。在住院期间，我们得到了很多名护士的协助-每天至少两名不同的护士，有时还会更多，因为我们要去不同的科室就诊，而且护士每天还有换班。这家医院的护理质量总体来说是相当高的，但我们也为从最差的护士那里和最好的护士那里分别得到的护理之间的差距倍感困惑。几天之后，我终于发现了一个共性-最差护士的沟通能力必定是最差的！这些护士无法跟我们进行有效的沟通，比如：
为什么她们需要做某事
可选方案有哪些
提供建议
解决我们的问题
这让我们觉得，她们都是些死板的、只知道照章办事的人，她们不会照顾人，或者她们没有主见（必须不断地请示上级）。当然，事实不是这样的。我相信，她们都是完全合格的专业护士。但在沟通方面，她们看起来确实很糟糕！我还得说句公道话，这些护士常常（也不总是）不是本地人（她们的母语不是英语）。
即使在最佳的条件下，招聘也不是件容易的事！但如果让面试流程太过依赖于谜题就太冒险了。当然，程序员们最终可能把你扔给他们的蹩脚谜题解决了（我猜他们也许只是记住了答案）。但是，把那些解决方案有效地解释给团队中的其他人听，难道不同样重要吗？对于很多程序员来说，那才是谜题中最难的部分。
第5章 促使团队紧密协作
不管怎么说，那总是人的问题
作者在Twitter上发的一条短讯：
"不要恨程序员！恨代码就好了。"
11:16 AM - 2012-5-18
Bruce Eckel 巧妙地指出了所有软件开发问题的根源：
我们身处一个新兴产业中。很原始，真的-我们对真正有用的东西知之甚少，而且我们总是认为我们已经找到了可以解决一切问题的"银弹"。结果呢？这么多年来我们一直在经历从繁荣到萧条的轮回：新的想法出现、进一步发展、失去控制、偃旗息鼓。不过，有些理念似乎有持久力。例如，敏捷方法论里的很多理念看起来在生产力和质量方面正在产生着实质性的影响。这是因为它们更多关注了在一起工作的"人"的问题，而更少关注"技术"的问题。
我从Gerald Weinberg那里学到了很多。他最早写的几本书都是关于编程技术的。后来他转变了方向，撰写了（包括与人合写）50多本关于软件开发流程的书。他还有一句名言："不管他们告诉你什么，那总是人的问题。"
项目的成败通常都是因为流程和人员的问题-你每天的工作方式；你的架构师、你的经理以及和你一起工作的编程团队成员；你是如何沟通的，最重要的是，当流程和人员出现问题时，你是如何解决它们的。让你陷入困境最快的方法，就是认为技术是决定性的因素，而且你相信你能轻易解决其他方面的问题。事实上，那些其他方面的问题最可能让你止步不前。
Bruce把Gerald Weinberg的原话记错了，它应该是"不管什么问题，那总是人的问题"。但是，Bruce的重述有一种不可言喻的真实感，当然也忠实于Gerald Weinberg原话的精神。
假设我现在有个任务，要去判断你的软件项目是否会失败。我手上有3个问题，当我得到你对它们的回答时，我几乎可以肯定地宣判你的项目结果：
1．你的团队将会写多少行代码？
2．你们在开发什么样的软件？
3．你喜欢你的同事吗？
最后的那一个问题不是笑话。我是在说正经的。从个人角度出发，你是否喜欢你团队成员的陪伴？你是否在专业上尊重你的团队成员？假设你换工作到了另一家公司，你是否会邀请你的同事一起过去？你们是否有令人振奋的团队讨论，还是那种打倒、拖出去，直到最后一个站着的强人说了算的争论？在你的团队里，是否有你想要"投票赶下岛"的人（如果你可以这么做的话）？
让你关注跟你一起工作的"人"，而不是那些实实在在的事情（例如，实际的工作或者你工作中所用的特定技术），这听起来可能有点本末倒置，但事实上并非如此。我发现，从你选择的跟你一起工作的人身上能最准确地预测工作满意度。而根据我以前的经验，工作满意度和成功有着密切的联系。我还从来没有看到过一个快乐、健康、有凝聚力、社交正常的软件开发团队失败过呢！遗憾的是，这样的团队太少了。
就像Gerald Weinberg所说的，那总是"人"的问题。如果你不是和你喜欢的人、你尊敬的人、会挑战和激励你的人一起工作，那你为什么不去找到这些人呢？是什么在阻止你？