程序员实施工程师面试题

1. 程序员面试，为什么感觉很多都和运维有关

不会运维的程序员不是好程序员。 这个信条要时刻谨记，不管是面试还是自己平时在工作中都要坚持这个准则，因为这对你以后的发展大有裨益。

观念问题

一直以来，很多圈外人对我们程序员的观念就是永远的一本正经，着装单一，了无生趣，聪明绝顶，其实这是他们对程序员的误解，因为多才多艺，多姿多彩的程序员比比皆是，但是传统的观念或者说以偏概全的观念蒙蔽了他们的双眼，而他们自己又没有尝试去了解，所以导致人云亦云，给程序员披上了一层灰。

同样的，我们大部分程序员的观念也跟他们差不多，认为程序员就只是搬砖撸码的，至于各种部署服务器相关的工作应该是运维做的，其实非也，如果真的这样认为的话，那就真的太不把自己当程序员了。为什么这么说呢？因为我们程序员是实实在在撸码开发产品的群体，可是如果我们开发出来的东西只能自个在本地玩耍，却不能众乐乐，那还有什么意义，此时，你可能会说，交给运维啊，那么如果没有运维呢，就没法玩了，所以我们不能总是将希望寄托在别人身上，当自己有能力能够将系统进行部署的时候，那就该学会部署。

其实不仅仅是程序员，优秀的运维工程师也是需要会开发撸码的，因为有时候他们也需要开发一些小工具来进行验证，或者开发网页来进行服务的管理，所以说程序员和运维都是相辅相成的。

公司问题

像我们现在很多的公司都没有明确的人员分工，特别是小公司连运维都没有，所以就谈不上让运维去部署了，那么怎么办呢？肯定就是开发人员自己去部署了，如果不会部署的话就可以去网上查找资料，其实总体来说不会很难，因为我看过很多运维其实也是在网上找资料按步聚进行操作。

另外公司之所以这么要求，一方面是基于人员成本的考虑，毕竟如果一个人能干好的事为啥非得招两个人；另一方面可能基于公司的发展问题，像一般的小公司确实没必要专门招一个运维，不过随着公司的发展，后期肯定会招专业运维，毕竟专人做专事，事半功倍。

总结

永远记住“不会运维的程序员不是好程序员”，其实作为程序员不能总是把自己陷在撸码的深渊，除了撸码，我们还要学会产品需求分析、简单的UI画图、数据库分表分库及性能优化、运维服务器部署、单元及系统测试等等，总的来说，要想成为优秀的程序员，我们有必要把产品线上的每一个环节都略知一二，这是经验收获，一定会成为我们日后发展的资本。

技术迭代是需要时间的，而且公司预算不多的话，会选择现有系统继续使用。有的企业也会选择维稳，不会轻易开发新系统代替现有系统。

这是一个非常好的问题，作为一名IT从业者，我来回答一下。

首先，在当前的大数据、云计算时代，程序员在面试的过程中，经常会遇到与运维相关的问题，尤其是有自身产品（平台类）的企业，往往对于程序员的运维类知识有比较多的要求，所以当前的程序员，尤其是Java程序员，要想获得较强的岗位竞争力，一定要重视运维类知识的学习。

在当前的大数据时代背景下，很多程序员在日常开发过程中，需要与运维人员进行配合，所以程序员在面试过程中，经常会被问及与运维相关的问题，通过这样的问题，也能够全面了解程序员是否面对过大用户的并发问题，这对于判断程序员是否适合当前的招聘岗位也有一定的参考价值。

以大数据开发岗位为例，程序员在进行大数据任务开发的过程中，不可避免地需要与运维人员打交道，其中大数据平台的搭建就是比较繁琐的过程，另外还有一系列产品的安装和部署，这些通常都需要运维人员来完成。对于一款平台类产品来说，运维人员的技术能力能够在很大程度上决定软件平台的性能，而且运维人员与开发人员的配合也非常关键。

当然，对于程序员来说，如果能够自己掌握一定的运维知识，对于开发任务的开展还是很有帮助的，如果什么问题都需要运维人员来完成，不仅需要更多的运维人员，同时也会影响项目的整体开发进度。从这个角度来看，随着未来大数据技术的逐渐落地，程序员掌握一定的运维类知识，对于提升自身的工作效率，还是很有帮助的。

