提出公平的技术招聘挑战

如何在尊重时间的同时区分申请人

在工作面试中，我总是讨厌编码挑战。 公司看起来越有趣，任务就越模糊和广泛。 在花了一个或两个周末建造东西之后，随着截止日期的临近，我开除了这封电子邮件，但没有。 数周。 在没有跟进的情况下，我从没有收到任何任务的反馈，而且在一个案例中，尽管遇到了广泛的编码挑战和现场采访，但我什至没有受到拒绝！

经常面试软件工程职位的任何人都可以建立联系。 精疲力竭， 无关紧要的采访是我们行业的主食。 就我而言，我发誓不去编码挑战，并积极游说反对在以后的工作中实施它们。

我最近重新考虑过，并想与您分享我们的动机，我们如何使该过程对所有相关人员公平，以及我们学到的知识：包括一些数据和统计数据以及有关如何改进该过程的建议。 最后，我们推测如何使渠道更加平衡-例如在性别方面。

我们正在招聘Python后端职位，您可以在此处找到挑战 。

动机

是什么改变了我对编码挑战的想法？ 我有一个愤世嫉俗的动机，和两个高尚的动机。

The cynical motive

我可能在这里会失去你们中的一些人。 我成为了一家新创公司（ corrux ，是的，我们正在招聘 ）的CTO，简直就是埋葬了为任何职位招聘所需的时间。 简历可靠的候选人在手机屏幕上表现出色，根本无法在现场采访中回答更多实质性问题。 少数可以拒绝该职位的人。 我非常需要一个更好的系统。

The candidates asked

候选人实际上要求我完成编码任务，以代替（或除了）技术面试。 这对我来说是一个很大的惊喜，但他们的理由很简单：corrux仍然是一家规模较小且相对未知的公司。 他们想知道他们每天会做什么样的工作，以及我们是否可以提出一项引人入胜，尊重他们的时间并且切合实际的任务。

最后，没有人选择接受这项任务的技术面试。

Our interviews were inconsistent

我让我们的一名初级开发人员参加了一次实习生候选人的面试-她自己几个月前才开始面试的工作。 之后，她指出这次采访的布局与她在采访中所经历的大不相同。 她坚持要求我们在流程上保持一定的一致性是正确的，并向我指出了典型的Matasano招聘职位 ； 如果您还没有阅读过，那绝对应该！

公平吗？

挑战的公平性当然有待辩论。 在这里，我们至少要处理两个公平的定义：我们要求候选人的公平和评估的公平。 我们希望我们的过程是公平的候选人中考生和公平。

在Matasano招聘职位以及我自己在招聘挑战方面的负面经历的帮助下，这是我想满足的重点。

Objective scoring

候选人应该确切地知道他如何被审查。 这可能是使编程挑战公平的最重要的事情。 给您和候选人带来很多好处：

• 客观评分会迫使您考虑如何以一种标准化的方式评估提交的内容。 这不仅可以为您和其他审核者节省大量时间，还可以使应聘者了解您的文化和价值观。 例如，您是否对干净，结构良好的代码投入了很多精力，还是仅在获得正确答案方面得分？ 即使是正确的，实现的复杂性也很重要吗？ 考生获得包括测试和文档在内的额外积分吗？

• 它可以帮助时间紧迫的候选人确定解决方案的哪些部分的优先级。

• 使您可以快速建立分数分布，从而向您显示应聘该职位的候选人的素质。 根据响应的差异，这可能会花费一些时间，但会在有人做出异常响应或您的挑战太容易或太难时通知您。

我们花了很多时间试图提出一个客观的计分卡，仍然可以很好地区分候选人。 供参考，这是我们对提交内容进行评分的方式。

尊重候选人的时间

一项范围广泛，定义不明确的任务表明您缺乏对候选人时间的尊重，并且对您作为招聘经理的反映不佳。 如果这是您编写招聘任务的方式，那么您如何在公司内部传达任务？

