After interviewing many candidates, I began to ponder the differences between embedded engineers with 1, 3, 5, and 10 years of experience, and what their years of work have brought them.
Sometimes, employers are not clear about the implications of the 10 years of work experience they require. After interviewing many job seekers, I found that many engineers with extensive experience have not developed their own structured thinking and technical systems.
What are the differences among engineers with varying years of experience?
Fundamental Knowledge
An embedded engineer often starts with 51 microcontrollers or STM32 microcontrollers, understanding the development environment, development process, and basic peripherals, having worked on practical cases such as blinking LEDs. They should be able to explain basic concepts like interrupts, registers, watchdog timers, and ADC principles. They should master hardware design methods, be able to design schematics and PCBs, at least for two-layer boards. They should be able to draw circuits using transistors and MOSFETs as switching devices and have a basic understanding of power chip design. They should be able to use the internet for information retrieval and copy designs based on understanding others’ schematics.
This is the level that a bachelor’s degree graduate in embedded systems should possess. Students who have worked on many projects may have deeper research in certain specialized areas and broader exposure, such as understanding basic sensors, encoders, and actuators. For example, graduate students may use MATLAB for algorithm simulation, while those in control may use microcontrollers to call FOC libraries to control PMSM motors, and those in image processing may use OpenCV for image processing tasks.
If they have experience contributing to international open-source communities, that is a significant plus. At least they should be proficient in English and Git.
Project Mindset
Engineers who have completed full projects understand that during project advancement, they will experience various mindsets, sometimes leading to frustration, and may often feel like giving up. However, once they experience the feeling of persistence leading to results, they realize that nothing is impossible.Project:Organizing microcontroller learning methods and product development processes.In fact, during the project validation phase, higher-level engineers have already conducted evaluations. The project mindset is essentially the tenacity of technical personnel; there are no insurmountable problems, and no projects that cannot be completed. Generally, engineers with around three years of experience should have gone through complete projects. Many engineers may spend their first year catching up on university courses, so three years is a safer estimate. Engineers with three years of experience may not yet possess a global or architectural perspective, but they should have a good project mindset.
Moreover, engineers with around three years of experience, supported by a tenacious mindset, should be searching various forums and posts for solutions to problems and should have developed the ability to solve problems independently. Regarding project experience,there is an article:Why Have I Studied Microcontrollers for So Long but Still Can’t Complete Projects?
Technical Architecture
What is technical architecture? After working on many projects and encountering larger projects, one realizes that all projects have commonalities; all embedded devices are essentially the same. Therefore, accumulating a stable set of foundational libraries and architectures becomes very important. For example, serial protocol encoding and decoding, logging systems, filtering algorithms, operating systems, GUIs, button I/O, timer libraries, etc.
I generally do not advocate reinventing the wheel because there are too many smart people in the world. A quick search on GitHub can help find suitable foundational libraries for integration and modification. After reviewing others’ work, one may realize that their technical thinking is sometimes quite basic.
For instance, buttons are often considered very simple, but when dealing with one button, multiple buttons, single clicks, double clicks, triple clicks, long presses, and short presses, if you write according to your logic, 90% of people will write it very clumsily. Therefore, you should be aware of the following library.
For example, circular buffers; when I first started working, I was impressed by a colleague’s implementation of a serial circular buffer program.
There are many such examples, so sometimes, having a broad technical vision is much more effective than being overly focused on hard work. By standing on the shoulders of giants, one can discover bugs, make modifications, and improve, gradually becoming more robust. At the same time, one will develop a more humble attitude.
For technical architecture, I recommend exploring and referencing some classic open-source hardware projects.
Technical Vision
Technical vision comes from several aspects:
-
One is having worked on enough projects and encountered a variety of things.
-
Having sufficient curiosity about technology and wanting to understand how the underlying systems operate.
-
Diligence (sometimes stemming from passion, without needing to be forced).
Engaging with open-source hardware is an excellent way to expand technical vision, and it is best to participate actively if interested. For example, with PX4, I still have not fully grasped the entire architecture, which involves a lot of knowledge, including Linux, GCC, CMake, Docker, Python parsing, Nuxt systems (similar to Linux, POSIX interfaces), Git, MAVLink protocols, various algorithms and papers, simulation methods, compilation, and downloading. However, this is a very interesting process. When I return to working with microcontrollers, I will understand what it takes for a microcontroller to operate a large and complex project.
Mature Solutions
A mature solution is the result of having completed many projects, which are stable and marketable. Based on the aforementioned foundations, the projects you have worked on should be stable in both hardware and software and should be marketable. These are solutions that you can use without wasting a development cycle.
For example, the motor drive solutions or printer solutions you have developed. At this point, essentially, you could start a solutions company. At least technically, you are capable. But what else is missing?
Interconnected Knowledge
At this point, you seem to have a way to quickly and effectively handle any project you encounter because your perspective on new cases differs from that of a novice; it is merely a variation of the architecture you have accumulated. Either the actuators change, or the sensors change.
Selection Ability
As mentioned earlier, if you want to start a solutions company, you still lack something; what you lack is selection ability. Just because you can technically implement something does not mean it is marketable. Marketability involves comparing with peers, whether you demonstrate cost advantages, technological leadership, or solve unique problems. Cost issues involve your accumulated supplier resources and your ability to search for and communicate with suppliers.
The author once reduced costs for a consumer electronics product, and three to six months later, the entire industry switched to the solution I designed.
Other Abilities
If we need to assess other abilities, it would be character and integrity, as cost reduction can sometimes be a sensitive issue, meaning you may disrupt a delicate balance within the company, facing significant resistance, often making you feel unappreciated. If you have any doubts or hesitations, you will compromise. Therefore, the upper levels of technology involve more complex matters. At this point, perseverance relies on values; you firmly believe that you are providing greater benefits to consumers, and your technical vision and project advancement capabilities create ultimate value.
Beware of the Comfort Trap
Many people who have worked for ten years remain at the foundational level or even regress. In companies that focus on system integration, they may only need to work on serial protocol parsing and forwarding daily. When switching products, they still do the same thing, and once a program matures, there are no significant changes; at most, different users require different functionalities, leading to minor additions or deletions to the protocol. Such companies are often large, and gradually, engineers doing this work may become somewhat obsolete. Similarly, those who constantly adjust PID parameters and switch systems may find themselves in the same situation. Therefore, many companies require experience in taking a product from zero to one.
In this trap, it may seem comfortable, but it is also dangerous, as it is easy to be challenged by younger individuals who are more energetic and work harder. For an engineer’s crisis, you can refer to this article:Why Do Workers with Ten Years of Experience Get Laid Off?
As a technical person, continuously tackling technical challenges and updating knowledge may be the right state to maintain long-term market competitiveness.