在程序员面试过程当中，通过一些运维知识也能够更加直观地了解到程序员的技术栈，相对于比较复杂的开发问题来说，运维知识的脉络还是比较清晰的，通过运维知识能够在一定程度上挤出一些“技术水分”，这也是很多面试官比较愿意问运维问题的主要原因。另外，对于一些创业型公司来说，程序员掌握一定的运维类知识，也会节省一些投入，尤其在产品研发的初期。

从技术体系结构来看，要想解决大用户的并发问题和系统扩展性问题，通常需要从两个角度出发，一个角度是技术选型，比如采用扩展性比较强的大数据平台，另一个角度就是硬件扩充，但是硬件扩充的前提是要有一个可扩充的平台体系，而通过运维知识，程序员的交流会更明确，技术方案也比较直观。

从岗位任务划分的角度来看，程序员的工作任务与运维人员的工作任务有比较明确的边界，但是在云计算技术的推动下，程序员接触运维场景的情况也在不断增加，比如通过云计算平台的支撑，很多传统的运维类任务，程序员也会比较方便地完成，比如安全配置等等。

最后，程序员在进行面试的过程中，如果遇到的运维类问题并不清楚，一定要如实回答，因为运维类知识需要一个积累的过程，而且经验往往非常重要，所以很多运维类知识，在短期内是无法掌握的，如果盲目扩展自己的知识面，会为后续的工作带来很多麻烦。

如果有互联网、大数据、人工智能等方面的问题，或者是考研方面的问题，都可以在评论区留言，或者私信我！

一、提问之前的准备

首先，最重要的是，你自己一开始就应该想清楚：

只有明确这些根本性的问题，才能正确高效地完成面试。

二、提问的原则

假定你对上一节的三个问题，已经有了清晰的想法，那么接下来就可以设计如何提问了。

有一些提问的原则，是你应该遵循的：

三、考察专业能力

为了确认面试者是胜任的，你可以问一些与职位相关的专业方面的问题。（不过通常来说，一次面试不足以看出一个人的专业能力。）

比如，你的招聘职位是系统管理员，你可以问"如何快速地在50台机器上部署Linux？"（提示：正确答案不是刻录50张安装光盘。）

另外，你还应该向面试者了解他的过去，因为过去是未来的最好预测依据。不过，提问的重点不要仅仅是他过去的成果，更要关注在当时的环境中，他是如何决策和实施的。

四、考察综合素质

因为人是会发展的，所以某种程度上，面试者的综合素质要比他的专业能力更重要。

所以，具体的技术问题（如何调用API、什么是设计模式、编程语言的语法等等）可以少问一些，更应该关注面试者的事业心、对工作的热情、进取心、自律能力、毅力等方面。

下面是一些典型问题：

五、考察理性思维

某些情况下，你可能需要了解面试者的分析判断能力，看他能否全面地思考问题、客观地评价自己。

那么，你可以依次提出这样三个问题：

这里的重点是，让面试者从正反两方面评价一件自己熟悉的东西，看看他的思维是否片面。答案无所谓对错，只要面试者有一个明确的立场，能够从正反两方面说出令人信服的理由，就可以了。比如，某个软件的口碑不好，但是面试者说他很喜欢，而且说得出一大堆理由，清楚地解释了这种软件的优点和缺点在哪里，这样就很好。

不邀自来。众所周知，越大型的公司，分工越明确。在BAT里面，有专门的前端，后端，ops，dba等等。他们专研一方面，所以有深度，有沉淀。遇到问题了，找到相应的人，能够快速解决问题。

但绝大多数中小公司，更偏爱样样都会的全栈，恨不得你一个人把所有活儿做完。并不一定需要有多大深度，能干活儿就行了。

再说，现在提倡devops，开发懂点运维，能够更好地定位问题，部署和架构项目，这是需求，也是趋势。

对小公司而言基本没有专门的运维，所以需要研发具备一些运维的知识，比如数据库的搭建、nginx、jdk部署，其它开源中间件，比如Kafka、es等等

其实这个目前真正大规模用的少，炒概念的多，很多公司根本没机会用. 但是他会问

我觉得很自然的事，为什么总有人说得高大上？装个软件，调个参数，做个逻辑卷，调一调网络，配置一下分布式组件，搞个文件系统程序员就应该不会？

这些工作，我们公司一般运维人员搞不定的。所以用啥，自己整。

个人观点，计算机知识就必须全面，才能做好一个程序员吧？

而且看大家回复，我有8成猜对，有8成以上的架构师，不懂底层，知识面也没传说中那么广。

