前言

沉寂了好一段日子，连我们公司自己人都问我为什么最近都不写文章了。 那么当看到本篇的标题的时候，大家应该可以猜到这是为什么了。 我最终还是决定要离开服务了 5 年多的公司。 而这次跳槽历经 3 个月，前后聊了 10 家公司，进行了将近 40 场面试, 基本都是 4+1 的流程 (技术面 +HR 面)， 所以日程被排的很满。 有一段时间每天都有 2 个面试邀约， 加上还有本职工作所以便没有精力再更新文章了。 这次面试也算是个大活了， 经历了各式各样的面试场景。 所以我想把这次跳槽的经验记录下来， 复盘一下自己的不足之处，同时也给大家提供一些素材，让大家以后出去面试能有个参照。

素材介绍

面试 List

我先介绍一下这一次面试的公司， 这一次我一心奔着大平台去的， 所以基本没有面试创业公司。 以上市公司或者准上市公司为主。 List 如下：BAT，快手，字节，贝壳，京东，美团，作业帮，神策数据。 其中也调级加面过，也有由于职位不匹配换部门重新面过。 所以虽然我没仔细计算过面试的场次，但是粗略估算差不多有 40 场这样一个数字吧。

岗位介绍

职位上都是资深技术专家岗， 岗位需求上带的人较少，毕竟还是走技术路线，主要内容是在质量团队中做技术攻坚以及建设基础设施。 业务方向上为容器，大数据，AI 这 3 个方向。

面试结果

5 家聊到最后，5 家由于岗位或方向不匹配主动放弃，1 家面试未通过（4 面交叉面的时候未通过）。

以上是这次面试的素材信息， 先介绍清楚， 避免跟我情况相差太多的同学有误解。

算法方面

遇到算法考核的概率

面试考不考算法的问题我想大部分人都是很关心的， 毕竟平时工作用不上但面试就是喜欢考。 我在面试之前其实也在群里询问是否要留足时间刷题，比较担心这么着急出去面试会不会因为准备不足而翻车。 那么现在市面上对于算法的考核是什么样的呢？ 我直接说结果吧，不管大家是否认可在面试中把算法作为主要的考核手段。 但是只要你有跳槽的心思， 就去刷题吧， 从我这次的面试经验来看，算法仍然是很主流的考核候选人的方式之一。 但确实不是每一次都会考， 这个看公司风格，团队风格，面试官风格也看岗位的特点， 不是可以一概而论的。 比如我在面试某家出了名的算法重灾区的时候，全程都没有考核算法。 并且考核算法的这些公司里几乎也只有 1 面的时候才会考算法。 所以综合我面试的所有数据来看， 遇到考算法和不考算法的团队是一半一半的概率。 但是由于我这次面试的岗位的特点， 有时候一面面试官就是团队负责人的级别， 而到了这个级别的人一般是不喜欢问算法这种这么细节的东西的。 所以我个人的结论是对于大部分测试开发人员来说，在面试的时候遇到算法考核的概率还是比较大的。PS： 我也询问了几个同时期也在面试的朋友， 他们遇到考核算法的概率也不低。

算法考核的范围和难度

我这次遇到的题目几乎都是可以在 leetcode 上找到原题的，即便没有原题也是一个原题之上的变种， 所以大家刷题上还是以 leetcode 为主。 难度上只遇见过 2 次中等难度， 其余的都是 easy 程度的题目，最多遇到的是链表和双指针相关的题目。 可以看出来市场对于测试开发人员在算法上的考核要比研发序列轻松。

算法考核占面试评价的比重

我个人的感受是不会把算法作为硬性的标准一刀切的否定候选人。 比如面试中有 2 次我是没有写出 bug free 的答案的，但是最后仍然通过了面试并且对方对我的评价依然不低。 所以总结下来如果我们其他的方面足够优秀的话， 算法的影响并不是很大。 但是如果面试官认为我们在其他方面并不优秀或者普普通通， 面试官就会很喜欢用算法来作为考核的最终手段了， 这时候没有答出来的话就是致命的了， 这一点我在接到某司 4 面挂通知的时候，就有所体会了。

总结

