登录
  • #刷题

作为‌‌‍‍‌‍‌‌‌‌‍‍‌‍‌‍‍‍‍‍‌‍‌‍‍‌‌‌‍‌‍‌面试官,给即将参加coding interview的你,分享一点刷题之外的事

enter_username
14621
73
楼主目前在湾区某公司做ML Engineer,今年以来,已经累计给五十余位candidates做了coding interview,有phone screening也有onsite,给candidate的评价从strong no到strong yes都有。发这个帖,主要是想跟面试经验不多的同学们分享一下,除了白纸黑字的代码以外,还有哪些你或许没有注意过的因素,也决定了你的面试结果(是否通过;如果通过,是否为strong hire/qualified for next level)。



  1. 首先是如何看待coding interview。很多国人candidates,特别是职场经验不多,或是刚刚转码的,是把coding interview纯粹当作高考/托福/GRE来做的:拿到题之后,不想废话,只想尽快把答案敲出来,通过所有test cases,然后点击交卷走人。没错,coding interview确实是聚焦在对编程能力的考察上,但是别忘记,对面坐着的面试官不是一个只按你的最终代码打分的机器,而是全程目睹你编码过程的活人。这就决定了,代码之外的很多因素,都会影响甚至决定面试官对你的评价。所以,对coding interview的准备,并不止刷题这一项。

  2. 不牵强地说,coding interview其实也算半个behavior interview。我面过的candidate里面,有在自我介绍阶段抱怨现在公司/老板/行业的(要知道coding interview的自我介绍一般都很短),有屡屡无视面试官问题坚持埋头写码的(给人的感觉是,这题他考前刚背过答案,不趁热写就要忘了),有不听面试官建议坚持要炫技写两种答案的(导致超时),有想给面试官上一课的(面试官问你的代码为什么这样写,并不见得是因为他真不懂,而是想看你能否给出合理解释,特别是有明显默写/抄写痕迹时;或者,你的答案不是最优解,面试官想给你机会改进),有面试官给hint之后不懂装懂走错方向的,等等。大家一定要理解,面试官在面试你时,其实也是在为自己寻找将来的同事,而上述behaviors大多时候其实在职场中并不受欢迎。很不幸上述例子的主角都是国人(当然也是因为国人占了candidates的绝大多数),所以希望大家一定引以为戒,不要把coding interview当作一场唯结果论的智力游戏。

  3. 不要对面试官预设立场。尽管在现实中确实存在着种种不公平和偏见,但对面试官预设立场,对你自己的面试表现没有任何帮助。不要因为面试官是国人就认为一定会对你放水,或因为面试官是某国人就一定会刁难你——即便你的猜想是对的,除了扰乱心态之外,对你的现场表现又有什么帮助呢?我曾经有一个candidate,提出了一个自认为最优而事实上非最优的答案之后,便着急写码。我打断他,问了一个带有hint的问题,本意是想引导他思考最优解,但他却误以为我是故意鸡蛋里挑骨头,不配合讨论,所以没有获得任何进展。最后我也给他过了(公司并不要求最优解),但因为不是最优解,且我对他的teamwork略感疑虑,所以他肯定和strong hire无缘了(有些情况下,有没有strong hire会直接影响最终的level和package)。

  4. 重视沟通,保持沟通。如果你有一定工作经验的话,肯定知道,作为工程师,沟通能力和写码能力是同样重要的,所以面试官也必然会对你的沟通能力有所要求(特别是目标level比较高的时候)。 很多candidates,一看是高频easy,立马嘴角上扬,不等面试官开口就噼里啪啦写完了代码,然后战术后仰,基操勿六。这其实是严重的减分项。记住,读完题目之后的第一步,是要跟面试官确认(比如通过复述)你的理解正确(有些题,乍一看是高频easy,其实条件略有改动,如果不仔细读题,很可能会陷入思维定势无法自拔)。如果有任何疑问,一定要及时说出来,以免代码写到一半发现关键的地方有ambiguity或者意料之外的edge cases,把自己搞的很紧张。尽管我每次都会提前跟candidate说,好好读题,有问题随时问,但能听懂这句暗示的似乎不多。读完题,问完clarifying questions,下一步仍然不是写代码,而是要主动跟面试官交代你自己的思路,主动提出并比较各种备选方案的优劣,然后问面试官的看法。如果你的思路有问题,或者面试官希望你能得到更优的答案,那么此处就会展开一些讨论。讨论结束后,要跟面试官确认双方已经达成一致,再动手写码。在写码的过程中,也一定要保持交流,主动解释为什么要这么写。写代码快是好事,但过犹不及,只顾闷头写,完全不理会面试官,不主动解释,难免让人觉得你是在默写/抄写而不是在思考,反而可能会引发面试官问更多问题。另外,无论是讨论思路,还是实现代码,遇到确实卡住的地方,不要闷头钻研,而是要告诉对方,你卡在了哪里,想通过什么办法解决;实在没有思路的话,一定要主动求hint;这样,即使最后没有得到正确/最优答案,也至少给了面试官一个给你partial credit的理由。

  5. 其他的一些做事习惯,虽然不是决定因素,但很反映candidate的经验,以及影响面试官的观感,进而有可能决定最后是hire还是strong hire。比如,代码太长太复杂时,是否会有意识地在中途做一些unit test而不是一口气写三十行;写test cases时,是否遵循一定的逻辑顺序(由简入繁),而不是东一枪西一枪;debug的时候,是否能有逻辑地逐步缩小排查范围/输出额外信息等等。



