我可以问面试候选人哪些问题，让我知道他是否是“复制粘贴编码器”？
我们发现，即使候选人在面试中很好地回答了编码问题，一旦进入工作岗位，他们仍然倾向于复制而不是重构。
其他人有类似的经历吗？
问问题
4351 次
9 回答
8
我们面试过程的第一步是一个 5 分钟的在线问题。我们给候选人诸如“FizzBuzz”或“递归斐波那契”或“查找 n 的阶乘”之类的内容。
我们没有任何规则。没有关于粘贴，或者需要编译的代码，或者它应该使用什么语言——只要去做。5 分钟的时间框架迫使大多数候选人走两条路之一——编写一些伪代码（或大部分工作代码），或者谷歌它。
当我们得到答案时，我们用谷歌搜索答案。大约一半的时间，它是从某个站点复制的。我们的期望是，如果他们花 5 分钟在 Google 上找到答案，它不仅应该可以编译，而且应该是解决该问题的绝对最干净、最好的示例。大约有一半的时间，粘贴的答案完全是废话。我们甚至得到了一个没有粘贴整个片段的数字，错过了一大块！
当没有编译器来检查它们时，复制粘贴往往会暴露出来。他们的作案手法是粘贴、编译、调整、编译。如果他们只是将一个网页上的解决方案粘贴到另一个网页上并提交它，他们没有任何信息告诉他们需要修复它。
这非常有效 - 没有人不应该通过电话筛选。
于 2009-10-06T14:57:45.303 回答
5
我有人（详细地）描述了一个比他们为解决问题感到自豪的难题。很容易判断他们是否从未真正了解细节，或者根本没有自己解决问题。描述解决方案时的热情（甚至闪闪发光！）是一大优势。必须热爱解决问题！
于 2009-10-06T14:51:50.573 回答
5
我对候选人也有这个问题。诀窍是减少仅依赖定义的问题数量。您可以向他们提供需要重构的代码，并询问他们将如何改进代码。这是一个非常开放的问题，显示了候选人的想法。
很多面试官喜欢问候选人在哪里编写新代码的问题，不幸的是，开发人员很少从头开始编写新东西。更多地关注向候选人展示现有代码并要求他们使用它来解决问题。
即使有这些问题，也有可能得到一个复制粘贴编码器，因为面试不一定是他们在现实世界中的行为方式。
那是我的两分钱。
于 2009-10-06T14:56:35.833 回答
5
我有两种方法，并且总是同时使用它们。它们总共需要十五分钟，我将它们用作入门级工作面试的最后三分之一。
问一个基于理论的非常简单的问题。
- “你熟悉 Java 中的 Vector 类吗？用伪代码编写支持 add、get 和 clear 的类的实现。” 如果他们不熟悉，请询问 ArrayList。如果他们对任何一个都不熟悉，请解释他们的工作。这个想法是他们可以编写一个链表，并且知道它是什么。
- 如果我当时不确定，请让他们编写一个手动排序列表的方法；不使用 Arrays.sort() 或类似的。让他们解释排序算法。我不在乎他们选择哪一个，我不在乎它的效率如何，任何人都可以。
“你写的最后一篇让你感到自豪的东西是什么？”
于 2009-10-06T15:18:27.307 回答
4
我们编写了一个测试，基本上检查是否有人知道如何/为什么要重构。
我们创建了一个简单的模型应用程序（允许用户创建预定义的形状并在屏幕上移动它们），但故意引入了许多类型的错误。
其中之一是复制和粘贴编码（在多个地方重复相同的功能）。另一个是将每个形状的逻辑嵌入到事件处理程序中。可怕的，可怕的东西——我们能想到的最糟糕的想法。
这使我们能够了解候选人是否会认识到改进的机会以及他们将采取哪些方法来解决这些问题。
这是一个带回家的测试，候选人可以重写应用程序或提供关于他们将进行哪些更改的说明。
于 2009-10-06T15:28:45.133 回答
2
并不是说这是借口，而是开发人员可能复制和粘贴代码的一个原因是他们不理解他们正在使用的代码。例如，如果您聘请 C# 或 Java 开发人员，并让他进入 Fortran 系统并告诉他完成工作，由于缺乏理解，他将在整个系统中复制和粘贴。
除此之外，代码质量也可以在其中发挥作用。我知道一个不允许重构的特定系统，但必须引入新的更改。开发人员必须做他们必须做的事情才能及时完成任务。
当然，这两种情况都不能成为复制和粘贴编码的借口，但值得在组织内部了解一下为什么会发生这种情况。
于 2009-10-06T14:56:47.817 回答
0
If they are on-site, make them whiteboard something. Lets you see how they will divide-and-conquor a problem in abstract. Watch what they focus on, what they omit, ask questions as they continue, and if you want to be a little evil - change the rules halfway through.
Break out parts of it and have them write the pseudocode on the whiteboard.
于 2009-10-06T16:06:04.183 回答
0
不要问常见问题和/或要求他们解释他们的代码。
于 2009-10-06T14:53:02.210 回答
0
你可以稍微修改一下你的方法。做你的技术审查和电话屏幕，当然，这只是你编码测试的挑战。与其提出简单的编程测试问题作为预筛选，不如提出一个他们可以解决的相当复杂的编程项目——可以很快找到一些几乎无法用谷歌搜索的东西。面试后给他们时间来完成它，并要求它是良好的文档且易于理解。然后安排后续讨论，讨论解决方案并询问候选人诸如“你在想什么？！”之类的问题。
我正在考虑的项目类型示例：
- 编写一个程序，在三个玩家之间玩单手扑克
- 为用户提供的随机字段编写洪水填充程序
- 编写一个小的校验寄存器程序，接受来自 .CSV 和起始余额的输入，并输出当前余额，允许用户查看已读取的交易。
于 2009-10-06T15:13:25.307 回答