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

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

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

大家对如何面试程序员也表述了自己的观点&＃xff0c;有人赞同&＃xff0c;也有人反对&＃xff1a;

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

&＃64;姜信宝Bob 在微博上向大家请教&＃xff1a;你认为从非常成熟的瀑布式转型到敏捷开发&＃xff0c;需要制定敏捷开发流程吗&＃xff1f;或者制定milestone敏捷衡量指标&＃xff1f;

很多人都给出了自己的意见&＃xff1a;

\u0026#xD;\n

徐毅-Kaveri&＃xff1a;在转变的过程中是需要的&＃xff0c;但是转变完之后应该要抛弃掉或者弱化其作用&＃xff08;更重要的是内化到每个基层工作者的习惯中&＃xff09;。

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

\u0026#xD;\n

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

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