问“您职业中最有趣的错误”是一个很好的面试问题吗？

#1 楼

我会在这个问题上坚持不懈。

面试问题是一台旨在从候选人中提取信号的机器。让我们检查一下机器的各个部分。


“最”已被评论。为什么答案最有趣很重要？您为什么要要求候选人在面试中解决优化问题？如果他们给您第二大有趣的错误，那么他们失败了吗？当我问一个要求最多的东西的编码问题时，我希望产生最大化的物品。这些是您正在与之交谈的计算机专业人员；除非您要对解决优化问题进行测试，否则不要让它们解决优化问题。


为什么“有趣”？漏洞“有趣”有什么重要的意义？ “有趣”是模糊的。有趣的是谓词，其中包含您没有提供的参数：谁感兴趣？您？现在，您要求职者读懂自己的想法。给他们？现在，您正在测试他们发现有趣事物的能力。人们通常会发现与众不同的“有趣”事物，因此现在您正在询问完全非典型的作品。为什么要向您询问罕见的，非典型的工作信号？您不应该在典型工作中寻求信号吗？

您试图用“有趣”提取什么信号？为什么该信号对您很重要？

此外，无论他们的答案是什么，无论您的问题是什么，答案都会被他们记住。人们更容易记住有趣的事情，最近的事情和重要的事情，因此响应已经偏向有趣和重要的事情。没什么需要大声说出来的。


“错误”。为什么是虫子？这个问题的前提是质量保证的目的是发现缺陷。它不是;质量保证的目的是……等待……代表客户保证质量。有很多确保质量的方法，这些方法不属于发现缺陷的范畴。发现了许多不影响客户体验的缺陷。

我在编译器中发现了许多有趣的bug，对最终产品的质量没有任何实际影响，因为它们处于没有理智的开发人员会遇到的情况。您会从我的详细怪诞的解释中得出什么信号，那就是一个怪异而有趣的错误，不会有任何客户会受到影响。质量检查的工作是发现缺陷。为何候选人发现错误很重要？有很多有趣的缺陷使我磨练了别人发现的工艺。您尝试在此处提取的信号是否具有发现有趣缺陷的能力？

我的团队中有一些人是因为他们具有发现异常缺陷的可靠能力而被专门雇用的。这些是对编译器技术有深入了解的专家，他们被专门聘请以发现通常的QA团队不会发现的缺陷。您想聘请这样的专家吗？它们很昂贵，对于常规的质量检查任务并不是特别有用；那是在浪费他们的才能。


“在您的职业生涯中”-首先，该问题假定候选人有职业生涯；该问题不适合入门级。该问题还假定信号将从候选人已执行的特定工作中得出。我从工作中学到的大多数缺陷是别人发现的，或者是通过静态分析发现的。您希望通过狭asking地询问应聘者在职业生涯中发现的缺陷而得到的信号是什么？


TLDR是：您的问题听起来像是在要求打破战争的“战争故事”；目前尚不清楚它是否会发出良好的信号。我希望将其分解为每个问题都可以发出清晰信号的问题：


为我描述一个从中学到一些重要知识的软件缺陷。缺陷是什么，您学到了什么？信号：应聘者认为重要的是什么？他们从工作中学习吗？示例：我还记得我作为全职Microsoft员工发现的第一个错误；该API中的错误已被错误修复并标记为“已修复”六次。代码中有六个if语句，每个语句处理一个特例！从每天仍会应用的错误中，我学到了很多东西：检查错误历史记录，查找错误农场的代码，检查根本原因并解决，而不是编写经过定制的补丁只是为了使测试用例通过，不要不只是为已修复的错误编写回归；寻找更多错误，还有更多。
为我描述一个您认为很重要的缺陷。有什么缺陷？哪些因素使您认为应优先考虑？信号：候选人是否专注于质量检查的使命，即成为客户的质量倡导者？他们优先考虑什么？他们是否考虑了修复成本与对客户的伤害？是否存在良好的成本效益权衡？他们如何处理在引入新缺陷与修复现有不良缺陷之间取得平衡的风险？等等。

等等。不要只是问一个战争故事。不要要求解决优化问题。弄清楚您真正要发出的信号，然后直接询问。

#2 楼

