关于面试的换位思考

我当面试官时

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

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

若是面试者写不出来，我基本是不给过的。由于这是我认为的一个golang程序与其它语言程序最大的不一样，若是写不出来就表明没真正的用过golang。

我当面试者时

风水轮流转，公司由于融资问题，经营不下去了，我只能再次踏上找工做的路。

虽然说在这份工做中，我获得了本身想要的golang工做经历，可是对golang语言细节的掌握仍是有些粗糙的。而转型当互联网行业的开发后，我对redis和kafka之类mq的使用，还未曾有过深刻的使用，也成了本身的软肋。

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

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

虽然说这些知识点不是彻底不知道（但回答的不是很准确），可能会缺少解决某些问题的能力，但具体是哪些问题呢？面试官又说不清楚。

我以前是不大承认这种搜索就能获得答案的问题，但换个角度来想。

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

无非是基于他认为是重要的知识点！因而，难免有认知偏见。

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

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

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

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

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

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

写到这时，忽然领悟，面试的考察方式在根本上取决于究竟是买方市场仍是卖方市场。

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