导读：关于面试的“侮辱”性表现，开发者应该勇敢说“不”。为什么，看本文。

最近，我在指导一些学员完成开发人员的面试时，看到很多的是侮辱性的操作。

许多公司常用以下两种方式之一“侮辱”开发人员：

• 要求别人一种不可能，非常可笑的时间完成密集型作业

• 对候选人和面试官都没有用的白板面试

我们来谈谈这些问题，以及为什么我建议各位拒绝侮辱性的面试机会。

带回家的工作

我的经验法则是：如果带回家的工作需要一个多小时（可能得 2 小时多）并且没有任何报酬，那么你就应该有更好的方式来利用时间。

想象一下，一位建筑师被要求完成一项带回家的干建筑的活，或者一位外科医生被要求做带回家解剖。这太荒谬了！这些人是专业人士。

作为一名专业开发人员，被要求做这些愚蠢的任务也是一种侮辱。

如果每家公司都要求一份详细的带回家的工作，那么你的整个求职将是数小时的免费工作。

此外，开发人员的需求量非常大！公司需要了解，他们是在招聘IT领域工作的高技能专业人士的人员。公司需要证明我们为什么要为他们工作，而不是相反。

当公司不了解这一现实并且不尊重开发人员的时间时，这便是一个危险信号。

我知道当你说不时，感觉就像要“失去”一个机会。但我发现，如果你明确自己民的期望并坚持原则，这样有助于你避免被利用，并且实际会吸引高质量机会的天赋。

白板访谈

在白板上进行的访谈毫无用处。他们大多是“抓住了” —— 来自面试官显得比你聪明的戏剧表演。

白板面试与软件工程的实际工作毫无相似之处。一些典型例子如下：

• 在解决方案不足的情况下，面试毫无意义。回答面试者随意编造或其他一些小的编码问题会浪费我的时间。

• 在必须找出解决方案的复杂情况下，我是否要在时间限制下，使用理想算法正确解决问题。这也是一个废话。

• 如果你雇用我作为一名软件工程师，那就是要决定如何解决问题、权衡实施和部署策略。在白板上解决一些毫无意义的算法并不能说明这一点。

• 当我专业地编写代码时，我会使用各种工具来编写干净、高效的代码。带走我的IDE、测试运行器、Git等只会妨碍我在现实生活中解决问题的能力。

解决问题

那么，我们该怎么办？

事实上，放弃面试比拒绝带回家工作要难得多。每个面试过程都变成了一个你在哪里划线的问题。

在某些情况下，您可能会喜欢与面试官的对话，并发现他的问题很有趣。也许你并不介意解决它或至少尝试去解决它。只需熟悉基本策略、常见解决方案/结构，并在手写代码时练习说话。

在其它情况下，当很明显面试官在这个过程中没有付出多少努力时，你可能会直接质疑任务的性质。

你可以会问白板问题与你将在这家公司从事的工作有什么关系。

企业能做什么？

有很多研究数据表明，通常情况下面试没有太多帮助。你只是随意挑选一些名字，公司走一遍不同团队的流程服务。

面试，很大部分意味着你将雇用的是擅长面试的人，不一定是擅长干活的人。

但是，我认为公司不会很快转而恢复正常的思维，大多数的企业都需要一些程序来审查候选人。

在我上一家公司，我帮助设计了技术面试流程。以下是实施细节：

1. 我们花时间开发了一个示例应用程序，展示了我们在公司工作时遇到的一些数据结构和具体问题；

2. 带回家的工作是在更大的示例应用程序中完成两个功能。我们已经为这些功能编写了测试用例，因此应聘者只需执行 TDD ，并判断自己的代码是否通过。

3. 当候选人到达面试地点时，我们对程序功能进行了小规模的代码审查（就像你在现实生活中审查代码拉取请求一样）

4. 然后，我向开发者提出了关于他们代码的扩展问题：如果我们只想对数据库只进行一次查询怎么办？你可以用什么结构和策略来缓存这些数据？如果数据集有数千万行，你会怎样做？需要怎样重构你的解决方案？

我收到了一引起这个过程的积极反馈。因为，它可以直接让候选人参与到当前公司正在解决的问题中。当我们要雇佣某人时，他们在第一天开始工作时就对我们的一个核心数据结构有了基本的了解。

这一面试过程尊重了开发人员的时间，同时他还参与了对代码、重构和方法的权衡，进行更高层次的思考。

就算他没有解决问题，也对后续的面试和工作也有帮助。大部分有良好解决问题能力的人从此不会被埋没，我们有一个良好的开端和了解，后续一起工作将更加舒适、顺畅。

作者：场长