面试时经常会被问到的 3 个问题

Posted 2021-01-06

前几天，我在《简历中打动人的 3 个关键点》和《简历中千万不要出现的 3 个问题》中讲了一些写简历的注意事项，今天想聊聊在面试过程中，如何更好的体现出自己的真实实力。

面试时，我经常会拿下面 3 个问题开场：

1.请做个简短的自我介绍；
2.简单介绍一个自己参与度比较高的项目，以及自己在项目中的职责；
3.简单描述下你在项目中发现的最有成就感的 Bug；

下面我分别针对这 3 个问题逐一做下说明。

1.请做个简短的自我介绍；

大部分的鸡汤文或者面经给出的建议可能是这样：

面试官你好，我叫张三，出生于 2018 年 8 月 31 号，女，属狗，我喜欢爬山、读书、游泳、跑步、下棋、写代码、做测试，非常高兴能获得今天的面试机会，谢谢。

恩，说的好不好，好，没毛病，但好像少了点什么，少了啥？少了我需要的信息，面试不是聊天，一问一答之间都是有目的的，所以我建议的回答方式可以是这样：

面试官你好，我叫张三，2016 年毕业，最近的一份工作是在特斯拉公司，最近做的一个项目是特斯拉线圈的测试，我在项目中担任测试负责人的角色，本次换工作是因为公司业务调整，准备投入资源做超级高铁，砍掉了特斯拉线圈的业务，本次想找一个团队氛围好，技术上更有挑战的工作。

这个回答我比较满意的原因有这么几点：

1. 主动告知一些必问的信息，比如公司和项目信息，比如换工作的原因，以及个人预期，这样做一方面减少了面试官来回问的时间，同时会让面试官感觉到这个人做事比较周到，或者说叫眼里有活。
2. 虽然是回答，但是在主导话题，或者说制造话题，比如他提到了公司和项目，但是没有详细介绍自己作为测试负责人的角色职责，所以我肯定会继续问下去。

能给面试官制造话题的面试者都是好的面试者(但是别给自己带沟里去了)，如果在第一个问题上给面试官留下好的印象，对后面的沟通会非常有帮助。

如果是你，你会怎么回答？

2.简单介绍一个自己参与度比较高的项目，以及自己在项目中的职责；

如果第一个问题，面试者没有主动告知这些内容，第二个问题我还是会主动问出来。

针对这个问题，有的同学回答的重点会有点跑偏，比如会花费不少的时间去介绍自己项目的详细情况：

我最近有参与一个 App 的测试，这个 App 有首页模块、好友模块、核心传输模块和个人中心模块，并且又分为 ios 端和 android 端，Android 端又分国内版和海外版，我主要负责 Android 端国内版的测试。

看，说了这么一堆，只回答了项目信息的部分内容，我还是不知道「你」具体都做了啥，那我就需要再继续重复问一下这个问题。

注意面试过程中的重点是面试者本人，项目信息算是背景信息，主要信息应该是面试者做的事情，那么只需要把能衬托面试者能力的地方凸显出来就行啦，比如：

我最近参与一个 App 的测试，周期是两周，一共有 10 个开发和 4 个测试参与，我主要负责带领其他 3 个测试人员一起保证项目所有版本的质量。我的主要工作内容是包括需求评审、用例编写、测试分工以及自动化脚本编写。

这样的话，信息是不是一下就丰富多了？多提供人员信息有助于面试官了解自己在团队中的位置，特别是关键角色的时候，一定重点突出一下，提供具体的工作内容是为了后面的沟通可以进一步展开。

比如这个话题中的需求评审、用例编写、自动化脚本编写都是我想展开的，还是那句话，能够给面试官制作话题的面试者都是好的面试者，不过要记住，不要给自己挖坑，比如上面提到了自动化脚本编写，结果自己只是改改配置参数而已，并没有啥技术含量，这样的话问下去会很失望的。

所以前面那句话可以完善下：主动把话题引导到自己的优势的面试者都是好的面试者。

如果是你，你会怎么回答？

3.简单描述下你在项目中发现的最有成就感的 Bug；

这个问题应该不是我的专利，几乎各个面经中都会提到，所以有很多面试者提前准备，那我先说下回答的注意事项：

1. 要的是自己发现的，不是别人发现的；
2. 同样的，不要把别人发现的，冠名到自己头上，很容易出破绽的；
3. 最好不是常规用例执行中出现的 Bug；

先看一个例子：

「有一个项目新增了本地搜索功能，我把特殊字符作为输入时，程序发生了崩溃，然后和开发一起用 windbg 调试定位，最后发现是程序没有对异常进行处理。」
「特殊字符输入不是常规用例就覆盖了么？这样的话任何人都能发现吧？」
「恩，是用例执行时发现的。」
「windbg 调试需要 pdb 吧，这个只有开发那有，所以实际就是开发给定位的呗？」
「恩，开发定位的，我是提供了重现环境和 dump 文件。」

前面说的关键点全部命中，常规用例能覆盖到的测试点，我们认为是大部分人都能考虑到的，既然这样，发现这样的 Bug，不应该是件很有成就感的事情吧？

再来看一个例子：

「因为一个需求，业务需要拦截注入的操作，开发提测后，确实满足了本次的需求场景，经过和开发沟通，了解到实现逻辑是处理了 API SetWinEventHook 的调用，但是经过研究发现 API SetWindowsHookExW 也可以达到同样的效果，但是开发没有处理，鉴于换个 API 就被绕过的成本太低，开发又新增了对这个 SetWindowsHookExW 的处理。」
「怎么想到这个测试点的？」
「Windows 系统 API 很多，而且繁复，所以碰到的时候都格外小心，之前也一直有查 MSDN 的习惯，所以在研究具体的实现方式时就发现了这个测试点，其他类似的情况还有很多。」
「测试工具是开发帮忙写的么？」
「不是，我自己写的。」

这个例子中：

1. 自己发现的问题；
2. 不是常规用例覆盖的范围，搞清楚开发的详细逻辑，并做针对性的全面性测试，不是所有人都能做到；
3. 还有一个重点是，问题定位过程完全是自己完成。

如果你是面试官，面对这两个面试者你会选谁？

好了，我要说的就这些了，等等，我好像听到有同学有问题。

「上面这些道理我都知道，但是我确实没有拿的出手的东西可讲啊，怎么办？」

还能怎么办，赶紧回去补呗。

记住，做每个项目的过程，都是我们成长和收获的过程。

对了，先把这篇文章分享出去，然后再去补的话，效果更好的噢。

本文首发于公众号「sylan215」，十年测试老兵的原创干货，关注我，涨姿势！