我开始比较喜欢这种方法
我开始比较喜欢这种方法。我现在的公司使用一个类似的问题来评估候选人。对我来说,这很简单,我以为我们会大量雇佣那些懒散的人。但当我开始主持面试时,我意识到大多数候选人出于各种原因在这个简单的问题上表现得很差。看来,‘能够很好地解决简单问题’比‘能够解决困难问题’更不荒谬的优秀软件工程师的代理指标。这让我很惊讶。
源讨论我受够了LeetCode式的面试原帖 603 条评论 · 导入时统计我开始比较喜欢这种方法。我现在的公司使用一个类似的问题来评估候选人。对我来说,这很简单,我以为我们会大量雇佣那些懒散的人。但当我开始主持面试时,我意识到大多数候选人出于各种原因在这个简单的问题上表现得很差。看来,‘能够很好地解决简单问题’比‘能够解决困难问题’更不荒谬的优秀软件工程师的代理指标。这让我很惊讶。
源讨论我受够了LeetCode式的面试原帖 603 条评论 · 导入时统计在我所经营的所有公司中,我们都用一个简单的白板例子来达到这个目的。不要担心拼写错误;重要的是这个人是怎么思考的。 “陷阱”问题很无聊,但你希望了解候选人是否真的了解自己的东西(也让候选人知道我们是什么样的公司——面试是双向的销售过程)。如果有人问类似“修改参数是否可以”(或者他说“我假设不能修改参数”)这样的问题,那是很好的(或者他说“我不记得strlen是否包含空字符,所以我加1——通常我会去查)——再次强调,没有陷阱问题。 当我提到“简单”时,它可能像atoi或者“洗牌一副牌”这样的问题:基础但不完全是 trivial 的问题,比如 fizzbuzz。 我们最好的雇员之一是一个犯了基本错误的人——当我们问他这是否能按预期工作时,他说“我真是个该死的白痴”,然后修正了错误。你不应该这样说话。…
完整原文把你的经验,加入这段讨论。
“简单的问题”往往并不像事后看起来那样“简单”,如果你考虑到所有因素,比如压力水平、面试者的混合心态(他们不仅仅是在思考编程问题,同时也在考虑社交线索、在不同语言间切换、同龄人的评价,以及许多其他引发焦虑的因素)等等。 软件行业以低估整体复杂性因素、理解不确定性以及管理它们所需的时间而闻名,面试似乎也不例外。因此,“简单”的问题往往是好的(我同意你的看法),因为当你考虑到所有因素时,它们对大多数人来说其实并不简单,在特定的情况下它们往往具有相当的挑战性。 与此同时,真正困难的问题(在任何任意环境下以及更长的时间范围内)需要大量的机械训练和重复使用一些巧妙的、独特的技巧。…
完整原文你测试的是地板,而不是天花板。 说实话,我从来不是在寻找“最好的”,而是在寻找“足以胜任工作的足够好”。因为我们可以就什么是最好争论好几个小时。我们可能在什么样的品质以什么样的比例组合才能成为“最好的”这一点上存在分歧。但我们都能够普遍认同“能够完成工作”的人。正如我之前在别处提到的,我们现在正在招聘,我们的候选人池中存在两种不同的情况。 有一个家伙至少有组里的两个人直接说不行。而第三个成员也因为我们都坚持他不是合适人选而投了反对票。还有一个我们所有人都觉得非常靠谱。不是“最好的”,但他是坚实的底线,我们认为他能够学习并胜任工作。 但能够排除那些尽管简历不错却连基本工作都无法完成的人,这是无价的。
完整原文我有一个朋友,他为他的公司(一家位于中西部的小型上市公司)面试了大约30到40名软件工程师候选人。他说,仅FizzBuzz问题就足以淘汰25%的申请者。接下来稍微更难一点的问题会再淘汰30%到40%的候选人。我认为Leetcode的难题只是为了满足一些软件工程师的自尊心。
完整原文尊重不同观点,分享具体经验。
登录后即可发帖、评论、转发和引用。