老实说，我将无法提出任何特别的缺点。 />
如果第五次不得不重新打开缺陷，您将采取什么措施？
您需要重新测试由开发人员解决的缺陷，而无需任何其他评论或解释。除了重新测试之外，您还将采取什么措施？


个人最喜欢的答案：通过变更集查看固定代码


做什么您认为针对几乎无法重现的缺陷（但是有时在生产环境中会发生）的缺陷制定好的攻击计划？
您将如何最有效地测试应该在500个可能的值中的30个变为红色的字段？ />

对我来说，一个好的答案是：在UI中测试一个值以查看系统是否正常运行，然后检查数据库/代码/配置中30个值的列表。

#3 楼

我很想起名字，地点，餐馆和……我调查过的错误。我通常要求我的女朋友或朋友给我一个我们一起去过的地方的名字，或者是与她一起看电影的女演员的名字。这就是我的大脑连接的方式。我不喜欢它，但是我已经习惯了。我想有些应聘者可能就是这样。做事胜于描述。

#4 楼

在上一次采访中，有人问我这样的问题，这花了我一些时间来思考并给出一个好的答案。部分原因是缺乏经验-当时我只担任实习职位。

我读了您的问题后，重复了练习，试图在一段时间内提出我最喜欢的错误接受采访的时间。我很容易就能回忆起上一两周的一些有趣的错误，但是记住那之后的所有细节花费了一些时间。当然，此练习是在没有面试环境压力的情况下完成的。但是，可能需要针对候选人量身定制。举例来说，即使是需要至少一分钟思考时间的人，也可以毫无问题地回答问题，即使他们花了一分钟的时间思考。

如果候选人是新的CS毕业生，也许可以这样询问，使他们指向与他们的经历有关的方向：“告诉我们有关学校或附带项目的开发过程中的某个时间，在那里您被错误或缺陷所困扰，以及最终如何解决了问题。“

#5 楼

我想说的这个问题可能会集中说明候选人对技术的理解，分析根本原因并能够解决问题的深度。

根据我的经验，我可以记住一些有趣的缺陷，但是我认为它们很有趣，因为我确实在代码，环境或人为因素等中找到了它们的根本原因。
如果候选人刚刚发现并报告了缺陷（但并没有试图弄清楚为什么存在这些缺陷），那么这些缺陷将不太可能具有任何特殊的特性引起人们的注意。

#6 楼

我不知道我是否太过直白，但是当我被问到这些问题时，我就迷上了“最”一词。发出一个bug并不难，但要确保我从未见过任何更有趣的错误是一项艰巨的任务。因此，我的建议是摆脱“最”一词。另外，如果您要寻找一般的才能而不是特定的软件经验，则可以将问题扩大到一般的设计缺陷。您还可以给他们举一个发现（或组成）错误的示例，并查看他们提出的建议和问题。

#7 楼

我认为这是一个很好的问题。我认为这可能会帮助您了解：

（a）受访者习惯应对什么样的技术挑战。 （他们选择编程问题，人机界面问题还是系统体系结构问题？他们是否将“错误”解释为不符合规格或不符合业务要求？）

（b ）他们在质量和缺陷预防方面承担何种程度的个人责任。 （他们是问题的所有者，还是其他人的过错？）

（c）他们对问题的根本原因的分析深入了多大（我们的流程有错吗？我们应该如何处理？阻止了这种情况的发生？）

如果在面试中向我提出这个问题，我将很难从很快想到的六个事件中进行选择，但是无论我选择哪个，我都认为这个问题会我是一个很好的机会来介绍我的特殊技能和经验。

我是从开发人员/设计师/建筑师而不是质量检查人员的角度来回答这个问题的。但我仍然认为答案会提供参考。

#8 楼

如果您没有得到好的答案，那么也许您可以稍作修改以帮助受访者。 “有趣”一词可以用多种不同的方式来解释，也许那是候选人被卡住的地方？修复”错误，也许是“最不可能解决的”错误。也许这确实是一个“讨论您发现的最讨厌，最怪异的错误”的机会。

