首页
学习
活动
专区
工具
TVP
发布

百亿美元“独角兽”Lyft是如何设计机器学习软件工程师面试的?

Lyft的使命是通过全球最方便的运输工具来改善人们的生活,如果派发车辆接送时要手动匹配司机和乘客,那么Lyft将需要经历一个极其漫长的过程才能达成使命。因此我们需要自动化的决策方式,并通过增强可扩展性来优化用户体验和市场效率。作为科学家岗位的补充,我们需要一些具备机器学习实践能力并了解业务的工程师,他们能够独立地构建模型并将其产品化,从而优化Lyft的产品体验,使出行成为一种享受。 大约一年半之前,Lyft开始搜寻这类机器学习人才(有时候我们称之为机器学习软件工程师,ML SWE:Machine Learning Software Engineer),我们当时看了其他公司同类岗位的招聘信息,但是那些招聘内容都不太符合Lyft的业务要求,我们不得不建立一个全新的岗位和招聘流程。

大多数公司对面试的岗位、面试过程和准备面试的注意事项都持有开放态度。他们的面试官在面试时会给出口头提示,提供书面指引,甚至会雇佣整个工作室来制作特色宣传影片。但有一点你很可能不会知道,就是他们想出这些点子的过程。坦率地说,我们其实也不知道。

典型的面试流程漏斗

作为候选人,要想进入面试环节被面试官评估是很容易的事情。而作为面试官,要想进入面试房间来评估一个候选人也是很容易的事情。不容易的是,公司在设计和评估一场面试时,保证候选人、面试官、用人部门的主管在做出艰难选择时的一致性和可靠性。

总览

这篇文章突破了传统方式,展示了我们这样设计面试的出发点,以及整套面试原则,这套原则给我们的迭代式面试提供了指引。为了例证我们的方法,我们会重点看下ML SWE的“面试循环”,并且深入探究我们是如何把这些原则应用在机器学习建模现场面试上的。我们把面试流程的关键部分分为如下几个方面:

  • 定义问题,
  • 和谐一致的面试,
  • 发现人才,以及
  • 追踪进度。

定义问题

在正式介绍面试循环的设计原则之前,我们需要理解设计这个循环的动机。这个动机来自于我们希望从这个岗位中得到的内容,这反过来帮助我们定义了我们应当从哪些方面考察候选人。我们需要解决以下三个问题:

  1. Lyft的挑战是什么(某个具体的岗位能否起到帮助作用)?
  2. 设置什么样的岗位能够贴合公司目标?
  3. 给定这个岗位的期望后,这个岗位所需的技能、知识和才华是怎样的?

我们已经把Lyft面对的挑战作为了动机,并引入了以上所指的岗位。那剩下的就是为成功的招聘定义必要的元素,就像上述第三条所述的Lyft环境下的岗位元素:

  1. 实践过程所需的技能;
  2. 通过学习和个人经历所掌握的知识,以及
  3. 每位候选人特有的才华。

所需的技能和知识可以很容易定义和检验;例如设计模型原型的技能和掌握机器学习理论、概念和软件库的知识,这些你可以从学习、实践和经历中获取,所以我们在这里不会反复讨论它。但是,我们来具体看一下这里才华的含义。

我们所希望看到的才华是重复出现的思想、感觉和行为模式这些模式需要高效地应用于Lyft的ML SWE工作岗位中。我们想要考察候选人的不仅仅是他们过去是否很好完成了工作,还会考察更复杂一些的东西。面对同样的考题,人们的反应和行为都不太一样。当我们寻找与公司适配的角色和角色价值时,我们正是要考察这些方面。除了纯技能和知识方面,候选人应对这些Lyft独特业务环境下的考题时所作出的反应,能够帮助他们成功通过面试吗?尽管通俗意义上的技能知识能够暗示候选人的能力,但我们并不总是在寻找机器学习界的Michael Jordan(或者说,要么选我,要么选Michael Jordan)。与杰出表现相关的那种狭隘的才华可能很重要,但在大部分情况下,当面试官给出Lyft工作中特有的一些问题后,他们会仔细从候选人的回答中寻找他们如何应对公司特有的问题。(我们发现Gallup的《First, Break All the Rules》这本书,通过数据驱动的方式,很好地解释了技能、知识和才华之间的区别)