暂时先想到这么多,欢迎各位大佬批评指正和补充。

希望大家刷题顺利,早日找到理想工作!

补充内容 (2021-11-27 05:18 +8:00):

很感谢大家的讨论!

如果原帖没有表达清楚的话,楼主希望可以在这里澄清一下:

1. 楼主并没有否认过“把题做出来”的重要性。既然是coding interview,怎么可能不看code呢?code怎么可能不是面试成败的关键因素之一呢?

2. 如原帖所言,楼主开此贴,本意是为了“分享代码之外的影响因素”(behavior/沟通/习惯),并非为了“否定代码本身的重要性”。写代码和保持沟通并非此消彼长的互斥关系,楼主也从来没有尝试要将它们对立起来,所以希望大家也不要陷入非此即彼的误读之中。譬如,当楼主说“沟通很重要”的时候,其含义并不是“只有沟通重要,别的都不重要,只要沟通好,一行代码不写也能面过”。同样,当有人说“把题做出来也很重要”时,他/她的本意可能也并不是“楼主胡说八道,只有把题做出来才重要,沟通什么的都不重要”。为什么不能二者兼得呢?

3. 楼主想表达的是,面试官对candidate的评价,既基于代码本身,也有代码之外的因素,是一个综合结果。说出来你可能不信,虽然candidate从recruiter口中得到的结果只有Yes和No两种,但面试官的评价过程并非只是给个Yes/No这么简单。面试官可能需要显性地或隐性地对各个小的要点分别打分(比如,解题思路,代码实现,edge cases,熟练度,沟通合作,等等——不同公司可能侧重点不同),之后依据各项权重生成一个综合评分,再按照这个综合评分给出Yes或No的最终评价。最终得到Yes的candidates,并非在每个要点上都是满分;最终得到No的candidates,也并非在每个要点上都是0分。当代码得分一定时,behavior和沟通等方面表现得越好,综合得分也就越高,也就越有希望得到Yes。如果你有能力在代码部分得到高分,那楼主的意思是,尽量不要因为behavior和沟通方面的问题,把到手的strong hire变成weak hire甚至no hire.

补充内容 (2021-11-27 05:20 +8:00):

4. 当然了,像其他面试一样,这个评分里面会掺杂面试官的主观性,而且不同公司的评分标准也不尽相同。但楼主并不认同“既然不同公司/面试官的评价标准不一样,那你说的就不是放之四海而皆准,所以behavior/沟通其实并不重要”的逻辑。楼主的看法是:既然有公司/面试官会看重这些,那为什么不注意一下呢?楼主斗胆揣测,有些朋友的逻辑可能是“既然不是所有公司/面试官都同样看重behavior/沟通,那即使在这些方面表现再好,也不能100%保证我面试通过。对于不能100%保证结果的事,我为什么要费心费力呢?我有那时间多写两行代码不好吗?”对此,楼主看法有三:(1)把题全做出来也未必保证面试100%通过(论坛上这类帖子不少吧),难道就不做题了吗?(2)“只对看重沟通的面试官好好沟通”听上去想是个100%有用的办法吧?问题是,对每一个面试官,你如何能预测他/她是否看重这些呢?你愿意承担预测失败的风险吗?(3)其实,“注意自己的behavior”和“加强沟通”,并不需要付出天大的努力,甚至只要有这个意识就足够了(这也是楼主写此帖的初衷)。如果有看官觉得连拥有这个意识都是一种压力和挑战,那我觉得您确实要在这方面努力了:behavior和沟通,不只对coding interview有影响,也是其他面试环节的考察内容,更是日常工作的必备素质和技能。躲得过初一,躲不过十五的。

补充内容 (2021-11-27 05:23 +8:00):

5. 如果你仍然觉得只有“把题做出来”才是唯一的成败指标,那我们不妨仔细思考一下,如何定义“把题做出来”呢?(1)实现了最优解,但没处理好某个关键的edge case,算“把题做出来”吗?(2)没想到最优解,但实现了次优解,且代码bug-free,算“把题做出来”吗?(3)两道考题,一道写了最优解,一道只写了brute force,但口述了次优解的思路,算“把题做出来”吗?(4)最后三分钟突然想到了最优解并实现了出来,但因时间所限没敲上最后的return,导致代码不能运行,算“把题做出来”吗?(5)关键的步骤全靠面试官提示,但反应很快且代码写的又快又美,算“把题做出来”吗?(6)用面试官从来没想到的清奇思路实现出了一个最优解,面试官当场表示认可,但事后发现关键步骤有漏洞且并非最优解,算“把题做出来”吗?(7)实现了次优解,代码能跑过test cases,但难以阅读,算“把题做出来”吗?(8)写出了可以跑过test cases的最优解,但回答错了最基本的时间复杂度问题/关键步骤解释错误/面试官稍微改动了条件就无法应变,算“把题做出来”吗?

6. 如果以“最优解+能跑过test cases”为“把题做出来”的定义,那只有(8)符合标准,但却未必能过面试。(1)~(7)都不符合这种“把题做出来”的定义,却都有可能拿到Yes。对于这些处于中间地带的情况,面试官是有一定的自由裁量权的,换句话说,面试官给Yes还是No都可以,都能找到证据自圆其说。在这种情况下,你说代码之外的因素起不起作用呢?如果在behavior/沟通里面发现了red flag,作为面试官,你是更倾向于给Yes还是No呢?
73条回复
热度排序

发表回复