前两年做面试官的时候，总是喜欢考算法编程题，对于来面试的人的工作经验却问得潦草。 这其实很偷懒的一种做法。因为考算法一定是挑你会做的题去考别人，主动权是在面试官手里，而跟被面试的人聊项目经验，人家却比你懂得多，不认真投入是不行的。
当然现在想来也是有另一重原因的，工程经验这个东西，那时我自己都没有，怎么去考别人？
以我的面试经历来看，社招来的人做算法题大都磕磕巴巴，但招进来给的钱却更多，除了市场竞争原因之外，经验必然还是有用的。 如果来面试的不是一个刚毕业的学生而是一个有几年工作经验的人，那么光考察算法编程能力就实在是没抓住重点了。
最近一年多来，贵司大力度的招人让我狠狠地攒了一下面试的经验值，面试过的人五湖四海形态各异，从我上小学那年就已经研究生毕业的大叔到90后小留，从在简历上都不写教育背景的野路子程序员，到MIT绩点5.0毕业的神仙。 在尝到小破公司建团队不易的同时，也对于跟被面试者聊天这个事情越来越有心得。
问一个人的经验，实际上是问一个人做事的方式。如果说考察算法算是考试人会不会做事，而跟人聊经验才是真正看人能不能成事。
一般来说，一上来我会先让被面试的人简要介绍一下自己，到后来我会提示对方，可以给我讲讲你简历中的闪光点。特别是有比较长工作经验的人，他们的简历可一点也不“简”。 在这个阶段，我觉得一个优秀的码农起码应该清楚自己的简历里面哪些东西是真正有价值的，并且能够很有条理地讲给没有相关背景的人听。 之前看过很多通用的求职鸡汤文章，都说简历里面重要的是突出自己的工作把产品的效率提高了百分之几十，让销售额增长了多少之类的。 但是作为程序员的面试，我其实只关心两件事：
这件事的复杂度如何，你接触到了多大的一块，对于你没有参与的模块，你又了解多少?
一个人过往的项目的阐述清晰程度，直接反应了他对自己做的事情的参与程度以及对复杂系统的把握能力。这也是挤出简历水分的常用技巧。
最近几年面试的人，经历五花八门，有号称自己给美军潜艇写网络协议的，也有说自己在拉斯维加斯写老虎机的嵌入式代码的，还有说自己维护着现在公司的私有Linux版本的。 但是大多数人不但说不清楚自己参与的项目的全貌，连自己做的一小块东西在整个系统里哪一个位置都很难指明白。
最近面试的一个比较印象深刻的人，虽然有着浓得化不开的印度口音，却让我觉得其实这个事情也是有套路可言的。
她跟我说她参与的项目是一个企业级的ERP系统，这个系统有个功能是通过一系列复杂的操作导出不同的报表，但是这个事情的测试很麻烦，因为是工作流软件，很多时候都要手动测试。 于是她设计了一个基于XML的表述性语言，通过脚本解析，把这些操作自动化了，这样可以自动模拟测试场景直接比较最终报表结果。
寥寥几句，其实覆盖了四个方面：
- 参与的是一个多大规模的系统
- 要解决的是什么问题
- 做出了哪些努力
- 得到了什么效果
比起来，很多人花很多时间给我吹嘘他们参与的项目和产品有多少多少功能，多么多么强大，还滔滔不绝让人没法打断，实在是让我哭笑不得。
当然，更高级一点的求职者，会把全局讲述得更主干清晰一些，抓大放小，既便于听者理解，也吸引人发问，一来一去，很容易就聊开心了。
比如有些有创业经历的人，对于产品的方方面面都很了解，但是他只告诉你这个产品实现什么功能，前端用什么，后端用什么，怎么联系起来。 你自然会想要问如何扩展？缓存是怎么做的？一致性是怎么保证的？总之在别人发问之前，不要先自己沉迷于细节是很重要的。
对应到招聘者的实际的需求则是一个新人来到一个新环境里，需要短时间内熟悉的东西很多，那么对于复杂系统的快速上手能力就很重要了。 同样是一个项目的代码，有的人会抱怨文档不够，有的人有会抱怨文档太多，有的人却能短时间内理清脉络甚至根据自己的经验提出改进意见，最后者才是社招真正的价值所在。
你是如何做出技术上的选择的？
这类问题往往问起来很随意，比如既然你抱怨AngularJS不够快，有没有考虑过ReactJS？为什么使用Redis而不是Mysql？ 其实可以了解一个人在做事的时候只是跟随别人还是自己有思考，以及这个人是不是对技术有热情，对完美解决方案有追求，最后就是考虑事情够不够周全。
总之一点，就是是否靠谱，是否可托付。 说真的，如果招进来一个人，分分钟都得看着，他写代码比你自己写还累，这团队的可扩展性不会太好。
当然，编程还是要考的。既然是码农，基本起码功不能丢，但是在写程序的同时，我会更少关注手册上可以查到的东西，而更多地看重逻辑之外的东西。又或者说对于产品运维方面的考虑。 通常在被面试者吭哧吭哧写完代码之后，我会问类似如下的问题：
- 你这段代码如何测试
- 程序效率如何优化，在什么情况下需要重构
- 有哪些冗余的逻辑可以去掉
- 你的程序如何监控
对应到自己这两年学到的东西，其实写逻辑代码真的只是一个软件产品很小很小的一部分。在一个产品的生命周期中跟业务逻辑不相关的但是又非常重要的问题包括：
- 产品经理的设计是否合理？如果不合理，是否是需求理解的问题？ 如果过于复杂，是否需要重新评估成本？
- 代码如何自动化测试，例如一个由timer触发的任务，是不是应该提供一个接口给测试框架来强制触发该任务？timer本身又应该怎么测试？
- 如何支持冗余，一个服务不应该变成单一失效点，所以在设计的时候，就需要考虑多实例共同运行，那么实例之间的协作和一致性又怎么保证？
- 如何自动化部署？对于一个新建的服务，部署的时候并没有已有的流程，而你必须假设实施部署的人没有任何产品知识。如何保证部署的时候不出错？
- 产品的运行如何监控？是不是应该添加进程监控脚本？需要关注那些指标的变化，是否暴露了足够多的运行时状态使得自己能先于用户感知问题？
- 如何对正在运行的服务进行诊断？如果后台的事务出错，是否有足够的日志记录？是否能重现错误？是否有足够友好的界面提供给支持部门的人使用？
- 你设计的产品的性能是怎么量化的？何时扩展？如何扩展？是可以直接加硬件，还是需要额外的开发工作？
对上面这些问题的回答，基本上是鉴别一个人是否真的在之前的工作中学到了真正有用的经验的标准。
而这有没有这些经验有什么区别？ 借用《禅与摩托车维修艺术》里的比喻，如果说你的产品是一辆摩托车，没有这些经验的人就是那个根本不了解摩托车怎么运行，只会拿着扳手四处敲碰运气的车行伙计，有时候凑巧能修好些小毛病，但长期来看一定会加速弄坏它。 而真正有经验的工程师则是那个知其所以然，所以敢于拿易拉罐上的锡皮去修宝马摩托，使得它即使用过改过坏过之后还能接着平滑运转的人。