快乐的天空

时间来得快,去得也快

 

TW的经验

在ThoughtWorks日常的面试中,大致会分为多个回合,每个回合由不同的人采用不同的方式来面试,例如电话,笔试,面对面交流等等。一般能够通过这样的流程的人,大多可以接受,一般的公司也都采用这样流程招聘开发人员。电话面试的主要意图是要考察求职者的个人经历。因此,求职者应多谈自己:自己在团队中做了什么,自己挽回了什么错误,自己的责任是什么,自己带来了什么影响,自己存在什么问题。面试者看中的是这个人的表达能力,他所发挥的作用,他个人经历,他的信心。问问题也多为开放问题,并经常要追着问他某个项目中的某件事情,并要求他举例来说。
笔试一般为写代码或其他题目,对于代码,我一般要先看这个人的简历,根据他的工作年限和经历,判断他的代码应该是什么水平。对于未毕业的学生,不妨有所宽松,对于工作很久的人,如果他好学上进,接受新鲜的事物和新鲜思路多的话,代码应该是什么样子。这样的标准大概在90%的情况下是准确的。
Joe Homs 写了一篇 如何被我面试 很清楚的写出了各种过程的注意事项。对于技术人员的面试,相信每个做过开发人员招聘的人都会有所体会。技术问题很好度量,说一是一,很容易。然而,对于一些技术要求低一点的职位,如何面试就成了很微妙的问题。例如BA,PM等。
很多BA和PM很久没有写代码了,考察他们代码无疑是浪费时间。对于BA和PM,你可以不需要技术有多好,但你应该对技术有sense。至少别人正在用的新技术你知道是怎么回事。很多时候,BA和PM会在项目前期出现在客户处,决定一个项目的初始技术选择。

电话面试一个非技术人员也很麻烦,他们天天看别的PM和BA做事,你怎么知道他说的是他看到的还是他自己实践过的?所以很多时候,要追着一个问题问到底。这时候逻辑分析很重要,有的人前后说话会有矛盾,这就说明了他的说法有虚假之处,要小心。
我公司在面试的时候,有套逻辑题比较特别。对于Developer,当然要要求很好的逻辑才行。对BA和PM逻辑要求也不能低。例如BA,很多时候会面对逻辑比较差的客户,不能被侃晕是不是。
一个很tricky的事情是,许多人,可能觉得BA是要求比较低的工作,在申请公司职位的时候,觉得达不到Developer的要求才申请BA。我可以明确的告诉这样的人,BA不比Developer要求低,甚至在某些方面比对Developer要求更高,例如专注细节,例如交流,表达,组织,管理等等。一个差的BA,比一个差的Developer更能搞砸项目。
对于BA的面试,我经常采用角色扮演的方式来进行。我扮演客户,另一个同事扮演开发人员,我们一起面试一个BA candidate。我描述一些简单的需求,要求这个BA来分析和整理,并最终转述给开发人员。从这个过程中,很容易就能看出这个人是不是真正的做过需求管理的工作,是不是能够顺畅的表达,是不是能用一些巧妙地方法来获取真正的需求。
另一个难以面试的是PM。国内的PM很多时候扮演的更像是“政委”的角色。他负责管人和管理客户关系,主要靠做思想工作来控制团队,搞平衡。很少见有PM 真正的做项目进度、成本、范围、质量控制,或者说,在这些方面做的比较欠缺。而这样的PM,面试时候也很头大。敏捷团队中,人和思想基本上不需要太多控制,更多的是需要项目经理真正的监控项目本身的属性,理解项目并领导项目。
对于一些想要转行的人,例如作了很久Developer想要做BA了,这样公司也支持。面试的时候就主要看潜质了,也就是学习和接受能力。但如果一个人是因为做某方面实在做不下去了才要转行,那还是好好做回原来那份有前途的工作好。公司鼓励每个人多方面发展。一个Developer也应该具备BA或PM技能,BA也应可以兼任PM,QA也可以转行当BA,这种每个人都了解其他知识,每个都负责的团队,才是最好的团队。

posted on 2012-06-03 12:52 探路者 阅读(217) 评论(0)  编辑 收藏 引用 所属分类: 学习笔记


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿

随笔分类

随笔档案

文章分类

文章档案

新闻档案

Android

Compiler Course

VIM

编译技术集合

测试

高性能计算

个人博客

框架/组件/库

搜索

最新评论

阅读排行榜

评论排行榜