关于面试的换位思考

710 阅读3分钟

我当面试官时

之前公司招后端程序员的时候,我负责考察面试者golang的掌握程度。

通常我是要求面试者上机用channel写一个多常驻协程的任务队列,然后再不断的延伸发问,考察面试者对goroutine和channel的掌握。

如果面试者写不出来,我基本是不给过的。因为这是我认为的一个golang程序与其它语言程序最大的不同,如果写不出来就代表没真正的用过golang。

我当面试者时

风水轮流转,公司因为融资问题,经营不下去了,我只能再次踏上找工作的路。

虽说在这份工作中,我得到了自己想要的golang工作经历,但是对golang语言细节的掌握还是有些粗糙的。而转型当互联网行业的开发后,我对redis和kafka之类mq的使用,还不曾有过深入的使用,也成了自己的软肋

最近的一次面试,就是挂在了这上面。

关于,golang的GPM、协程的调度方式,包的初始化顺序等细节问题,我没有答上来。加上偏偏他又问我有没有用过redis和kafka,和数据库有几种锁。。

虽说这些知识点不是完全不知道(但回答的不是很准确),可能会缺乏解决某些问题的能力,但具体是哪些问题呢?面试官又说不清楚。

我之前是不大认可这种搜索就能得到答案的问题,但换个角度来想。

一个面试官如何考察面试者的水平?

无非是基于他认为是重要的知识点!于是,不免有认知偏见。

话说回来,对于一个工程师而言,最重要的不应该是他的学习和解决问题的能力吗?

对于一个资深的程序员,分析问题并合理的设计可扩展可维护的方案不才是他的价值所在吗?

那么,为什么面试时确要用语言细节+使用的工具经验来考察面试者呢?甚至还会是用纯算法来考察面试者?

想来想去,我的初步结论是:学习能力、解决问题的能力和设计能力难以被量化衡量,所以只能间接的借用一些特征来辅助判断,比如说语言的掌握程度、算法能力等。

再加上国内的互联网企业的招聘更重视“开箱即用”,所以才有用没用过、知不知道之类的问题吧。

接着换位思考一下,如果面试者这些不知道、没用过,只表示说愿意学,确实对面试官没很大的吸引力,毕竟来面试的人又不少。

写到这时,突然领悟,面试的考察方式在根本上取决于到底是买方市场还是卖方市场

好吧,赶紧睡了,明天还要抓紧刷"面试常问题库"呢 ^_^