• 刷题是一定要刷的，不过 leetcode 上几千道题要刷完不太现实，成本太高。个人建议 easy 级别 top 系列可以刷一下。 有精力的中等级别的刷一个高频系列，比如全排列，子集，子序列这些就可以了。 再多的就不建议大部分人去刷了， 毕竟成本太高了。我们都是有工作和生活的，不可能整天都泡在算法上。 否则会影响你正常的工作和学习的进度
• 做好心态建设，算法这个东西就跟高考似的， 刷过的题型是可以试试但是没刷过的可能连个思路都没有，leetcode 上那么多题型，你刷的再多也可能碰上没思路的题。 这时候该认栽就认栽， 面试挂了也别气馁， 换一家继续面就可以了。
• 预留好足够的时间， 刷题是个长期的活，尤其我们都是有工作和生活的，做好长期战斗的准备。 不要在已经开始投简历的阶段才开始刷题，临时抱佛脚不太管用。 要在刚动了跳槽的心思的时候，就开始偷偷的刷起来。 这一点我做的不好， 真的是简历已经发出去了，才开始刷。 这就导致了我有几次没有写出正确的答案。

面试频率方面

我的建议是有条件的话尽量的多面试几家，不要犯懒，即便这家公司你不想去， 也要去聊聊看。 原因如下:

• 面试讲究的是状态和心态，刚刚面试的时候一般是找不到一个良好的状态的， 很可能连自己的项目介绍的都磕磕巴巴的。 而在心态上，刚出去面试不是过于乐观就是过于悲观，只有多面试几家公司才能树立一个比较合适的自信心。 所以在去面试你特别想去的公司之前，最好先找 2 家公司练练手。
• 多面试也是为了找准自己的定位， 像我这种已经快 5 年半没有出去面试过的人，其实是很比较难能准确的评估自己的级别的。 自己的定位找不准就容易出事， 比如本来你是 P8 能力的人，但是你觉得自己只有 p7 的水平，那么在跟 HR 谈薪的时候就会因为底气不足不敢要期望的薪资， 而如果你只有 P7 的水平却误认为自己是 P8 的级别，那也会因为自己有过高的期望而让谈判失败错失了好的工作机并会打击自己的信心。 所以在面试初期的时候一定要快速的找准自己的职级定位
• 面试是一个互相博弈的过程，尤其是跟 HR 谈薪资和定级的时候， 你需要手上至少有那么 2 个 offer 才能有底气与 HR 谈判。 如果手上没 offer 就跟你心仪的公司谈， 很可能会被一压再压。 要知道 HR 也是希望你过去的， 这也涉及到她的绩效。 你手上有好的 offer 她就不敢压的太狠， 要不然你不来了她的损失也不小。
  
• 有些时候不聊一下，其实你都不知道这个岗位其实很适合你，没准聊着聊着就成了。

面试题方面

首先说明一下， 经过这次面试的总结，以及我跟几个同样在找工作的朋友沟通的情况看， 高级职位基本不会问基础方面的问题了， 因为这个级别开始就是走专家方向，要求的技术深度和广度是不一样的， 不会小打小闹的跟你扣基础技术。 比如咱们社区里提到的一些常考题目一般都是看不到了。 例如给你一个场景怎么设计测试用例，问 xpath 语法，问接口测试里怎么封装数据，问长连接和短连接的区别，问某个语言的语法， 类似这样的问题很少会碰到， 而我面试了 40 场是一个也没遇到。 取而代之的会问一些成系统的问题来考核，希望候选人从更全局的角度来回答问题， 也希望候选人能更深入的分析一个方案的前因后果，成本收益，技术选型， 方案优势等等。 当然面试官们还是以在简历中介绍的项目和技术点来挖掘问题为主， 不会天马行空的问不相干的问题。 我把我还能记得的面试题分成几个类型列在下面。

考核技术深度的类型

这一类问题是考核候选人硬实力的杀手锏，因为不像考核软性素质和项目管理类的这种偏务虚的问题， 务虚的问题是有话术的。而这类问题没有话术可言，只能靠自己的实力硬抗。 下面我列一下我遇到的几个典型的问题。

