如何处理“错误代码”面试？[关闭]

“错误代码”面试是向受访者显示一小段“错误代码”，并要求其纠正或指出错误的地方。我在进行这些采访时遇到了麻烦，因为我花了一些时间来阅读代码，弄清楚代码的作用并指出缺陷。在有时间压力的情况下，我倾向于停滞不前，我发现代码“应该”起作用，即使它不起作用。

什么是处理这种采访的好方法，更广泛地讲，有什么好的技巧可以快速阅读和理解代码？

错误的代码访问（如果正确完成）应该向您显示以下代码：

• 不良的语言技巧（using在需要时不使用C＃中的语句，或使用ArrayList代替List<T>）
• 一个糟糕的设计决策（为什么我们到底要在各处传递字符串，还是使用ref和out参数太多？）
• 语法错误（甚至不应该编译！）
• 运行时错误（例如由C＃中引用其自身的属性引起的堆栈溢出）

有一个心理检查清单，您应该仔细检查一下上面的每个要点。如果您不能看代码而不能这样做，那就是改进的地方。无论您声称自己精通哪种语言，都应该能够查看一段代码并指出这四种错误。

我最近在博客上写了一段展示了所有这些问题的代码，它应该可以帮助您经历相同的思维过程。

Ayende 的《罪恶之薪》系列更加深入。

不要试图快速理解它。这里的目标不是看您是否能像专家一样理解代码，而是看您的想法。

IMO的关键只是大声思考。因此，即使您定格了，也可以说：“我在这里压力很大，但是让我慢慢地大声地讲一下”。

假设您具有大声思考的能力，将使您的速度减慢至足以使您的思维正确。如果面试足够精明，他们会看到您的情况并帮助您，直到您清楚地思考。他们不会试图欺骗您让自己看起来很愚蠢-只是一种了解您的想法的有力技巧。

奇怪的是，您感觉到的“时间压力”完全是自我施加的。这更多与您自己的不安全感有关，并担心您的评估水平如何。

任何人都可以提供的最佳建议是：放松。花些时间，看一下代码，然后谈谈所看到的内容。随意谈论优劣之处；这将有助于减轻您的紧张感，并内在地担心时间流逝。

此外，通过不同的“通过”可能会更容易发现特定细节。一遍寻找不匹配的括号或错别字。换另一张通行证寻找混乱的行。再找一个寻找椒盐脆饼的人。专注于一种“错误的事情”可能会更容易发现这些细节，并且（再次）减少您内心的声音，质疑您是否做得足够快/足够好。

最重要的是，通过您的工作和思想进行交谈-这将对您和面试官都有帮助。

我从来没有在这样的采访，但是当我试图做好工作棘手的一段代码，我可以怀疑的是不好的，我有时会悄悄地自言自语。我发现发声有时可以帮助解决问题。同样在面试中，您可以尝试以图表或铅笔和笔迹追踪执行的步骤。这曾经在学校为我工作，有时仍在工作中。YMMV，当然...

我认为从“调试”开始是一个不错的起点（如果您看不到任何明显的东西）。除非立即发现可能的问题，否则一个好的开始是列出一小部分测试值。好的值是“快乐路径”（正常）值，“零”或“空”值，空值，很小的值（1个字符的字符串，整数1等），很大或很长的值值和特定于类型的“奇怪”值（例如，字符串的Unicode字符，整数的负数等）。在这里提到，通常您将使用这些值来编写单元测试来测试代码，而只运行那些代码来验证功能就不会感到无所顾忌。

首先介绍您的快乐路径值。对于加法函数，您可以从3或4开始。检查每行是否存在拼写错误和逻辑错误，并在运行时跟踪局部变量的值。希望您会发现一些错误。完成幸福的道路后，您将对代码有更好的了解，并希望自己不会感到不知所措-像这样说：“现在，我对代码的工作有了更好的了解，我然后退后一步，看看它。”然后这样做-寻找与您将做的事情不同的事情（错误的设计决策，命名错误的变量，调查可能的错误等）。

如果那没法让您走到前面，或者您觉得自己已经无话可说了，请返回测试值列表，然后重新进行测试，找到可能会引起问题的新值。

这至少会帮助您前进。

正如史蒂芬·贝利（Stephen Bailey）所说，在这种情况下，大声思考是一种出色的技术，因为它可使您的面试官看到您的思考过程。可以解释一下您要弄清楚的内容。您可以做的另一件事是，在对代码的缺陷进行诊断之前，让访问者知道您将正确地阅读代码。我一直在桌子的两边，我知道在这种情况下，双方都可能会感到沮丧。

如果您觉得做笔试的压力不大，请拉出笔记本，开始做笔记。在采访中，我抽出一个笔记本，开始草拟笔记，这是我思考过程的一部分。拥有笔记本和笔会让您看起来井井有条。您可能会写下一些要查找的要点，语法，逻辑错误，数据类型不匹配，局部变量的值（列表可能会因您获得的代码类型而异，我的复杂SQL列表会与在处理过程中得到的不是以数据为中心的一段代码的人不同），等等。一旦您编写了其中一些代码，便开始寻找它们。这样，即使您没有在面试官想要继续之前找到所有问题，他/她也将能够看到您要检查的事情的列表。如果您事先创建了可能要查找的内容的清单，那么您将对知道计划要查找的内容感到更加自信。通常，这些问题更多地是关于如何找到错误而不是实际找到所有错误。

我参加这个聚会有点晚了，但是您可以使用的一种技术是为有问题的代码编写单元测试。然后，您可以将精力集中在代码的根本错误上，而将更多的精力集中在所要查找的预期结果上。我宁愿雇用可以编写良好测试的人员，而不是可以立即发现一段代码出问题的人员。

可能有两个问题：

这可能是一次“压力面试” http://en.wikipedia.org/wiki/Job_interview#Stress。采访者试图查看您如何应对压力，因为他们的工作环境如此。

要么

您可能会感到压力重重。在这种情况下，您将不得不处理这种压力，例如自省，看看如何保持冷静。