棘手的逻辑难题-它们真的对评估编程技能有用吗？[关闭]

在我参加的上一次面试中，我被要求解决一个难题，在该难题下，假设两个桶分别具有blah和blah升的容量，那么我应该精确地测量blah升的水。在给定的时间（约5分钟）内，我无法解决难题。

面试官有些失望，并说程序员必须具备“这些”技能。我没明白他在说什么技能。

对于编程面试中通常会问到的这类难题，我一直感到奇怪。我根本不理解这类难题和编程之间的联系，如果有的话。面试官打算用这些难题来评估哪些技能呢？

有人问他们，以评估您解决问题的能力和方法。就我个人而言，我认为这样的难题不能提供准确的指标。在“现实世界”，你有超过五分钟弄清楚，如果你处理的是装箱 Vs的背包问题，例如。最初，有时很容易误解眼前的问题，直到您陷入应用错误的解决方案的中间。具有1、5、10甚至20年经验的人会遇到这种情况。

最好的面试“难题”是您坐在电脑前解决您声称拥有专业知识的领域中的问题。我还不喜欢“嗯，程序员应该能够……”的想法，因为它没有考虑到人们在已经很紧张的环境中被意外击中时会感到焦虑。当然，你可以解决，如果你有时间去思考它..也许你可以，如果你意识到，如果你没有你的生活会比更快解决问题。如果您无法在五分钟内解决问题，您是否想在生活将结束的地方工作？如果不能，你会被解雇吗？

所有伟大的程序员都应该成为数独解决方案的冠军吗？我敢肯定有很多，但是这不像某种能力的先决条件。

我不是说你应该不会对你如何处理的问题进行测试，但测试应该是有趣的，并邀请“最好的”，申请人必须给，因为他们的专业领域。证明你作为布鲁斯·威利斯饰演角色似乎一种毫无意义的，考虑到生产商花了很可观的数目，以获得该场景的智能只是权利。

换句话说，如果您发现自己正在接受某人的采访，而该人对您实际要做的事情几乎一无所知，请原谅自己去洗手间，再也不会回来。

Microsoft在1980年代初开始使用这些问题。随着微软的显着成功，其他公司也开始复制它们，但是在翻译中却失去了一些关键点。

当时，Microsoft试图填补许多技术性但非编程性的职位：技术作家，测试人员，电话支持等。这些在当时并不常见，而在这些领域具有实际经验的人很难找。作为替代方案，Microsoft认为他们可以雇用真正聪明，聪明，灵活的人员，并对其进行培训。由于这些人没有编程背景，因此在面试中向他们询问编程问题毫无意义。选择这些谜语是为了找出那些聪明且具有出色分析能力的人。程序员通常会遇到白板编程问题，尽管在午餐或晚餐时也会被问到谜语。

这些问题绝不意味着失败。它们旨在作为有关如何解决问题以及如何思考从未见过的问题的对话的开始。唯一“失败”的方法是拒绝尝试解决问题。当时这是一个新颖的策略，您不能只在Google上查找问题。

编辑：

写完这个答案后的某个时候，我读了《计算机男孩接手》，这是1950年代和1960年代机构计算的历史。显然，要求脑筋急转弯和候选人之谜来编程工作的做法可以追溯到1950年代。美国试图将其防空系统计算机化，IBM估计他们将需要数千名程序员来完成这项工作。回应令人震惊和震惊：全世界只有几十个“专业程序员”。尝试了几种方法：抽象编程能力测试，招募数学家作为程序员，招募下棋者和填字游戏，解谜器以及使用谜语和脑筋急转弯筛选申请人。

他们最终确实成功地招募了足够的程序员来完成该项目，但是结论是，没有任何一种甄选方法比找到能够继续以程序员的身份成功的新兵更好。

它们有用吗？不，不是。它们曾经在Microsoft非常普遍，甚至被称为“ Microsoft问题”，并且已经有很多关于它们的书，这本书确实读得很好。

他们有2个问题。首先，如果申请人进行了研究（并读了书），他们无论如何都会知道它们，其次，即使他们能够解决问题，这如何表明他们将是一个好的开发人员/测试人员/项目管理人员。

由于这些原因，Microsoft很少再询问他们了。提出编码问题或不需要“技巧”答案的问题解决问题要好得多。换句话说，您需要提出一些问题，以便在他们尝试解决问题时探索申请人的技能和行为-作为面试官，我希望他们提出问题，提出解决方案，然后在他们找出答案时回头一个问题，也许甚至没有在他们拥有的时间里找到解决方案，但是至少以明智的方式去解决。这反映了现实生活中的工作。我从来不需要用2个桶和一只鸡来测量3品脱（或其他问题）。

就是说，当时我被问了几个棘手的问题，现在我把自己看作是用小船运送鸡和狐狸并计算生活在火车上的苍蝇的寿命的专家。我从不需要使用此信息，但是谁知道呢，也许有一天...。