• 详细介绍一下容器网络的原理。 这是我在面试一个做云的团队的一面面试题，后面又追问了 iptables 的原理， 因为现在的云产品都是要提供容器化服务的么，我简历中也写了很多 docker 和 k8s 的东西， 所以问这个问题也是对口。 这个问题怎么说呢， 我觉得算是比较难的吧 ，大家用 docker 和 k8s 的时候一般都比较少关注底层原理。 这涉及到 linux 底层的知识，包含了 namespace， 网桥，iptalbes 等知识， 具体的答案我曾经写过帖子，大家可以参考一下：https://testerhome.com/topics/9567
• 在简历中描述的混沌工程项目中， 你是否调研过开源的故障注入工具比如 chaos-blade 和 chaos-mesh。你是否了解这两款工具，而当时你为什么没有选择开源工具而选择了自研， 你自研的东西对比这两款工具有什么区别？ 这个问题大概遇到了 3，4 次吧， 目前混沌工程比较火， 很多地方都希望我去做混沌工程相关的东西，所以碰见问这个问题的情况比较多。 这个同样考察候选人的技术深度， 首先要解释清楚 chaos-blade 和 chaos-mesh 的原理，他们在故障注入方面是用什么样的机制去注入，各自的优缺点是什么。比如要解释 chaos-mesh 是直接从宿主机上通过切换名称空间来达到故障注入的目的，而我选择的是用 side car 模式直接注入故障容器的方式在 K8S 中注入故障。
• 说几个你在运维 k8s 集群中出现的问题和解决思路，也有几个面试官直接问比较传统的介绍一下你印象最深刻的 bug。 这个类型的问题回答思路一定要往高逼格上回答， 要体现技术身体和你处理问题的能力。 我回答的是在维护 k8s 集群的时候遇到的 k8s 自己的 bug， 尤其是涉及到了 k8s 和 docker 的设计与 linux 内核冲突的 bug 方面上， 体现了自己研究 k8s 的技术深度。 刚才也说了这是一个立 flag 的问题， 如果只是说一个很平常的 bug， 面试官会觉得你技术很一般， 没有解决过一些困难的问题。
• 简述一下 spark 运行的原理/Flink 有几种窗口分别是做什么的。 这是一道大数据相关的问题，是我面试一个大数据团队的时候遇到的。 面试官估计就是想考核我 spark 的硬实力， 完全跟测试无关，这可能是很多小伙伴们不能理解的， 因为可能会觉得我要是会 spark 干嘛不去做大数据开发。 但很遗憾， 很多的领域里面就是你不懂这个领域的研发技能的话，就是没办法做测试的。 而大数据就是其中之一， 不懂大数据开发的人基本上很难能做大数据的测试。 所以这道题从 RDD 讲起，数据切分，数据倾斜，shuffle 的原理，包括 shuffle 中的 shuffle write 和 shuffle read 的过程都是会考的。 而 Flink 的题略简单， 时间窗口和数字窗口两个大类， 再详细讲一下时间窗口里的滚动窗口， 滑动窗口，session 窗口， global 窗口都说一遍也就过关了。
• 如果你自己维护一个 k8s 集群， 你通过什么手段保证集群的稳定性。 这道题其实就是考察你懂不懂 k8s 的调度机制， 但是面试官没有直接问 node selector， pod selector，节点亲和性啊这些具体的知识点， 而是给我假设了这样一个场景看看我能不能灵活的运用这些知识点。 所以我回答的思路就是围绕这些知识点的。 比如第一点，流程规范上需要把 k8s 中运行的服务或任务分成不同的类别。 类似算法中的分治思想。 把集群中的节点也分成不同的类别， 比如有 SSD 硬盘的， 有 GPU 的， 有万兆网卡的，适合运行在线服务的，适合运行离线服务的， 适合运行业务服务的。 这些节点分别按类别打上不同的 label， 然后把不同任务和服务使用 node selector 或者节点亲和性反亲和性调度到合适的节点上去。 这样分而治之， 避免类似 IO 密集型的任务把业务服务给弄垮了的情况出现。 所以流程规范上要规定每个团队按这种规范来启动容器。 第二点，资源调度和规划上，每个任务和服务都要填写 request 和 limit 这两个字段明确的声明自己对于资源的需求， 禁止大量超卖导致资源失衡把机器搞垮， 同时节点的 kubelet 也需要在启动的时候限制好当前机器启动的 pod 数量的上限，避免 pod 过多， 也要通过参数给操作系统预留资源， 不能让 k8s 把资源都吃满，导致操作系统没有资源了整台机器崩溃。 第三点，k8s 本身的服务要使用高可用模式， 并且所有启动了高可用模式的 pod， 需要使用 pod 反亲和性保证两个相同的服务不会启动到同一个节点上，同时每个 pod 必须配置好探针，对服务有完整的健康检查探活机制。 第四点，要有完善的监控和自动化运维机制， 监控方面使用普罗米修斯监控所有节点和容器，并设置微信告警， 自动化运维方面编写自动化的程序， 比如自动清理存活时间太长的 pod， 节点压力过高时自动给该节点打 taint 以阻止任务继续调度到该节点上。 第五点， 集群要有冗余， 多加几个节点防止某些节点崩溃的时候可以让服务迁移到其他健康节点上， 同时镜像要有规范，不能太大，免得迁移的时候 IO 太高，时间太长。 这道题其实我理解对方就是在考我的 k8s 的调度机制，只是他没有直接问技术点， 而是考核我有没有一个成体系的技术能力解决问题。 我发现这是好多大厂面试官的提问风格。