现在devops在流行，说白了企业为了省成本，研发要干一部分运维的活。运维只负责硬件网络和k8s维护，其他什么部署啦，服务编排啦，通通交给程序员做。

不过这样倒也合理，运维只负责全公司通用的设施建设，至于cicd，服务编排，熔断限流等等，都和业务强相关，交给开发做比较贴近实际业务

2. 应聘用友的erp软件维护工程师，面试会问些什么

首先给你分析一下，他们的职位要求的原因：
1、需要入职者经过一个好的理论环境熏陶过，或者说对一些专业知识、词语不是很陌生，即方便与ERP的理论结合！
2、ERP软件维护工程师服务的对象就是客户，也就是一些生产和物流行业的企业。这点就是要求入职者对一些行业熟悉，即方便与生产和供应链的实际流程结合！
3、ERP实施无非就是推项目及解决异常，即方便与理论和实际的结合！
你的条件：
1、本科毕业，计算机和会计专业，其中应该涉及很多ERP相关知识，特别是会计，至于计算机网络你只需要知道基本就可以了，因为用友针对软件使用过程中由于计算机及网络出现的异常都有FAQ！
2、沟通协调能力你目前仅仅限于理论，不过这个也是你的优势！
3、CRM客户关系管理，也可以理解为ERP的一个模块，不过你也仅仅限于使用！
总结：
1、这个职位基本不需要编程，但是你需要懂一些编程的知识，因为你是客户（使用者）和程序员之间的关键点，你需要将两者的语言互译，你可以去网上了解一些简单的编程知识！
2、多去网上找一些ERP项目推行的计划书，因为你这个职位主要是做这些，可以去用友官网去找！
3、多去网上找一些ERP的FAQ（异常处理方法）主要针对用友！

3. 工程师与程序员

简单来说程序员负责软件产品的设计开发工作，实施工程师负责软件产品的安装与运维工作。

4. IT面试经验：程序员面试什么最重要

