做了半年面试官的心得

ABCcac3 发表于 2019-1-19 17:44
大哥 你还在上学吧，你要是面试时候连for loop都解释我觉得你那就是傻：）

Hiring manager 告诉你，支持lz说法

“不要沉默”其实要求是think out loud

这个过程如果是平常工作，就是下笔（键盘）写代码之前，把解法思路跟组里过一遍，经过同意后才动手
反映在面试上 -- 我们assess这个人是否能如此的跟组里人工作
面试场景就好比平常跟同事交流

需要你能边想边说，即使实在是需要时间考虑，你也可以自言自语的样子说，这道题能否先给我1分钟考虑一下，然后我再跟你说我的思路，我们觉得都可以以后，我就动手写

你可以得到1分钟沉默

然后你需要开始说：你试图用什么data structure或者什么算法，不要张口就是leetcode题目名字，然后马上动手写
就算你知道那个题目的名字，也可能人家打算问variation

debrief的时候描述面试人的表现，大家一般这样说：这个人先打算使用recurrsion，试了一会以后发现不行，改用了blabla，然后做出来了，还是有点bug，不过自己walk through的时候发现并且fix了，一共用了xx分钟，所以我觉得还是可以的。

这个过程就是你在现场面试的时候需要清晰表达的：
比如不是上去就写recurrsion，而是说：因为这道题的如此特性，所以我打算用recursion，然后观察面试官。如果OK，就继续：我会先去考虑边界，然后“xx字描述recurse什么”，然后观察面试官，如果还OK，我觉得这样的空间时间复杂度什么什么的。。。。如果还OK，就写代码。i.e. 先 talk through问题，然后talk through 解决思路，考虑一下可能遇到的问题，再动手。

如果面试官觉得有问题，在你第一句就会提示，或者起码面露难色。这时候就要赶紧讨论，准备换方法。

所谓的交流应该就是保证面试者和面试观的思路在一个pace上。写一个东西，如果不是显而易见的，和面试官说明接下来要干什么，这样面试官才能跟上思路；另一方面，面试官说了一下，也可以去confirm，保证自己没有理解错误。这样每一步都保证两人节奏一致才能把交流往前推进，也是实际工作中需要的交流技能。

感谢分享！

谢谢分享！请问你们是有题库呢，还是自己想一个题？

ABCcac3 发表于 2019-1-20 05:33
to be fair,面试时候太安静简直是bullshit,没做过的题不可能看到就侃侃而谈，如果能有很好的communication ...

不会啊 有的时候没见过题 你也要先分析出来大概要怎么approach 跟面试官讨论你的方向合不合理 能不能先做一个brutal force的结果出来 然后不断改进

code需要达到能运行的成都吗  如果code思路大致正确，但是没写完成或者语法有纰漏，算是基本过关还是完全fail？

ABCcac3 发表于 2019/01/20 05:33:31
to be fair,面试时候太安静简直是bullshit,没做过的题不可能看到就侃侃而谈，如果能有很好的communication一定是之前做过的，然后大家就去拼演技，先给brutal force,...

我一般不會裝，直接給我知道的最優解 就算看過題
以後不太想做面官，做百几個一樣題的面試

ABCcac3 发表于 2019/01/20 05:41:28
communication应该考察的是candidate是否能和组里的人正常交流，不要太奇怪，而不是做题的时候说多说少，我赌一百刀要是出一题medium or 以上你没见过然后又不是熟悉的题目你立马就...

.--谁说直接讲答案的？你不要问具体要求吗？一句不问就做的才tmd是以前见过吧。

个人感觉交流肯定是必要的，但也不用一直说，不用每写一行代码都解释一下，think out loud就好。个人经验是，对于算法题不管见没见过，先花一分钟讨论题目，确认题目理解，确定限制条件。如果没有头绪，可以向面试官表示让自己思考一两分钟，控制好时间。然后开始讲自己的思路，时不时问一下how do you think about the solution so far之类的，确保开始写代码之前，面试官对你的解法认可。如果代码不复杂，可以向面试官表示自己先写，写完之后一起go through一遍，如果复杂，在每个方法或者重要代码块之前和面试官解释一下自己进行到哪里了。最后test的时候也会一直说话，所以个人感觉这样给面试官的整体印象就会是沟通比较积极。如果是设题计，可以沟通的更多，也便于打开思路。不过其实也要看面试官，有的面试官会主动提出让你先写，然后他们专注看代码，这样如果再写代码的时候一行一行解释，反而会觉得烦。