渡十娘｜北美码农初入职场——码农面试中的Behavior Questions

2023-10-28 23:10

做公众号里的《纽约客》

戳蓝字一键关注渡十娘

转发也是一种肯定

作者｜鸭哥

编辑｜渡十娘

作者简介：鸭哥，毕业于中国科学技术大学PB0611，08年代表学校参与了奥运火炬传递。后赴美哥伦比亚大学留学。期间取得了固定翼飞机，机动船舶，和小型挖掘机驾驶执照。鸭哥喜爱摄影，虽然没有艺术细胞，但和厂商很容易打成一片。使用徕卡，振旺，锐星，TeleVue等多个品牌拍摄的作品被厂家用于宣传。

鸭哥职场系列文首發於GRAPEOT博客，作者授权渡十娘公号发表

在之前的文章中，我们已经介绍过Coding和System Design的面试。这次，我们打算讨论在Project Experience和Behavior面试中，面试官主要关注的信号是什么，以及如何为这些面试做准备。

从大的方面来看，Coding面试主要考察的是编码和调试的能力，而System Design面试则主要看你在软件工程方面的思维深度和熟练程度。至于Project Experience和Behaviour Question，主要是考察你在工程内外的思维深度。具体来说，面试官在进行Behavior面试时，主要关注三个方面：一是你的项目scope有多大，impact有多广；二是从工程决策或实践的角度看，你是否展现出深度思考或优秀特质；三是从工程之外的角度，如主动性或沟通等软实力方面，你是否有深度思考和熟练度。我们经常在网上看到一些Behavior Question很空洞，比如让你谈谈过去的项目中出现的错误、失败，以及你从中学到的经验教训，或者你和其他组员或老板之间的冲突，是如何解决的。很多网上的教程都建议你避重就轻，不要谈论真正的失败，或者要靠近Leadership Principle。虽然有些公司可能有自己的特殊情况，比如麻厂的Behaviour Question可能就要靠近Leadership Principle，但总的来说，我并不赞同这种观点。

我认为，behavior question的本质是为candidate提供一个展示自己的机会。它的真正目的并不是让你在一个虚拟的场景问题中，用一些含糊其辞的故事来回避问题，让面试官觉得你没有明显的缺点。如果你真的这样做，那就太浪费这个机会了。实际上，我们应该把behavior question看作是一个展示自我能力和思维深度的机会。有些人可能会说，由于各种主观和客观的原因，他们的项目可能只影响到一两个人或者一个小团队，所以他们的scope并不大。对于这种情况，我想说的是，scope并不是决定性的因素。真正决定性的因素是你的思维深度和熟练程度，无论是在工程内还是工程外。接下来，我们将用上述两个behavior question作为例子，简单介绍一下如何把握这样的问题，将其视为一个展示自己的机会，并简单分析一下面试官从这些回答中能得到什么样的signal。

首先，我们来看第一个题目：请简单介绍一下在你的项目中遇到的失败，并且分享你是如何从中吸取经验教训的。注意，下面的“我”都是泛指，并不是我个人实际参加过的例子，而是改编自多人的真实或虚构的经验。假设我是一个机器学习工程师，我开发了一个机器学习系统。这个系统的scope并不大，主要是我们的团队在使用。我一直坚信，一个好的机器学习系统必须要经过多轮快速迭代，才能在客户反馈中成长，才能让我们在工程师和产品经理之间的合作中真正把握客户的需求。因此，我在完成这个系统后，紧接着实现了一个observability系统。它的主要作用是在机器学习系统中埋点，计算各种指标。通过这些指标，我希望达到三个目的：1) 理解用户如何使用这个系统，从而为产品的迭代提供方向；2) 衡量我们的系统的稳定性如何，为我们通过oncall来提供良好的用户体验打下基础；3) 在我们的机器学习算法出问题需要调试的时候，我们也可以从一些更细节的指标中找到一些线索，帮助我们调试。然而，在这个observability系统上线以后，我很快就收到了oncall工程师的抱怨，原因是我设计的这个系统所汇报的指标太过详细，这一方面给oncall带来了很大的压力，每次有一些细节的指标波动，他们就需要去处理。另一方面，这么多的、没有区分主次的指标，也让PM对observability失去了兴趣，一眼望去，上百个指标根本看不完。他们就不太愿意去用。

我意识到这是项目的一个失败，因为如果PM都懒得看指标的话，这完全defeat the purpose of the observability system。因此，我做了以下几个改动。首先，从产品的角度，我把这些指标分成了几个tier。有的是top line metrics，oncall工程师需要监测，产品经理需要审查。其次是supportive metrics，如果top line metric出现问题，我们可以从supportive metric中找到一些原因，这对PM很有帮助。第三是debugging metrics，当工程师需要调试这个系统时，他们可以查看更详细的debugging metrics以寻求帮助和启发。我做的第二个改动是在procedure上。我通过使用一些模板，让这个系统每周自动发送一个总结邮件，从而获得更高的visibility。同时，如果有人发现这个总结邮件里有一些interesting pattern，我们也会安排一个review meeting与PM讨论是否需要进行一些迭代。在做了这两件事情后，一方面我们形成了有效的oncall机制，让系统的稳定性得到了实质性的提升。另一方面，它也大大增加了PM对这个项目的积极性，甚至在与PM的讨论中，他们足够有动力去推广这个系统，从而促成了我们组与其他组的合作，让这个机器学习系统来empower其他组的场景，实现了功能和代码的复用。