由于Lyft的业务环境一直在变化(有时候在走向市场时会快速变化),我们所需要的才华也一直在变,我们的面试也必须随之而变。在过去的业务环境里,因为那时有很多很容易采摘的果实,我们可能会很重视候选人面对模糊的业务问题时展现的适应性和激情。而未来,因为随着我们的产品逐渐成熟,最大的业务机会在于确保产品功能之间的交互自然性,所以我们会更重视解决问题时的有条不紊和思维清晰特性。迭代式的面试是非常重要的,它能够帮助识别候选人是否匹配这种变化,确保面试角色始终是和我们的需求相关的。

本节的标题一语多关,说明了我们在面试设计中面对的不同类型问题的定义:

  1. 来自Lyft业务环境中的高层面问题;
  2. ML SWE角色应当处理的问题,以及
  3. 候选人在面试中对实际问题的反应,这可以帮助面试官了解这些候选人。

一旦我们很顺利地解决了这些问题,我们就要考虑将面试工作的规模扩展开来。具体来说就是,不同的面试官和招聘经理怎样一致可靠地评估各类候选人的角色和适配程度呢?

和谐一致的面试

本文大部分都是在描述面试官和候选人之间发生的事情。一般来说,面试流程包括很多层面,我们需要在一层层剥开它们的过程中,设计面试问题和评估方法,这样才能找到我们需要的人才。在较高层面上看,一个奏效的面试设计会让所有这些组成元素和谐共处。

首先,ML SWE面试循环中的候选人会走一遍Lyft的整个招聘审核流程。审核是一个常规流程,评审委员会将从公平的视角研究候选人,并决定是否录用他们。与评审委员会并行工作的是由面试官们组成的独立陪审团,他们能提供技术反馈。这些反馈用于帮助委员会决定候选人是否匹配,如果匹配,他们的技术级别是多少。乍一看,这个评审过程真的是很累赘。但通过仔细检查和权衡,我们发现这是特意设置的机制,用来在招聘过程里设置阻力。设置一致性的评审委员会能够统一标注和消除偏见。

其次,面试循环包含一次技术电话面试,和接下来的一系列现场面试,它们之间没有特别的顺序。电话面试决定了一个候选人能否成功进入现场面试,它会考察候选人的机器学习基础概念和基本编程能力的掌握程度。一系列的现场面试进一步考察候选人在实际工作需求中的技能知识的掌握深度。另外,现场面试还能够提供机会,让候选人在面对不同技术挑战时展示他们的才华。

ML SWE面试循环中的不同面试种类。我们根据面试岗位和候选人来组合选出图中的面试类别。

这两层的面试流程不是一成不变的。当我加入Lyft时还没有招聘审核环节,那时只有面试陪审团和招聘经理主导的提问环节。这个招聘效率并不高。当我们首次推出ML SWE面试循环方法时,我们仅仅是向标准的SWE循环添加了一些规范化的面试流程。但随着我们对Lyft的ML SWE岗位理解逐渐深入,我们引入了一个委员会来修正这个循环系统。成为委员会的一份子需要理解面试中所有这些环节和面试官的问题、候选人的回答是如何联系在一起的。

发现人才

把一位候选人和面试官配对能让我们检测候选人的技能、知识和才华。技能是通过传授来获取的。我们内部甚至提供机器学习的“大师级课程”。人们通过经验和个人学习来获取知识。两者都很重要,也是我们为任何招聘设置的门槛和水平标准。但是,为了决定候选人是否合适,简单地评估候选人的技能和知识还不够,我们还需要知道候选人反复出现的思考、感觉或者行为模式是否匹配这个岗位。

通常我们都不愿承认,仅仅持续约一小时的面试,是很难测试出和这个岗位相关的才华的。我们很难设计出这样的面试问题,能通过不同的面试环节和面试官向候选人提问,发现他们一致的行为方式。当你想辨别候选人是否针对这样的面试特意有所准备时,这个就更难了:这是经过反复练习的面试行为还是自然行为?在Lyft,我们会定期地寻找一些以前从没有人解决过的问题。尽管我们感激候选人为准备面试付出的时间和努力,但是面试技巧不等于实际工作岗位上的工作表现。