程序员面试一直是社区乐于讨论的热门话题。我自己从06年实习以来，先后经历了4家软件公司，全部是外企，其中有世界500强的通信企业，有从事期权期货交易的欧洲中等规模的金融公司，也有为大型汽车制造商开发Android智能汽车的新兴公司。跨入IT行业以来，我在求职过程中经历过多次面试，最近两年也有过多次面试别人的经验。我感觉现在到了对这个问题发表自己看法的时候，这篇文章是我站在面试官角度对于程序员面试问题的一个阶段性反思和经验总结。
目标
相信和不少朋友一样，有了几年工作经验成为Senior后就开始了面试别人的经历。我在最初这个阶段只是按照自己的想象把”找到基础好的程序员“，”找到算法能力优秀的程序员“，”找到有Android开发经验的程序员“等作为面试的目标。但是，实际的经历告诉我，尤其是按“基础好”，“算法好”这些目标招到的人最终效果并不好。比如，有的面试者基础知识和算法掌握情况不错，进程、线程、内存等概念清晰，基本的Hash，二叉树，快速排序等数据结构和算法也比较熟悉，但是进公司后在实际工作中表现得很糟糕。后来，我才发现原来是我的面试目标出了问题，我原先的面试方法更像是大学的算法或操作系统期末考试，按照这种方法让许多并不合适的人通过了面试，同时也可能错过了许多合适的人。
后来，我的反思是，从公司的角度讲，面试的根本目的是找到“能够干好工作”的人，而“高学历”，“算法好”，“基础好”，“有经验”这些都是表象而不是根本，它们并不能直接和“工作好”划等号。
方法
目标明确了，但接下来的问题是假设面试者是一个黑盒系统，“工作好”不是直接可观测变量，你所能直接观测的变量是基础、算法、经验、学历、性格、谈吐、年龄等等。所以，实际上，你只能从“基础好”，“算法好”等可以直接观测的量去推测“工作好”的概率，这就是一个在“X好“条件下”工作好“的条件概率问题：P(工作好 | X好)。
根据这个模型，面试所应该考察哪些方面就很明显了，那就是选择那种最具有区分性的方面来考察。比如，考察面试者的体型特征没有太大意义，因为P(工作好|高)，P(工作好|矮)，P(工作好|胖)，P(工作好|瘦)的概率都差不多；所以，体型特征不具有区分性，这不是面试所应该关注的内容。
面试官应当结合职位的要求明确哪些因素具有比较好的区分性。比如，如果要招一名技术门槛比较高的3D游戏引擎开发工程师，面试者A具有3D游戏引擎开发的经验，但是在基础知识和算法面试方面表现一般；面试者B相反，基础知识和算法面试表现很好，但没有游戏开发经验，而你只能选择其一。你选谁呢？其实，这就是两个条件概率问题P(工作好|经验好，基础一般，算法一般）和P(工作好|没经验，基础好，算法好）。这个问题就留给面试官来判断了，就我个人而言，对于技术门槛较高需要技术积累的职位，经验更加说明问题，因此，我更倾向于面试者A。
下面，我再结合自己的经验谈谈对面试中常见方面的看法。
算法
算法是Google和MS等大公司面试所重点考察的内容。我个人很喜欢算法，曾经参加ACM/ICPC拿过北京赛区的13名。但是，就个人经验来看，我所接触过的绝大多数开发职位而言，算法都不适合作为考察面试者优劣的主要因素。对于普通的非算法性开发职位，考察面试者的算法就相当于考察他打乒乓球好不好一样，与目标“工作好”的相关性太低。就我个人的经验来看，差不多P(工作好|算法好)=50%，也就是算法面试没有太大的区分性。
甚至，还有一种很不好的情况特别多地出现在算法好的面试者身上，我称之为“只磨刀，不砍柴”。什么意思呢？有类人只对什么A*算法，异步编程，JVM类加载机制这种纯技术问题感兴趣，对实现用户需求毫无兴趣。这类人看起来有一定的技术能力，但是对公司来讲贡献十分有限，甚至不如技术一般但认真负责的人。所以，一旦遇到面试者算法好，我就特别留意考察会不会是这种“只磨刀，不砍柴”的人。
另外，虽然我个人不了解Google和MS，但我对于其特别重视考察算法能力的面试策略是持怀疑态度的。即使在这样的世界级大公司，算法虽然重要，但可以想象在项目实施过程所遇到的各种各样问题中，算法问题绝大多数时候不会是主要瓶颈，没有到那种需要每个人都是算法高手的情况。实际上，绝大多数项目真正难点并不是一两个算法瓶颈，甚至也不是单点的技术瓶颈，而是系统性的组织、协调、设计、开发问题，有大量的看起来不是那么有技术含量的脏活累活，也有许多问题是由于信息不足，并不是技术能力强就能克服这些困难。一个团队最好优势互补，有人算法强，有人业务分析能力强，有人擅长后端服务，有人擅长前端界面，有人聪明，有人踏实，这是最好的。如果按照“算法好”的单一标准选材，必定会把许多优秀的人才拒之门外。
基础
基础面试是指考察诸如指针使用、进程线程概念等基础知识的面试，十分类似于大学期末考试题。我曾经以为基础面试十分重要，但是现在不这么看了。在工作中基础的确是重要的，但是在面试过程中，它必须具有区分性才有意义，也就是说P(工作好|基础好)的概率要高，那么考察指针使用，进程线程区别这样的基础题目才有它的意义。我的实际经验是，基础面试并不具有很好的区分性，和算法一样， 差不多P(工作好|基础好) = 50%。同时，基础面试是最容易准备的，中国人有长期的应试教育经验，要准备几个把玩指针题目太容易了。
我曾经遇到过这样的面试者，他的C语言基础和编译、链接等原理掌握得非常好，给我留下了深刻的印象，我给的面试结论是：知识面不宽，只会C语言，但基础很扎实，建议录用。后来的事情证明了那个结论的前半部分是对的，但是”建议录用“错了。他在实际工作中表现得一塌糊涂，不理解需求，不理解整体架构；同时，上班时间不是花在项目上，而是花在阅读诸如《程序员的自我修养》之类的书籍上。最后，这位同事由于长期“不出活”离开了公司。
基础不是不重要，而是“基础好”不足以说明面试者能干好工作，因为基础是属于局部性知识，而实际工作需要综合性能力，二者有天壤之别。C语言、操作系统能考高分，但是不会写程序的人在大学我们还见得少吗？ 软件开发就像盖房子，综合能力是设计和搭骨架，基础知识是码砖。张小龙原先Foxmail是Delphi开发的，他它不懂C#，你如果要招聘一个开发.NET Email客户端的人，你考察他对CLR掌握得好不好有意义吗？ 让张小龙来开发一个C#版的Foxmail真的会有困难吗？ 你招一个精通C#但没有Email客户端开发经验的人来真的比张小龙靠谱吗？
我说基础知识不重要，和古人说的“不积洼步无以至千里”是不是矛盾呢？不矛盾！“洼步”与“千里”是一种可累加关系，但再多的“基础知识”都累加不成“综合能力”。学习软件开发要像持续集成一样，一开始就是一个完整的系统，虽然规模不大，问题很多，但它麻雀虽小五脏俱全，从小系统到大系统，从简单系统到复杂系统逐步演化。
所以，基础好本身不足以说明太多的问题，必须进一步考察综合能力。对于基础面试表现不好的面试者，如果时间允许也要进一步考察，有的面试者其实是有能力的，只是没有进行充分的准备。最理想的状态当然是基础和综合能力俱佳，若不能兼顾，应当综合能力优先。
经验
这里所说的经验不是通过工作了多少年来衡量的，而主要是指面试者的经历，比如，是否完整地实现过一个软件，或作为主要开发者完成过一个项目。经验的重要性在于它能说明一个人的综合能力。从项目的性质、规模和难度，面试官就可以大致判断出面试者的综合能力。如果一个面试者一直在大公司负责一个小模块的开发维护，那么基本可以判断他不具备独立或作为主要开发者承担一个项目的能力，只适合在另一家大公司做类似的事情。对于门槛较高需要长期技术积累的职位，相关经验更显得尤为重要，比如，Linux内核开发，JVM开发，游戏引擎开发，数据库实现，高级UX等。对于这类职位，没有经验的面试者即使综合素质不错也是需要长时间的学习和积累才能胜任。所以，基本上如果确定了你的职位属于此类，那么相关经验毫无疑问应该成为首选因素，换句话说，P(工作好 | 相关经验好)的概率是非常高的。
通过项目经验判断面试者的优劣比通过基础和算法测试更加靠谱，所以，面试过程中面试官应该花比较多的时间听面试者介绍项目经验，并进行深入地探讨交流，了解面试者的知识面、思维能力、表达能力等。同时，可以结合项目提一些基础知识和算法的问题，比如，如果面试者做过C++相关的项目，那就可以问他如何进行内存管理？是否熟悉智能指针？如果面试者的回答不能令人满意，那么就基本上可以判断他的项目做得不是很好。
要注意的是，经验也是一个多维度的事物。比如，C++股票交易中间件系统，这就涉及(C++，中间件，股票) 3个维度。假如面试者A做过C++股票交易客户端，面试者B做过C的股票交易中间件。从语言角度看，A最匹配，从项目性质看，B最匹配，你如何选择？这就是在多个维度中，哪个维度更重要的问题，就这个例子而言，我个人更倾向于B，因为我认为中间件开发经验是主要矛盾，而从C切换到C++并不是问题。所以，面试官需要判断哪一种经验是主要的，而哪一种经验是次要的。比如，我们招聘Android应用开发，这个职位的Android技术门槛并不高，它的真正难点在于做出好的用户体验(UX)。所以，如果一个面试者没有Android的经验我们是可以接受的，但是我希望他在UX方面有经验，至少做过其他平台的移动应用开发。
性格
现在，我来谈我认为最重要的因素：性格。这可能是许多初为面试官的朋友所难以想象的，怎么会是性格最重要呢？说实话，当我意识到这一点时，我自己也很惊讶！说白了，还是 P(工作好|性格好)的概率最高啊。我的实际经验是，如果一个人的性格好，他能把工作做好的可能性是最高的，性格好远比基础好、算法好要靠谱。
一个人如果技术上有缺陷，经验上有不足，但性格好，在团队中是很容易由其他人来补位的，他自己也很容易逐渐补起来；相反，如果一个人的性格不好，所有的技术优势经验优势都发挥不出来，甚至还会起到负作用，而且性格缺点很难改变。我一直谈到实际工作所需要的是综合性的能力，这种综合能力的发挥中性格是至关重要的。项目中不止会遇到技术问题，要涉及沟通、协调，不同的人不同的部门既有合作又有磨擦，如何处理这些事情都需要一个良好的性格。可以说，在开发团队里让你与众不同的不是你从哪个学校毕业，也不是你过去的经验，而是你的性格。
当然，性格是一个复杂的东西，它包含了很多的方面，并非所有方面都是程序员面试所需要关注的。我的经验是可以重点考察这些方面：
1) 态度积极还是消极。有的面试者在谈吐中就会自然给你一种积极上进的感觉，或者你可以在他的经历中发现他积极的因素，这些都不是太难看出来的。相反，有的面试者你能明显感觉到他的消极情绪。积极性在工作中是十分重要的，积极的人能给团队带来朝气，也更易于合作。基本上，如果确定面试者属于态度积极的，他通过我这一关的可能性就会大大增加；相反，如果确定属于态度消极的，即使技术能力不错我也会十分谨慎。
2) IQ。我的经验是，总体来看，聪明的人在工作中的表现更为优秀。在面试中要考察一个人是否聪明并不一定要像Google和MS那样找些专门测试IQ的智力题，其实，你只需要看他讨论问题是不是很有逻辑性，思考和说话是不是反应敏捷就可以做出大致的判断。另外，眼睛是人心灵的窗户，一个人聪明与否，眼睛是会说话的。不过，聪明也不完全是优点，比如，当公司或项目遇到困难时，往往是聪明人先跑掉了，坚守的往往是IQ一般的人。
3) 语言表达能力。语言表达能力也是程序员十分重要的一项素质，它关系到项目中的沟通是否顺畅。面试官可以看看面试者能否用简明的语言介绍清楚曾经做过的项目，能否抓住要点，能否考虑到听者的相关背景。一般来讲，语言表达能力强的人综合能力都不会太差。
4) 是否具有用户意识。有人说程序员是做研发的，哪来什么用户？只有销售、市场人员才会和用户打交道。其实，这是完完全全的错误认识。你写一个模块，甚至一个API，只要有别人用，他就是你的用户。有的程序员设计一个模块或是一个软件总是习惯于从使用者的角度来考虑，尽量地方便使用者，这就是一种良好的用户意识。具有良好的用户意识的人更能考虑别人的感受和整体的需要，而不是单纯地从自己和局部来思考问题。当面试者谈及过去的项目经验时，面试官可以常常站在用户的角度对其进行提问，从这个过程中观察其是否具有良好的用户意识。
5) 如何应对质疑和压力。面试官应该对面试者的回答以及以往项目进行合理的质疑，看看他如何应对。曾经有一位面试者谈到做游戏登录服务器的经历，我就问：“如果登录服务器挂了，怎么办呢”？他说原先虽然没有考虑这个问题，但是可以怎么怎么改进。其实，大家都理解项目中有各种不完美，这里面原因很多，只要面对质疑和压力能从容应对努力往好的方向思考解决就可以了，不需要掩饰缺陷，更不应该有情绪。我遇到过有的面试者，一旦你对其项目提出质疑，他马上产生反抗情绪，或不高兴，或不承认有问题，这很容易一下子看出来他在工作中容不得质疑和批评，这种人要想合作就很困难。
6) 个性特点。许多面试者喜欢在简历上写“精通C++/Linux“，这些字眼看得人麻木，如果有人写”喜欢C++/Linux“，我就会有一种眼前一亮的感觉。“精通”是没有感情色彩的叙述，而“喜欢”包含了面试者的个性，我更愿意看到面试者的个性。我相信对某样东西真正的热情远比你当前对它的掌握程度更为重要。其实，N年的经历告诉我们，同一个班的同学，同一个项目组的同事，虽然每天所学的知识，所接触的工作都是相同的，但其实每个人的成绩和表现差异是十分明显的。那么，到底本质的差异是什么呢？其实，就是每个人的个性。是个性使得有的人业余时间去打球，有的人业余时间去看书，有的人喜欢Linux，有的人喜欢Mac。一个人在团队中扮演的角色也和他的个性有很大的关系。面试官应该引导面试者展现自己的个性，并判断其是否有益于团队。
总结
最后总结起来，我的经验是： 1) 面试官的目标是找到”工作好“的人，一定要围绕这个目标来进行面试，如果把面试当成了算法或操作系统期末考试这就走入了误区；2) 面试过程是通过学历、性格、基础、经验、算法等可以测试的因素去综合判断面试者“工作好”的概率；3) 在各种因素中，性格 > 经验 > 基础 > 算法。性格是最重要的，如果性格不好，所有技术能力都会大打折扣，而且技术缺陷容易弥补，性格缺陷很难改变；经验体现了一个人的综合能力，你可以从面试者过去的经历中判断他能从事哪种工作，不能从事哪种工作；基础和算法则主要起到辅助参考的作用，基础好的程序员一般适应性比较强，学新技术更快，但是切忌单纯从基础来判断一个人的能力。