这是一个对behavior question的实质性回答。相比于避重就轻的回答，这种回答能充分展示"我"的思维成熟度。面试官可以从中看到几个signal。首先，从工程的角度来看，我对机器学习系统有自己的观点：我认为，与其采取瀑布式风格，试图在第一个版本就把系统做到完美，机器学习系统应当采取一个迭代的思路。为了有效地实施这种迭代思路，我们需要做数据驱动的决策，因此需要一个observability系统。这个逻辑链条展示了我对机器学习系统工程实践的熟练程度和深入思考。第二，我对这个系统的三个作用有清晰的总结，这既展示了我对问题本身的深入思考，也展示了我的思考过程是有条理和组织的。第三，我能够识别这个失败，这并不trivial，因为它不仅涉及到工程团队的抱怨，更重要的是涉及到项目经理对这个项目的不感兴趣。这需要有一定的沟通协作的敏感性。第四是我对失败的改进，这包括从技术和组织两方面进行的改进。这表明我不仅是一个懂技术的工程师，我还对procedure, mechanism和policy有一些经验，这对于软实力来说是加分的。第五点是通过改进后，我阐述了这个改进的影响。它不仅实现了系统原先的目标，甚至带来了一些额外的好处，也就是让这个系统可以支持其他组的场景，实现了scope的扩大。这也证明了我们对于这个失败的解决方法是正确的。所以，整个流程下来，它说明我有从头到尾把一件事情迭代修正执行，最终实现影响的能力，这是一个非常正面的例子。所以，大家可以思考一下，如果和一些网上说的比如过分注重细节导致一段时间work life balance不好，或者因为太较真所以和老板有一些细节上的冲突等等例子相比，这样的例子才是真正能够展现你的能力，才是真正把握住behavior question这个机会的例子。

接下来，我们来看另一个behavior question的例子：你在工作中是否曾经和别人产生过冲突，以及你是如何解决这些冲突的。同样，下面的回答也是一个假设性的例子，它并非基于我的亲身经历，而是由多个人的真实或虚构的经历组合而成。这个例子的情境是，我们有一个机器学习系统，由于我们公司有"Dogfood"的传统（在生活中自己使用自己的系统进行测试），从工程师到PM，再到leadership，都会使用这个系统。最近，这个系统进行了一些较大的改进，因此在dogfood方面，大家的参与度也相对较高。然而，在使用过程中，大家发现了一个问题。尽管我们报告说，这个系统相比于上一个版本，在精度上有了很大的提升，但是产品经理和领导层发现了一些明显的failure pattern。由于leadership的authority，再加上PM非常善于make noise，这就导致了大家对整个项目的态度产生了一些变化。在会议上会经常出现类似的疑问，比如"你们真的打算上线这个系统吗？"或者"为什么我们一直没有解决这种简单的failure pattern？"这给信任和产品决策都带来了一定的挑战，从而产生了一些冲突。

在这个过程中，我们的TPM的主要职责是加强沟通并保持诚意。在项目汇总会议上，TPM与各个关键stakeholder进行了沟通，承认这确实是一个可以改进的地方。但他也强调，没有任何一个机器学习系统在第一次迭代中就能达到完美。我们已经开始调动资源，针对这些failure pattern进行研究，并已经开始重新训练模型。我们期待在两周内能看到一些改进的结果。然而，在这种大的冲突背景下，我并不同意TPM的这种思路。作为一个机器学习工程师，我的经验告诉我，机器学习与传统的软件工程是不同的。传统的软件工程中，每一个Bug在很大程度上都是确定性的，而改善软件质量的过程就是不断修复Bug的过程。但是，机器学习是概率性的。一个算法或模型的精度，往往不能仅通过一个或几个failure case，甚至几个failure pattern来判断。这样做往往只能管中窥豹，盲人摸象，看不到整体。

我们真正应该做的是，构建一个与实际数据分布相吻合的测试集，在这个测试集上进行评估。只有通过全面的评估，才能对所有可能的failure pattern和用户体验有一个全局的、概率性的理解。换句话说，leadership看到的failure pattern可能与我们的客户看到的failure pattern不同。这取决于每个公司的具体客户是谁。以这个特定的例子为例，leadership的日常使用和我们针对的客户群体的实际场景相去甚远，那么他们遇到的failure pattern在整个数据分布中可能只占很小的一部分。如果我们过度优化在这一小部分用户会遇到的问题上，就会有一个机会成本。同样的时间，我们花在优化80%的用户都会遇到的failure pattern上，和只有1%的用户会遇到的failure pattern上，显然前者更划算。如果我们因为这个故障模式是一个VP提出来的，就去优化这1%的故障模式，那就意味着我们会错失优化大多数用户体验的机会。因此，在这里，我和TPM的观点出现了分歧。我认为，虽然VP的抱怨是一个重要的信息，但我们仍然需要对它的prevalence进行评估。只有在确定它真的是大部分用户都会遇到的failure pattern时，我们才会去进行改进。如果这是一个只有少部分用户会遇到的failure pattern，我们不应该盲目地在错误的路径上更改模型。因为盲目的更改会有很大的可能性引入regression。而是否有regression，还是要以这个系统的测试集为准。

