Work 版 (精华区)
发信人: qubo (qubo), 信区: Work
标 题: 15位业界专家的面试高招(zz)
发信站: 哈工大紫丁香 (2003年09月18日14:26:47 星期四), 站内信件
原文http://www.csdn.net/news/newstopic/11/11193.shtml
在众多的求职者中找出优秀的程序员并非易事。文中讨论的面试技巧,均来源于一些世界
级专家在最近一次关于编写优质代码的会议上的发言,经典而实用,相信读者定会受益匪
浅。
2003年1月,我参加了俄勒冈州波特兰市召开的一个名为Writing Better Code的会议,这
次会议是由Scott Meyers和Bruce
Eckel共同组织的。在为期三天的会议中,有15位专家聚集在一起,讨论代码质量的问题以
及他们是如何改善代码质量的。整个会议贯穿着一个明确的主题:优质的代码来源于优秀
的程序员。因此,在企业内提高代码质量的一个重要的途径,就是雇用更好的程序员。问
题是,在一大群求职
者中找出优秀的程序员却并非一件易事。
找到优秀的程序员不容易,这是因为良好的程序设计不仅仅依赖于编程语言的语法知识。
你需要深谙面向对象设计思想的人,却不去在乎他穿着条纹短裤和圆点花布衬衣;你需要
具有足够的创造性、能够找到解决问题的革新方法的人,却不去在乎他的屁股后面总是拖
拉着卷曲的背带;你需
要足够谦虚、能够坦然接受改进意见,但又足够自信,能够坚定立场并在其成为最佳人选
的时候能够担负领导责任的人。如何仅凭与一个陌生人在会议室中相处的短短30分钟就可
以判别这些问题呢?
会议的最后一个早晨,Bruce Eckel宣称他“控制”了会议。Bruce Eckel希望在场的每个
人共享他们的面试技巧。他想要知道我们如何在面试中识别一个优秀的程序员。在本文中
,我将重点谈一些那个早晨所讨论的面试技巧。如果你有更多的想法或是愿意就这些技巧
进行讨论,请到News
& Ideas Forum Topic(http://www.artima.com/wbc/interprogP.html)来发表见解。
发掘专业技能的领域
虽然那天早晨谈到了各种各样的面试方法,但在讨论中只形成了一些基本的技巧。例如,
与其简单地考察候选者在他将从事工作的某个特定领域中的专业技能和经验,不如更注重
综合的编程才能和技巧。判断候选人才能的一个方法是发掘其专业技能的领域。
Dave
Thomas:雇用那些有才能的人。一些公司犯的一个最大错误是雇用人员时象列购物清单:
“我需要具有6年Java经验、3年Oracle经验以及2年EJB经验的程序员。”世界不断在变化
,因此你需要雇用那些能够跟上这些变化的人员。寻找那些理解计算技术方法的人,而无
需在意一些细枝末节。
这样的人不但可以更好地适应未来的变化,而且在目前来讲也可能更具创新性。
Chris
Sells:可以从技术上来判别候选者是否优秀,我让他们选择一个自认为具有技术专长的领
域。我需要他们熟知其中的知识,我会向他们提出有关的问题。我还会问他们为什么。我
希望能够了解在他们所专长领域中的技术为什么会是这样的,但我不必寻找我所需要的领
域中的专家。如果他
们在过去能够理解为什么,那我相信他们在未来同样也会这样。
让他们进行评论
另外一个技巧涉及到与候选者展开对话的重要性。要了解他们的才能和性格,你不能仅仅
提出一些缺乏实际意义的问题,而应该尽力去营造一种交谈的氛围。为了促进对话,你可
以让他们对某些技术进行评论。
Josh Block:我要候选者对我们都使用的某个系统或平台进行评论,最好是他们在工作中
将要用到的。例如,我可能会问:“你不喜欢Java的哪些部分,为什么?”
Pete McBreen:我给候选者一些我们当前所写的代码样例,让他们解释这些代码并加以评
论。这不仅可以帮助我了解他们的技能,还能使他们知道自己将会做些什么。
让他们解决一个问题
可以促进坦诚交谈的另外一个途径是让候选人完成一项任务:解决一个问题或进行一项设
计。尽管这个话题引起了大量的关注,甚至在场的每个人差不多都同意这是一种重要而且
有用的方法,但大家却普遍认为,要求候选人解决难题需要谨慎对待:
Josh
Block:我会要求候选人解决一个小规模的设计问题,看看他们如何思考、如何做。例如:
你怎样编写一个能够告诉我其参数是否是2的乘方的函数?我并不期望得到使用位操作的最
优方法((n&-n)==n),我只是想看他们是否能以正确的方法解决问题,他们是否考虑边
界值的情况,他们
的算法是否合理以及他们是否能对最初的方法进行改进。
Bruce Eckel:我让候选者创建一个关于小鸡的对象模型。这消除了问题域的不确定性问题
,因为每个人都知道小鸡是什么样子。我认为这也可以使人从计算机的技术细节中脱离出
来。这样可以测试他们是否有能力考虑一些较大的场景。
Scott Meyers:我不喜欢被要求当场进行某些设计。在一种压力很大的环境中要求他们展
示一些在工作中很少会用到的技能,对于候选者来说很难准确地证明他们的能力。我认为
这种要求对于候选者来说从根本上就是不公平的。
Matt
Gerrans:我不喜欢要求我在一张纸上写出一个实现某些功能的程序,所以,我也不要求候
选者在纸上编写程序,那是在浪费时间和精力。人们并不是在纸上编写软件,他们在计算
机上使用自动填充、宏、索引化的API文档以及上下文敏感的帮助等工具来编写软件。他们
对软件进行思考、重
构甚至是重写。如果你想要看一个人的作品,要求他们在面试之前编写一些小的模块或实
现一些接口并把代码存在笔记本电脑或其他硬拷贝上带来。然后,你可以审阅这些代码并
对其设计、编码风格以及其内部的一些处理进行讨论,这将使你能够对一个人的工作能力
和风格做出更实际、更
有用的评估。
Kevlin
Henney:我喜欢设计一些没有某个确定答案的谈话问题。这样的话,他们便不得不向我提
出问题,这样也就能引发一场讨论。在房间里最好能够有块白板。对话可以让考官了解被
面试者如何工作,而问题实际上只适合于电视测验节目,并不能告诉你某人将如何工作以
及在以后能完成什么事
情。一道难题需要的是了解一些诀窍,本质上不过是知道或是不知道。我不喜欢难题,因
为那不需要对话。
Josh Bloch:一个合理问题的提出在很大程度上依赖于候选者的经验和成熟。
Dave Thomas:我寻找那些具有好奇心的人,会提出问题,但不是难题。
考察他们的代码
Josh
Bloch提出了一种我们都比较认同的方法:要求候选者在面试时带一些代码资料。考察候选
者的代码并与他们谈论这些代码。虽然我们担心一些候选者可能没有能够合法地带来面试
的代码,但相信大多数人还是可以的。要求候选者在面试时带一个他们过去所写的代码样
例至少不会有什么负
面的影响。
Josh Bloch:我希望看他们的代码。你可以看到他们挑选了什么。你可以了解他们的价值
取向。你可以了解他们如何进行交流。
了解他们读什么书
一部分人指出,他们会向候选者提出关于他们所读的编程方面书籍的问题,这样可以看出
一个程序员是否具有能够自我激励或者是否关注提高自己的编程技能。
Matt Gerans:我会问候选者,“你读过哪些关于程序设计的图书?”,如果他们回答的书
是超越语法层次的,那就是重要的。
Randy Stafford:我要知道他们读了什么书,这是因为我很看重他们这种自觉意志下的自
我学习。
提出关于人的问题
与技术才能同样重要、甚至比它更重要的,这就是性格。候选者是否能够与团队融洽相处
?他们是否能适应工作环境?我们可以通过一些方法来判断性格:
Randy Stafford:良好的品格可能比技术才能更为重要,因为那些具备良好的态度和行为
方式的人,公司可以帮助他们获取技术知识并培养软件开发习惯。但对于那些缺乏谦虚和
成熟的人,不论他们如何聪明或是他们过去有什么成就,都很难与他们通力协作来实现目
标。
Chris Sells:我会问候选者,“和我谈谈你曾经与老板或是同事之间发生过的问题,请告
诉我你是如何处理这样的问题的。”
Jack Ganssle:我会核实推荐者,并询问候选者最好的5个朋友。虽然他们不会说任何有负
面影响的话,但我会向这些介绍人询问一些有关候选者的情况,并向这些人进行咨询以帮
助我做出判断。通过这种方式,我铺开了一张超越候选者所能设想的网。
Kevlin Henney:我试图设想能否在酒吧中与他们进行非技术性的谈话——如果我不喜欢他
们,我是否能够与他们打交道。他们易相处吗?我能够在非工作环境中与他们交谈吗?
Dawn McGee:最合适的人往往不是最优秀的人。
进一步了解他们
这次讨论会最显著的主题就是竭尽所能地去了解候选者:在面试过程中与他们交谈,尝试
形成对他们的认识。如果可能的话,让他们进行基本的测验或者进入试用期。这将给你更
多的时间进一步了解他们,也给他们更多的时间了解你。
Chuck
Allison:与他们交谈,对他们形成一些认识。我喜欢问他们曾做过什么。通过观察一个人
在技术上会对什么问题感到兴奋,你可以了解到很多重要的情况。过去,我曾经让求职者
描述一个他们非常感兴趣的项目、或非常有挑战性并获得成功的项目。有时我会问,在过
去的工作中最令他们
自豪的是什么。这些问题的回答通常可以反映一个人的理解力以及所掌握技术的深度。令
他们兴奋并开始滔滔不绝地讲述,你就可以静坐一旁、得到大多数所希望得到的答案。
Randy
Stafford:我会考察他们简历中所列出的以前的项目,并就这些开始讨论——开发团队是
如何组织的?使用什么技术和体系结构?软件是否成功投入使用等。在他们的回答过程中
,我还会罗列出他们从这些经历中学到了什么,这些经验是否与我从自己的经历中和专业
文献中所学到的一致。
我会对他们如何定位自己与周围环境之间的关系有一个初步的了解。有些人显出骄傲自大
,有的无知,有的没有什么能力,其他一些则谦虚、机智并具有推动力。我经常问面试者
读过什么软件开发的图书,这是因为我认为持续的学习是非常重要的。
Angelika Langer:在德国,雇用员工就像结婚一样,大多是“从一而终”,因为你不能解
雇员工。解雇员工的唯一机会是在3到6个月的试用期中间,或是公司破产。
主要的筛选是根据个人履历及其所呈递的文件,例如来自前一个雇主的评估(在德国,雇
主必须在雇员离开公司的时候为其提供一份书面的评估)等材料,主要在面试之前完成。
面试本身很简短。筛选的主要手段是仔细审查个人履历和文件材料;98%的申请者在这个
阶段会被取消资格。面
试应该进一步证实你从求职者的材料中所获取的印象并使你判断他们的性格。幸运的胜出
者随即将进入试用期。
试用期并不能取代筛选;它不过是在真正确认之前给你留的最后一条退路而已。
Andy Hunt:我们曾经雇用过在面试中表现出色,但在实际工作中很糟糕的人。如果可能的
话,应该有一个试用期。
Dawn McGee:你也可以让面试者在公司实习半天,让他们做一些实际工作中需要做的事情
,以此来判断他是否能适应这个职位。
结束语
综合这次会议的主题,这就是:你应该寻找那些有才能、可以胜任更多技术领域的人才。
对以上专家的考察方法,可以总结为如下几点:
l提一些开放性的问题以促进坦诚的对话;
l让候选者对技术进行评论;
l让他们动手设计一些东西;
l考察他们过去的经历;
l阅读他们的代码;
l通过交谈,最好再通过一个试用期;
l设法熟悉候选者的技术能力、才智以及性格。
你如何面试程序员?
你是否对本文中提到的面试技巧有一些看法?你是否具有用来发现优秀程序员的途径和技
巧?希望你能到News & Ideas Forum Topic(http://www.artima.com/wbc/interprogP.ht
ml)分享你的观点。
读者反馈:
就本文的内容,TheServerSide.com网站上展开了热烈的讨论,有兴趣的读者可以去看看(
http://www.theserverside.com/home/thread.jsp?thread_id=18040&article_count=41)
。这里仅摘译了部分内容。
Vic Cekvenich:一个重要的问题,“和我谈一些有关你开发过的、并投入使用的Web应用
。”如果他告诉你一些关于规模、操作方面的情况,那他就是一个实干家。一个危险的信
号是:“我可能会这样做……”,那表明他是一个新手,并没有实际的工作经验。
你希望他们说:“我是这样做的,……”,那表明他们具有实际的经验。但如果他们从未
将程序投入使用,那我认为或许他们以后也不会。更糟的是,他们代码中存在的试验性可
能会导致项目的失败。
至于另外的一个问题:“你读过什么书?”,我觉得可能会造成一些误导。我可以买一本
关于外科手术的书籍并阅读,但这并不能使我成为一名医生。因此,这个的问题提出可能
使你挑选一个滥竽充数者。
Suez zeus:To Vic,我不同意你关于将软件投入使用的观点。这是个相对的问题,如果我
是构架设计队伍中的一员,我的工作是创建一组供那些核心业务开发人员使用的framework
;或许我永远不会将其投入使用,而是核心业务开发人员来这样做,绝大多数时间其实并
没有我的参与。
Anthony Eden:Suze,即使你只是进行framework开发的架构组成员,如果你的软件在投入
使用,那你就会通过某种方式参与其中。即使你不是直接地参与,但至少在软件投入使用
的调试过程中你会被涉及到。除非你编写的软件没有任何错误,这在面试官看来,简直是
在说谎。
Eamonn J.Casey:我最近在 www.computerworld.no 上看过一篇文章。研究人员对130名职
业人员和60名学生进行调查,结果在计算机程序设计方面,如果进行一年的学习就相当于
在此领域内十年的经验。包括Accenture、Cap Gemini以及Software Innovation等公司都
参与了此项调查。
Eric Bengtson:我会向程序员提出一些关于OO的问题,例如:subtyping和subclassing之
间的区别,interface和abstraction之间的区别。此外还有一些关于他们将要使用的IDE的
问题。对于那些资历较深的开发人员,我会提出有关模式方面的问题。
TQ:为了找到合适的程序员,了解如下几个方面的情况是很重要的:
教育背景;逻辑分析能力;解析能力;设计、开发的过程以及代码质量方面的知识等。我
听说有人曾经在面试中提出关于framework API以及有关行业内领先的应用程序构架存在的
bug之类的问题。
我们需要雇用那些具有创造性观点、乐于学习并且可以在工作中承担责任的员工,这是我
们形成团队的需要。
Lawrie Cornell:我认为面试应该有6个重要的组成部分:
(1)第一印象;(2)仔细阅读履历;(3)有关OO、Java、设计模式以及数据库设计等方面的基
本问题或测试;(4)技术规范的问题或测试;(5)一般的逻辑方面的问题或测试;(6)代码样
例。
David Jones:我同意让候选者提供代码文件的方法。我最成功的一次面试就是展示一个完
整的J2EE项目案例。我将这个项目作为继续使用的原型。
Binil Thomas:可以参考http://www.dorsethouse.com/features/excerpts/expsych8.htm
l 上有关Weinbergs所著的The Psychology of Computer Programming一书的节选,思考其
中与这个讨论相关的内容。
注:(15位专家介绍)
n Chuck Allison:为美国著名的Utah Valley State College的计算机科学教授,同时也
为C/C++ Users Journal (C++ and Java)杂志的资深编辑。是C & C++ Code Capsules一书
的作者,并与Bruce Eckel合著了Thinking in C++, Volume 2。
n Josh Bloch:现为Sun Microsystem公司Core Java Platform 小组的架构师,为Java
APIs和Java语言的发展做出了很大的贡献。著有Effective Java Programming Language
Guide一书。
n Alistair Cockburn :是Humans and Technology以及Cockburn and Associates两家咨
询公司的创始人。他本人以其在面向对象方面的功迹而闻名于业界。
n Bruce Eckel:Thinking in Java一书的作者。
n Jack Ganssle:他的工作主要是帮助开发者构建更好、更快的嵌入式系统。是多个嵌入
式期刊的专栏作家和编辑,曾著书两本:The Art of Designing Embedded Systems 和
The Art of Programming Embedded Systems。
n Matt Gerrans :有超过12年的软件开发经历,为资深的软件工程师。现为Artima.com
网站的C# 专栏作家。
n Kevlin Henney:业内资深顾问和培训专家,尤其在QA方面,设计了一系列的培训教程和
资料,帮助许多公司进行质量控制。
n Andy Hunt:著有闻名于全球的畅销图书The Pragmatic Programmer。
n Angelika Langer:Standard C++ IOStreams and Locales一书的作者。
n Dawn McGee:知名的商业顾问专家。
n Scott Meyers:世界上最著名的C++专家之一。著有多部图书:Effective C++、More
Effective C++、Effective STL等。
n Pete McBreen:Software Craftsmanship and Questioning Extreme Programming一书
的作者。
n Chris Sells:专业顾问、作者、演讲家以及非常用功的技术人士,专注于Windows环境
下的基于组件技术和分布式系统。
n Randy Stafford:IQNavigator.Inc的高级软件开发专家、首席技术架构师。
n Dave Thomas:与Andy Hunt一起,因为Pragmatic Programmers一书和相关技术而齐名于
业界。
关于作者:Bill Venners担任Artima Software。Inc的总裁以及Artima.com的主编。他是I
nside the Java Virtual Machine (Computing McGraw-Hill)一书的作者,在JavaWorld
杂志开辟了一些很受欢迎的专栏,包括:Java internals、object-oriented
design以及Jini等。Bill从Jini Commmunity(http://www.jini.org/)成立之初便一直活
跃其中。他领导了Jini Commmunity的ServiceUI(http://www.artima.com/jini/serviceu
i/index.html)项目,现在的ServiceUI API已成为了连接用户接口和Jini服务的事实标准
。
--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.228.146]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:205.258毫秒