不懂技术，如何为公司捕获一只靠谱的攻城狮？

 

关键词是 “轻松”，面技术的人一定要轻松，因为技术人很容易绷着。我们面试的那个屋子，有一个正经的凳子，还有一个放在地上的那种，类似于野餐时的一个靠垫。我面试时，经常坐在这个靠垫上，就是我仰视他，他俯视我。

通常来讲一般是不好的，交流最好是平等的，但是做技术的人这样是可以的，特别是如果我们对他专业水平判断上觉得比较吃力时，我们要通过一些附加的东西来判断，这些附加的东西一定要建立在一个非常好的沟通基础上。
面试技术人才，可以注重几个加分项：

在一个行业里，可能有一些技术问题是广泛有共识的，就不需要再费太多心思钻研技术。那这个时候，招进来的人了解这个共识会有优势。

就像唯品会，早期时候，它是一个非常简单的技术架构，三层，应用、缓存、数据库。这个应用结构跟其他电商的有很多相似性，在电商里面存在库管系统，它后面还有一个很大的后台系统。这个跟社区，跟 UGC 体系设计是不一样的。如果有行业经验的话，就知道这样的一个库管系统应该怎么做比较合适。

我觉得创业公司有一个会张罗的，又会做技术的人是非常幸福的一件事。因为很多大公司流程管理通常来讲是比较严格的，从产品设计到产品原形，到切图，到开发都有人给你做好了，自己不用费心。但是在创业公司里面，很多时候是需要有推动能力，怎么能够把这个东西在不影响进度的情况下，尽快地推出去。这个时候管理经验是比较重要的。

我们之前有一个客户，说他的项目老延期。延期的原因其实是非常简单，他的产品定义导致工程师陷入了....深深的思考。

这个产品定义是：短时间之内，你不能频繁改你的个人资料。工程师就想短时间是多长时间？三天？七天？于是他自己设计了一个非常复杂的算法，来处理这个短时间之内不能重复修改个人资料这个事。但实际如果要做管理的人就知道，这个事不重要，就跟产品经理打声招呼，说我给你做成三天了，或者说这个东西暂时不是很好设计，我能不能放一放？稍微沟通一下，就能减少浪费的时间。

公开资料指的是，比如在中国架构师大会，在一些论坛、知乎等公开的场合发表过东西。因为工程师如果对自己的专业没有信心，他是不敢说这些事的，会被人喷，工程师说话一般都不留情面，很喜欢去批判，所以他敢公开地写自己的资料，写这些他对技术的观点，都是经过仔细的打磨。
 

这里的聪明就是大家理解的聪明，我总结了一下，所有我觉得最后很棒的工程师都非常聪明，而且都是看起来很聪明。那些一开始觉得可能大智若愚的，最后其实也不怎么太能干。好的工程师一定是聪明的，怎么表现出来聪明呢？你跟他对话时，会很舒服，你问的问题他一定听得懂。就算不懂这个专业，也能够很好地交流。能听懂问题，能很顺畅地把自己所要表达的东西有逻辑性地说出来，这个事其实很重要。也有的工程师，他不跟你说很多，他就说这个很简单，这也未必不聪明。他说这个很简单的时候，你可以问他如果不用这个方法会不会很复杂。总之，一定要把他逻辑性里他最后没说出来的那个东西问出来。

如果喜欢把简单问题讲复杂，这个人请到团队里，是有可能对这个团队造成伤害的。现在很多 CEO 很难去管理自己技术团队，原因是沟通不便，明明是一个很简单的问题，他非要把它说得很绕，说得非常复杂，说成某种神秘的东西，越神秘的东西你越不好控制。他问你要钱、要人的时候，你又不好评估，这个处境就很尴尬很被动。所以说当一个不太爱交流的工程师说 “这很简单”，其实这是一个好事，让他简单讲一下，如何做，第一第二第三，听一听就大概知道了。如果不了解他所说的领域，就看他说那几点之间的逻辑性是不是能找出漏洞出来，这个一般是能够看出来他的技术水平怎么样的。

Geek 是双刃剑，非常牛的 Geek 可以解决超具挑战的问题，但如果你团队里没有一个人能控制得了他，是有风险的。

主要是三个事情，第一是过度使用技术，有些 Geek 喜欢用的技术确实太前沿，不成熟。检验这个可以去搜他所用的技术关键词，看有多少关键词的结果，社区活跃不活跃，有没有开源的东西，对标的产品里面有没有人在使用，来看这个技术的风险有多大。