用科学的说法来说,面试的统计效率很低,采样代价很高。但是,下面这些是我们认为有效的面试工具设计原则。为了展示它们,我们会讨论这些原则是怎样应用于机器学习建模的现场面试设计中的。

挑选校准过的开放式问题

面试的目标是预测候选人在Lyft真实业务环境里的实际表现如何。从这方面来讲,我们的面试官是从一个问题池子里挑选和设计问题,问题池里的问题有各种潜在的解决方案。使用这种方式,候选人就不用为了生搬硬套出一个好的解决方案,而被迫去研究任何具体的主题。而且,这也降低了候选人反复练习面试问题的可能性。

在建模的现场面试环境里,我们在提出开放式问题之前,会提供足够的业务和问题背景,让候选人能够清晰地认识到这是一个基于机器学习解决方案的问题。毕竟,我们就是要招聘ML SWE岗位的候选人,所以我们不会试图隐藏这一点。因此,好的面试关键的一点就是面试官通过早前的问题上下文来引入问题约束,上下文里不要给候选人提供任何正确答案的指向。面试官调整他们的问题,并让可信的同行们对问题校准,之后再在正式面试中使用这些问题。

创造一些能够对期望评估的空间

在建模面试中,我们想要测试候选人怎样把一个描述性的、模糊的业务问题转成明确定义的机器学习问题,例如回归或者分类问题。面试官应聚焦于候选人的即时反应。所以,面试官提供了题目的业务上下文,并清晰解释后,这实际上是将压力转向给了候选人,让他们来推动话题。重要的是候选人怎样理解这个业务问题,以及接近问题答案的过程。这种将对话主导权转移到候选人这边的方式也同样适用于问题设计和经验面试环节。

当然,候选人的反应是受到其经验影响的。如果由候选人来驱动对话,而他们又不太适应这种方式,甚至在敦促他们进行主动对话时也如此的话,面试官可以有意识地给候选人一些指引。同样的,需要做出适当权衡,就是可以给出足够的上下文提示,但又不要提示太多信息。设计这个循环的其中一部分,包括创建面试官的入职流程,使面试官对我们想要关注的细节有一个统一的认识。当我们设计这个循环时,我们要科学对待,不要忘了面试是一种艺术,需要面试官学习和实践。

鼓励创造,提供验证

为了能够足够充分地评估候选人,建模问题必须非常模糊,可能通过多个定义来描述它,用多种机器学习方法来解决它。实际上,候选人应当从问题的模糊性里受到启发,从而产生创造性。面试官应当能评估候选人的创新性方式是否合理,或者仅仅是为了创新而创新,面试官需要尝试引导候选人处在问题相关的方向上,这是面试官的职责所在。例如,我曾经不得不敦促一位候选人尝试一种启发式机器学习方法,这种方法其实是一种更容易想得到的方法,能够直接了当的解决问题,而不是把这个具体问题转化为形式化描述的通用问题,如非凸约束优化问题。渴求想出更通用、更复杂的答案,这是我们想要考察的才华之一,但是保持在正确的轨道上思考问题也同样重要,这能让我们在正确的上下文环境里评估候选人。

一种方法能确保是在正确的轨道上讨论问题,这就是面试官要懂得什么时候需要候选人提供方法验证了,并且把握对话方向。即使我们面对的是开放式的问题挑战,面试者也需要让候选人了解什么时候要往深处思考,什么时候可以继续往前解答问题。 面试官把宽泛的问题分割成几块大的子问题,能够让候选人使用他们自己的方式来回答,同时又不超出我们想考察的范畴。更现实一点来说,我们是在模拟Lyft工作中解决机器学习建模问题的不同阶段。我们可能会在原型实现阶段思考问题形式化描述。我们可能会在产品化阶段思考模型评估问题。这些都是足够宽泛的问题领域,候选人能够展示出他们反复使用的思考模式,同时这种方式能够确保面试官遵循一致的技能、知识标准和要考察的才华标准。

除了映照出现实世界问题的情况,面试还是一个良好的渠道,它让候选人感觉到了Lyft需要处理问题的大致情况,建立了Lyft的品牌。记住一点,我们的面试问题是Lyft业务独有的问题,候选人不会在其他任何地方碰到这样的问题。为了保持一致性,每个问题都需要同行审查,之后才能发布到内部的问题库中。面试官负责主持正式面试,参加的还会有其同事们,他们在面试中作为面试官的“影子”,负责提供面试反馈。