在C ++标准化的年代，我向构建编译器的公司提交了一些错误报告（甚至修复了错误）。这些绝对是“有趣的”。但是，也许当我刚开始并尝试编写脚本语言以便我们的用户可以在我们的产品中运行脚本时，您是否想知道我在FORTRAN中的错误？还是我在IBM磁带机嵌入式软件（当然是预发行版）中发现的错误？还是那个令人讨厌的东西，原来是特定用户的点击和击键顺序与其他人不同？所有这些都带来了我的技能的不同方面。还没有到，或者我觉得需要加强），所以根据您问这个问题的时间，您可能会得到与我完全不同的答案。因为我可以将我的回答建立在谈话要点上，所以您不会学到任何我不希望您知道或尚未告诉过的关于我的信息。感谢这个词“有趣”。

#9 楼

这是一个很大的问题，因为它会将代码复印机/脚本小子与实际的软件工程师区分开来。没有说出他们的名字，但是名字的首字母是I，B和M）将拒绝允许通过SSL向下钻取数据。 ，程序员被困在尝试解决第三方编译代码的问题。尽管有文档，但没有任何效果。是的，必须依法解决。

kiddy对此无能为力。堆栈交换中没有复制/粘贴代码可以解决此问题。

但是程序员-工程师-会说他复制了环境并查看了服务器日志并看到了错误并没有显示在屏幕上，并且他在生产日志中确认了这些错误。程序员会说他反编译了代码并找到了处理协议的IF语句。程序员将看到IF语句如何无法正确处理HTTPS协议，并在代码之外实施了变通方法：使用带有加密的端口号的URL（而不是443）并相应地配置Web服务器。

您雇用哪一位？

#10 楼

我认为在面试中提出这个问题是适当的。我会重新组织这个问题，因为您或您的团队发现了最有趣的错误是什么，并且从中学到了什么？这样，不仅可以找到个人，还可以从团队中的其他人那里学习。

我不记得我发现并修复的最有趣的错误，但我记得我们作为一个团队发现并修复的几个错误。

#11 楼

我已经有足够长的职业生涯，我已经看到并修复了许多缺陷。这些天来，真正的麻烦是要引起任何真正的兴趣，而不仅仅是对有效地描述和纠正问题的兴趣。在某种程度上，我想起过去的错误，我倾向于从现在的角度来看它们。因此，尽管我认为自己在跟踪和压制错误方面相当擅长，但我很难回答这个问题。

此外，由于最近我通常是一个团队，所以最新鲜在我心目中是我负责创造自己的人。从这个角度来看，这个问题有点“你最大的弱点是什么？”的味道。我真的不想告诉面试官所有我能做的大麻烦，即使是在解释我在自己（和其他人）的清理工作方面做得如何的情况下。

#12 楼

是的，这是一个很好的问题。

如果您要问的人真的很喜欢测试，他会很高兴告诉您这个故事。不管他是手工测试员还是自动化工程师，都应该为之感到骄傲（但是我们应该考虑到他是从他的角度讲这个故事的，我的意思是，这个错误对于是一名自动化工程师，但在手动测试人员团队中却是一个很大的错误）

这是我的示例：内存泄漏缺陷。在软件中：有时会以无法预测的方式崩溃（有时在一项操作中，有时在另一项操作中）。那时，我主要使用QTP（现在称为UFT）进行测试，并开始尝试Java测试。优点是很大的：我可以在执行期间检查JVM内存，并在崩溃时转储内存使用情况（使用MemoryAnalyzer-1.6.0）。在分析了内存之后，很明显在程序执行期间有8个对象被重复多次。因此，我报告了某些对象名称的缺陷。开发人员之所以喜欢它，是因为它被认为与这种不可预测的崩溃无关，并且该错误的本地化是最高级别的。

#13 楼

我认为答案和评论都满足了这个主意和这个问题。

我认为这个问题必须以其他方式进行更改，即使在这种情况下，我坐在家里并感到压力很大，我什至很难回答这个问题，甚至很难理解帽子的要求是什么...
如果您的问题主要与情况无关，那会更好，因为：


我们的思维方式如此，它使所有内容可视化，也就是说，我们倾向于从可视化记忆中记住任何东西，而不是那种情况下的每个单词或句子，所以如果我们具体情况，我们将更可能记住它！ >

#14 楼