第二个就是 Geek 一旦走了之后，里面的代码没人能改得了。很多工程师都会说这个东西我还不如推倒重写，这个原因就在于很多代码是非常难去改的。是一个新房子重新装修比较简单，还是你已经装好了二手房，你把它拆了重新再装比较简单呢？接盘其实比重新做还要复杂的多。这也就是说 Geek 团要做一个技术方案时，需要有一些文档，需要有一些讨论记录，需要有一些辅助性的东西能让他把自己的思路讲出来。那种独狼型的，很厉害，一个人把事全搞定了，但是别的人不知道怎么接，如果他走了，你的公司就有巨大的风险。

最后一个风险就是不以业务为导向。一般来讲要做以业务为导向、技术为驱动，这样是个比较好的方式。不以业务为导向的一个很重要的表现形式就是一个工程师在接产品需求的时候不问任何问题，这个东西给你做，看一眼说 OK。这一定有问题，几乎没有任何一个产品需求是没有问题的。

我举个例子，大家来看看。我在微博的时候，有一个产品经理跟我提，说我要给微博大 V 做一个需求。这个需求其实不难，但大 V 这件事不简单。大 V 是一个很虚的概念，什么叫大 V 呢？是王老师、徐老师这种有几千万粉丝的叫大 V，还是有八百万、五百万的叫大 V 呢？代码是数学逻辑，它没有模糊的概念。如果我们拍下来说一千万以上叫大 V，这个人突然掉了一个粉，变成 999 万，那他还是大 V 吗？这个事情是没法做的，大 V 这个标签是很虚的东西，所以说几乎所有我们认为理所应当分分钟就搞定的产品需求里面，都是有各种各样的技术问题。

但是如果我不以技术为导向，我觉得这个事情很简单，接了。接了然后我就慢慢做，我就自己设计一个很复杂的方法把大 V 算出来，然后我还可以预估这个人什么时候可以成为大 V，根据他过去一周粉丝增长的数量，我完全可以做得非常复杂，而且技术上做得非常漂亮，但是并没有卵用，但是技术大咖 Geek 会很爽，做了这个东西，非常有成就感。
 

普通工程师最关切的就是我到这能学什么东西，所以这个时候，我们应该在术语上会来强调一下我们这确实有牛人带你，我们这个团队技术上有多厉害。像我每次招人的时候，我都会说我们是新浪微博通讯平台核心团队出来的，然后怎样怎样，让他觉得这个事情是可以学到东西。

技术主管看重的是专业要对口，业务要好，领导要支持。技术主管的年龄通常 30 岁左右，积累了一些经验，所以希望要大展所长，专业要对口。业务好会给他很大的信心。我问了几个之前在微博的同事，跳槽的，大部分都是这样的情况。专业上，他认为对口，业务上，他觉得未来有发展，领导也比较支持他。

Facebook 有一个技术管理的金句，当一个工程师在专注写代码的时候，即使是跟他打招呼，say 一下 hello，也是在打扰他工作。工程师最好的状态就是他每一天早上一睁眼就知道我今天要干什么，有序的、稳定的去干。最好不要不断地打断他，不断地调整他的工作节奏。

晚上七八点钟的时候，要在技术团队里面转圈。一般来讲，如果一个工程师的工作顺利，而且又有节奏的话，他到七八点钟的时候，不会是那种愁眉苦脸的样子，一定是很轻松愉悦的。因为今天一天的工作差不多要结束了，看看博客，看看线上服务器怎么样，一定很轻松，很舒服的一个状态。如果他是非常痛苦的在那搞一个东西，很有可能陷入到了短期之内不要变更资料这样的问题里面去。这个时候，要技术的老大来主动发现，所有中国的工程师都是这样的，你要主动地去接触他，不要等他来汇报。

我觉得周报还是很有必要的，特别是技术老大写周报，我觉得是有道理的。这个主要是为了让技术的人学会用非技术的语言来描述技术问题。什么是技术语言呢？典型的就是说我这周把我的数据库分了 128 个表，消息队列我设了 64 个队列，每个队列长度是多少，然后部署在什么服务器上，这是一种技术性的语言。

非技术的语言是这样的：我们现在处理的这个请求峰值或者是用户量是多少多少，下面我要做数据库相关的扩容，能够承载这些数据量。我要做消息队列，主要是为了提高写入的能力，预计要花多长时间把这个事做完，做完了之后，我就能达到多少多少量了，然后这件事情我现在已经完成了多少多少，后面可能有什么风险，最坏情况下可能要延迟一周。

大概这样的一个东西，你就能知道技术的团队忙活了一周，他们能对业务带来什么样的改进。比如说我要承载多少多少数据量，这个事是谁来定的？肯定是我们业务团队来定，比如我要做个活动，我要做个双十一，那我要预算服务器要到什么程度，这个项目才不会挂，这个很重要。