面试首要的目标是最大化面试对候选人的区分能力,同时最小化对候选人能力预测的方差。当然,面试官确实有客观反馈,也会有主观反馈。团队成员面试候选人,并且思考候选人和Lyft整个公司是否互相匹配,这很重要。但挑战在于,我们的候选人多种多样,要维护一个全面的面试官清单(记录候选人匹配Lyft的程度)是不可能的。我们依赖我们的面试官,依赖他们平日的面试训练,以及内部的校准机制来帮助区分候选人。

追踪进度

一旦你已经构建了面试循环里的关键组成部分后,就可以思考如何维持可靠的反馈循环,这可以在不断面试的过程中衡量面试的健康程度,这很重要。这和获取足够多的统计样例一样困难,我们努力地通过数据来判断哪些地方出了问题。例如,假设从电话面试进入现场面试的健康通过率是50%,从现场面试到拿到offer的健康通过率是25%。但如果实际上,从电话面试进入现场面试的通过率是70%,而现场面试到拿到offer的通过率是10%,那在电话面试阶段就一定是有大问题的。在这种情况下,我们会仔细查看电话面试环节,和面试官协商,检查异常案例,建立更丰富的面试通过准则。针对这类情况,接下来做出的任何更改都被密切监视,以此确保我们的通过率是稳定的。

不同角色的面试循环,甚至是不同时间上的同一个面试循环,都会产生稍微不一样的基准。例如,针对刚毕业的学生的招聘计划流程,很可能会产生较高的录用率,而我们想发掘的高级候选人则具有较低的录用率。招聘团队在面试循环设计委员会中的作用,就是为合理的通过率数字提供指引。一旦面试循环正式启用,招聘团队会定期地检查这些数字,发现其中隐藏的潜在趋势。在面试流程之外,追踪被录用候选人的长期业绩表现趋势可能会很有用。

YMMV:面试循环中,从电话面试到现场面试,到提供offer,到offer被接受,健康通过率分别为,比如,50%,25%和70%。

共享信息

我们有充足的理由在面试设计阶段做到小心谨慎。如果我们给出的信息帮助候选人想要在面试中碰运气,那会怎样?如果我们希望在面试中寻找的东西随着时间变化了,那会怎样?如果设计过程本身就是错的,那会怎样?更糟糕的是,人们如果意识到在LeetCode上的高级订阅也无法在ML SWE面试循环中帮到他们,那又会怎样?

尽管有这些疑问,但是让设计面试的过程变得透明,就能够改善我们的面试情况。我们称之为受启发的自身利益(enlightened self-interest):候选人花费时间和我们交谈,我们投资人力来了解是否会有一个合适的候选人,我们因此也能受益。即使当时没有立马找到合适的候选人,正面积极的经历也能够建立公司品牌,改善候选人的人力资源投向。也许,候选人能够在未来更好的时间点上再次申请岗位。实际上,雇佣一位工程师很容易就花费数以万计的美金。展示我们是如何迭代推进面试流程的,就可以揭示我们真正关心的内容,以及我们是如何尝试研究这些内容的,希望通过这个过程把研究成果添加到招聘流程的良性循环里。

本文聚焦在ML SWE的面试循环上,因为我熟悉这个岗位的招聘流程。自从引入了面试循环,我已经主导了超过一百个该面试循环的变种,面试了来自各个背景领域的候选人。我和审核委员会一起工作过,他们负责定义岗位角色,我也和招聘团队一起工作并引入了面试循环,我参与设计并调整面试目标、形式和题库,题库是为我们所需要的具体技能、知识和才华而设计的。最近,我动员并且拉入了更多的团队成员到这个面试循环中来,以此来帮助扩大面试官资源池。我参与设计的其他面试循环,以及我参加的其他公司的各种面试也是很好的参考。

最后,我们希望那些和我们的岗位及价值相匹配的候选人获得成功,我们很早前就有这样的愿望了。

原文链接:

https://eng.lyft.com/how-lyft-designs-the-machine-learning-software-engineering-interview-bbbb9fc8bb28

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/gEUrcNj0tt2oQOaZl4U2
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券