工程过度是警告标志吗？[关闭]

因此，我们向具有明确定义要求的新候选人提出了直接的编码练习。有时，我们收到的解决方案并不能真正解决眼前的问题，而是过度设计以解决感知到的问题-通常不在练习范围之内。

现在我的问题是，这是一个警告信号吗？

编辑：相当多的讨论是基于有缺陷的测试-这是一个公平的观点。正如我在评论中所述，测试的基本前提是展示如何以一种明智的方式从文件中读取数据（并且您会惊讶于我们看到的各种方法），以及如何匹配计算更新之间的延迟之前的项目。现在，要使此方法起作用，必须对数据做出某些假设，我们将寻找这些假设，并且还明确声明我们希望在两小时内看到您采用的方法（包括OO方法等）。大体时间。

恕我直言，当我面试时，这是我遇到的最完整的练习。

我正在考虑的一种特殊情况是，候选人而不是从文件中读取多线程应用程序中的“网络”输入，这显然不在范围之内。

问题是测试偏斜。您是在要求某人通过一个简单的练习来证明他们编写复杂的企业级软件的能力，只需花费几分钟。其他公司的其他面试官也抱怨说，候选人在这些练习中没有表现出足够的面向对象设计技能，因此人们倾向于过度补偿。这并不一定意味着您的候选人在情况允许时不能使用更简单的代码。

如果您想知道应聘者是否属于这种情况，只需请他们重做，并为他们提供一些具体准则。说，“我可以看到您展示了您的面向对象的设计技能，但是对于这样一个简单的问题来说似乎有些矫。过正。您可以仅使用两个小功能来重写它吗？”

我想说这是一个明确的警告信号，但不一定取消候选人资格。

候选人似乎有两个独立的问题：

1. 缺少练习的要点 -这相当令人震惊。如果某人无法提出他们正确解决的问题，那么世界上所有的编程技能都不会产生良好的结果。我发现，最有生产力的工程师是能够确定要解决的真正问题的工程师，即使这并不是所提出的问题。能够批判性地思考所提出的问题，并且可能将其重新表述为更容易解决的问题，这是一项关键技能。如果没有明确指出问题，那应该是一个很大的危险信号。
2. 解决方案过度设计 -这是第二个问题，通常是第一个问题的结果。有几种不同的病理可以导致此结果。首先，如果不正确地理解问题，或者过于广泛地解决问题，可能会导致解决方案过于复杂。这显然与上面的第一点有关。其次，尝试通过思考可能不太相关的未来方案来“炫耀”。这可能是有问题的，因为它表明应聘者直到真正必要时才了解解决方案中简单性的价值并推迟了复杂性。在良好的指导下可以纠正此问题，但是在将某人带入组织时要当心。

在整个过程中，我建议跟候选人跟进他们的答案。与其简单地查看他们的结果，不如确定导致他们走向结果的原因，并给出一些指导，他们将如何应对并改变他们的答案。这可能会更多地显示出他们的能力，而不仅仅是他们对问题的直接反应。他们的方法的“为什么”可以使您了解他们是否只是不了解它，或者他们的理解在他们如何选择应对方式方面略有偏离。这种跟进还将揭示他们解决问题的整体方法的更多信息。

另外，重新检查问题本身，看是否可能不清楚，并可能导致人们在制定答案时走上错误的道路。

不，不是在面试中。太多的访调员会做一些事情，例如故意低估要求并期望被访者提出其他问题，或者关注未明确提及的现实问题。

在我脑海中，有些事情您的要求可能没有提到：

• 编码标准

• 评论

• 异常处理

• 变量，类，方法的描述性名称

• 遵循惯用的语言

• 正确的面向对象设计

• 注意可能的并发问题

• 为代码编写测试用例

您是否只关注其中一件事情而没有明确说明？候选人将如何知道您在乎哪些，而您不在乎？

面试是高度人为的环境。面试官经常试图“欺骗”候选人，以使面试官很难告诉他想听的任何内容，而面试官则试图猜测面试官真正想要的是什么。

通常，在该猜测上犯错误与在现实世界中的设计决策中犯错误完全不同。如果您想知道是否有人过度设计了事物，则可能不得不谈论设计，而不是进行非常人为的编码练习。

恕我直言，答案显然是，如果有的话，这是一个警告信号

• 编码工作有明确的任务
• 有明确的要求（也写得很好），
• 候选人有机会提出问题，以确保他们解决正确的问题。
• 您需要的是聪明的人，并能在团队中完成工作，而不是建筑宇航员。

没有警告标志不如不能解决眼前的问题那么大。他未通过测验且未提供正确的解决方案的事实是一个警告信号。这不一定是一成不变的情况，因为这取决于他如何以及为什么没有提供正确的解决方案。

很多时候，问题是完全废话，根本无法回答。不要假装面试官永远不会犯错。他仍然无法弄清这个问题为什么是废话。如果您正在招聘一名有望帮助您提出要求的工程师，那将是一个问题。如果您正在聘请编码员，就别指望他这样做。

假设编码工作并没有被搞砸，看来他失败的方式是错误地解释了问题，然后进入杂草试图解决一个不存在的问题。是的，这是一个警告信号。