5. 实施工程师面试的话一般会问些什么问题

1、根据你的经验说说你对软件测试/质量保证的理解？软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入数据和预期的输出结果），并利用这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及外观排布.2、软件测试的流程是什么？需求调查: 全面了解您的系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等根据系统概况进行项目所需的人员、时间和工作量估计及项目报价。制定初步的项目计划: 在与您充分共同和协商的基础上制定我们的测试计划。测试准备: 组织测试团队、培训、建立测试和管理环境等。测试设计: 按照测试要求进行每个测试项的测试设计，包括测试用例的设计及测试脚本的开发等。测试实施: 按照测试计划进行实施测试。测试评估: 根据测试的结果，出具测试评估报告。3、(1) 你对SQA的职责和工作活动(如软件度量)的理解：SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程（如果有相应的CMM规程），对于不符合项及时提出建议和改进方案，必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等；(2) 说说你对软件配置管理的理解：项目在开发的过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制，配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的规模越大，配置管理就显得越重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并且只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS等，偶只用过CVS，对其它的不熟悉(3) 怎样写测试计划和测试用例：简单点，测试计划里应有详细的测试策略（测试方法等），合理详尽的资源安排等，至于测试用例，那是依赖于需求（包括功能与非功能需求）是否细化到功能点，是否可测试等。(4) 说说主流的软件工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情况以及对它们的理解：CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴CMMI:Capability Maturity Model Integration能力成熟度模型集成CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷RUP:rational unified process 是软件工程化过程。XP：extreme program，即极限编程的意思，适用于小型团队的软件开发，想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试（重点是单元测试）先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题很有好处。PSP ,TSP 分别是个体软件过程（Personal Software Process），群组软件过程（Team Software Process）大家都知道，CMM只是告诉你怎么做但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能（如何制定计划、控制质量及如何与其他人相互协作等等）而TSP着重于生产并交付高质量的软件产品（如何有效地规划和管理所面临的项目开发任务等等）。总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。4、还有问一下你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度地保证软件质量？测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式，是软件质量保证工程的一个重要组成部分。5、然后紧接着就基于目前中国的国情，大多数公司的软件项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量？(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况—–既不想投入过多又想保证质量，faint )出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化何谈足够且有针对性进行测试。所以，作为公司质量保证的你应该先和项目经理确定符合项目本身最适合的软件生命周期模型（比如RUP的剪裁，原型法）,明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员（项目经理更加重要）都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范围之内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。6、一个测试工程师应具备那些素质和技能？1、掌握基本的测试基础理论 ；2、本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现3、可熟练阅读需求规格说明书等文档 ；4、以用户的观点看待问题5、有着强烈的质量意识 ；6、细心和责任心 ；7、良好的有效的沟通方式(与开发人员及客户)8、具有以往的测试经验 ；能够及时准确地判断出高危险区在何处.7、做好软件测试的一些关键点1.测试人员必须经过测试基础知识和理论的相关培训。2.测试人员必须熟悉系统功能和业务。3.测试必须事先要有计划，而且测试方案要和整个项目计划协调好4.必须事先编写测试用例，测试执行阶段必须根据测试用例进行5.易用性，功能，分支，边界，性能等功能性和非功能性需要都要进行测试6.对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据7.测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测哪个场景或分支的8.个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好9.除了每日构建的冒烟测试可以考虑测试自动化外，其它暂时都不要考虑去自动化。8、软件测试员自身素质培养（1）首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。（2）善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。（4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。（8） 设身处地为客户着想，从他们的角度去测试系统。（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。（11）提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。（13）幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。（14）到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？9、为什么要在一个团队中开展软件测试工作？因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。10、您所熟悉的软件测试类型都有哪些？测试类型有：功能测试，性能测试，界面测试。功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。11、您认为做好测试用例设计工作的关键是什么？白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果黑盒用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：1、是否有不正确或遗漏的功能？2、在接口上，输入是否能正确的接受？能否输出正确的结果？3、是否有数据结构错误或外部信息（例如数据文件）访问错误？4、性能上是否能够满足要求？5、是否有初始化或终止性错误？软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：1、对程序模块的所有独立的执行路径至少测试一遍。2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。3、在循环的边界和运行的界限内执行循环体。4、测试内部数据结构的有效性，等等。4、验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。12、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法（最好是能先评审）13、您认为做好测试计划工作的关键是什么？1. 明确测试的目标，增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确2．坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。3．采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。4. 分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。14、 您所熟悉的测试用例设计方法都有哪些？1．等价类划分2．边界值分析法3．错误推测法4．因果图方法15、你的测试职业发展是什么？测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。17、你自认为测试的优势在哪里？优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。18、当开发人员说不是BUG时，你如何应付？开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

