一个测试工程师面试官的真实分享！个人超赞同！
作者：互联网
最近一段时间都在做集中招聘，参加了许多面试，累个半死。加上之前在团队中最近几年也做了不少面试，关于测试工程师招聘的话题，刚才没事特意google了一下，除了一些面试题外居然没有几篇心得方面的文章。上午招聘轮空，抽空写一下自己的看法，仅供参考。记得看完即焚。
所有团队的招聘，基本上都是要找最“合适”的人，而不是技术最强的人，或者最优秀的人。技术最强的人不一定合适，原因有很多，
1. 岗位一定的情况下，并不需要超出岗位能力特别多的人，完全没有这个需求。
2. 性价比问题。因为这些人比较“贵”。如果不给比较高的待遇和级别，无法吸引这类候选人。
3. 如果团队的整体技术水平是6分（满分10分），但候选人是个10分，你觉得他会很乐意跟水平是6的人合作吗？就像把詹姆斯请到cba来打球，即便你付得起薪水，詹姆斯自己也会很郁闷，在他眼中“不怕神一样的对手，就怕猪一样的队友”。
4. 对管理的挑战比较大，一般来讲，强人一般在融入团队方面有点小问题，除非遇见了比他更强的人。可以参加下文的非技术部分。
招聘的目的就是要找到最“合适”的人，跟结婚很像，要选择跟自己搭得上的，自己不帅还要那些脸蛋漂亮、身材火爆的，没用，早晚得离，弄不好还给自己带一顶绿帽。 在团队管理中也要充分发挥每个人的长处，扬长避短，让合适的人做适合的事情，才能让团队的贡献最大化（这是另外一个话题，以后有时间再写）。所以在招聘中要试图去发现候选人更多的优点，而不是找他的缺点。你很容易就用一道特别难的题把候选人给问住，或者使劲在他不熟悉的领域让他难堪，除了打击一下候选人的自信之外没啥意义。所以整个面试过程中，多数时间都花费在找优点上。只要不是特别严重的缺点，都可以通过后期的团队管理来弱化其影响。
技术方面
首先要确定，测试工程师是一个技术岗位。为了彰显这一点，许多公司都把测试岗位的 title 改为测试开发工程师，像微软的sdet（software design/develepment engineer in test）、谷歌叫set（software engineer in test）等。纯粹的手动黑盒测试工程师早已不复存在。所以，技术技能是最基本的要求，我会针对初级岗位、高级岗位或专业岗位的不同要求来讲对招聘的要求。
代码能力
对于测试开发工程师的招聘，由于其是基础岗位，要求也是最基本的编码能力，所以针对这类岗位，我一般会花费80%的面试时间在技术考核上。之前很多团队遗留下来的恶习，总是觉得测试对技术的要求不高，强调“Test Sense”的重要性，我不是否定它的重要性，但对于应届毕业生或者初级岗位的人，压根儿没做过测试，他有个屁的test sense，还不如去花点时间考核候选人的逻辑思维能力靠点谱。我一般喜欢让候选人现场写写代码，对绝对不是那种巨变态的算法问题，一般都是二分法、字符处理、简单数据结构相关的小题目，只是想看看候选人有没有基本的代码功底。在review代码的时候可以有针对性地对编码语言的一些关键字提问，看看候选人的代码掌控能力。基本上，只要能把自己想法通过代码实现且没有大的逻辑错误，在代码考核这一关都会放过。但如果要得到很高的分数，那必须在代码的可读性、异常处理、算法效率、可测试性方面有比较好的表现。我认为对于测试工程师来说，写代码的能力是必须要有，但不一定要求到达“精通”的地步，特别是在算法效率方面。很多的测试工作，都是在工程系统的验证层面上，你要那么牛逼的算法背景做甚？ 未来转岗去开发吗？有人可能会在这里崩出来说了，编码语言不精通说明潜力不足。潜力是什么？潜力只能说明你现在能力很差而已，有很大的上升空间。幸亏我写这篇文章的时候只是沉溺在自己的思维世界里，否则还不被那些唱反调子的人给恶心死。好了，继续聊我的。具备了基本的代码能力，可以写自动化的程序或者工具即可。在测试程序的算法效率和巧妙性上花费太多的时间，我觉得这是一种不务正业的表现，除了有助于提高你的个人技术之外，对于公司的项目没有任何的价值，对于测试来说，其自动化用例的编写的效率要比执行效率重要的多。在实际的工作中，脚本语言是也是测试代码的最爱，life is short, test in Python，道理大家都懂。
测试思路（“Test Sense”）
对于一些稍微高端的岗位，例如资深测试开发工程师或者测试专家的招聘，需要考核更多的测试思路和测试技术（参见下一段），不再是简单的程序设计问题。关于测试思路，在写完一段代码之后，会被要求来测试这段代码。这个时候，候选人的测试思路就会涌现出来，尝试尽可能多的测试方法与思路来测试这段代码。一般的候选人会考虑正常情况下的使用场景、边界情况、bad case等功能性的方面问题，这说明你入了门，知道基本的思路，而经验丰富的候选人，会在性能方面多考虑一些，例如performance test, load test, stress test（不知道他们的区别，我只能说你不是性能测试专家，赶紧去google一下吧）。在这里，肯定又有好事者会跳出来说了，哥是来应聘性能测试专家的，你让我写代码我就认了，你还让我针对这些代码做性能测试，我可是正经的性能测试出身，之前都是用的loadrunner、jmeter这些高端大气上档次的性能工具，根本不用自己写代码针对某个函数做性能测试。哎，遇到这种人，也不知道是他的不幸还是我的不幸，但在面试官面前我觉得你还是应该低调一些，如果你公开拒绝，我除了认为你比较坦诚之外还会认为你很有“潜力”，注意这个潜力是上一段中所说的潜力。废话少说，白盒的性能测试或者叫性能分析能力，在跟踪定位性能问题的时候特别重要，如果你还能把gperftool(google perfmance tool)、operfile等工具原理及使用场景告诉我，加分！性能测试绝对不是简单的系统方面的性能测试，能够指出整个系统的性能结果只是第一步，系统级别的性能测试工具loadrunner可以做到，但如果想定位到性能瓶颈所在、并提供改进方案那你就必须要掌握刚刚提到的白盒性能分析能力，从系统层面到模块级别、再到函数级别的问题定位，这才能彰显牛逼人的牛逼之处。就是比普通人多那么一点点。发现我的废话还真多，继续说测试思路的事情，优秀的候选人会提供功能、性能方面的思路，再优秀的人会提供更多的思路，例如稳定性方面，这段代码在持续运行24小时之后怎样？函数的响应时间、内存和cpu的占用情况还跟调用之初一样吗？是否符合预期？还有一些人会考虑安全方面的场景，在多线程的调用下程序会出错吗？是否线程安全？多进程的情况下呢，是否有共享的进程间数据安全问题，有没有被死锁的可能等等。还有很多测试思路方面的点子，在这里就不再一一罗列，你要感兴趣，我们可以私下交流。总之，对于有丰富测试经验的人（可不是工作年头），总是可以提出很多思路和方法，而获得这些知识的唯一来源就是实践，否则几个问题深入下去你就露馅儿，而在面试过程中“诚信”永远是底线，不可违背。
测试技术
针对高级测试岗位需要一些有针对性的测试技术类问题。例如，针对前端测试岗位，在技术提问上会由针对性地在前端提问，没有自己写过前端程序的人也很难把前端测试做好，html/css/js/Wartir/Selenium/Webdriver等方面的知识必不可少，开源的工具没用过，没有关系，你只要能把类似的思路说清楚也可以。怎样精准定位web页面上得元素、如何得到这个对象而不是另外一个相同类型的元素、背后原理是怎样的，等等这种有针对性的问题很容易试探出候选人在前端测试方面的技术深度。再例如，一个测试工具开发的候选人必须知道框架、工具、平台的区别，框架如何提供接口给业务测试人员使用，哪些是框架要解决的问题哪些是业务测试自己要解决的问题，他们的问题域和解决方案都必须要了如指掌。类似地，在单元测试、api测试、安全测试、mobile测试、后端服务测试、大数据测试等方面，都会有针对性的问题等着你。相比较之前的代码能力，面试官一般更看中测试技术本身的掌握能力，代码能力只能说明你有潜能，而测试技术是未来会在项目中真实用到的技术，会真正地帮助到测试本身的技术。
技术热情
在之前的面试中，遇到很多候选人，但被问及为什么来选择来做测试时，有些会说“我是女生，我很细心”。卧槽，适合不适合做测试跟细心有个毛线关系，我承认细心体贴是中华女性的传统美德，可测试真不是靠细心就能做的很好的。而且我发现有一批人的确就是这么想的，所以有必要在这里啰嗦几句。可以这样说，细心地观察是可以发现一个事物的某处缺陷，就像“鉴宝”节目中你要细致地观察，你细心你可以发现某个青花瓷藏品中是否砂底有釉，但如果你不了解元青花背后的知识背景即便你发现了这个缺陷你也无法做出正确的判断，相比较细心，更重要的是背后积累的技能知识。知识技能的增长因素中，很重要的就是技术热情。所以即便候选人技能还不到火候，但如果技术热情饱满，我还是会认为这样的人是真正有潜力的人，甚至会给一个通过。俗话说，“活到老，学到老”，背后依赖的就是热情。没有热情的人就像是一潭死水，工作对他而言更多的是一份工作，毫无声色与激情。在技术日新月异当下，没有热情，慢慢地你就“死”了。
技术之外
每一个岗位都有它的针对性，有及技能要求，也有技术之外的要求。团队中需要什么样的人，我们就招聘什么样的人。除了技术能力之外，你最希望团队中的人具有什么特质？这个恐怕因人而异，但你不得不去思考这些问题。如果你招聘到一个不合适的人，对团队的影响是巨大的，会破换团队的水质。一旦发现这类人，一定要“fire quickly”，否则遗患无穷。这里居然扯出了facebook得招聘理念“hire slowly, fire quickly”，我把它翻译成“结婚慢慢找，离婚快点离”，哎呀，我的思路可真发散啊，都不知道自己要说啥了。:)
言归正传，在面试过程中，技术之外，考查更多的几个软技能大致如下， 1. 沟通能力。整个面试过程本身就是一次沟通的过程，你能够很好地理解面试官的问题，面试官也能听懂你的答案，perfect，这算是一次完美的沟通了吗，体现了候选人优良的沟通能力。错，大错特错，特别是针对面试这种场景，针对测试这个岗位。候选人听得懂你的问题，有可能是你讲的很明白，而你能听懂他的回答是因为你是这个问题域的专家，可以从少数关键字中抽取出正确的答案，这种语境下，并不能说明候选人就具备良好的表达能力或者优秀的理解力。我个人认为，考核一个人的沟通能力时需要提问一些模糊的问题，在逆境下方显能力。如果候选人可以针对你的问题多问几个问题以及经过后继的一些反复确认，这才能证明他具备一定的沟通能力，并说明候选人是一个爱问问题的人，而对于测试来说，爱问问题或者怀疑的态度永远是最弥足珍贵的品质。 2. 团队合作。测试是整个研发环节中的一环，大型的项目更是需要多人一起测试完成。人与人一起打交道，就会有各种合作的需求。合作关系是一种共赢逐利的行为，强调同步与整体，节调一致。但对于一个产品或者项目，有人做红花就要有人甘愿做绿叶，所以在合作中需要奉献。情商较低的人团队合作一般都比较困难。 3. 执行力。执行力不是简单的听话，“执行”才是听话，“力”更多的是强调执行的结果。没有一个主管喜欢不听话的下属，但听话的下属执行力却不一定强。很多人说的漂亮但做起来却没有说的那么好，相反，有些人动手能力很强，但不苟于言辞。坚强的人，或者笨的人更容易成功，因为他们懂得坚持。 4. 易相处。很多团队强调这一点，一个nice的人，一般都很容易相处，团队成员之间的关系也会比较和谐。一般情商比较高的同学，在这方面都不会有太大的问题。反倒是一些智商高的人，容易让人有点担忧。易相处绝对不是唯一的标准，不易相处的同学会给管理上带来一定的难度，多数管理者都会希望自己的团队成员不是那么的刺头。但在面试的过程中对一个人做出这样的判断还是非常困难的。通用言谈举止，或许可以做出一定的判断，但人一是会伪装的，或者说是掩饰，特别是一些知道自己缺点的人，会尝试掩盖自己的不足。
面试技巧
所有的技巧基本上都没有什么用处，基本上都是狗屎，再好的技巧都是为了掩饰。所以切记在面试过程中使用什么“技巧”。
最后
说了这么多，多数都是对候选人的要求，其实对于面试官也一样，你配做面试官吗？你能真实考察出候选人的能力吗？你判断的依据又是什么。千里马难寻的背后往往是因为伯乐太少。写这段话的时候，我也打了几个激灵，!@#$%一身冷汗呀！面试的过程就是选择的过程，不仅对于面试官，对于应聘者也是这样，可以通过面试了解岗位的情况，以便做出适合自己的决定。坦诚，别装，即便你骗过了面试官，在日后的工作中你也骗不了你自己，这对谁都没有好处。公司找合适的人，个人选择适合自己的公司，Double Win。
最后，关于招聘信息，不少互联网公司都在微博上发布岗位信息，可以重点关注一下。但，别天天没事就挂在微博上，微博上扯淡的人比较多，他们都是优秀的time killer，专门扼杀你宝贵的时间还让你觉得自己长了见识
所有团队的招聘，基本上都是要找最“合适”的人，而不是技术最强的人，或者最优秀的人。技术最强的人不一定合适，原因有很多，
1. 岗位一定的情况下，并不需要超出岗位能力特别多的人，完全没有这个需求。
2. 性价比问题。因为这些人比较“贵”。如果不给比较高的待遇和级别，无法吸引这类候选人。
3. 如果团队的整体技术水平是6分（满分10分），但候选人是个10分，你觉得他会很乐意跟水平是6的人合作吗？就像把詹姆斯请到cba来打球，即便你付得起薪水，詹姆斯自己也会很郁闷，在他眼中“不怕神一样的对手，就怕猪一样的队友”。
4. 对管理的挑战比较大，一般来讲，强人一般在融入团队方面有点小问题，除非遇见了比他更强的人。可以参加下文的非技术部分。
招聘的目的就是要找到最“合适”的人，跟结婚很像，要选择跟自己搭得上的，自己不帅还要那些脸蛋漂亮、身材火爆的，没用，早晚得离，弄不好还给自己带一顶绿帽。 在团队管理中也要充分发挥每个人的长处，扬长避短，让合适的人做适合的事情，才能让团队的贡献最大化（这是另外一个话题，以后有时间再写）。所以在招聘中要试图去发现候选人更多的优点，而不是找他的缺点。你很容易就用一道特别难的题把候选人给问住，或者使劲在他不熟悉的领域让他难堪，除了打击一下候选人的自信之外没啥意义。所以整个面试过程中，多数时间都花费在找优点上。只要不是特别严重的缺点，都可以通过后期的团队管理来弱化其影响。
技术方面
首先要确定，测试工程师是一个技术岗位。为了彰显这一点，许多公司都把测试岗位的 title 改为测试开发工程师，像微软的sdet（software design/develepment engineer in test）、谷歌叫set（software engineer in test）等。纯粹的手动黑盒测试工程师早已不复存在。所以，技术技能是最基本的要求，我会针对初级岗位、高级岗位或专业岗位的不同要求来讲对招聘的要求。
代码能力
对于测试开发工程师的招聘，由于其是基础岗位，要求也是最基本的编码能力，所以针对这类岗位，我一般会花费80%的面试时间在技术考核上。之前很多团队遗留下来的恶习，总是觉得测试对技术的要求不高，强调“Test Sense”的重要性，我不是否定它的重要性，但对于应届毕业生或者初级岗位的人，压根儿没做过测试，他有个屁的test sense，还不如去花点时间考核候选人的逻辑思维能力靠点谱。我一般喜欢让候选人现场写写代码，对绝对不是那种巨变态的算法问题，一般都是二分法、字符处理、简单数据结构相关的小题目，只是想看看候选人有没有基本的代码功底。在review代码的时候可以有针对性地对编码语言的一些关键字提问，看看候选人的代码掌控能力。基本上，只要能把自己想法通过代码实现且没有大的逻辑错误，在代码考核这一关都会放过。但如果要得到很高的分数，那必须在代码的可读性、异常处理、算法效率、可测试性方面有比较好的表现。我认为对于测试工程师来说，写代码的能力是必须要有，但不一定要求到达“精通”的地步，特别是在算法效率方面。很多的测试工作，都是在工程系统的验证层面上，你要那么牛逼的算法背景做甚？ 未来转岗去开发吗？有人可能会在这里崩出来说了，编码语言不精通说明潜力不足。潜力是什么？潜力只能说明你现在能力很差而已，有很大的上升空间。幸亏我写这篇文章的时候只是沉溺在自己的思维世界里，否则还不被那些唱反调子的人给恶心死。好了，继续聊我的。具备了基本的代码能力，可以写自动化的程序或者工具即可。在测试程序的算法效率和巧妙性上花费太多的时间，我觉得这是一种不务正业的表现，除了有助于提高你的个人技术之外，对于公司的项目没有任何的价值，对于测试来说，其自动化用例的编写的效率要比执行效率重要的多。在实际的工作中，脚本语言是也是测试代码的最爱，life is short, test in Python，道理大家都懂。
测试思路（“Test Sense”）
对于一些稍微高端的岗位，例如资深测试开发工程师或者测试专家的招聘，需要考核更多的测试思路和测试技术（参见下一段），不再是简单的程序设计问题。关于测试思路，在写完一段代码之后，会被要求来测试这段代码。这个时候，候选人的测试思路就会涌现出来，尝试尽可能多的测试方法与思路来测试这段代码。一般的候选人会考虑正常情况下的使用场景、边界情况、bad case等功能性的方面问题，这说明你入了门，知道基本的思路，而经验丰富的候选人，会在性能方面多考虑一些，例如performance test, load test, stress test（不知道他们的区别，我只能说你不是性能测试专家，赶紧去google一下吧）。在这里，肯定又有好事者会跳出来说了，哥是来应聘性能测试专家的，你让我写代码我就认了，你还让我针对这些代码做性能测试，我可是正经的性能测试出身，之前都是用的loadrunner、jmeter这些高端大气上档次的性能工具，根本不用自己写代码针对某个函数做性能测试。哎，遇到这种人，也不知道是他的不幸还是我的不幸，但在面试官面前我觉得你还是应该低调一些，如果你公开拒绝，我除了认为你比较坦诚之外还会认为你很有“潜力”，注意这个潜力是上一段中所说的潜力。废话少说，白盒的性能测试或者叫性能分析能力，在跟踪定位性能问题的时候特别重要，如果你还能把gperftool(google perfmance tool)、operfile等工具原理及使用场景告诉我，加分！性能测试绝对不是简单的系统方面的性能测试，能够指出整个系统的性能结果只是第一步，系统级别的性能测试工具loadrunner可以做到，但如果想定位到性能瓶颈所在、并提供改进方案那你就必须要掌握刚刚提到的白盒性能分析能力，从系统层面到模块级别、再到函数级别的问题定位，这才能彰显牛逼人的牛逼之处。就是比普通人多那么一点点。发现我的废话还真多，继续说测试思路的事情，优秀的候选人会提供功能、性能方面的思路，再优秀的人会提供更多的思路，例如稳定性方面，这段代码在持续运行24小时之后怎样？函数的响应时间、内存和cpu的占用情况还跟调用之初一样吗？是否符合预期？还有一些人会考虑安全方面的场景，在多线程的调用下程序会出错吗？是否线程安全？多进程的情况下呢，是否有共享的进程间数据安全问题，有没有被死锁的可能等等。还有很多测试思路方面的点子，在这里就不再一一罗列，你要感兴趣，我们可以私下交流。总之，对于有丰富测试经验的人（可不是工作年头），总是可以提出很多思路和方法，而获得这些知识的唯一来源就是实践，否则几个问题深入下去你就露馅儿，而在面试过程中“诚信”永远是底线，不可违背。
测试技术
针对高级测试岗位需要一些有针对性的测试技术类问题。例如，针对前端测试岗位，在技术提问上会由针对性地在前端提问，没有自己写过前端程序的人也很难把前端测试做好，html/css/js/Wartir/Selenium/Webdriver等方面的知识必不可少，开源的工具没用过，没有关系，你只要能把类似的思路说清楚也可以。怎样精准定位web页面上得元素、如何得到这个对象而不是另外一个相同类型的元素、背后原理是怎样的，等等这种有针对性的问题很容易试探出候选人在前端测试方面的技术深度。再例如，一个测试工具开发的候选人必须知道框架、工具、平台的区别，框架如何提供接口给业务测试人员使用，哪些是框架要解决的问题哪些是业务测试自己要解决的问题，他们的问题域和解决方案都必须要了如指掌。类似地，在单元测试、api测试、安全测试、mobile测试、后端服务测试、大数据测试等方面，都会有针对性的问题等着你。相比较之前的代码能力，面试官一般更看中测试技术本身的掌握能力，代码能力只能说明你有潜能，而测试技术是未来会在项目中真实用到的技术，会真正地帮助到测试本身的技术。
技术热情
在之前的面试中，遇到很多候选人，但被问及为什么来选择来做测试时，有些会说“我是女生，我很细心”。卧槽，适合不适合做测试跟细心有个毛线关系，我承认细心体贴是中华女性的传统美德，可测试真不是靠细心就能做的很好的。而且我发现有一批人的确就是这么想的，所以有必要在这里啰嗦几句。可以这样说，细心地观察是可以发现一个事物的某处缺陷，就像“鉴宝”节目中你要细致地观察，你细心你可以发现某个青花瓷藏品中是否砂底有釉，但如果你不了解元青花背后的知识背景即便你发现了这个缺陷你也无法做出正确的判断，相比较细心，更重要的是背后积累的技能知识。知识技能的增长因素中，很重要的就是技术热情。所以即便候选人技能还不到火候，但如果技术热情饱满，我还是会认为这样的人是真正有潜力的人，甚至会给一个通过。俗话说，“活到老，学到老”，背后依赖的就是热情。没有热情的人就像是一潭死水，工作对他而言更多的是一份工作，毫无声色与激情。在技术日新月异当下，没有热情，慢慢地你就“死”了。
技术之外
每一个岗位都有它的针对性，有及技能要求，也有技术之外的要求。团队中需要什么样的人，我们就招聘什么样的人。除了技术能力之外，你最希望团队中的人具有什么特质？这个恐怕因人而异，但你不得不去思考这些问题。如果你招聘到一个不合适的人，对团队的影响是巨大的，会破换团队的水质。一旦发现这类人，一定要“fire quickly”，否则遗患无穷。这里居然扯出了facebook得招聘理念“hire slowly, fire quickly”，我把它翻译成“结婚慢慢找，离婚快点离”，哎呀，我的思路可真发散啊，都不知道自己要说啥了。:)
言归正传，在面试过程中，技术之外，考查更多的几个软技能大致如下， 1. 沟通能力。整个面试过程本身就是一次沟通的过程，你能够很好地理解面试官的问题，面试官也能听懂你的答案，perfect，这算是一次完美的沟通了吗，体现了候选人优良的沟通能力。错，大错特错，特别是针对面试这种场景，针对测试这个岗位。候选人听得懂你的问题，有可能是你讲的很明白，而你能听懂他的回答是因为你是这个问题域的专家，可以从少数关键字中抽取出正确的答案，这种语境下，并不能说明候选人就具备良好的表达能力或者优秀的理解力。我个人认为，考核一个人的沟通能力时需要提问一些模糊的问题，在逆境下方显能力。如果候选人可以针对你的问题多问几个问题以及经过后继的一些反复确认，这才能证明他具备一定的沟通能力，并说明候选人是一个爱问问题的人，而对于测试来说，爱问问题或者怀疑的态度永远是最弥足珍贵的品质。 2. 团队合作。测试是整个研发环节中的一环，大型的项目更是需要多人一起测试完成。人与人一起打交道，就会有各种合作的需求。合作关系是一种共赢逐利的行为，强调同步与整体，节调一致。但对于一个产品或者项目，有人做红花就要有人甘愿做绿叶，所以在合作中需要奉献。情商较低的人团队合作一般都比较困难。 3. 执行力。执行力不是简单的听话，“执行”才是听话，“力”更多的是强调执行的结果。没有一个主管喜欢不听话的下属，但听话的下属执行力却不一定强。很多人说的漂亮但做起来却没有说的那么好，相反，有些人动手能力很强，但不苟于言辞。坚强的人，或者笨的人更容易成功，因为他们懂得坚持。 4. 易相处。很多团队强调这一点，一个nice的人，一般都很容易相处，团队成员之间的关系也会比较和谐。一般情商比较高的同学，在这方面都不会有太大的问题。反倒是一些智商高的人，容易让人有点担忧。易相处绝对不是唯一的标准，不易相处的同学会给管理上带来一定的难度，多数管理者都会希望自己的团队成员不是那么的刺头。但在面试的过程中对一个人做出这样的判断还是非常困难的。通用言谈举止，或许可以做出一定的判断，但人一是会伪装的，或者说是掩饰，特别是一些知道自己缺点的人，会尝试掩盖自己的不足。
面试技巧
所有的技巧基本上都没有什么用处，基本上都是狗屎，再好的技巧都是为了掩饰。所以切记在面试过程中使用什么“技巧”。
最后
说了这么多，多数都是对候选人的要求，其实对于面试官也一样，你配做面试官吗？你能真实考察出候选人的能力吗？你判断的依据又是什么。千里马难寻的背后往往是因为伯乐太少。写这段话的时候，我也打了几个激灵，!@#$%一身冷汗呀！面试的过程就是选择的过程，不仅对于面试官，对于应聘者也是这样，可以通过面试了解岗位的情况，以便做出适合自己的决定。坦诚，别装，即便你骗过了面试官，在日后的工作中你也骗不了你自己，这对谁都没有好处。公司找合适的人，个人选择适合自己的公司，Double Win。
最后，关于招聘信息，不少互联网公司都在微博上发布岗位信息，可以重点关注一下。但，别天天没事就挂在微博上，微博上扯淡的人比较多，他们都是优秀的time killer，专门扼杀你宝贵的时间还让你觉得自己长了见识
标签：面试官,工程师,代码,面试,赞同,测试,团队,岗位,候选人 来源： https://blog.csdn.net/FlyPigYe/article/details/96178921