采访测试人员非常棘手，想要的人就是正在采访您的人。但我不建议在面试中推荐它。
过去成功使用的一种技巧是问一些使人们获得STAR答案的问题。应该采用这种模式，然后看看他们是否愿意为访谈进行研究。

让人们为访谈编写代码仅真正适合于开发人员，因为他们对算法设计的敏锐度至关重要速度和可扩展性。测试人员只会查找它，因为它的可靠性和准确性更为重要。询问测试人员他们如何知道以及在哪里学习。

#15 楼

对于老年人来说，这是一个很大的问题，对于初级测试者来说可能不是那么好。我认为，对于老年人，必须要能够通过一些良好的错误故事向经理，开发人员和其他测试人员解释风险。如果您不能从经验中教书，而您可能只是中等程度的人。 br />
想到的一些故事：



缺少的where子句：第一次遇到缺陷后，我删除/更新了更多数据比我预期的要多，在测试步骤中，我开始使用数据库差异。确保没有比我预期更多或更少的数据被更新。我有个很好的故事，那就是生产中数据丢失的情况，我们在测试中发现了这些数据，但无法复制。之后，这是一个复杂的关系问题，在某些情况下，可能丢失了子句，从而更新了数千条记录。如果我在测试过程中只有数据库差异，那么我可以证明问题，尽管当时我无法重现。

管理员密码是显而易见的：我对Citrix托管应用程序进行了基本的安全测试。几个小时后，我登录到主控制服务器。首先，我可以将应用程序转存到PowerShell中，然后在该文件中搜索所有文件和网络共享，以查找单词password。似乎无人看管的安装脚本本身并未清除。我不是一个伟大的黑客，我只是遵循了如何从Web上闯入Citrix指南。

它可以工作，但客户并不需要它：我有很多故事，我们从现场得到了缺陷报告。我们构建了“必需”的东西，但是使用时出现了错误。标签印刷的情况是一个。我们添加了一种新的打印标签形式，但是它们需要两个标签，但是在打印第一个标签之后，我们会将其隐藏在系统中。现在，不可能再次打印它，除非重新处理整个工作订单，这会导致大量的人工劳动。易于修复，但是客户不想升级，因为他们刚刚开始了为期两周的高风险维护工作。我确信在压力下我不能现场提出一个新的。也许会想到我最近发现的缺陷。

仍然可以要求受访者在他/她进场之前准备一个好的缺陷故事。他们处理了这种情况。点击猴子和调查谜底并从中成长的人之间的区别。

#16 楼

我准备回答类似这样的事情很有趣，因为从支持/故障查找的角度来看，这是软件和用户体验之间的相互作用，并在思考用户的实际操作方式，而不是“这是应该如何工作”透视图。

试图在有问题的软件的一个屏幕中复制观察到的用户错误，我们只是无法使错误发生。我们进行了远程访问，经历了他们的复制步骤，每次都运行良好。我们看着他们做这个过程，而且每次都起作用。但是，每次将它们留给自己的设备使用时，最终都会引发间歇性错误。最后，由于实际上有人在现场观察，而没有直接告知用户我们正在观看，所以我们了解了发生的情况。事实证明，最终用户对软件非常满意，因此打字，浏览屏幕，选项和键盘快捷键的速度大大快于几乎其他任何人都无法管理。现有的程序不能完全跟上用户输入的速度，这暴露了输入处理中的一些错误。更重要的是，每次我们观看它们时，用户都会放慢一些速度，既有意识地确保我们可以看到他们在做什么，又无意识地花费更多的时间和精力来避免他们因做错事而受到暗示。因此，当他们知道我们在观看时，它当然就没有这样做。

#17 楼

最有趣的缺陷（IMHO）是缺乏团队沟通


由于人们已经对它是否是一个好问题给出了很好的答案，所以我不再赘述但是，我分享了一个有趣的经历。在小组会议上，一个有趣的启示表明，功能完全可以正常工作并且可以按要求正常工作，但是实际使用情况与开发人员和测试人员所设想的完全不同。

最后，我们发现屏幕业务场景和用户输入是完全不同的，当前实现的功能已完全正常运行并经过测试，但对业务完全没有用。在团队中是“团队沟通”。

*一个沟通良好的团队可以在实施任何操作之前首先防止很多缺陷。