总结一下这类问题是所有问题中最扣技术能力的了， 面试官会从简历中挑选他感兴趣的东西使劲往深了问， 考核的就是候选人在某样技术领域里到底走的多深。 甚至直接就是问你研发技能， 这个是很多小伙伴们反感的。 但这就是现实吧， 不仅仅是面试官， 我自己也比较认同只有在一定程度上了解了研发技术后，才能设计出更合适的测试场景。 比如在大数据领域里你不知道 shuffle 这个东西的话， 那就真的不知道要去测试数据倾斜这个场景了。 不知道 checkpoint 的话也就想不到在流计算里去测试数据一致性。 所以有些时候你会面对一些研发技术的问题，我遇到一个比较极端的是面试官直接问我如何设计一个在线的实时排名系统， 就是客户端 +kafka+flink 这套思路， 我理解面试官也不是说希望你能开发出这么一个系统出来， 他只是想知道你是否有相关的概念， 是不是深入的测过这样的系统， 因为如果你真的深入测试过一个系统， 那这个系统的架构你一定能说的出来。

考核测试策略的类型

这一类问题主要出现在如果面试的岗位和当前公司的岗位很匹配的情况下， 或者面试官也是这一领域里面， 他会使劲的问测试策略。 比如我是在 AI 领域中的， 我这一次找的工作也大多数是做 AI 的团队， 所以经常遇到如下问题：

• 如果评估模型的效果？ 类似于问怎么做效果测试。 这个问题在 AI 圈子里属于最常问的问题， 一般听说过的同学基本都知道采集数据灌入模型然后评估模型预测的正确率。 但是如果这么简单的回答基本是会跪的。 因为其实这个测试类型还蛮复杂的， 模型效果涉及到很多东西。 比如线上模型和线下模型的效果一致性， 不同类型的模型的评估指标都有什么。 整个模型的生命周期中分成哪些阶段， 每个阶段怎么测试来保证效果。 做效果测试的时候数据如何采集等等。 这类的问题肯定不是一两句话能说清楚的， 需要候选人更全面的分析每个场景和对应的测试方案。
• 在大数据产品里都做过哪些测试方案？ 同样是一个很大的问题， 我的答题思路是批处理和流计算要分别说， 批处理方面就涉及到了功能，性能，数据倾斜，异常场景， 数据及时性。 流计算里功能，性能，数据一致性。 同样共性的都要做监控，批处理的监控主要是写 spark 程序扫描数据， 而流计算主要是写一段 Flink 来对接消息中间件来扫描数据。 白盒测试方面需要去研发的 repo 里以 UT 的形式去测试 UDF 和 UDAF， 还要去拆流，把大的流拆成若干个小流进行集成测试。 同样不管批处理还是流计算在数据领域不管是功能还是性能测试都避免不了造数这个话题。 需要分析一下需要造数进行测试的场景， 怎么造数， 甚至介绍一下自己的造数工具的思路。 我自己的思路无非就是批处理用 spark， 流计算用消息中间件的客户端。
• 如果测试产品的稳定性？这个问题容易理解为问你如何开展混沌工程。 因为混沌工程的目的就是测试产品的高可用架构在生产环境下出现故障的时候是否有足够的容错能力保证产品继续的稳定提供服务。 但混沌工程的这种故障注入进行测试只是一个思路， 所以我回答的时候也说明了在云原生架构下， 如何从服务调度方面，镜像规范方面， 容器编排规范方面来保证服务的稳定性。 因为有些时候调度策略不对或者镜像太大或者没有设置合理的探针，资源规划都会导致服务的不稳定。 而混沌工程方面也会展开来说在不同的场景下主要注意的地方， 比如在流计算场景里更注意的是故障在触发后会不会造成数据不一致的情况。 所以验证点就不是业务正常的返回， 还要验证数据是否正确。