您可能需要阅读《如何移动富士山》一书？。进入推理的原因是，许多人在面试中都使用了谜语，而我的观点是，这是一种冒昧的行为（“微软这样做了，如果我们想像他们一样成功，那么我们最好做他们做的”和博爱恐吓（“天哪！我必须回答那些问题，您最好相信下一个家伙将必须回答它们！”）。

这些问题作为采访活动的历史始于1950年代的William Shockley。这是面试官提出的一个相当常见的硅谷面试问题，因为其他面试官正在这么做（也许他们知道此面试官不知道的某些内容？）。肖克利曾打算将它们作为一项智力测验，而这两个水桶的问题是1916年斯坦福·比奈（Stanford Binet）最初进行的智商测验之一。

进行面试的人实际上很可能想看看您如何寻找答案，因此他们将无法计算问题，例如您的城市中有多少个气泵。这些问题就是费米问题。杰夫（Jeff）撰写了两篇有趣的博客文章，这是有史以来最困难的面试难题 和您的估算师有多好？第三部分。

就我个人而言，我对这类问题持较低的看法，因为通常采访者不知道自己在做什么，也不知道如何寻找开发人员。除非您要为制作拼图/谜语的公司工作，否则它们会与“什么是您最大的弱点”（回答真相并以一种不好的方式结束面试）一起属于历史的尘土堆上是圆形的沙井盖”（并非全部都是）。

其他的都提供了，我upvoted作为的问题的答案必须的。我写另一个答案的原因是，我想说的内容可能不会包含在注释中，并且因为必须要说一番关于好的编程工作面试的感觉。

我记得在第一个好的采访中，我们聊了很多，并不着急。首先一个小时，通过电话讲一下面向对象的设计以及用C ++实现它的利弊。然后，在现场，我和几个人讨论了他们的软件开发实践，集成，测试，版本控制和配置管理，团队和职责，技术和设计。这是一整天的采访，其中包括与采访我的人共进午餐。事后看来，这就是我是否可以有效地适应他们已经在做的事情。

从那以后，关于软件开发的良好访谈历时很久，只有一到两个小时。没有解决问题的问题，没有难题，也没有编码挑战。

如果我今天要面试某人从事编程工作，那我会喜欢的。我希望就广泛的话题发表意见，并留出深度：

1. 您最喜欢哪种编程语言？为什么？
2. 如何处理异常处理？
3. 分层设计的好处不是神话吗？
4. 持续集成不是效率的负担吗？
5. 谁写的代码应该拥有它，对吗？
6. 您要做什么才能进入“流程”。
7. 报告的缺陷应如何包含在项目计划中？
8. ...

这些都是答案不只一个的问题，它们都是关于软件开发人员应有充分见解的主题。我完全同意提到以前作为对话主题（而不是问题）遇到的实际问题的答案。

自Peopleware以来，有关有效软件开发的更多科学研究表明，最好的程序员是即使不具有最高的IQ也会了解软件开发动态的人。我宁愿选择一个渴望学习的菜鸟，也不愿将具有n多年经验的人归结为1一年重复的经验n。我个人的偏向是倾向于倾向于跳槽思考，同时又知道如何适应当前（我）的候选人。

它们对于评估解决问题的技能很有用，这当然是编程的关键方面之一。

多年来，作为许多人的面试官，我通常不会像您似乎要描述的那样询问疑难杂症类型的问题，但是我很可能会问一些问题并问“您将如何解决...”。

在那种情况下，我的期望是听到您清楚地说明解决问题的方法。您还将尝试收集哪些其他数据？您将如何检验假设等。

这些只是伏都教的聘用做法。其他人问这些问题，使他们觉得自己应该这样做。他们知道不回答问题是“不好”，回答是“好”，但是他们无法告诉您为什么除了诸如“开发人员需要这些技能”之类的非回答之外。这是浪费时间，并且表明面试官不是称职的面试官。

那就是您必须具备基本逻辑技能的老派推理。其他任何东西都可以教。但这并非完全正确。读取布尔逻辑，条件和循环与解决逻辑难题不同。

就是说，在程序语言时代，可以解决这些问题的人可能会更倾向于解决切换方面的问题。但是在我看来，面向对象/功能编程需要一种工程思维方式，这是完全不同的（尽管并不矛盾）。

就个人而言，我不确定是否要在一家公司工作，而该公司仍然认为逻辑比实际编程技能更重要。

免责声明：我非常擅长逻辑难题，如果没有这个基本原理，可能不会开始我的工作。

面试官一定是在提到解决问题和逻辑技能，这是程序员日常工作的一部分。遇到问题时，您需要能够使用最佳方法对其进行分析，细分和编写解决方案。

您可能会争辩说，这样的难题能很好地代表您做到这一点的能力。我看不到提出难题而不是仅仅提出现实生活中的编程问题的优点。

编程与编写代码行无关，而与解决其他人（客户，用户等）的问题有关。

碰巧对于程序员来说，解决方案采用程序的形式。

因此，这就是为什么具有问题解决能力很重要以及为什么要对其进行测试的原因。

