Contents
1. Probation period and overtime pay
2. Recruitment
3. Monthly defense and regular defense
4. Credible examination certification
5. Interface person
6. Problem and defect list
7. Code review
8. Functional development
9. Going overseas
1. Probation period and overtime pay
The probation period generally lasts 3-6 months, and wages and bonuses are calculated according to the standards of regular employees. The only difference is: employees in the probation period cannot transfer overtime work on weekends, which is equivalent to working overtime in vain. Therefore, PL (Program Leader) will not ask probationary employees to work overtime on weekends unless they are at their busiest. If they have to work overtime, they will be given time off by going out on business.
If you work overtime on both weekends, you will get double pay for 4 days, which is equivalent to an 80% increase in basic salary, which is close to doubling. Of course, this kind of continuous overtime work on weekends is also very energy-consuming. No matter how strong your body is or how young you are, you have to admit in the end: your life is at stake. Nowadays, weekend overtime work is still calculated as double wages, but it will not be paid next month. Instead, it will be accumulated for you. It will not be paid to you uniformly until you change your job number or resign once every eight years. In addition, overtime work on weekends also requires approval from the supervisor and is no longer directly calculated based on punch-in time.
2. Recruitment:
When I first graduated, I heard that Huawei would recruit students as long as they were 985/211 students and passed the programming test. It almost didn’t depend on your personal experience. Huawei will establish a complete set of systems and processes based on distrust of employees to allow employees to do their jobs well. People who can't bear the pressure will be eliminated, but those who can withstand the pressure and follow the system and procedures can survive. On this basis, people with particularly high IQ and emotional intelligence will get money.
At Huawei, non-HR employees also have to participate in recruitment, which has almost become a must for them in their careers at Huawei. Based on the existing talent pool, they will call one by one to ask about their willingness to work, and guide them to do interview questions, online programming and participate in one-on-one interviews with interviewers.
The stored recruitment budget is not enough, so recruitment generally tends to recruit OD/WX employees. The employee ID of OD starts with 300, and the ID of WX starts with WX. Both of these employees are not considered as regular employees of Huawei. Among them, OD employees are relatively better and are mainly engaged in development work. Employees starting with WX can basically only do testing work. They follow the test documents step by step and check whether they meet expectations. The vast majority of WX employees don't know why they do this and what the expected results mean, because they are not qualified. Participating in the design and discussion of the solution, no TDE (Test Design Engineer, a Huawei employee responsible for designing test cases) was willing to explain it to them.
Due to the large turnover of outsourced personnel, the task of recruitment is very heavy. At the same time, they tend to recruit OD/WX employees, so recruitment will be very difficult. To sum up: capable people look down on OD/WX, and incompetent people cannot pass online programming and other assessments.
3. Monthly defense and full-time defense
During the probation period, there will be a monthly defense every month. You will need to make a PPT to describe in detail what you have done and learned during this month, and answer the judges' questions on the spot. When you become a full-time employee, you need to prepare a defense defense and summarize the work during the entire probation period.
During the defense process, the judges will listen to you carefully and ask you some questions after thinking about it. This atmosphere is quite good. In fact, the defense does not play a particularly big role in performance, because everyone can see what you usually do and estimate its weight.
The biggest role of the defense is to prevent new employees from being lazy. When an employee enters the company, there will be a short window period before he is completely familiar with the process and becomes a busy screw. At this stage, since you don’t know anything, no one will come to you, and no one can assign tasks to you. At this time, if you know that you need to report on your work and learning progress every month, you will have enough motivation to integrate into the team as soon as possible. After completing the defense for becoming a full-time employee, you are basically a standard screw. At this time, you no longer need to defend. You can just be motivated through performance appraisal.
4. Trusted examination certification
For development, everyone needs to pass the trusted examination. The credibility exam is divided into professional level and working level. There are four courses and four exams in total. It is often easier for new employees to pass because they have more time; while old employees have no time to study and almost all take the exam naked, except Subject 1 is online programming, and other subjects are theoretical knowledge, covering the scope of programming language syntax and techniques, programming language specifications, requirements analysis, safety red lines, design patterns, agile development, etc. These experiences are summarized into concise language and instilled into the brain of every employee through the idea of promoting training through examination.
5. Interface person
It actually takes almost two months from the time of joining the company to the departure of the mentor. The most important task is to pass the trusted certification exam. After two months, I started to take over some simple tasks, modify the issue ticket or undertake some simple function development. But in some departments, you will often be given a terrifying task at this time - the interface person.
Generally speaking, a product will be divided into multiple modules, and each team maintains multiple modules. When the test finds that a module belonging to a certain group has a problem, or that the parts of other modules that depend on this module are not working properly, they need someone to help find out the cause. This person is called the interface person.
There are about 10 people in a team, and the amount of module code they are responsible for ranges from tens to millions of lines. At first glance, you may think that an experienced employee should be selected as the interface person, someone who has a clear understanding of the modules responsible for the group, historical situations, etc. But in fact, helping others see the problems and find the reasons is a thankless job, because the leaders cannot see it, and the colleagues around them cannot sense it.
In some companies, the supervisor is usually the interface person. He will conduct a simple analysis of the problem, and then select the appropriate person to analyze the problem based on the areas of expertise and load conditions of the team members. At Huawei, a similar position is PL. For the sake of performance, they cannot waste time on this every day. At the same time, everyone in the group is extremely busy, and the people most familiar with the field may be completing urgent tasks and have no time to analyze. Therefore, PL usually finds junior colleagues in the group to act as interfaces and rotate them according to a fixed period.
The amount of code maintained by a group is not small. Let new employees be interface people. It is called "exercise", but in fact it is to let them resist pressure. As the interface person, PL's requirement is not to disturb other people in the team as much as possible. All problems, unless they are truly bugs, cannot be submitted to the test. Such a request may seem simple, but for new employees, many times you don’t even understand what they mean when it comes to testing and consulting questions. In addition, there are various historical reasons and special circumstances in the design. Most of the new employees It's confusing. Want help from an experienced colleague? It's okay when the project is not too stressful, but when the project becomes tense and everyone is talking on the phone with headphones on, you may not see them free for several hours. And the test has requirements on your response time. Why don’t you give a clear explanation within one hour? Then take the bill of lading.
For example: You are analyzing the cause of problem A and reading completely unfamiliar code, and two other tests leave you messages to consult you about problems B and C. You briefly scanned questions B and C. They are not areas you are familiar with. It takes time to read the code and understand the design to know whether it is a problem, so you did not reply for the time being. Two minutes later, the two testers called you respectively. You were annoyed and didn't want to answer the phone, but they kept calling and told you in their messages that they would place the order if you didn't answer the phone. You can only pick up the phone and try to persuade them, tell them they are really busy now, and you can only ask them to register first and wait in line for your message. Not long after, you read a part of the code logic in question A that you couldn’t understand, and you wanted to find someone to ask. When you looked up, everyone in the group was on the phone. So you grit your teeth and confirm the logic of the test case with A's tester, while ignoring some of the incomprehensible code to guess the subsequent logic. At this time, the tests of B and C tell you that you can't wait any longer. The superiors are urging you to ask for the bill of lading. You can only temporarily put down the code and explain again, give them a reasonable deadline and ask them to accept it. Suddenly the phone rings again. It's a conference call. The problem is very serious. Four or five developers online are discussing it together. They need your confirmation. TDE urges you to take a look quickly. If you can't figure it out, just push it up. You quickly put down question A, and while reading the phenomenon of question D, answer these development questions based on your understanding. Question D is not very difficult, but it involves a lot of conditions and variables, and the logic is very convoluted. You have to figure it out. While you are doing it, the TDE from the A test angrily left you a message: I have been watching it for two hours. Why hasn't it come out yet? A bill of lading is necessary.
If you really can't figure it out and the test can't wait for a bill of lading, you usually have to talk to the PL. But as a new employee, you have to be mentally prepared, because you will inevitably get scolded at this time. Because PL is always extremely busy. He has plans to discuss, designs to do, and a lot of chores within the group. He is already overwhelmed. Not only can you not help him share the burden, but you also tell him that he does not understand an existing problem. He was also very broken. But the scolding is often worth it, because PL will quickly point you in the direction, because if the positioning is off, he will quickly correct your direction.
6. Problem and Defect Order
The "bill of lading" mentioned many times just now refers to the problem order. The questions asked in the test generally indicate that there is a bug in the function of a certain module.
For tracking problem orders, Huawei has a system called DTS to test the bill of lading. The development and resolution process is roughly as follows:
The test outsourcing employee creates a problem ticket in the DTS system and fills in the product, version, problem description and other information.
The problem sheet is submitted to the test TDE (a Huawei official employee) responsible for this module for review.
The test TDE forwards the problem ticket to the PL in the group responsible for the development of the module.
The PL within the group then forwards the problem to the development team that needs to solve the problem.
Development solves the problem, submits the code, fills in the root cause analysis and forwards the problem ticket to the PL within the group.
At the same time, development needs to make an appointment with the test TDE, and communicate with the test TDE the cause of the problem ticket and the impact of the modification.
After the PL discussion within the group is completed and the latest Build contains the developed Commit ID, the issue ticket will be forwarded to the test TDE.
The test TDE forwards the problem ticket to the test outsourcing employee for verification.
After following such a set of procedures, I feel like I have shed layers of my skin. For the superior leader, he does not need to know the details, he only needs to ask for the target number of problem tickets for a group. For example, today the entire group has 40 question tickets left, tomorrow the request is 35, and the day after tomorrow is 30...
Therefore, in order to achieve the goal, PL was very disgusted with the problem sheet coming to the head of his group. Some problem tickets involve coordination between modules. When testing the bill of lading, the problem was found in module A. However, after research on module A, it was found that the actual problem lies in module B, which module A depends on. Module B is managed by another group. Maintenance, so communicate with the interface person of module B. In this case, even if it is basically determined to be a problem with module B, the PL and interface people of module B will try every means to delay the time when the problem ticket is sent to module B. They will only agree to the problem after locating the root cause of the problem and modifying the plan. Walk to module B. After all, where is the target of the daily problem sheet, and one more one on my head is a heavy burden! At this time, the PL of module A definitely doesn’t want the problem to be in his own group, so now it’s up to the PK between the two PLs. As PLs, they have been working at Huawei for at least several years, and everyone has feelings like comrades. Understand each other, leave it to you this time, leave it to me next time, and don’t tear each other apart.
In this process, the step that developers dislike the most is test talk. The original intention of this design is good: you are worried that the impact of your changes will not be tested clearly, so that you cannot test the affected scenarios. But unfortunately, this regulation is too rigid, and most cross-talk is meaningless. You only need to test to reproduce the original scene and check whether the problem is solved.
The design of the problem ticket is so complicated, it still shows distrust of employees. At other companies, the process is much simpler:
Create a test ticket and fill in the product, version, problem description and other information.
Issue tickets are sent to developers who need to solve the problem.
Development solves the problem, submits the code, fills in the root cause analysis and scenarios that require key testing, and transfers the order back to testing for verification.
The simplification of steps requires high quality of employees. Take the cross-talk between problem sheets and tests as an example. Generally, developers feel that the impact of this change is relatively large. When they may need to focus on testing some scenarios, they will indicate it on the problem sheets; similarly, if the tester is aware of the developer's If the changes are risky, or if you don’t understand the developer’s root cause analysis, you will also take the initiative to communicate with the developer.
Huawei's process is complex, and its basic logic is: trust old employees like DE/TDE who have worked at Huawei for a long time, and new employees are not worthy of trust. The supporting incentives also tend to be PL/DE/TDE, which will make new employees feel frustrated, but it doesn't matter, because there will always be a group of people who can endure the frustration and are willing to follow the rules and keep working hard.
The complex process has led to a problem, which is that testing TDE is unimaginably busy. Because a test TDE is often responsible for multiple modules, that is, corresponding to multiple developers, when there are many problem tickets, it is easy to form a single point bottleneck. For example, assume that a TDE has 10 outsourced test employees and 10 problems are detected respectively. These 10 problems correspond to 8 developers. After these 8 developers fix the problems, they will contact the outsourced test employees. Cross-talk does not count, and the TDE must queue up for cross-talk, thus forming a single point bottleneck.
I was so busy testing TDE that I couldn't find anything to do, so my temper was naturally not very good. Developers don't dare to offend the testers at all. If TDE is dissatisfied with you, if it doesn't say anything else, it will only criticize you in the discussion, or put your discussion to the end, which will greatly slow down your work progress and enthusiasm.
7. Code review
Code review, also known as Code Review. After each developer writes the code, he must send the code for review before merging it into the main branch.
In other companies, developers usually look for two developers who are more familiar with this field to review. After getting two Approves, they merge easily.
At Huawei, code integration theoretically requires the following steps:
Select two development
views. After the review is passed, select a Committer for
review. After the review is passed, select a person with merge permissions to merge.
Generally, a committer is a senior employee in a team, has strong skills, and works carefully and conscientiously.
At other companies, the code integration steps are simplified to:
Select a development review
. After the review is passed, find a Commiter to review and review before merging.
The number of Committers is very small, accounting for about 20%. If 100 people want to integrate into the code, they have to find these 20 people for code review. These people are basically DE (Design Engineer), mainly responsible for tasks such as program design and solving difficult problems. At the same time, they also help a large number of colleagues review the code. So most of them are too busy to find Bei.
On the one hand, these Committers are responsible for work that is beneficial to their future on projects such as solution design. On the other hand, they review everyone's code. If there are any problems, they will be patiently explained (if you don't explain clearly, you will not be approved), so they The progress will be rapid. Most of the new employees are just executors and have no idea about the overall plan, background principles, etc. It is impossible for them to ask the Committer to explain patiently. They can only learn something when reviewing the code, but it is also piecemeal. of.
Since then, the gap between new employees and old employees (Committers) has widened. The final result is a gap in knowledge. New employees are easily lost because they can only study on their own after tedious work. Old employees have no time to teach them; at the same time, they receive relatively little incentives unless they work hard to climb to the position of Commiter. location, otherwise future development will be slim.
8. Functional Development
When a requirement comes in, the time for completion needs to be evaluated. But this is just a reference. Every level will find ways to shorten the time. As a result, it is almost an impossible task to reach the developer level.
For example, for a task, the development and testing involved in the design are estimated to take 12+4 days, and the version requirement is 10+3 days. However, when the task is actually given to the development and testing involved in the implementation, there may only be 6 days left. +1.5 days.
Where did the time in between go? From top to bottom, leaders at every level are worried about not completing their tasks, so they want to reserve a little buffer. So the time passes from 10+3 days to the lower level to 8+2.5 days, and gradually downwards to 6+1.5 days. Therefore, the development of functions is extremely urgent, and it is almost impossible to complete it within the specified time.
At the beginning, I will be very anxious because I can't complete the task. Later, I found that no one could complete it, and the goal was placed there as a decoration. Although I started to rush the goal when the time was approaching, in fact, it didn't matter if I couldn't finish it. However, the person who urges you has a bottom line in his heart. This bottom line is the request given to him by his superiors, but he will never tell you this bottom line.
9. Going overseas
. Going overseas generally refers to going to the front line to sell Huawei products overseas. There are many places to choose from, almost all over the world. But if you choose countries with good conditions in Europe, the subsidies are very small. If you choose countries in Africa with poor conditions, the subsidies are very powerful.
There is a quota for the number of people who need to go overseas every year, and almost every team needs to send someone. Except for a very small number of friends who are willing to abandon their families and children to work overseas, the vast majority of people are unwilling to go. Therefore, asking you to go overseas is similar to forcing you to resign. It is basically a way to eliminate people.
Huawei also has relatively experienced employees who are asked to go overseas. Although they are not as hardworking as Committers, they have accumulated a lot of knowledge in about five years and can be considered key employees. Unfortunately, due to this rigid rule, I had to choose to leave the development position.
These employees who have worked for about five years should be very familiar with the modules they have worked on. It took a lot of effort to reach this level and adapt to Huawei's work intensity. It should be the best time for them to shine, but Huawei asked them to go overseas and recruit new employees to go through the painful learning and adaptation process.
In fact, the knowledge of these developers is not very useful for overseas sales: you have mastered a certain module of the product that your group is responsible for, which contains hundreds of structures and thousands of fields. You can understand each What the fields mean and why they were designed. so what? so what? At the time of sale, the customer is not interested. For content that customers are interested in, you still need to participate in sales training like a newcomer, so why not just let the newcomer do sales?