6. 软件实施工程师具体是做什么的

软件实施工程师主要负责工程实施： 包括常用操作系统、应用软件及公司所开发的软件安装、调试、维护，还有少部分硬件、网络的工作； 负责现场培训： 现场软件应用培训； 协助项目验收； 负责需求的初步确认；把控项目进度；与客户沟通个性化需求； 负责项目维护。

大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。

项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容，

每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶段的顺利完成是保证下一阶段的工作开展的基础。

(6)程序员实施工程师面试题扩展阅读

岗位职责：

1、负责客户售前售后技术支持及销售人员的售前售后的技术辅助；

2、负责客户软件安装与调试；

3、负责客户的现场培训及现场答疑；

4、负责客户售前售后的技术问题答疑、处理及维护;

5、参与项目招投标相关技术内容的筹备，负责标书技术部分的编写及答疑、应标等；

6、协助公司各部门工作，排除相关技术障碍;

7. 实施工程师和程序员有什么区别

实施工程师，就是指软件实施工程师，其与程序员的区别如下：

软件实施工程师的工作是软件产品服务主线的一个决定性环节，软件的成功离不开实施。负责工程实施： 包括常用操作系统、应用软件及公司所开发的软件安装、调试、维护，还有少部分硬件、网络的工作； 负责现场培训： 现场软件应用培训； 协助项目验收； 负责需求的初步确认； 负责项目维护。

