我当面试官时
之前公司招后端程序员的时候，我负责考察面试者golang的掌握程度。
通常我是要求面试者上机用channel写一个多常驻协程的任务队列，然后再不断的延伸发问，考察面试者对goroutine和channel的掌握。
如果面试者写不出来，我基本是不给过的。因为这是我认为的一个golang程序与其它语言程序最大的不同，如果写不出来就代表没真正的用过golang。
我当面试者时
风水轮流转，公司因为融资问题，经营不下去了，我只能再次踏上找工作的路。
虽说在这份工作中，我得到了自己想要的golang工作经历，但是对golang语言细节的掌握还是有些粗糙的。而转型当互联网行业的开发后，我对redis和kafka之类mq的使用，还不曾有过深入的使用，也成了自己的软肋。
最近的一次面试，就是挂在了这上面。
关于，golang的GPM、协程的调度方式，包的初始化顺序等细节问题，我没有答上来。加上偏偏他又问我有没有用过redis和kafka，和数据库有几种锁。。
虽说这些知识点不是完全不知道（但回答的不是很准确），可能会缺乏解决某些问题的能力，但具体是哪些问题呢？面试官又说不清楚。
我之前是不大认可这种搜索就能得到答案的问题，但换个角度来想。
一个面试官如何考察面试者的水平？
无非是基于他认为是重要的知识点！于是，不免有认知偏见。
话说回来，对于一个工程师而言，最重要的不应该是他的学习和解决问题的能力吗？
对于一个资深的程序员，分析问题并合理的设计可扩展可维护的方案不才是他的价值所在吗？
那么，为什么面试时确要用语言细节+使用的工具经验来考察面试者呢？甚至还会是用纯算法来考察面试者？
想来想去，我的初步结论是：学习能力、解决问题的能力和设计能力难以被量化衡量，所以只能间接的借用一些特征来辅助判断，比如说语言的掌握程度、算法能力等。
再加上国内的互联网企业的招聘更重视“开箱即用”，所以才有用没用过、知不知道之类的问题吧。
接着换位思考一下，如果面试者这些不知道、没用过，只表示说愿意学，确实对面试官没很大的吸引力，毕竟来面试的人又不少。
写到这时，突然领悟，面试的考察方式在根本上取决于到底是买方市场还是卖方市场。
好吧，赶紧睡了，明天还要抓紧刷"面试常问题库"呢 _