明确定义的特定任务应尊重所有经验水平的候选人。 对于合格的候选人，她可以立即估计任务应花费多少时间。 对于不合格的候选人，她应该能够立即看出自己已经超出了深度。 在这两种情况下，候选人都可以自己决定时间投入是否值得冒险。

我们的任务定义清楚了吗？ 看看自己看看！

Use blind review when possible

长期以来，人们一直怀疑诸如“ 文化契合度 ”之类的不精确标准是一种更加可口的现代歧视化身。 即使事实并非如此，您还是要使用盲目审查，因为这是良好实验设计的基本原则。 对于评分的主观部分（ 代码样式和约定） ，我们使用了盲目检查。

Be realistic

不要让求职者对二叉树求逆，除非那是您在公司中所做的事情，或者您有太多求职者可以摆脱它。 对我们来说也不是这样。 毕竟，这对候选人来说是对我们进行审查的机会，而对于我们对他们进行审查则是他们的机会，因为他们想要的东西尽可能与他们在工作中实际所做的尽可能接近。 就我们而言，我们做了一个玩具任务，在发布时嘲笑了整个后端。

Provide feedback

无论您多么尊重候选人的时间，这对于他们来说仍然是一项冒险的时间投资。 如果您提交的职位多于职位，那么就不会有人找工作。 他们不仅应该知道他们在客观意义上的表现，而且还应该知道他们与普通候选人的比较。 此外，如果可以的话，还应包括审阅者的具体反馈。

为此，一旦我们提交了两个以上的项目，我们就会在回答单个候选人的分数时包括所有候选人的分数的均值和标准差。

Alert immediately

如果您要进行滚动评估，或者在截止日期之后的固定日期，请尽快向候选人提供反馈。 候选人已经投入了大量时间，应该知道自己的立场。

数据

我们从每月的Hacker News“ Who's Hiring”线程以及欧洲招聘平台tias.io中获取渠道 。 最后，我通过电话筛选了9名候选人，团队审核了4份代码提交，然后我们录用了1名。

为了提供类似基准的信息，我向团队分发了简历，并向我的一些同事提出以下要求：“给我这些候选人的简历的评分，评分范围为0-5，其中5完全适合这份工作，而0根本不合适。”

候选人编号为1–9。 每个点代表corrux工程师的简历评估分数。

评论到处都是：我认为令人惊讶的主观！ 我们没有足够的代码提交来使CV的适用性与代码提交的得分之间有很强的相关性（请参阅下文），但是这种传播令人惊讶。 除了通常的偏见，我们还想知道：看到一所名牌学校或公司会对我们有多大影响？

接下来是代码审查的分数。 记住，这是单盲的，所以审阅者不知道哪个代码对应哪个CV。 尽管我们只有少量结果可以进行，但审阅者之间确实存在更多共识：

如果我有更多收到的意见书，我可能会写另一篇关于简历筛选的文章。 为什么？ 因为在我们公认的小样本中，简历复习分数和挑战分数之间的相关性至少可以说是微不足道的：

您可以看到几乎没有任何关联。 实际上，与最佳代码风格相关的回复之一在（提交代码的候选人的）简历审查中得分最低！ 当然，必须有一些关联。 没有编程背景的人应该一贯得分为零，并且简历完全不合适。 要弄清楚这种趋势有多弱或多强，您需要等到我们成为更大的公司之后。

请注意，我没有包括挑战正确性部分的分数。 那是因为没有差异：每个能够完成挑战的人都可以以相同的程度完成挑战（更多内容请参见下文）。 但是，我们发现对组织和风格的评分足以区分我们的情况。 毕竟，您是否不希望与撰写内容丰富的注释，具有干净的目录结构并添加测试的人员合作？ 即使我们指定这将是评估的很大一部分，但一些候选人还是忽略了这些观点。