一般的程序员都有四年的在专业领域的学习，需要一个在程序领域的学士学位获得者，不论是数学方面的还是工程方面的都是可以的。
大约有20%的人在这一领域的计算机科学和工程学拥有更高的学位。还有很小一部分程序员是自学的，尽管一些专业性的学校或者综合大学可以提供，但是也需要一些别的途径来提供相关的人才。尽管学历是比较重要的，但是公司经常把重点放在应聘者的工作经验上，很多刚从大学毕业的大学生虽然有引人注目的学位证书，但是他们找不到工作是因为他们缺乏经验。一个程序员虽然没有正规的学历，但是如果一个人拥有程序设计的深厚知识背景或者丰富的工作经验的话，那么他的机会要比有学历的应届毕业生大得多。所以要尽量抓住有用的工作和实习机会，这样的话在毕业后你就会发现，多实习让你有更多的经验，在找工作的时候就有更多的机会。
对于职业程序员，另外一个重要的方面就是，程序员需要不断提升自己的业务技术，他的技术必须一直保持在一个较高的水平，并且要不断发展，程序员也要寻找贸易的机会，要参加研讨会，在周刊上发表文章和接受职业教育，这些使程序员在自己的领域中分级或者不断并排前进。

8. 程序员和软件工程师，软件实施工程师，项目经理有什么区别，级别怎么排哪个更有前途

程序员和软件工程师是没有什么区别的，不过是叫法不同罢了，是纯技术的。实施工程师有点偏向于和客户交流，但懂软件的安装和使用，要求好的口才和应变能力。项目经理是最牛的，不过一般的刚毕业的学生难以胜任的，都是要有3-5年经验的才可以的。一般人都是从程序员开始的，慢慢走向项目经理或销售经理。

9. 程序员与工程师

有很多的公司他们会把程序员也称为工程师，所以程序员是工程师这一个大集合当中的一个子集，而工程师是不包含在程序员这个概念里面的。

10. 用技能的分类来分析你对 “学问好不如做事好,做事好不如做人好”的理解。

举个例子吧。
就拿软件来说事，程序员的职场规划：程序员----实施工程师---项目经理
学问好不如做事好，就比如，程序员会写代码，这是专业技能。
但项目做完了要到客户那去实施丫，不懂安装调bug，解决突发状况的话是不行的哦。
这是应急处理实战技能。这样，次数多了，跟客户沟通多了，了解客户需求多了，
懂得客户的需求了，知道如何为客户打消顾虑了。
这些只有经验丰富的项目经理才有的哦。这叫沟通领导的技能。
所以软实力才是我们职业生涯要增长的东西。