从这个角度出发，我对TPM的建议是，我们作为机器学习团队，有责任对其他团队进行教育或科普，告诉他们机器学习是怎么work的。因此，我们不应该屈从于他们的压力，而应该向他们清楚地解释一个high level的思路。从政治的角度来看，这也有助于我们团队不给其他团队一个reactive的形象——如果他们只要有authority或者urgency为理由来要求我们做什么事情，我们就以高优先级很快把它做出来，这对于长远来看，大家的有效合作也是不利的。因此，从这个角度出发，我建议TPM使用这样的communication strategy：首先，我们需要从一个holistic view的角度来考虑问题，解释一下机器学习的评估流程。其次，我们非常重视他们的意见，因此我们会评估这些failure pattern的prevalence，以决定是否需要对模型进行有针对性的修改。再次，大家不必过于担心，因为我们的模型有一个周期性的正常维护周期。两周后，我们的模型将进入一个新的维护周期，到时我们可以再看看是否有所改进。最后，我们也会针对上一个版本进行分析，如果这个failure pattern在上一个版本中就已经存在，那么在这个版本中仍然存在也不是不能接受的。

但是在与TPM 1-1沟通后，他仍未被说服。我理解这是因为，作为TPM，他的核心职责是确保项目能够按计划正常推进。在这种情况下，如果leadership和PM给出了明确的需求，而他无法满足，那就意味着他没有完成他的工作。为了有效地与他沟通，我找了一个经验更丰富的TPM前辈来帮忙。在我与前辈达成一致后，我们一起用TPM的语言去说服TPM。在与他沟通时，我特别注意不要把我们两个人放在对立面，而是把我们都放在机器学习团队的大背景下。经过一系列的会议和讨论后，我们达成了共识。TPM在项目会议上进行了演示，得到了其他组的理解，暂时缓解了危机。另一方面，这次讨论也给了我们很多关于如何改进模型，改进用户体验以及测量用户体验的启示，这对项目的下一步非常有益。

在这个例子中，"我"向面试官传达了五个关键的信号。首先，我表明这是一个涉及范围广泛的项目，参与者包括各种不同的stakeholder，包括VP级别的领导团队，以及机器学习组以外的其他组。其次，我强调这是一个非常复杂的问题，涉及到算法评估、产品体验的衡量和改进，以及如何有效地与leadership沟通，包括在与之有分歧时是否以及如何坚持自己的观点。第三，我展示了我对机器学习有深入的理解，尽管TPM的回答已经非常专业，但我从更深层次的角度出发，认为这并不是一个技术上正确的回答。对于机会成本的理解也说明了我对工程实践的熟练。第四，从非技术的角度来看，我认为向其他组提供教育也是我们的责任。这种主动性，以及如何与其他组沟通的策略，以及如何让我们的组在政治方面给其他组留下不一定良好但正确的印象，以实现更有效的协作，都表明我在技术之外也有敏感度和成熟度。最后，在无法达成共识的情况下，我知道如何通过委托和利用他人的力量，在没有authority的情况下影响他人的观点，并为他们提供支持，以帮助他们成功完成presentation，实现我们的战略目标。这种沟通技巧也是一个加分项。

总的来说，当面对“你和其他人，包括同事和老板之间是否有过冲突”的问题时，回答不仅仅是“有冲突，我通过实验说服了他们”，或者“有冲突，我选择了disagree and commit”。这些直观的答案只是问题的一部分，这个问题其实是一个舞台，你可以在上面描述复杂的情境和思考过程，这才是面试官真正想看到的，也是他们能收集到足够多signal的回答。

因此，通过这两个示例的题目和回答，我认为behavior questions既可以提前准备，又不能提前准备。如果你只是简单地查看网上的常见的behavior question，并提前准备答案，这在节省时间和提高答题熟练程度方面确实有一定的优势。但是，这并不能有效提升你的回答深度，也不能有效地给出一些额外的正面signal，因为这些正面signal取决于你的思考深度和视野，这通常是无法在短期内有效提升的。然而，behavior question又是可以有效准备的，因为网上的这些问题，每一个都是你在工作中需要注意的地方。如果你真的把它当作一个职业发展问题来思考，而不是当作一个面试题来准备。如果长期对照自己现有的工作项目进行思考，这通常是一个非常有效的提升自己深度的方法，甚至还可以让你在工作中有实质性的提升。从这个角度来看，behavior question又是可以准备的，但这种准备并不是投机取巧的准备，而是实实在在的准备，就像写简历最好的方法是通过工作来写简历一样。