目录
一、试用期与加班工资
一般而言，试用期持续的时间为3-6个月，工资、奖金都按正式员工的标准计算。唯一的区别在于，试用期的员工，周末加班不能转调休，相当于白加班。因此，不到最忙的时候，组长（PL）不会叫试用期的员工周末加班，如果非得加班，也会通过外出公干的方式让他们调休。
如果周末两天都加班，双倍工资就是4天，这样相当于基本工资涨80%，接近翻倍了。当然，这种连续的周末加班也很消耗精力，无论你有多么强的体魄或是多么年轻，最终都不得不承认：命要紧。现在周末加班，依然按双倍工资计算，但不会下月发，而是给你累计，直到8年一次换工号，或者离职的时候，才会统一给你结清。并且，周末加班也需要主管审批，不再按打卡时间直接计算。
二、招聘
刚毕业那会，就听说过华为只要是985/211的学生就招，编程题通过就行，几乎不看你的个人经历。华为会以不信任员工为基础，建立一套完善的制度和流程让员工把活干漂亮。承受不了压力的人被淘汰，承受住压力并遵从制度和流程的人能活下去，在这基础上智商、情商特别高的人会拿钱到手软。?
在华为非HR也要参与招聘，这几乎成了他们在华为职业生涯中的必经之路。他们会根据现有的人才库，挨个打电话询问就职意愿，并引导他们做面试题、在线编程并参与面试官的1对1面试。
存储的招聘预算不太够，因此招聘一般倾向于招OD/WX的员工。OD的员工工号以300开头，WX的员工工号以WX开头，这两种员工都不算华为的正式员工，其中OD的员工相对更优秀些，主要从事开发工作。而WX开头的员工基本只能从事测试工作，他们按照测试文档一步步执行并查看是否符合预期，绝大多数WX员工并不知道自己为什么要这么执行，预期的结果代表着什么，因为他们没有资格参加方案的设计和串讲，也没有TDE(Test Design Engineer，负责设计测试用例的华为员工)愿意跟他们讲解。
由于外包的人员流失较大，因此招聘的任务就很重。同时又倾向于招聘OD/WX的员工，所以招聘难度会很大。总结一下就是：有能力的人看不上OD/WX，没有能力的人又过不了在线编程等考核。
三、月度答辩和转正答辩
在试用期，每个月都会有一次月度答辩，你要做PPT详细描述在这一个月内你做了啥，学到了啥，并现场回答评委的问题。在转正那一次，又需要准备转正答辩，把整个试用期的工作进行总结。
在答辩过程中，评委们都会认真听你讲，并经过思考询问你一些问题，这种气氛还是不错的。实际上，答辩对绩效的作用并不是特别大，因为你平时做的事情大家都能看到，也能估算出分量。
答辩最大的作用，在于防止新员工偷懒。当一名员工进入公司后，在完全熟悉流程，成为一颗忙碌的螺丝钉之前，会有短暂的空窗期。在这个阶段，由于你啥也不懂，没人会找你，也没法给你分配任务。这时，如果你知道每个月都需要报告工作和学习进展，就会产生足够的动力，尽快融入团队。转正答辩完成后，基本上你已经是一颗标准的螺丝钉了，这时候不再需要答辩，通过绩效考核进行激励即可。
四、可信考试认证
对开发而言，每个人都需要通过可信考试。可信考试分专业级和工作级，一共四门课，四个考试，往往新来的员工更容易通过，因为他们有更充足的时间；而老员工没有时间学习，几乎都是裸考，除了科目一的在线编程，其他科都是理论知识，涵盖的范围包括编程语言语法和技巧、编程语言规范、需求分析、安全红线、设计模式、敏捷开发等等。这些经验被总结成精炼的语言，通过以考促训的思想灌输到每个员工的脑子
五、接口人
从入职到导师脱手，其实就差不多两个月时间。最重要的任务就是通过可信认证考试。两个月后，开始接手一些简单的任务，修改问题单或者承担一些简单的功能开发。但在一些部门，这时候往往会给你一个恐怖的任务----接口人。
一般而言，一个产品会被分为多个模块，每个小组维护多个模块。当测试发现属于某个组的模块出现问题，或者别的模块依赖该模块的部分工作不正常时，他们需要有人能帮忙查看原因，这个人就叫接口人。
一个组大概10个人，负责的模块代码量在数十~数百万行的级别。乍一看，会觉得应该选一个经验丰富的员工，对组内负责的模块、历史情况等掌握很清楚的人作为接口人。但实际上，帮他人看问题找原因，是一种吃力不讨好的工作，因为领导看不到，身边的同事也感知不到。
在有些公司，通常是主管当接口人，他会对问题进行简单的分析，再根据组内成员的擅长领域、负载情况 ，选择合适的人去分析该问题。在华为，类似的岗位是PL，为了绩效，他们不可能每天把时间浪费在这上面。同时，组内的每个人都忙得要命，最熟悉该领域的人可能正在完成紧急任务，根本没时间去分析。因此，PL通常会找组内资历浅一些的同事去充当接口人，并按固定期限轮换。
一个组维护的代码量不算小，让新员工去做接口人，美其名曰“锻炼”，实际上是让他去抗压。作为接口人，PL的要求就是尽可能不打扰到组内其他人，所有问题，除非真正是Bug，否则不能让测试提单。这样的要求看似简单，但对于新员工而言，很多时候测试咨询的问题你连他讲的啥意思都不明白，再加上设计又存在各种历史原因、特殊情况的考虑，新员工大多是懵逼的。想求助经验丰富的同事？如果项目不太紧张的时候还好说，项目紧张起来，每个人都戴着耳机在通话，你可能好几个小时都见不到他们空闲下来。而测试对你的响应时间是有要求的，一小时不给清楚解释？那就提单吧。
举个例子：你在分析A问题发生的原因，阅读完全陌生的代码，另外2个测试给你留言，找你咨询B、C问题。你简单扫了一下B、C问题，都不是你熟悉的领域，需要花时间去读代码，了解设计，才知道是不是问题，所以你暂时没回复。两分钟后，两个测试分别给你打电话，你很烦，不想接电话，但他们不停的打，并在留言中告诉你再不接电话就提单。你只能接起电话好言相劝，告诉他们现在真的很忙，只能请他们先登记，排队等你的消息。没多久，你读到A问题中一部分看不明白的代码逻辑，想找人问，一抬头组内所有人都在打电话。于是你咬咬牙一边跟A的测试确认测试用例的逻辑，一边忽略部分看不懂的代码去猜测后续的逻辑。这时候B、C的测试告诉你不能再等了，上面催着要提单，你只能暂时放下代码再次解释，给他们合理的截止期限并请求他们接受。突然电话又响了，是一个电话会议，问题很严重，线上四五个开发正在一起讨论，需要你做确认，TDE催促让你赶紧看，搞不定就往上捅。你赶紧放下A问题，一边读D问题的现象，一边凭你的理解去回答这几个开发的问题。D问题的难度不大，但涉及的条件特别多，变量也多，逻辑很绕，你得理一理，正在理的过程中，A测试的TDE气愤的给你留言：都看了两个小时了怎么还没结果？必须提单了。
如果实在搞不定了，测试等不及要提单，一般是要跟PL讲的。但作为新员工，你要做好心理准备，因为这时候免不了一顿臭骂。因为PL永远是忙得要死，他有方案要讨论，有设计要做，还有大量组内杂事，本来已经焦头烂额，你不仅不能帮他分担，还告诉他现有的某个问题搞不明白，他也是很崩溃的。但这顿骂往往又是值得的，因为PL会快速给你指明方向，因为如果是定位偏了，他会快速纠正你的方向。
六、问题缺陷单
刚才提到很多次“提单”，就是指的问题单。测试提的问题单，一般代表某个模块的功能有Bug。
问题单的跟踪，华为有一套系统叫DTS，测试提单，开发解决的流程大致如下：
- 测试外包员工在DTS系统中创建一个问题单，填写产品、版本、问题描述等信息。
- 问题单提给负责该模块的测试TDE（华为正式员工）审核。
- 测试TDE把问题单转发给负责该模块开发的组内PL。
- 组内PL再把问题转发给需要解决该问题的开发。
- 开发把问题解决，提交代码，填写根因分析并把问题单转给组内PL。
- 开发同时需要与测试TDE预约时间，与测试TDE串讲问题单发生的原因和修改后的影响。
- 组内PL等串讲完成并且最新的Build包含开发的Commit Id后，将问题单转给测试TDE。
- 测试TDE将问题单转交给测试外包员工进行验证。
这么一套流程走下来，感觉脱了层皮。对于上级领导来说，他不需要知道细节，只需要要求一个组的问题单的目标数量即可。比如今天整个组剩下40个问题单，明天的要求是35个，后天是30个...
于是，为了达成目标，PL非常反感问题单走到自己组头上。有的问题单涉及到模块间的协调处理，测试提单的时候发现的是A模块的问题，但A模块经研究后发现，实际问题出在A模块依赖的B模块身上，B模块由另一个组维护，于是跟B模块的接口人沟通。这种情况，即使已经基本确定是B模块的问题，B模块的PL、接口人也会想尽一切办法拖延问题单走给B模块的时间，定位问题根因和修改方案后，才会同意问题走到B模块。毕竟每天的问题单目标放在那里，多一个在自己头上，都是沉重的负担！这种时候，A模块的PL肯定也不希望问题单在自己组，所以这时候就看他们两个PL的PK了，作为PL，至少都在华为奋斗了好几年，大家像战友一样有感情，互相理解下，这次留给你，下次留给我，互相不撕破脸。
在这套流程中，开发最不喜欢的步骤就是测试串讲。这个设计的初衷是好的：担心你的改动造成的影响测试不清楚，从而无法对受影响的场景进行测试。但遗憾的就是这个规定太死板，绝大多数的串讲根本没有意义，只需要测试进行原场景复现，并检查问题是否解决即可。
问题单的设计如此复杂，依然是对员工的不信任。在其它公司，流程就简单多了：
- 测试创建问题单，填写产品、版本、问题描述等信息。
- 问题单提给需要解决该问题的开发者。
- 开发把问题解决，提交代码，填写根因分析和需要重点测试的场景，把单转回给测试验证。
步骤的简化，就对员工的素质要求高。就拿问题单与测试的串讲来说，一般开发人员觉得这个改动的影响比较大，可能需要重点测试一些场景的时候，就会在问题单上注明；同理，测试如果意识到开发人员的改动有风险，或者对开发人员的根因分析不太理解时，也会主动找开发人员沟通。
华为的流程复杂，它的基本逻辑是：信任DE/TDE这种在华为干了很长时间的老员工，新员工不值得信任。配套的激励也是倾向于PL/DE/TDE，这会让新员工做得很憋屈，但这没关系，因为总会过滤出一批忍得住憋屈，愿意遵从规则坚持努力下去的人。
复杂的流程导致了一个问题，就是测试TDE的繁忙程度超乎想象。因为一个测试TDE往往负责多个模块，也就是对应着多位开发，当问题单较多的时候，容易形成了单点瓶颈。举个例子，假设一名TDE手上有10个外包测试员工，分别测出了10个问题，这10个问题对应着8个开发，那这8个开发人员修复完问题后，跟外包测试员工串讲并不算数，必须排队给这名TDE串讲，从而形成了单点瓶颈。
测试TDE忙得找不着北，脾气自然也不会太好。开发更是一点也不敢得罪测试，如果TDE不爽你，别的不说，就单单在串讲里给你挑刺、或者把你的串讲排到最后，都会大大拖慢你的工作进度和工作热情。
七、代码检视
代码检视，也就是Code Review。每个开发写好代码后，都必须发代码检视才能合入主干分支。
在其它公司，开发一般会找对这个领域比较熟悉的两个开发进行检视，得到两个Approve以后，就顺手合入了。
在华为，代码合入理论上需要以下步骤：
- 选择两个开发检视
- 检视通过后选择一个Committer审核
- 审核通过后，选择具有合入权限的人合入。
一般Committer是在一个团队里的资深员工，技术比较强，并且做事仔细认真。
在其它公司，代码合入步骤简化为：
- 选择一个开发检视
- 检视通过后找一个Commiter检视并审核再合入。
Committer的数量是很少的，大概占20%左右。100个人要合入代码，都得找这20个人进行代码审核。这部分人基本已经是DE(Design Engineer)，主要承担方案设计、困难问题攻关等任务，同时还要帮大量的同事检视代码。所以他们大多也会忙到找不到北。
这些Committer一方面承担着方案设计等项目上对自己未来有利的工作，另一方面检视所有人的代码，有任何问题会得到耐心的解释（不解释清楚就不会给你审核通过），所以他们的进步会很快。而新员工大多只是执行者，对整体规划、背景原理等都搞不清楚，他们想让Committer耐心解释是不可能的，只有在审核代码的时候，能学到点东西，但也是零零碎碎的。
这样以来，新员工和老员工(Committer)的差距就拉开了。最终导致的结果就是知识断层，新员工很容易流失，因为他们只能在繁琐的工作之余进行自学，老员工没时间教他们；同时他们得到的激励也相对较少，除非拼死拼活爬到Commiter这个位置，否则未来的发展一片渺茫。
八、功能开发
一个需求过来，需要评估完成的时间。但这只是一个参考，每一级都会想办法把时间往短了压。导致最后到开发者这一层，几乎是不可能完成的任务。
举个例子，一个任务，参与设计的开发和测试预估12+4天，版本给的要求是10+3天，但当这个任务真正给到参与实现的开发和测试时，可能只剩下6+1.5天。
中间的时间到哪儿去了？从上到下，每一层领导都担心任务完不成，所以想预留一点缓冲。所以时间从10+3天传达到下层变成8+2.5天，逐渐往下最终变成6+1.5天。所以，功能的开发极其紧迫，你想在规定的时间里完成几乎是不可能的。
一开始，会因为完不成任务非常焦虑。后来发现大家都完不成，目标放在那儿成了摆设，虽然目标时间快到了就开始催，但实际上做不完也不会怎么样。不过，催你的人心里是有底线的，这个底线就是他的上级给他的要求，只是这个底线他永远不会告诉你。
九、出征海外
出征海外，一般是指上一线去海外销售华为产品，可以选择的驻扎地很多，几乎全球都可以。但是选择欧洲那些条件好的国家，补贴很少，选择非州那些条件不好的国家，补贴很给力。
每年需要出征海外的人数是有指标的，几乎每个团队都要出人。除了极少数愿意舍家弃子去海外打拼的小伙伴，绝大多数人是不愿意去的。所以，要求你去海外，和逼你离职差不多，基本成了淘汰人的方式。
华为也有经验比较丰富的员工，被要求出征海外。他们虽然没有Committer这么拼，但五年左右的时间也让他们积累了很多知识，也算是骨干员工。无奈的是，由于这个硬性规定，不得不选择离开开发岗位。
这些工作五年左右的员工，对他工作过的模块应该是很熟悉了。好不容易达到了这样的水平，也适应了华为的工作强度。正好应该是他们发光发热的最佳时期，但华为却让他们出征海外，重新招新员工进来再经历一次痛苦的学习和适应过程。
实际上，这些开发者的知识对海外销售而言起不到多大作用：你掌握了产品中你们组负责的某个模块，里面包含数百个结构体和数千个字段，你能理解每个字段的含义和设计它们的原因。所以呢？那又怎么样？在销售的时候，客户对此是不感兴趣的。客户感兴趣的内容，还是需要像新人一样参加销售培训，那为什么不直接让新人去做销售呢？