总结一下这类问题跟上面说的技术深度不一样， 考核技术深度的时候是一条线的使劲往深了问， 而这种测试策略类型的问题我理解更看重的是候选人能否从整体的角度全面的介绍你的测试策略。 毕竟这个级别不是大头兵了， 需要负责一个方向，不能是只在一个点上发力。 个人理解这种问题会比较少扣技术细节， 更关注的是候选人对特定业务的测试方案的理解是否足够全面。我们在日常工作里很多人可能只是负责某一块东西， 很难能熟悉所有的测试方案， 比如从效果测试来说我们团队其实有人专门做在线效果测试， 有人专门做离线， 有人专门做一致性，有人专门做数据正确性测试， 并不是效果测试中所有的场景都交给一个人来测试。所以平时工作的时候除了自己负责的测试外， 还是建议大家都关注一下其他人做的测试类型， 给自己形成一个整体的测试思维和视角。 这一点我自己也有所不足， 我更擅长的是机器学习场景， 而深度学习类比如 CV,NLP，OCR 我都不太熟，回答问题的这时候这部分有些缺失。

考核管理能力/软性素质/测试理念/业务理解 等

比较懒了我就把这些类型都汇总在一个标题里了， 回答这类问题有话术， 需要候选人口才好， 说话逻辑清晰， 并且对于问题有自己独到的见解， 我列一下我被问到的印象深刻的几个问题。

• 你是如何理解工程效能的？
• 你是如何理解 QA 这个职业的？
• 如果给你一个 40 人左右的团队， 你如何管理，如何展开招聘工作
• 如果设计一个国内通用的可以评估自动化测试的效果的模型，你考虑一下这个模型要怎么设计， 要从哪些维度评估。
• 在推进工具/平台/流程 的时候遇到不配合的团队怎么处理？
• 大概介绍一下产品的业务，盈利模式，公司对这个产品的策略
• 如何度量你的自动化测试方案/工程效能工具 的成本，收益
• 你如何证明当前的产品的质量是 OK 的
• 你如何设计你所在产品的质量保障体系

首先这类问题大多数是没有正确答案的，每家公司的理念不一样， 仁者见仁智者见智。 有些看运气， 就是看你回答的理念符不符合面试官的价值观， 不符合的话别想太多就认栽吧。 然后回答这类问题的时候很看你的表达能力， 言语之间的逻辑性比较重要。 个人觉得最关键的是对这类问题要事前有准备， 否则容易被打个措手不及。 平时工作的时候也要多注重一些系统性思维的思考， 对以后都是有帮助的。

总结

剩下的有些问题我自己也记不清楚了， 就主要列上面那 3 个大类吧。 整体看除了考核算法有固定的题库外， 其他的问题基本都是根据我简历里描述的项目来展开问的， 所以好好准备自己简历中描述的内容十分重要， 结合我自己做面试官的经验， 逻辑表达能力其实也是占了一个比较重要的位置。 如果在回答上述这些问题的时候逻辑混乱， 磕磕巴巴，前言不搭后语, 那面试可能也是会挂的。 所以事前准备真的很重要， 只要是简历里写的，都要自己过好几遍， 能预想到的问题都准备好答案背下来， 比如项目描述， 测试方案这些东西。 并且整个技术方案的前因后果也要准备好， 因为有些面试官会比较喜欢问你为什么要推进这个技术方案， 是遇到什么问题导致的？ 还是你自己主动推进的？ 推进这个技术方案遇到了什么问题， 这个技术方案有什么优势， 后面的拿到了什么结果， 怎么度量你的结果。 面试官会根据简历写的东西使劲扣， 所以事前准备好是非常重要的。 自己简历里写的内容一定要经得起考验， 否则勾起面试官的兴趣后最后缺比较失望，那就很影响面试结果了。

谈一谈业务方向的选择

这次出来面试对于业务方向的选择也有一些感受， 我觉得有一句话也挺对的叫选择大于努力， 我自认为是比较努力的类型， 但也不得不承认当初也是选择了几个比较好的业务方向， 所以现在找工作比较容易， 竞争对手少，大厂都愿意要这几个方向的人才，而且价钱也都能聊的上去。 这几个方向分别是：容器，大数据，AI。

