Recently, I interviewed tens of thousands of candidates for core programmer positions. These candidates come from big, good, well-known chip companies or embedded operating systems/systems companies. Many of them claim that they have at least 10 years of kernel experience. Their resumes look pretty good-various new projects and various awards and awards ...... but most of them cannot answer a very basic question: what happens in the kernel when we call the standard malloc function? Don't be surprised. When I asked a candidate to write a simple LRU cache framework based on the glib hash function, he first claimed that, he never used glib-this is what I expected-I showed him the API page of the glib function and explained it to him in detail. Nearly an hour later, he only wrote a few lines of messy code. I don't know if the situation in other countries is similar, but in China or, more specifically, in Beijing, this is a reality. "Advanced" programmers who have worked for well-known foreign companies cannot prove them on simple basic issues.
Why is this happening?
The more I think about it, the more I believe not only themselves, but also the company they work. These companies usually provide stable protocol stack Code, some of which have not changed significantly over the years. The technology wrapped around this code allows them to simply follow the existing path rather than work creatively. If you have been working for this type of code for a long time and haven't reached the level of the outside world, one day you will find yourself in a poor position-inside the company or project team, they call you an "expert", but unfortunately it is hard for you to find a suitable job in the market. This is the so-called "expert trap ". From the first day, our programmers dream of becoming experts within the team/company. However, when this day comes, we are in trouble. The deeper we get into the existing code, the deeper we get. Because the existing code is so stable, we gradually lose the ability to write code from the beginning to the complete project. What's worse, if our main task is to maintain the existing Code and some special development, no matter how much code we have read or studied after a while, we will find that we cannot write code.
-Even as a simple graduate school assignment problem. This is a programmer's dilemma: we rely on code to support ourselves, but large companies that support us tend to destroy our ability to make a living.
How can we get rid of this dilemma?
For individuals-first, create your own personal project. You need to always "keep your saw sharp ". If the work itself cannot help you do this, pick up the problems you want to overcome and conquer in your personal time. By doing so, you are most likely to learn new things. If you publish your personal project on GitHub, you may get a chance to know people who may keep you away from your current location. Do not stay in a project group for more than two years. Force yourself to flow, even in the same organization, the same company, you will face new challenges and new technologies. Try an interview every 18 months. You don't need to change your job, but you can see what the market needs and how you integrate. Team/company-puts pressure on employees and challenges. Cyclic work gives "experts" the opportunity to broaden their skills. Use battles to train warriors. Hold hackers' marathon on a regular basis. This will help build a culture that embraces innovation and creation. People will be inspired by their peers-"Oh, I have to work hard to write such a beautiful framework within 24 hours ".
From: https://medium.com/i-m-h-o/231d7499a75
