2012.5.25 微博热报——面试程序员的方法、敏捷转型

  • 侯伯薇

2012 年 5 月 24 日

话题:敏捷语言 & 开发架构文化 & 方法算法

梁斌 penny在微博上指出,面试程序员的时候,要的是生产力,而不是高智商;姜信宝 Bob在微博上提出问题,从非常成熟的瀑布式转型到敏捷开发,是否需要制定敏捷开发流程。两条微博引发大家的热议。

@梁斌 penny微博上提到:面试程序员最好的方法,定义一个系统,让其回去 rush 一个礼拜,rush 出来,gtest 都能过,外部几下子搞不挂,就行了。别尽整些数学题,ACM 小 trick 题,用这些没用的来苦逼码农何苦呢,要的是生产力,不是高智商。

大家对如何面试程序员也表述了自己的观点,有人赞同,也有人反对:

81 米:有道理,因为实际生产过程和搞研究完全两码事啊,很多思路对了,具体参考的资料可以很方便获得的…

爱瞎折腾的土人:这样的好处是能比较全面看出一个人的实际能力,缺点是是无法防作弊。折中一点的办法是关起来搞一天。不过这也有问题,就是各人环境不同,有人 vi,有人 ide。企业就算肯出钱让你搞一天,却很难提供合适的工作环境。

鞠海洋:这只能适用于候选人少的时候,像有些公司大规模招聘,来上 1000 个候选人,总要先通过面试题砍掉一批。

Ghost_141:还有,有些人在一个方面很精通,但是其他的不是很行,你让他看代码他能看懂,让他写完全不成,那样的话很有可能做不出一个系统来。总之感觉面试者在这个方法前太弱势了。

你也曾是愤青:我觉得有这种想法的人才是真正不尊重程序员的人, 你 10 个里面挑 1 个, 就要浪费别人九周的时间? 还要别人 rush? 你凭什么? 现在技术面试有弊端是没错, 但这个主意明显是空想嘛. 我觉得目前看来最有意义的, 就是编程社区: stackoverflow + github 的发展, 以后谁求职, id 一报高下立分。

sagasw:想法很好,不过不容易实现,还是很理想主义。我多半是根据要找的人大致级别询问问题,6 年经验的,对一两个小问题能很快回答清楚,能说清楚自己曾经做过的系统一些细节,知道一点点设计模式,说话能看着我,没有不良习惯,感觉不是冲动型或者过于缓慢型的,英语能对付几句,就可以收下了。

一杯摩卡 ICT:我觉得面试问数学题一个原因是还是想招具有一定分析问题、抽象能力的码农,因为本身工作就是要抽象模型,将不可计算的问题转化为多项式时间复杂度可以解决的问题,所以这些能力还是需要具备的。

郭昂 9:我觉得不妥,这反而是最容易作弊的方式。我面试还是看四点,第一,问一件过去做过的事情,要问细节,可考察一个人的经验、交流以及诚信;第二,基本功,例如数据结构,要问内涵,不照抄书本;第三,出一道实际问题让其提思路,考察解决问题能力;第四,现场写程序,不一定要很难很刁钻,但要考察其素质。

SiDT:我一般核心问两个问题,处理过最难的技术问题(看专业功底),作过或参与过的代表性系统 (看团队贡献和系统把握)。

左手戴佛珠:这个要看你招聘什么水平的程序员,如果你是招个写代码的,一般只要 IDE 用的熟悉,对将要从事的工作所采用的技术较熟悉,并且感觉人还靠谱就可以了。如果是招高级程序员或者架构师一般我就是从设计模式或者 UML、原型开发等方面来看。

@姜信宝 Bob微博上向大家请教:你认为从非常成熟的瀑布式转型到敏捷开发,需要制定敏捷开发流程吗?或者制定 milestone 敏捷衡量指标?

很多人都给出了自己的意见:

徐毅 -Kaveri:在转变的过程中是需要的,但是转变完之后应该要抛弃掉或者弱化其作用(更重要的是内化到每个基层工作者的习惯中)。

路宁同学:那些是手段,都在被或强或弱地使用着,对它的过度自信会带来副作用。流程会浮现出来,改进也自然有人关注其效果。

larrycaiyu:不要从流程想起。看看传统的最大问题,来想针对的方法。再把这些串起来,制定一些指导性的说明。不倾向于制定流程。另外,那瀑布熟透了点。

赵卫 David:为什么需要制定敏捷流程呢?实施现有的敏捷方法有什么障碍呢?比如 scurm,我们要创造我们的 but 吗?所以最好不要一开始去做这个事情,但是在转型过程中,也许它就涌现出来,以组织特有的语言描述来指导团队。无论有无敏捷流程,是否 but, 一切都要以敏捷价值观和原则来指导和衡量。

大绍鹏:新的标准可以是转变过程(持续改进过程)中的一个基线,不需要一步到位搞一个特别“理想的”新流程,逐步地改进以适应人的转变的过程需要。不过如果你的团队都是学习能力特别强的同学,或者已经进行了大量地宣传、教育、讨论、workshop、试点,群众基础已经打牢,那就可以考虑加快转变的速度。

大卫张 33:瀑布是应对确定性问题的,敏捷是应对不确定性问题的。milestone 和指标是将不确定性问题转化为确定性问题的努力,是在走老路,这是一种误导。但已经适应了确定环境的人们对不确定抱有很大的畏惧感,指标能带给大家安全感,减少对转变的抵触,可能是必要的,但在后期它会减缓真正转变的速度。

Ethan 苏于登:回复@姜信宝 Bob: 跟徐有点不同的意见。敏捷开发流程是什么呢?这个词好像用得有点广泛。用 scrum 或 xp 不已经是很好的起步了吗?关于指标,如果是想了解自己的实践与使用的进度,以便持续调整方向,那是非常合理的。况且我们都需对 boss 交代,总需要拿点实际的东西出来吧,也许这可成为部分考量?

关于面试程序员和敏捷转型,你的观点如何,欢迎加入讨论。


 欢迎读者关注@InfoQ官方微博,推荐热门话题,可私信@InfoQ,同时请您说明推荐理由。

敏捷语言 & 开发架构文化 & 方法算法