• 首先云目前比较火，尤其是云原生架构特别火， 不少公司都在转型云原生架构，线上线下环境都要上云。 从我这次找工作的情况来看， 即便是顶级公司中也有不少项目是没有上云的， 而这些公司都不约而同的希望能将这些项目上云， 所以才会在面试的过程中非常关注我简历中描述的 docekr，k8s，混沌工程，环境治理等相关内容。 看目前的趋势， 以后这类技术会成为行业内很普遍的技能，很多测试人员尤其是大厂测试人员都要或多或少的掌握一些这样的技能，而能在云原生架构下建设环境治理， CICD， 混沌工程以及各类测试平台与工具就成了目前比较稀缺的能力， 并且现在专业做云的公司也越来越多， 连字节都要搞自己的云了， 所以相关的测试岗位也变多了， 但是在测试行业里懂这些的人是比较少的， 毕竟容器技术才火了这么几年，而且被很多人当做是运维领域的技能，所以很少有 QA 会去研究。而这个领域的研究深了也会比较值钱。 所以现在云领域我认为是一个比较好的方向。 感兴趣的同学可以了解一下。
• 再说大数据， 我记得 15 年的时候，当时我们质量部这边有一个架构师就说过大数据是未来。当时我还不知道什么是大数据，好像那个时候大数据这个词还没有像现在这么普遍， 可能那个时候做大数据的人还是比较小众的。 但是现在基本上成点规模的公司都会有自己的数据部门， 目前这部分业务的测试工作在很多公司仍然以研发自测为主，也没办法，懂大数据的 QA 比较少。 这也导致了如果你在大数据上有一些沉淀的话， 就会比较抢手。 我们团队之前有 2 个人拿了美团和快手的数据团队的 offer， 听说总包涨幅都不低。
• 最后说说 AI， 前几年 AI 热潮造就了不少工作岗位， 虽然现在 AI 四小龙后劲不足，但市面上各个公司仍然都还在构建自己的 AI 能力。 而跟上面 2 个领域一样的是 AI 领域的 QA 人才仍然很缺少， 做这部分测试需要懂机器学习，深度学习，大数据（因为目前机器学习都是构建在大量的数据下的）。 我跟一些大厂的同行聊天的时候，大家都表达出了招人的乏力， 想在世面上招到符合要求的测试人员太困难， 大家都开启了内部培养的模式。 所以在这样一个大环境下，懂 AI 业务和相关技术栈的 QA 会比较吃香。 从我自己这次找工作来说， 在当前公司做机器学习平台的经历还是很加分的。

所以业务方向的选择是挺重要的， 除了我说的这 3 个方向以外一定也是有其他不错的方向， 只是我不熟悉的就不说了。 我个人觉得选择一个技术类的业务方向是比较好的， 就比如我上面说的这 3 个方向， 全部是技术类的业务，也就是技术本身就占业务中很重要的部分。 在这样的业务中工作就可以兼顾技术与业务两方面的发展。比如你在云产品中做测试人员， 云产品中很多时候玩的就是 docker，k8s，OpenStack，分布式存储这些东西，这样你测试的过程中就能练出一身技术了。选择走技术类的业务还有一个好处是业务足够复杂， 深度也足够深。 可发展的空间比较大，越走到后面竞争对手就越少。 当然做起来难度就越高，需要学习很多技术， 但也正因为难度大， 竞争对手才少， 机会才多。 如果业务比较简单， 那很难做出亮点， 机会也少，门槛低，竞争对手就多。

职业发展上个人感觉几个比较重要的事情

• 选择一个自己热爱的领域： 这个怎么说呢， 努力的重要性是不言而喻的， 但是如果我不热爱这个领域的话， 实话实说我很这么多年来一直保持学习的状态。 长期保持高强度的做一件自己不喜欢的事还能做的特别好， 这不是一般人能坚持下来的，起码我就不是。 所以我个人觉得做自己喜欢的事挺重要的， 这很大程度决定了后面自己是不是能发展的好。
  
