前几天，我在《简历中打动人的 3 个关键点》和《简历中千万不要出现的 3 个问题》中讲了一些写简历的注意事项，今天想聊聊在面试过程中，如何更好的体现出自己的真实实力。
面试时，我经常会拿下面 3 个问题开场：
1.请做个简短的自我介绍；
2.简单介绍一个自己参与度比较高的项目，以及自己在项目中的职责；
3.简单描述下你在项目中发现的最有成就感的 Bug；
下面我分别针对这 3 个问题逐一做下说明。
1.请做个简短的自我介绍；
大部分的鸡汤文或者面经给出的建议可能是这样：
面试官你好，我叫张三，出生于 2018 年 8 月 31 号，女，属狗，我喜欢爬山、读书、游泳、跑步、下棋、写代码、做测试，非常高兴能获得今天的面试机会，谢谢。
恩，说的好不好，好，没毛病，但好像少了点什么，少了啥？少了我需要的信息，面试不是聊天，一问一答之间都是有目的的，所以我建议的回答方式可以是这样：
面试官你好，我叫张三，2016 年毕业，最近的一份工作是在特斯拉公司，最近做的一个项目是特斯拉线圈的测试，我在项目中担任测试负责人的角色，本次换工作是因为公司业务调整，准备投入资源做超级高铁，砍掉了特斯拉线圈的业务，本次想找一个团队氛围好，技术上更有挑战的工作。
这个回答我比较满意的原因有这么几点：
- 主动告知一些必问的信息，比如公司和项目信息，比如换工作的原因，以及个人预期，这样做一方面减少了面试官来回问的时间，同时会让面试官感觉到这个人做事比较周到，或者说叫眼里有活。
- 虽然是回答，但是在主导话题，或者说制造话题，比如他提到了公司和项目，但是没有详细介绍自己作为测试负责人的角色职责，所以我肯定会继续问下去。
能给面试官制造话题的面试者都是好的面试者(但是别给自己带沟里去了)，如果在第一个问题上给面试官留下好的印象，对后面的沟通会非常有帮助。
如果是你，你会怎么回答？
2.简单介绍一个自己参与度比较高的项目，以及自己在项目中的职责；
如果第一个问题，面试者没有主动告知这些内容，第二个问题我还是会主动问出来。
针对这个问题，有的同学回答的重点会有点跑偏，比如会花费不少的时间去介绍自己项目的详细情况：
我最近有参与一个 App 的测试，这个 App 有首页模块、好友模块、核心传输模块和个人中心模块，并且又分为 IOS 端和 Android 端，Android 端又分国内版和海外版，我主要负责 Android 端国内版的测试。
看，说了这么一堆，只回答了项目信息的部分内容，我还是不知道「你」具体都做了啥，那我就需要再继续重复问一下这个问题。
注意面试过程中的重点是面试者本人，项目信息算是背景信息，主要信息应该是面试者做的事情，那么只需要把能衬托面试者能力的地方凸显出来就行啦，比如：
我最近参与一个 App 的测试，周期是两周，一共有 10 个开发和 4 个测试参与，我主要负责带领其他 3 个测试人员一起保证项目所有版本的质量。我的主要工作内容是包括需求评审、用例编写、测试分工以及自动化脚本编写。
这样的话，信息是不是一下就丰富多了？多提供人员信息有助于面试官了解自己在团队中的位置，特别是关键角色的时候，一定重点突出一下，提供具体的工作内容是为了后面的沟通可以进一步展开。
比如这个话题中的需求评审、用例编写、自动化脚本编写都是我想展开的，还是那句话，能够给面试官制作话题的面试者都是好的面试者，不过要记住，不要给自己挖坑，比如上面提到了自动化脚本编写，结果自己只是改改配置参数而已，并没有啥技术含量，这样的话问下去会很失望的。
所以前面那句话可以完善下：主动把话题引导到自己的优势的面试者都是好的面试者。
如果是你，你会怎么回答？
3.简单描述下你在项目中发现的最有成就感的 Bug；
这个问题应该不是我的专利，几乎各个面经中都会提到，所以有很多面试者提前准备，那我先说下回答的注意事项：
- 要的是自己发现的，不是别人发现的；
- 同样的，不要把别人发现的，冠名到自己头上，很容易出破绽的；
- 最好不是常规用例执行中出现的 Bug；
先看一个例子：
「有一个项目新增了本地搜索功能，我把特殊字符作为输入时，程序发生了崩溃，然后和开发一起用 windbg 调试定位，最后发现是程序没有对异常进行处理。」
「特殊字符输入不是常规用例就覆盖了么？这样的话任何人都能发现吧？」
「恩，是用例执行时发现的。」
「windbg 调试需要 pdb 吧，这个只有开发那有，所以实际就是开发给定位的呗？」
「恩，开发定位的，我是提供了重现环境和 dump 文件。」
前面说的关键点全部命中，常规用例能覆盖到的测试点，我们认为是大部分人都能考虑到的，既然这样，发现这样的 Bug，不应该是件很有成就感的事情吧？
再来看一个例子：
「因为一个需求，业务需要拦截注入的操作，开发提测后，确实满足了本次的需求场景，经过和开发沟通，了解到实现逻辑是处理了 API SetWinEventHook 的调用，但是经过研究发现 API SetWindowsHookExW 也可以达到同样的效果，但是开发没有处理，鉴于换个 API 就被绕过的成本太低，开发又新增了对这个 SetWindowsHookExW 的处理。」
「怎么想到这个测试点的？」
「Windows 系统 API 很多，而且繁复，所以碰到的时候都格外小心，之前也一直有查 MSDN 的习惯，所以在研究具体的实现方式时就发现了这个测试点，其他类似的情况还有很多。」
「测试工具是开发帮忙写的么？」
「不是，我自己写的。」
这个例子中：
- 自己发现的问题；
- 不是常规用例覆盖的范围，搞清楚开发的详细逻辑，并做针对性的全面性测试，不是所有人都能做到；
- 还有一个重点是，问题定位过程完全是自己完成。
如果你是面试官，面对这两个面试者你会选谁？
好了，我要说的就这些了，等等，我好像听到有同学有问题。
「上面这些道理我都知道，但是我确实没有拿的出手的东西可讲啊，怎么办？」
还能怎么办，赶紧回去补呗。
记住，做每个项目的过程，都是我们成长和收获的过程。
对了，先把这篇文章分享出去，然后再去补的话，效果更好的噢。
本文首发于公众号「sylan215」，十年测试老兵的原创干货，关注我，涨姿势！
