研发人员面试技巧.docx
《研发人员面试技巧.docx》由会员分享，可在线阅读，更多相关《研发人员面试技巧.docx（15页珍藏版）》请在冰点文库上搜索。
研发人员面试技巧
研发人员面试技巧
【篇一：
hr招聘开发人员的面试技巧】
hr招聘开发人员的面试技巧
hr面试开发人员的有效方法
当要雇佣开发者时，传统的面试方法显得力不从心，这是必须要面对的现实。
你会读简历、电话面试、技术面试、文化适应面试、各方面测试，最后，你基本上跟着自己的感觉走，雇佣了你认为优秀的人，即使这样，也会经常看走眼。
情况不太理想，这是因为开发者属于技术性工人，谈话反应不出他或她对所在领域有多精通。
为什么传统面试方法不行呢?
当你要求别人跟你一起面试时，你会给他们多少准备时间呢?
很可能没多少（如果你会给多于5分钟的时间，说明你准备的比较充分），所以和你一起面试的考官只是在前往面试地点的路上匆忙浏览一下简历，所以我也不会继续讨论提前准备一些问题这个话题。
提前准备到这种程度，你又怎么可能了解到简历之外的信息呢?
即使大家准备了一段时间，他们培训过多少关于面试技巧的知识呢?
和其他一样，面试也是一名技术，即便有丰富的阅历，也不一定能成一名面试官。
人们提问题时问不到点子上，即使能够提出比较好的问题，他们也不知道该从回答里得到哪些信息。
所以，缺少培训以及准备不足是个问题，但你可以克服这些困难，但这有助于改善状况吗?
收效甚微，那么在面试过程中你应该测试求职者的哪些能力呢?
下面列出了一些：
学习能力
人际交往/团队工作能力（可以在面试过程之外测试）
能够在现实与设计之间折中
工作到最后一刻
在公司需要的技术方面有足够的经验
对其他技术也有所涉猎
等等
所有你能做的就是提问，然后相信求职者所回答的。
面试过程中，不要提这
样的说法：
很多优秀的人在某个职位上都没做好。
你要放弃他们吗?
如果你能面试到一个你信任的人推荐的面试者，你应该感到很幸运，但是，如果遇不到，怎么办呢?
很幸运，可以很简单地去甄别，让求职者展示一下他们的技术，让他们写点代码看看。
不!
不是在白板上写代码
在白板或纸上写代码，即使是在笔记本电脑上进行5分钟的测试，这些都不是真正的编码。
你需要把这些技术人员放到他们所处的位置上，然后后退，观察他们。
观察他们如何工作、如何跟别人交流，以及别人如何跟他们交流。
sethgodin提出，我们需要跟我们的潜在雇员共事几个月，这听起来不错，但有点不切实际，而且也不需要观察那么长时间。
让我说，一天时间就能让你得到足够的信息，然后做出正确决定。
如果你心里有中意的求职者，把他们安排到你的团队里工作一天，观察他们是否合适，而不是再对他们进行一轮又一轮的面试。
这一天的工作结束之后，把你的团队成员召集起来，然后让他们告诉你是否应该雇佣这个人。
（编注：
如果觉得这样的代价很大，可以尝试《通过电子邮件发现优秀的程序员》。
）
这种方法的优势很明显。
你不需要假设他们适应你的企业文化（或者做多选择心里分析），你只须测试一下。
如果你信任的人乐意跟这个人一起工作，那么你直接就能发现，毕竟，这也是他们必须要做的事。
你可以大体了解一下你的求职者技术的深度和广度。
你可以测试出他们驾驭新系统的能力，以及对事情的领悟能力。
所有你所做的这些都在一个远不如面试正式的气氛中进行，而且在这种气氛中，开发者可以感到很舒服。
如果面试官们让那些候选雇员提前准备一下，效果会更明显。
用创新来吸引有创意的人
很显然，在最终雇佣一个人之前，我们不能要求他一整天都在工作或者面试。
但是，我们真的不能吗?
为什么不可以呢?
难道在你的公司不是一个有足够吸引力的地方吗?
如果不是，那么尽快改进，然后执行雇用程序。
如果要求别人放弃很多休息时间而带来的诸多不便让你感到很不安，那么想想当你意识到你已经雇用一个蹩脚的雇员6个月之后，已经太晚了，这会给你带来更多的不便。
创意无限你才能吸引那些喜欢充满创造力的氛围的人才，人们才会乐意花一整天的时间，
因为他们可以经历一次有趣又与众不同的面试。
你的公司应该成为这种公司：
可以吸引到那些你想雇佣的人才。
你的面试过程以及雇佣方式是第一步，要不要采取那种有效的方式完全取决于你。
【篇二：
软件开发人员面试问题（经典）】
软件开发人员面试问题（经典）想雇到搞软件开发的聪明人可不容易。
万一一不小心，就会搞到一堆低能大狒狒。
我去年就碰到这种事了。
你肯定不想这样吧。
听我的，没错。
在树上开站立会议门都没有。
问点有难度的问题能帮你把聪明人跟狒狒们分开。
我决定把我自己整理出来的软件开发者面试百问发出来，希望能帮到你们的忙。
这个列表涵盖了软件工程知识体系中定义的大多数知识域。
当然，如果你只想找出类拔萃的程序员，便只需涉及结构、算法、数据结构、测试这几个话题。
如果想雇架构师，也可以只考虑需求、功能设计、技术设计这些地方。
不过不管你怎么做，都要牢记一点：
这里大多数问题的答案都没有对错之分！
你可以把我的这些问题作为引子，展开讨论。
例如下面有个问题是使用静态方法或是单例的缘由。
如果那个面试的就此展开长篇大论，那他很有可能是个聪明能干的家伙！
如果他一脸茫然的看着你，发出这种声音，很明显这就是只狒狒了。
同样，想知道一个数是不是2的乘方也有很多方法，不过要是面试的人想用mod运算符，嗯……你知道我的意思吧。
（你不知道也没关系，来根香蕉？
）
需求
你能给出一些非功能性（或者质量）需求的例子么？
如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？
你能给出一些用来描述需求的不同技术么？
它们各自适用于什么场景？
需求跟踪是什么意思？
什么是向前追溯，什么是向后追溯？
你喜欢用什么工具跟踪需求？
你怎么看待需求变化？
它是好是坏？
给出你的理由。
你怎样研究需求，发现需求？
有哪些资源可以用到？
你怎么给需求制定优先级？
有哪些技术？
在需求过程中，用户、客户、开发人员各自的职责是什么？
你怎么对待不完整或是令人费解的需求？
功能设计
在功能设计中有哪些隐喻？
给出几个成功的例子。
如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？
如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？
有哪些方法可以保证数据项的完整？
建立系统原型有哪些技术？
应用程序怎样建立对用户行为的预期？
给出一些例子。
如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？
有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？
如果是1000个元素，每个元素有3个字段呢？
用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？
web环境和环境各有些什么限制？
技术设计
什么是低耦合和高聚合？
封装原则又是什么意思？
在web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？
你知道设计模式吗？
你用过哪些设计模式？
在什么场合下用的？
是否了解什么是无状态的业务层？
长事务如何与之相适应？
在搭建一个架构，或是技术设计时，你用过几种图？
在n层架构中都有哪些层？
它们各自的职责是什么？
有哪些方法可以确保架构中数据的正确和健壮？
面向对象设计和面向组件设计有哪些不同之处？
怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？
怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？
程序设计
你怎样保证你的代码可以处理各种错误事件？
解释一下什么是测试驱动开发，举出极限编程中的一些原则。
看别人代码的时候，你最关心什么地方？
什么时候使用抽象类，什么时候使用接口？
除了ide以外，你还喜欢哪些必不可少的工具？
你怎么保证代码执行速度快，而又不出问题？
什么时候使用带有静态成员的类，什么时候使用单例？
你在代码里面怎么提前处理需求的变化？
给一些例子。
描述一下实现一段代码的过程，从需求到最终交付。
算法
怎样知道一个数字是不是2的乘方？
怎样判断一个数是不是奇数？
怎样找出链表中间的元素？
怎样改变10,000个静态html页面中所有电话号码的格式？
举出一个你所用过的递归的例子。
在散列表和排序后的列表中找一个元素，哪个查找速度最快？
不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？
怎样把字符串反转？
你能不用临时的字符串么？
你愿意用什么类型的语言来编写复杂的算法？
有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？
你知道“旅行商问题（travelingsalesmanproblem）”么？
数据结构
怎样在内存中实现伦敦地铁的结构？
怎样以最有效的方式在数据库中存储颜色值？
队列和堆栈区别是什么？
用堆或者栈存储数据的区别是什么？
怎样在数据库中存储n维向量？
你倾向于用哪种类型的语言编写复杂的数据结构？
21的二进制值是什么？
十六制值呢？
不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？
怎样在xml文档中存储足球比赛结果（包括队伍和比分）？
有哪些文本格式可以保存unicode字符？
测试
什么是回归测试？
怎样知道新引入的变化没有给现有的功能造成破坏？
如果业务层和数据层之间有依赖关系，你该怎么写单元测试？
你用哪些工具测试代码质量？
在产品部署之后，你最常碰到的是什么类型的问题？
什么是代码覆盖率？
有多少种代码覆盖率？
功能测试和探索性测试的区别是什么？
你怎么对网站进行测试？
测试套件、测试用例、测试计划，这三者之间的区别是什么？
你怎么组织测试？
要对电子商务网站做冒烟测试，你会做哪些类型的测试？
客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
你去年在测试和质量保证方面学到了哪些东西？
维护
你用哪些工具在维护阶段对产品进行监控？
要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？
如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？
你怎样保证代码中的变化不会影响产品的其他部分？
你怎样为产品编写技术文档？
你用过哪些方式保证软件产品容易维护？
怎样在产品运行的环境中进行系统调试？
什么是负载均衡？
负载均衡的方式有哪些种？
为什么在应用程序的生命周期中，软件维护费用所占的份额最高？
再造工程（re-engineering）和逆向工程（reverseengineering）的区别是什么？
配置管理
你知道配置管理中基线的含义么？
怎样把项目中某个重要的时刻冻结？
你一般会把哪些东西纳入版本控制？
怎样可以保证团队中每个人都知道谁改变了哪些东西？
tag和branch的区别是什么？
在什么情况下该使用tag，什么时候用branch？
怎样管理技术文档——如产品架构文档——的变化？
你用什么侗剧管理项目中所有数字信息的状态？
你最喜欢哪种工具？
如果客户想要对一款已经发布的产品做出变动，你怎么处理？
版本管理和发布管理有什么差异？
对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？
同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？
项目管理
范围、时间、成本，这三项中哪些是可以由客户控制的？
谁该对项目中所要付出的一切做出估算？
谁有权设置最后期限？
减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？
你喜欢用哪种图来跟踪项目进度？
迭代和增量的区别在哪里？
试着解释一下风险管理中用到的实践。
风险该如何管理？
你喜欢任务分解还是滚动式计划？
你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？
dsdm、prince2、scrum，这三者之间有哪些区别？
如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？
【篇三：
软件开发人员面试问题汇总】
1.你们的项目组使用源代码管理工具了么？
应该用。
vss、cvs、pvcs、clearcase、ccc/harvest、firefly都可以。
我的选择是vss。
2.你们的项目组使用缺陷管理系统了么？
应该用。
clearquest太复杂，我的推荐是bugzilla。
3.你们的测试组还在用word写测试用例么？
不要用word写测试用例（testcase）。
应该用一个专门的系统，可以是testmanager，也可以是自己开发一个的小网站。
主要目的是track和browse。
4.你们的项目组有没有建立一个门户网站？
要有一个门户网站，用来放contactinfo、baselinedschedule、news等等。
推荐sharepointportalserver2003来实现，15分钟就搞定。
买不起sps2003可以用wss（windowssharepointservice）。
5.你们的项目组用了你能买到最好的工具么？
应该用尽量好的工具来工作。
比如，应该用而不是notepad来写c#。
用notepad写程序多半只是一种炫耀。
但也要考虑到经费，所以说是“你能买到最好的”。
6.你们的程序员工作在安静的环境里么？
需要安静环境。
这点极端重要，而且要保证每个人的空间大于一定面积。
7.你们的员工每个人都有一部电话么？
需要每人一部电话。
而且电话最好是带留言功能的。
当然，上这么一套带留言电话系统开销不小。
不过至少每人一部电话要有，千万别搞得经常有人站起来喊：
“某某某电话”。
《人件》里面就强烈谴责这种做法。
8.你们每个人都知道出了问题应该找谁么？
应该知道。
任何一个feature至少都应该有一个owner，当然，owner可以继续dispatch给其他人。
9.你遇到过有人说“我以为…”么？
要消灭“我以为”。
neverassumeanything。
10.你们的项目组中所有的人都坐在一起么？
需要。
我反对virtualteam，也反对dev在美国、test在中国这种开发方式。
能坐在一起就最好坐在一起，好处多得不得了。
11.你们的进度表是否反映最新开发进展情况？
应该反映。
但是，应该用baseline的方法来管理进度表：
维护一份稳定的schedule，再维护一份最新更改。
baseline的方法也应该用于其它的spec。
baseline是变更管理里面的一个重要手段。
12.你们的工作量是先由每个人自己估算的么？
应该让每个人自己估算。
要从下而上估算工作量，而不是从上往下分派。
除非有其他原因，比如政治任务工期固定等。
13.你们的开发人员从项目一开始就加班么？
不要这样。
不要一开始就搞疲劳战。
从项目一开始就加班，只能说明项目进度不合理。
当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
14.你们的项目计划中buffertime是加在每个小任务后面的么？
不要。
buffertime加在每个小任务后面，很容易轻易的就被消耗掉。
buffertime要整段的加在一个milestone或者checkpoint前面。
15.值得再多花一些时间，从95%做到100%好值得，非常值得。
尤其当项目后期人困马乏的时候，要坚持。
这会给产品带来质的区别。
16.登记新缺陷时，是否写清了重现步骤？
要。
这属于dev和test之间的沟通手段。
面对面沟通需要，详细填写reprosteps也需要。
17.写新代码前会把已知缺陷解决么？
要。
每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
18.你们对缺陷的轻重缓急有事先的约定么？
必须有定义。
severity要分1、2、3，约定好：
蓝屏和datalost算sev1，functionerror算sev2，界面上的算sev3。
但这种约定可以根据产品质量现状适当进行调整。
19.你们对意见不一的缺陷有三国会议么？
必须要有。
要有一个明确的决策过程。
这类似于ccb（changecontrolboard）的概念。
20.所有的缺陷都是由登记的人最后关闭的么？
bug应该由opener关闭。
dev不能私自关闭bug。
21.你们的程序员厌恶修改老的代码么？
厌恶是正常的。
解决方法是组织codereview，单独留出时间来。
xp也是一个方法。
22.你们项目组有teammoraleactivity么？
每个月都要搞一次，吃饭、唱歌、outing、打球、开卡丁车等等，一定要有。
不要剩这些钱。
23.你们项目组有自己的logo么？
要有自己的logo。
至少应该有自己的codename。
24.你们的员工有印有公司logo的t-shirt么？
要有。
能增强归属感。
当然，t-shirt要做的好看一些，最好用80支的棉来做。
别没穿几次就破破烂烂的。
25.总经理至少每月参加次项目组会议要的。
要让teammember觉得高层关注这个项目。
26.你们是给每个dev开一个分支么？
反对。
branch的管理以及merge的工作量太大，而且容易出错。
27.有人长期不check-in代码么？
不可以。
对大部分项目来说，最多两三天就应该check-in。
28.在check-in代码时都填写注释了么？
要写的，至少一两句话，比如“解决了bugno.225”。
如果往高处拔，这也算做“配置审计”的一部分。
29.有没有设定每天check-in的最后期限？
要的，要明确check-indeadline。
否则会buildbreak。
30.你们能把所有源码一下子编译成安装文件吗？
要的。
这是每日编译（dailybuild）的基础。
而且必须要能够做成自动的。
31.你们的项目组做每日编译么？
当然要做。
有三样东西是软件项目/产品开发必备的：
1.bugmanagement;2.sourcecontrol;3.dailybuild。
32.你们公司有没有积累一个项目风险列表？
要。
riskinventory。
否则，下个项目开始的时候，又只能拍脑袋分析risk了。
33.设计越简单越好越简单越好。
设计时候多一句话，将来可能就带来无穷无尽的烦恼。
应该从一开始就勇敢的砍。
这叫scopemanagement。
34.尽量利用现有的产品、技术、代码千万别什么东西都自己coding。
biztalk和sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。
或者可以尽量多用现成的control之类的。
或者尽量用xml，而不是自己去parse一个文本文件；尽量用regexp，而不是自己从头操作字符串，等等等等。
这就是“软件复用”的体现。
35.你们会隔一段时间就停下来夯实代码么？
要。
最好一个月左右一次。
传言去年年初windows组在stevb的命令下停过一个月增强安全。
btw，“夯”这个字念“hang”，第一声。
36.你们的项目组每个人都写dailyreport么？
要写。
五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。
一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。
37.你们的项目经理会发出weeklyreport么？
要。
也是为了沟通。
内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
38.你们项目组是否至少每周全体开会一次？
要。
一定要开会。
程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。
包括teammeeting,specreviewmeeting,bugtriagemeeting。
千万别大家闷头写code。
39.你们项目组的会议、讨论都有记录么？
会前发meetingrequest和agenda，会中有人负责主持和记录，会后有人负责发meetingminutes，这都是effectivemeeting的要点。
而且，每个会议都要形成agreements和actionitems。
40.其他部门知道你们项目组在干什么么？
要发一些newsflash给整个大组织。
showyourteam’svalue。
否则，当你坐在电梯里面，其他部门的人问：
“你们在干嘛”，你回答“abc项目”的时候，别人全然不知，那种感觉不太好。
41.通过email进行所有正式沟通
email的好处是免得抵赖。
但也要避免矫枉过正，最好的方法是先用电话和当面说，然后email来确认。
42.为项目组建立多个mailinggroup
如果在ad+exchange里面，就建distributionlist。
比如，我会建abcprojectcoreteam，abcprojectdevteam，abcprojectalltesters，abcprojectextendedteam等等。
这样发起email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。
43.每个人都知道哪里可以找到全部的文档么？
应该每个人都知道。
这叫做知识管理（knowledgemanagement）。
最方便的就是把文档放在一个集中的fileshare，更好的方法是用sharepoint。
44.你做决定、做变化时，告诉大家原因了么？
要告诉大家原因。
empowerteammember的手段之一是提供足够的information，这是msf一开篇的几个原则之一。
的确如此，tellmewhy是人之常情，tellmewhy了才能有understanding。
中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。
大错特错。
权威、权力，不在于是不是能accessinformation/data，而在于是不是掌握资源。
45.stayagileanｄexpectchange要这样。
需求一定会变的，已经写好的代码一定会被要求修改的。
做好心理准备，对change不要抗拒，而是expectchange。
46.你们有没有专职的软件测试人员？
要有专职测试。
如果人手不够，可以peertest，交换了测试。
千万别自己测试自己的。
47.你们的测试有一份总的计划来规定做什么和怎么做么？
这就是testplan。
要不要做性能测试？
要不要做usability测试？
什么时候开始测试性能？
测试通过的标准是什么？
用什么手段，自动的还是手动的？
这些问题需要用testplan来回答。
48.你是先写testcase然后再测试的么？
应该如此。
应该先设计再编程、先testcase再测试。
当然，事情是灵活的。
我有时候在做第一遍测试的同时补上testcase。
至于先testcase再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
49.你是否会为各种输入组合创建测试用例？
不要，不要搞边界条件组合。
当心组合爆炸。
有很多testcase工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多testcase。
50.你们的程序员能看到测试用例么？
要。
让dev看到testcase吧。
我们都是为了同一个目的走到一起来的：
提高质量。
51.你们是否随便抓一些人来做易用性测试？
要这么做。
自己看自己写的程序界面，怎么看都是顺眼的。
这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。
52.你对自动测试的期望正确么？
升级会员 