话虽如此，我不确定解决棘手的难题是否是评估某人的最佳方法。

面试中的难题分为两类：“逻辑难题”（就像您被问到的那样）和“不同思维”。与此不同的类别（我不确定它们是否也称为横向难题？）通常是这种类型的：那棵树上有多少片叶子？或您的城市中有多少名裁缝？

我对“逻辑难题”很好，因为它们最多只有一个或两个解决方案，并且可以通过简单的逻辑得出。而且我相信逻辑难题在某种程度上是好的，因为解决难题的过程很大程度上是程序员在现实生活中需要思考的方式。

“不同思维”类型给我带来了无限的麻烦，因为它们迫使您做出假设，然后根据这些假设进行一些计算。简而言之，如果您的面试官同意您的逻辑，但不同意您的假设，反之亦然，那么您就迷路了。面试官有太多余地不同意您的解决方案。

当我接受采访时，我不会问逻辑难题。原因：即使我要求3-4年的经验，大多数候选人还是失败或放弃，而我要求他们编写诸如斐波那契数列或回文之类的简单教科书问题。

难题的问题，无论哪种方式，都是不太好的程序员知道，只要在网上查找此类常见难题的解决方案，他们就能打动面试官。很少有人会诚实地说出他们已经知道解决方案。

两点：

1. 编程主要不同于解谜。史蒂夫·麦康奈尔（Steve McConnell）在“代码完成”中对其进行了详尽的解释：

   什么？您不必超级智能吗？不，你没有。没有人真的足够聪明来编程计算机。全面理解一个普通程序需要几乎无限的能力来吸收细节，并且具有相同的能力来同时理解所有细节。集中精力的方式比拥有多少智力更为重要。正如第5章所述，在1972年的图灵奖演讲中，埃德斯·迪克斯特拉（Edsger Dijkstra）发表了一篇题为“谦虚的程序员”的论文。他认为，大多数编程都是为了弥补我们头骨的有限尺寸。最擅长编程的人是意识到大脑很小的人。他们很谦虚。编程能力最差的人是拒绝接受大脑不等于任务的事实的人。他们的自负使他们无法成为优秀的程序员。你越多学会补偿自己的小脑袋，成为一个更好的程序员。您越谦虚，就会越快进步。

2. 这样的困惑在面试过程中可能很有用，但前提是面试官着眼于过程，而不是结果本身。

但我认为，理想情况下，难题应该更复杂并且与编程相关（例如2小时的小型项目）。问题是面试官是人，没有完善的“面试技巧”。

有两种不同的方法可以检查此类问题：

1. 了解先前的解决方案。 在电影中……《复仇者联盟》……向我解释一下……？是了解blah分别为4,3和5的情况的解决方案的示例。某些人将能够快速利用他们对过去解决方案的内部知识，并在需要时进行调整。我通常认为这是面试官所期望的，但这可能不是一个好主意。

2. 即兴创作技能。如果您不知道以前的解决方案，或者甚至不认为该问题是可以作为Diophantine方程建模的问题，就会是这种情况。因此，问题是您能多快地使用给出的内容并以创造性的方式找到问题的解决方案，并解释为什么拥有的东西才是问题的有效解决方案。

可能是使人满意地解决问题的一种方法，尽管在每种情况下，都需要对自己的沟通技巧进行一些测试，因为也可以尝试回答：“这与我所担任的职位真的相关吗？申请这些技能的时间是什么时候？” 如果访调员公开他们到底想知道的是什么，或者在这里，替代方法可能会更有效，那么这可能会导致有趣的对话。

这不是一个特别棘手的问题。仅需要三个步骤，并且每个步骤只有两个选择。如果我的任何同事都无法在很短的时间内解决这个问题，我会感到惊讶。我们不会在面试中提出此类问题，但我认为提出此类问题是合理的。它们肯定比有关语法或库的详细问题有用。

OTOH，我认为编程问题更有用。

您必须记住，没有绝对的方法可以确定某人将擅长工作。尤其是CS作业，因为无法预测该作业可能会遇到的许多挑战。

因此，潜在的雇主必须猜测您未来的表现。

可以通过时间/精力和社会工程来获得学位，建议和GPA，可以修饰和/或虚假的工作经验，坦白地说标准化的测试过于基础，以至于不能过度地表明能力。因此，履历表可能会显示出您历史上的努力/承诺水平，但这些都无法说明您解决计算机科学领域难题的实际能力。除了几个好的逻辑/数学/ CSy难题，我想不出更好的方法来预测这种能力。

请记住，这是一个猜谜游戏，现实是，所有事物都等于我们所有人，宁愿雇用能够解决这些难题的人，也不能雇用无法解决这些难题的人。

是的，您可以研究面试难题，但我认为如果给出的难题与您所学习的难题不符，您会发现自己很生气……而且只要您不记住难题及其解决方案，也许就可以研究难题自己会像任何真正的教育一样，以一种真实的方式使您成为一个更聪明的人。