面试时,我会问你什么

最近由于需要在团队中增加人手,陆陆续续的参加了几场面试。于是便有了LinkedIn上“面试面的万念俱灰”的状态更新。依稀记得半年多前,自己也参加了一大批面试,当时也是为了扩充团队。但那时候的感觉貌似比现在要强一些。

“万念俱灰”只是一时间的情感冲动。事实上远没有到那个地步。但这批应聘者整体能力偏低确实超出了自己的想象。尽管已经被提醒过:永远不可能招到完美的人,但发现自己的底线实在是无法再降低了。

每个人去当面试官都会有自己不同的侧重点。但无外乎是考察应聘者的基本能力,对自己实际参与的项目的真实的掌握度,过滤掉简历和面试沟通中的水分。再多一些可能就是看看应聘者的沟通能力,学习能力甚至是抗压能力。

我通常会让应聘者先做个卷子。里面是一些相关技术的基础题,涵盖面比较广,但难度并不大。限时30分钟完成。英文试题但可以中文答卷。我们是个美国企业,对员工有基本的英文读写能力的要求。用英文出题就是为了检查这最基本的阅读能力。如果发现应聘者对题目的理解出现错误,那至少他在这方面没能完全符合我们的要求。理解错的题目可以在后面的面试过程中口头提问,这样也能避免因为他理解错而答错的情况。做卷子的另外一个目的是给到应聘者一定的压力。对于这个级别的招聘,不大可能有人能全部答出题目。如果应聘者在答完题后发现有一部分自己不会,那相对来说他在后面的面试部分会少些水分。其实我个人一般不太关心答案本身的对错。因为都是基础题,答对了不表示水平高,答错了也可能只是因为没接触过那部分而已。

面试部分我会让应聘者自己挑一个他参与的较深的项目做介绍。对我来说,我并不关心这个项目,或者说这个产品是做什么的,有些什么很酷的功能。我希望听到的是该应聘者在这个项目里参与了什么,做了哪些部分,有哪几个模块或者功能块是他做的。在做的时候考虑了什么,怎么设计的架构,怎么做的优化,遇到哪些问题,又是怎么去解决的。

这是个比较容易掺水的部分。很多人会把别人做的讲成自己做的,把别人的设计讲成自己的设计。而我会通过一问到底(通常是追问到代码级别的细节),找出到底哪些是真的,哪些可能不是真的。有些人声称使用了某某框架,多种设计模式。那我会想知道这个框架的架构是什么样子的,能不能画出相应的图例来简单表述。我也会问设计模式中一些比较常见的模式该怎么写,能不能给出示例代码。如果啥框架也没用,那我会要求通过类关系图来介绍整个项目的架构,通过序列图来说明某个行为的流程。(不是所有人都会画类图和序列图的!)

我通常还会问一些相关技术领域里比较常见的问题以及应聘者的解决方案。我会要求对比不同方案的优劣,以及什么情况下该使用哪种方案。

面试时应聘者的态度也会成为考量的对象。你别说,我还真遇到过应聘者趾高气扬,觉得你(面试官)啥都不懂,怎么这种问题都问的人。不过常见的应聘者一般还都比较谦虚,多见的是紧张,有的甚至紧张到结巴。我问出的问题,我并不一定都知道答案。我说我“不太了解”的未必我真的不懂。作为应聘者,能不能以最少的话,最简洁的描述把答案讲清楚,能不能耐心的为面试官细化答案是我非常看重的。我觉得一个无法进行有效沟通的人是会给以团队为单位的开发小组带来消耗的。

作为面试官,我希望应聘者表现的是最真实的一面。没做过,不知道没关系,直接告诉我就行。别在那里瞎忽悠,因为最终还是会被识破(我会把一切我不确定的内容归到“假”的那部分去),并且被扣上“忽悠”的帽子。

Advertisements

Google Reader, 谁可以替代你?

昨天在我还没来得及打开Google Reader看过去24小时世界上发生的事情前(我一般在下午4点才有时间看GR),惊闻GR将在7月1号关闭,一时间有点措手不及。

GR对我来说确实有点“不可替代”。我还不习惯所谓的“个性化阅读推荐”。实际上是最近的尝试让我根本不相信他们能推荐出什么好东西。而自己搜集的RSS却能让我以最少的时间获得最大化的信息搜集。所以一款传统的RSS订阅软件对我来说最合适不过了。

对于这种软件,我的要求其实很低。我只要一个Web网页,可以让我在任何机器、设备上用同一个账号登陆。当然它需要有能自适应手机、PAD浏览器的能力。我不喜欢一个手机应用,也不喜欢一个电脑客户端,因为他们都不是可以让我在不同设备、不同环境下使用。根据我的需要,我花了一个中午的时间找了一找,并试用了几个。Good Noows是我觉得比较好的一个(从功能上来说)。但它的界面设计,用户体验实在是让我不知道说什么好。GR的各种方便的功能在GN里一概找不到。字体小而丑。我很难想像自己以后要用这样的一个客户端。

后来看大家都极力推荐Feedly。这个服务我以前试过,但由于听说它后台也是连的GR服务器,担心它在7月1号也会随GR一起消失。不过Feedly及时“辟谣”,说他们不会。Feedly有着漂亮的界面,不错的移动支持。虽然在阅读体验上和GR不同(也感觉没GR好用),但目前看来这可能是最有可能替代GR的一款服务。

其实让我更担心的是我的信息归集的方式。获得一个特定范围的大量信息不是一件容易的事情。RSS是其中一种方式,但从RSS的搜集端(软件,客户端)来说貌似这种方式有着其自己的弊端。目前我还没找到有其他什么方法可以达到同阅读RSS一样的效果。本来计划在近期总结一下自己的信息归集方式,但现在看来,还是需要好好再考虑一下了。

从亚马逊的快速下拉菜单看产品的细节设计

刚才在著名的36氪看到一篇文章,揭秘了为啥亚马逊首页的那个产品分类的下拉菜单响应速度那么快。文章里提到了从技术上实在菜单的实时更新并非难事,但如何在保持菜单更新速度的前提下减少用户从主菜单切换到子菜单时菜单切换的问题。亚马逊采用了对鼠标轨迹判断的方式,通过用户移动鼠标的路径来猜测用户是要进入子菜单还是切换主菜单。

看了之后我手一痒,点开了亚马逊,那个菜单确实飞快。又点开了京东,相比之下,差距就比较明显了。

这就是一个产品的细节设计。很多人说苹果的产品好,用着舒服,原因也就在于人家把很大的精力花了在细节上。甚至于有些细节一辈子都不一定用的上。即使用上了也不让人觉得这个是刻意设计的。细节上的成败就是体现在让用户无形中感到对产品的使用“顺手”,“意料之中”,“低学习成本”。

我自己属于产品开发团队,平时也收到很多产品经理对产品的要求。但大都是出于对产品大的功能性的定义和要求,而很少(准确的说是没有)收到过任何对产品细节上的改进。如果我们只注重于交付一个“可用”的,“功能丰富”的产品,那也对我们来说,充其量只是合格。离“优秀”还有很大的距离。

对于桌面电脑(带键盘鼠标的那种),有没有想到过通过按键盘的ESC或者在弹出式对话框区域外来按鼠标来关闭弹出框?有没有想到在用户推出程序后保持程序状态从而在下一次启动时恢复上一次的样子?对于移动设备,有没有想到在用户接上外接显示器时,自动暂停当前播放的电影几秒钟并且稍后继续播放?

我们有好多好多可以做。