上个月，在负责技术晋升评审的过程中，有人认为在评审过程中以述职讲述为主，可能对某些比较擅长写代码而不擅于演讲的同学不公平。而对于中级别的程序员技术晋升我们更倾向于筛选出擅长编程，而非仅仅是说得好的同学。
这个过程里面，存在四种情形：
代码写得好，也说得好
代码写得好，但说不出
代码写得不太行，但说得很好
两者都不行
晋升筛选的目标是选出 1 和 2 两种，筛掉 3 和 4。这里面的挑战在于，在采用述职答辩这种形式下，1 和 3 这两种很难分辨，同时 2 和 4 也很难分辨。关键就在于如何识别并判断代码写得好还是不好的问题，区分度的标尺怎么定的问题。这个判断问题在面试程序员时也存在，要不就先从「代码面试」说起吧。
1
在我过去十年多一些的从业经历中，倒是面试过很多次，其中不乏面试写代码的。
刚毕业那年第一次去面试，聊了没几句面试官就给了一张白纸和铅笔，要求在纸上用 C 语言写一个快速排序算法的实现。这次经历我记忆犹新，差不多半小时，我磕磕碰碰的写了一个实现。在和面试官讨论时，被指出了不少没考虑到的情形和漏洞，后来的结果自然是没能通过。
现在回想起来，在纸上编程真是一件很难受的事情。虽然五十年代的程序员基本都在纸上编程，那是因为那时计算机的运行成本很高。但面试时的纸上编程，一方面时间很有限，另一方面环境和氛围比真正的编程要紧张不少。所以，我是不支持纸上编程这种形式的，它既不能让候选人很好的发挥，另外一方面也可能没有足够的区分度。比如，像上面那样写一个著名的算法实现，背过和没背过差别可以很大，但对真正的编程能力却不足以区分。