• 选择一个有门槛的领域：门槛的重要性我之前专门写过文章表明我的观点， 上面也说过门槛高，挑战大，但是机会多，对手少，上限高。 门槛低，容易做，但是机会少，对手多，上限低。
• 心态上不要纠结于QA的本职范围内：好些同学总会纠结一些事到底是不是 QA 的职责范围， 比如有人会觉得 docker 和 k8s 是运维才应该学的东西， 面试的时候面试官问几句心态就炸了，直言我又不是 研发/运维 我干嘛要学这个。 这样是不行的， 还是那句话，高阶的测试开发人员一定要有技术追求。 技术与业务的结合才是最优解。 我在一场面试的时候，面试官问我混沌工程这个事情有些公司都是 SRE 部门做的， 你觉得 QA 做的优势是什么。 我回答说 SRE 或运维可能在云原生相关能力上比我更优秀， 但是他们不懂用户，不懂业务，不懂产品。注入故障后他们并不能很好的评估故障带来的影响， 而 QA 可以。 以我这几年做测开的经验， 很多有价值的事情都是需要一定的研发和运维能力才能去做。
• 年龄是每个人都要面对的坎， 只有不停的提高自己的能力， 让能力的增长匹配的上年龄的增长才能让自己处于一个比较安全的位置。 这一点在出来面试的时候就会感受的到。 不希望自己面试的时候因为年龄问题被卡住，平时就不要趟平， 多锻炼自己的能力。 我一个朋友在 43 岁的时候还能找到不错的工作， 而另一个人在 30 来岁的时候就早早的被迫转了行。 这个行业， 逆水行舟， 不进则退， 大家努力吧。
  
• 自己的实力决定了周围人对待你的态度， 多年前我还是菜鸟的时候出来面试到处受白眼，遭嫌弃。 而这次面试感觉全世界都变的友好了起来， 到处都洋溢着灿烂的笑脸， 婉拒对方的时候，他们还会各种挽留。 而我再公司中推进事情的时候也是发现比以前容易很多，不再像以前那样不把自己当回事。 所以想要受尊重， 想要工作开展的顺利， 还是要往上爬。 这个世界就是这么现实，还是那句话， 逆水行舟不进则退。 我们都是在水流中不停向前的人。
  

跳槽的时候需要注意的几个事情

• 有些同学可能担心跳槽涨幅会不会卡 30%。 普遍会有这个情况， 但优秀的人可以打破这个限制。 想要超过 30% 一般要走特批， 或者业务方极力争取，所以面试中的任何一面的面评都是比较重要的，大家要认真对待每一次面试， 不要因为一面的时候觉得对方比你年轻或者能力没你好就态度轻慢。 总之就是想要涨幅超过 30%， 就要证明自己有这个价值。
• 大厂背调一般比较严格， 大家注意千万别造假。 简历中的工作信息最好对着自己的社保记录写一遍。第三方背调公司一般会要求提供 10 年内最近两家公司的信息， 要求提供同事， 直属上级和 HR 的联系方式。 再强调一下别因为觉得自己跟领导或者 HR 关系不好，担心说自己坏话而填写其他人， 如果被查出来的话，也是可能会导致背调失败的。 他们的评价并不会直接影响你的入职， 只要确定你没有造假就不会出事。 如果上家公司找不到联系人了， 可能会要求提供社保记录， 离职证明（所以以前公司的离职证明最好留一个备份）。 最后如果实在没办法证明自己在那家公司工作过的话， 背调公司一般会顺延， 调查 10 年内第三家公司的经历。 在背调之前一定要跟 HR 再确认一遍他们手里的简历是不是你提供的最新的。
• 遇到不合拍的面试官的情况很正常，心里再不爽也别当时翻脸。 没有当场翻脸就还有周旋的余地，很多面试管其实在你入职后都跟你没多少交集，没必要跟他置气。 比如我 4 面挂的那一次就是美团技术委员会的交叉面， 完全是另一个部门的人。 他是业务团队的人， 我面的是数据团队的岗位， 他不懂大数据， 我不懂客户端。 被挂了也正常，因为两个人完全不在一个频道上。 心态放平和， 面试后找主管沟通说明情况，看是否有周旋的余地。 就算不成也没关系， 好好睡一觉准备下一家公司。
• 尊重每一家公司，不要在 offer 之间反复横挑， 太败人品。 如果决定不去这家公司了， 尽早说明， 不要拖着。 圈子很小， 要小心维护自己的风评。
• 尊重每一个面试官， 聊得开心的可以加个微信， 就算这次不成，以后也没准会有合作的机会。 圈子真的很小， 没准走着走着就又聚到一起了。

总结

就写这么多吧，估计大家可借鉴的也不多， 毕竟每个人有每个人的情况。最后说一下大厂的面试流程都很长， 动辄 1 个多月，大家要合理安排时间。 祝大家早日富可敌国