【Smeshing Coding Interview】从面试官角度解答coding interview
来自其他站点
今年行情不好，地理无数的ng小伙伴，甚至很多experienced的朋友们都感觉到了深深地寒意。
最近和朋友聊天，恰巧聊到面试经验。想想自己这些年有不少面试经验，被面试和面过别人也有小几百场了。
在大厂和独角兽工作的时候，还深入了解过各大厂和独角兽面试的rubrics，感觉对自己面试非常有帮助，有的放矢。所以楼主这些年自己经历的大部分面试也基本都过了，算是有些心得。
但有点遗憾的是，在地里几乎没有帖子有系统性的提及coding interview的criteria和rubrics。
所以经常看到有同学在帖子提到自己面的不错，但挂了的情况。
虽然每个公司的interview rubrics会有些许不同，而且是不能泄露的。但绝大部分公司的rubrics其实有很大的overlap，唯一的区别可能是侧重点有些不同。
所以楼主想根据FLAG、几家hot startups以及preIPO unicorns的coding rubrics总结一下，希望能给NG还有出入职场的新人们一些帮助。
这些对于面试经验丰富或者长期担任面试官的老人们可能帮助不大，因为大家基本已经对这些rubrics深入于心了。但各位senior同僚如果有发现遗漏，也欢迎补充下。
------------------------------------------------------------------------------------
【Coding interview Rubric No.1】Problem Exploration
这个主要是看被面试者在拿到问题的时候，是否能提出一些问题，或者clarify一些面试官没说清楚的点。有的时候面试官会故意说的比较模糊，比如输入输出的格式，比如资源限制，corner cases等等。就算是碰到看起来非常熟悉的题，有些问题还是要问一下，因为面试官可能改了一些背景题设，但并没有直言，而是等待面试者来clarify。
【Coding interview Rubric No.2】Solution Idea
这个主要是看被面试者是否能够在写代码之前，给面试官讲清楚自己的idea，并且make consensus。很多面试者，尤其是面试新手很容易在这一块上翻车，我看过很多review，面试者都挂在这一块。大部分人可能是由于紧张，并且对面试考察点不熟悉，经常想到idea就开始提笔写，完全忽略了和面试官的交流和达成一致。就算你写出了答案，但面试官可能想要的是另一种解法，或者面试官只希望讨论下这道题，而让你写下一个他准备的puzzle。
这不仅是面试上的一个大的red flag，在工作中也是。没有哪个老板或者TL希望组员吭哧吭哧写了一堆代码，却并不是有效的代码。既浪费了人力，还容易导致矛盾。
所以最好的方法，是你提出几种解法（可以提一下brute force的解法），然后说说你准备用那种解法，原因是什么，然后和面试官确定他/她是否认同使用这种解法。得到肯定确认之后再开始写。
【Coding interview Rubric No.3】Coding Competency
这一块，没什么说的。如果你能写的飞快，并且bug free，自然没什么问题。
如果有点错，但能很快debug出来，基本也没什么问题。
如果一下卡住了，能讲清楚思路，并且能一步步tackle，也能凑合。
但依然记住，在写代码的时候，如果能标注一些简单的comments并且能一直边写边说每一行是在干什么，是很有效的。
面试官也是人，有些时候也会走神，或者对你使用的编程语言不熟悉。如果你一点都不说，一点comments都没写，面试官也可能会忽略掉一些东西，在review的时候帮你说话的力度可能就没那么大，间接会导致可能会被其他面试者更强力的结果比下去而被刷掉。所以边说边coding，并且写一点小comments，方便面试官也方便自己理清思路。
这一块另一个考察方向是你代码的quality。有些人代码虽然work，但duplicate太多，没有模块化，代码不符合相应语言的coding style，不符合clean code的准则，是有扣分的。不是每个公司都会很注意着点，但确实有不少公司的rubrics上都有这点。
【Coding interview Rubric No.4】Testing
很多新人面试者写完之后就停了，等着面试官来drive。但其实，写完代码之后，不run一下test，怎么能确定你的代码是正确的呢？这个“run”并非一定要compile&run，也可以是口头drive through一些test cases，而且这是更推荐的一个步骤。
所以正确的做法是，先列出一些test cases，并和面试官讨论，确定这些test cases cover了大部分use cases和corner cases。然后挑选其中几个，口头带着面试官drive through每一行代码，确定逻辑正确（类似step debugger，每一步的variable，parameter都会怎么变化）。最后如果面试官需要，可以compile&run。
------------------------------------------------------------------------------------
一般面试到这里才算一个puzzle做完了。如果上面所有的点你都做得很好，那么恭喜你，从你的角度，这场面试应该是没有任何漏洞了。但你依然可能因为一些额外的因素fail，包括但不限于：position已经被fill了，没坑了。或者面试官不是很专业，review里表达的不清晰，没有完整体现你在面试里表现的水平等等。但这些意外因素并非个人面试者能够控制的，就不用纠结了。
希望这些rubrics能对大家有帮助，祝大家coding面试一切顺利，考的全会，蒙的全对，厄运退退退。
如果有帮助，希望版主能给加个精，大家能给加点大米。谢谢。
最近和朋友聊天，恰巧聊到面试经验。想想自己这些年有不少面试经验，被面试和面过别人也有小几百场了。
在大厂和独角兽工作的时候，还深入了解过各大厂和独角兽面试的rubrics，感觉对自己面试非常有帮助，有的放矢。所以楼主这些年自己经历的大部分面试也基本都过了，算是有些心得。
但有点遗憾的是，在地里几乎没有帖子有系统性的提及coding interview的criteria和rubrics。
所以经常看到有同学在帖子提到自己面的不错，但挂了的情况。
虽然每个公司的interview rubrics会有些许不同，而且是不能泄露的。但绝大部分公司的rubrics其实有很大的overlap，唯一的区别可能是侧重点有些不同。
所以楼主想根据FLAG、几家hot startups以及preIPO unicorns的coding rubrics总结一下，希望能给NG还有出入职场的新人们一些帮助。
这些对于面试经验丰富或者长期担任面试官的老人们可能帮助不大，因为大家基本已经对这些rubrics深入于心了。但各位senior同僚如果有发现遗漏，也欢迎补充下。
------------------------------------------------------------------------------------
【Coding interview Rubric No.1】Problem Exploration
这个主要是看被面试者在拿到问题的时候，是否能提出一些问题，或者clarify一些面试官没说清楚的点。有的时候面试官会故意说的比较模糊，比如输入输出的格式，比如资源限制，corner cases等等。就算是碰到看起来非常熟悉的题，有些问题还是要问一下，因为面试官可能改了一些背景题设，但并没有直言，而是等待面试者来clarify。
【Coding interview Rubric No.2】Solution Idea
这个主要是看被面试者是否能够在写代码之前，给面试官讲清楚自己的idea，并且make consensus。很多面试者，尤其是面试新手很容易在这一块上翻车，我看过很多review，面试者都挂在这一块。大部分人可能是由于紧张，并且对面试考察点不熟悉，经常想到idea就开始提笔写，完全忽略了和面试官的交流和达成一致。就算你写出了答案，但面试官可能想要的是另一种解法，或者面试官只希望讨论下这道题，而让你写下一个他准备的puzzle。
这不仅是面试上的一个大的red flag，在工作中也是。没有哪个老板或者TL希望组员吭哧吭哧写了一堆代码，却并不是有效的代码。既浪费了人力，还容易导致矛盾。
所以最好的方法，是你提出几种解法（可以提一下brute force的解法），然后说说你准备用那种解法，原因是什么，然后和面试官确定他/她是否认同使用这种解法。得到肯定确认之后再开始写。
【Coding interview Rubric No.3】Coding Competency
这一块，没什么说的。如果你能写的飞快，并且bug free，自然没什么问题。
如果有点错，但能很快debug出来，基本也没什么问题。
如果一下卡住了，能讲清楚思路，并且能一步步tackle，也能凑合。
但依然记住，在写代码的时候，如果能标注一些简单的comments并且能一直边写边说每一行是在干什么，是很有效的。
面试官也是人，有些时候也会走神，或者对你使用的编程语言不熟悉。如果你一点都不说，一点comments都没写，面试官也可能会忽略掉一些东西，在review的时候帮你说话的力度可能就没那么大，间接会导致可能会被其他面试者更强力的结果比下去而被刷掉。所以边说边coding，并且写一点小comments，方便面试官也方便自己理清思路。
这一块另一个考察方向是你代码的quality。有些人代码虽然work，但duplicate太多，没有模块化，代码不符合相应语言的coding style，不符合clean code的准则，是有扣分的。不是每个公司都会很注意着点，但确实有不少公司的rubrics上都有这点。
【Coding interview Rubric No.4】Testing
很多新人面试者写完之后就停了，等着面试官来drive。但其实，写完代码之后，不run一下test，怎么能确定你的代码是正确的呢？这个“run”并非一定要compile&run，也可以是口头drive through一些test cases，而且这是更推荐的一个步骤。
所以正确的做法是，先列出一些test cases，并和面试官讨论，确定这些test cases cover了大部分use cases和corner cases。然后挑选其中几个，口头带着面试官drive through每一行代码，确定逻辑正确（类似step debugger，每一步的variable，parameter都会怎么变化）。最后如果面试官需要，可以compile&run。
------------------------------------------------------------------------------------
一般面试到这里才算一个puzzle做完了。如果上面所有的点你都做得很好，那么恭喜你，从你的角度，这场面试应该是没有任何漏洞了。但你依然可能因为一些额外的因素fail，包括但不限于：position已经被fill了，没坑了。或者面试官不是很专业，review里表达的不清晰，没有完整体现你在面试里表现的水平等等。但这些意外因素并非个人面试者能够控制的，就不用纠结了。
希望这些rubrics能对大家有帮助，祝大家coding面试一切顺利，考的全会，蒙的全对，厄运退退退。
如果有帮助，希望版主能给加个精，大家能给加点大米。谢谢。
4条回复