最近的一次面试体验不佳, 怎样的面试才算"专业"或"有效"?

[MXXXXXS]

分享一下自己几次面试下来的思考, 大家怎么看?

面试的一些问题

不仔细看候选人的简历

面试官往往事先准备了想问的问题, 并不关心候选人的实际情况, 先入为主

这个现象遇到过不止一次, 在自己最开始学 vue 的时候被问 react, 后来上手了 react 又被问 vue

反正就是不关心候选人的具体情况, 这对候选人的了解是非常不深入的

不给候选人问问题的机会

面试是双向选择, 公司本身很多事情候选人也需要了解考虑

即使是买方市场, 公司招人可以随便挑, 但候选人如果发现入职后和预期有较大差距会导致浪费双方的时间

喜欢问一些很细节的点

闻道有先后, 术业有专攻, 问很细节的点为难候选人带来的虚幻的成就感并没有任何价值

一些很细节的点如果平时没遇上相关的场景一般是不会去了解的

但有些面试官就喜欢找一个小细节来问, 比如append和appendChild的区别

这种具体的细节问题往往只需要搜一下就可以知道, 问了也没什么价值, 难道是为了考记忆力?

平时实际编写过程中涉及的知识面广而杂, 一般都是记了一堆"key", 有个印象, 等实际要用再去深究

所以应该考察的是候选人解决问题的思路, 不知道这个东西会去如何搞懂

广撒网

遇到过用一道 hello world 级的笔试题考察候选人后就让其去面试的, 简历都没看

招聘方的想法是尽可能多的面试候选人, 广撒网, 有更多的选择余地

但忽略了效率和质量, 因为广撒网, 导致分配到每一个候选人的面试时间很少, 没法详细考察候选人的情况, 同时低门槛导致候选人良莠不齐, 总体质量偏低

从效率和质量上讲这种方式是有问题的, 而且浪费候选人的时间, 专程跑一趟费时费力

应该使用几道有阶梯性难度的题目作为笔试, 并结合简历评审后再决定是否邀请候选人

考算法

算法在实际业务编写中占比不大, 并且往往不复杂, 在造一些轮子时才会有要求

个人认为, 算法在实际应用中的正确打开方式是有需求的情况下去学习并实现, 或是使用已有的实现

比如自己实现列表渲染时才接触到"最短编辑距离"这个动态规划算法, 经过研读原理和多次调试给出了代码实现

但之后时间一久就再没什么印象了

而现在大厂普遍喜欢考各种经典算法, 候选人的应对方式是大量刷题背题, 非常非常应式又耗时

从零实现是不现实的, 先人耗费大量时间沉淀出来的理论成果怎么可能在短短的面试期间复现? 所以只能是背题, 而人记忆力是有限而不稳定的, 这种方式非常反人性

可能是由于买方市场, 只是为了筛掉人

这对平时的代码能力有多大提升?这些时间更应该用来巩固基础知识

应该怎么考察候选人

解决问题的方式

或者说是学习能力, 如何获取资料

实际代码编写过程中遇到的未知往往比已知更多, 解决和应对未知的能力是一个核心点

学习的方法

几乎所有的知识都可以通过堆时间来换取, 但不同的方式换取的速度和质量不同

正确的学习方法也是一个及其关键的点, 可以说是知识密集型职业的核心能力, 很多时候所谓的能力差距究其本质是学习方法带来的差距

不同的学习方法会导致不同的知识获取途径, 进而导致知识获取速率和质量的差异

[forward]

负责我司第一轮前端面试，只面基础和算法。上次去微软面试，直接就让我手写一个 promise 。。。

[ETiV]

我也负责面试，简单说就是“你的现有经历是否对得起你的工作时长”、以及“这个人经历得不多，那他是否聪明机灵，值得培养”