也许。

不解决问题当然是明确的警告信号，表明有问题。什么地方出了错？他们要么误解了问题，要么提出了错误的解决方案。对于简单的事情，不好的解决方案是候选人明显的信号。

如果他们误解了问题，请仔细阅读您的要求。即使您看似清楚的事情，对于不熟悉域或来自其他背景（地区，年龄，成长背景）的其他人也可能不清楚。如果应聘者和您一起在房间里，或者提供了提问的机会，但仍然失败了，那么我认为这是他们的失败。如果把要求扔到了墙外，我可能会给他们带来疑问的好处（并考虑解决面试过程）。

如果解决方案是正确的，那么它将变得不清楚。我个人认为，有些人把YAGNI推得太远了。如果您可以解决一个特定问题并创建一个通用解决方案，而又不增加复杂性或损害可维护性，那么为什么不制定通用解决方案呢？（考虑反转字符串与反转任何集合）在我看来，这种“过度设计”显然是好的。

其他一切都是那片灰色的中间地带。解决方案是否解决了变化的轴心？解决方案是否会增加复杂性或损害可维护性？增加一点复杂性来解决几乎可以肯定会成功的未来问题。极大地损害可维护性以解释完全不可能的事情并非没有。

成为一名优秀的软件工程师意味着在这里取得适当的平衡。成为一名优秀的面试官意味着对候选人如何以及为什么选择这种平衡做出正确的判断/推论，通常会使用面试的其他部分进行评估。

也许要考虑以下因素：

• 面试很难：人们承受压力。您在给某人的任何问题中都应将此因素作为重要考虑因素

• 需求长度：需求多长时间和直接？您是否让他们特别罗word，以确保您包括所有内容。因此，它们可能对您很清楚，但要求可能设计过度！我花了一个小时的时间进行一次面试，问题相对简单，大约3页文字。有时，所有这些文字在面试中可能很难阅读和解释，也可能会被误解。

• 有时，少即是多：我宁愿有一些要点，句子和/或示例显示主要要求，然后与某人进行讨论以提出问题，并在需要时与他们联系。我想我想说的是，对于一个简单的问题，您应该首先检查测试要求是否过于复杂。

• 沟通技巧：您应该测试应聘者首先进行沟通并提出有关问题的智能问题的能力，一旦知道他们已经证明他们理解问题，就可以提出实施建议。

• 底线：如果您尚未检查问题是否得到理解，那么您真的不知道如何处理过度的工程。正如其他人所说的那样，这可能是好事或坏事，但是如果您没有事先检查理解或与应聘者就问题进行沟通，则很难知道他们对问题的一般理解和解决方法。

这在很大程度上可以归因于您如何表达问题以及如何将整个访谈纳入视角。

就像，“让我们看看您的创造力如何。2 + 2是什么？” 四个？您能想到的只是最简单，最明显和最准确的答案？渴望在面试中留下深刻印象的年轻/入门级开发人员会选择“我们要测试您的编码技能，或者看看您的程序员有多出色。” 意思是“做一些非常复杂的事情”。我们都喜欢认为简单是最好的，除非它会使事情变得更加困难。

有多种方法可以查看某人是否总是总是过度设计。给出一个过于复杂的代码示例，并寻求更简单的解决方案。当某人提供您认为不可行的解决方案时，这是一个很好的机会，可以看到他们对批评的反应。就个人而言，我希望看到有人对新想法持开放态度，并比一个又一次犯同样错误的人认可更好的解决方案。

实际上，难道我们不总是有机会在不起作用时更改代码吗？您可以先进行设计，也可以进行过度设计。一旦认识到简单的解决方案，难道不是更容易实现吗？

这取决于，但通常不行。

通常，设计是一种从经验中学到的技能。Aaronaught对由Marjan链接的进展的描述通常是很好的。

任何形式的交流也很大程度上取决于环境。在一种情况下似乎很清楚地意味着一件事，而在另一种情况下似乎也很清楚地意味着另一件事。知道要问哪些问题也是经验带来的。

他们的思维过程以及他们对决策的推理方式比解决方案重要得多。如果不与他们一起审查他们的解决方案和决定，您将无法全面评估其开发的环境。

鉴于以上的进展，解决方案过度设计的候选人可能比简单解决方案的候选人要走得更远。

另外：您正在招聘什么级别的职位？与入门级或中级候选人相比，过度设计不是一个问题。

如果程序员没有解决问题，那么所有额外的代码就是程序员试图掩盖非答案。这与对主题不太了解的学生在作文测试中使用的技术相同。他或她将在一个引人注目的但无关紧要的问题上走来走去，希望他的无知被字数掩盖。

如果程序员确实解决了问题但添加了大量代码，请考虑程序员的背景知识，因为某些编程领域比其他领域需要更大的容忍度。

例如，与免费的Android游戏相比，在商用客机上运行自动驾驶的代码对失败的容忍度要小得多。如果开发人员曾经习惯于对难以访问且几乎无法更新的嵌入式设备进行编程，则将倾向于编写更多的假设代码，而如果开发人员每天可以推送15个更新。