def hours_since_last_maintaince (now: datetime.datetime) :
    """
    Calculates hours since last maintaince as specified in the excavator stats 'most_recent_maintenance' field
    The implementation is straightforward, look for the excavator object with the latest timestamp and get the data
    from there subtracted from now
    :return: hours in decimal format (2 signifact digits) since last maintaince
    """
    records = _get_records(EXCAVATOR_STATS, find_dict={}, sort_list=[( "timestamp" , -1 )], limit= 1 )

    if len(records) == 1 :
        latest_record = records[ 0 ]
        seconds_since_maintaince = (
                now - latest_record.get( 'most_recent_maintenance' ).replace(tzinfo=pytz.utc)).total_seconds()
        hours = seconds_since_maintaince / 3600
        difference = float( '{0:.2f}' .format(hours))
    else :
        difference = { 'error' : "no excavator data found" }

    return difference

来自最高评分的提交之一的干净代码示例。 经许可使用！

经验教训

Grading to a curve

我们希望尊重“ What's Fair”部分中的所有要点，同时仍然要使挑战变得足够困难以提供候选人之间的真正差异。 在我们的案例中，对代码质量和测试覆盖范围的评分确实使考生分开。 但是，每个能够提交有效解决方案的人在正确性方面的得分都差不多。 这是否意味着任务太容易了？ 也许。 进行更精细的任务来评估正确性将是另一种帮助方式。

Have a deadline

我感到遗憾的一件事是，所有候选人的开始和结束日期都不同。 我们是一家小公司，希望迅速填补这个职位，因此我们告知所有候选人，所有申请都被滚动接受。 后来，我对应聘者感到有些内，“我们面临着编码方面的挑战，但我们已经和几个人进入了最后阶段。” 幸运的是，据我所知，他们都没有尝试完成任务，但这仍然不公平。 滚动提交意见有利于那些恰好在您告诉他们的那一刻有时间进行处理并且恰好在一周前被电话屏蔽的人。 显然，这并不是与工作绩效相关的特征。 它还可以与您所在领域代表性不足的人群中的人进行对抗。

Build a fair pipeline

The pipeline problem is a hotly debated issue in tech hiring. Whatever your thoughts about the causes and consequences of gender imbalance in tech, one thing is for sure: women are underrepresented and it's particularly bad in Germany . In our case, out of the nine applicants, two were women. That's 22%, which is pretty close to the 17% given in the linked article.

如果我可以发表这样的声明：“为了使这个过程公平，我需要有3名女性候选人”，那么我可以用负二项式分布建模要面试多少候选人。

负二项式分布有助于回答以下问题：“如果阳性结果的概率为p，我需要进行多少次实验才能获得n个阳性结果？” （与性别不同，伯努利试验是二元的，请简化一下）。 更确切地说：“如果我想确保50％的渠道包括3名女性，我应该采访多少位男性候选人，而候选人成为女性的概率为22％？”

这是负二项式分布的概率质量函数。 在此，如以上示例中那样，n ＝ 3且p ＝ 0.22。 从0到9位男性申请人的阴影区域表示3位女性申请人的可能性为51％（即9岁时的CDF为51％）。

这个模型告诉我，在我采访3位女性之前，我应该会采访9位男性。 这是令人鼓舞的，因为我实际上采访了7位男性候选人和2位女性候选人。 但是，如果我想获得90％的把握怎么办？ 我们将不得不采访约20名候选人（想像一下将地块遮阴以覆盖90％的区域）。

这可能会有些麻烦，特别是如果候选人随着时间的流逝而滴滴答答。 如果我住在应征者只有5％的女性的地方（p = 0.05而不是0.22）？ 该模型表明，在我可以半确定自己的管道中包括3名女性之前，我需要采访51名候选人！

如果我们着急的话，我们可能已经注意到3大约是14的22％并已完成。 但是那有什么乐趣呢？

尽管这种方法并不适用于所有职位，但我们希望将来将其用于团队已充分理解的技术职位。 我们也已经成功地将其应用于业务职位。 这也使我们考虑了如何平衡我们的业务流程，并继续最大程度地减少招聘实践中不相关的偏见。

谢谢阅读！ 如果您对招聘或招募有任何疑问，请与我们联系 ！ 如果您有兴趣加入，请在此处申请。

Bauma 2019的团队

From: https://hackernoon.com/making-a-fair-technical-hiring-challenge-iu12q30im