Addressing some general misunderstandings regarding an electrical engineer’s role today
One of the first things we need to acknowledge is the fact that there are a variety of engineers out there and the nature of the work largely depends on the industry that they work in and the type of product. In this case, I am mostly going to cover electrical engineering (EE) as that’s my field.
The general perception of what an engineer does on a day-to-day basis stems from visuals decades in the past. In the case of EE specifically, one common misconception is that they work in dingy labs playing with equipment and wires.
It’s hilarious to hear family, friends and even random people paint a grim picture of an engineering environment and a lot of that probably has to do with many engineers not being involved with commercial or highly marketed products.
I am an EE myself and work for a sizeable semiconductor company with most products being sold in a B2B manner. We design, test and manufacture complex ICs (integrated circuits) or chips for various applications. My organization in particular works on chips used in wireless communications with a focus on LTE/5G applications.
Now compare that to a software engineer who works at Google. The environment in which the Google employee is working would appear far more rosy. However, it really depends on the type work.
Furthermore, all engineers do not handle hardware. In fact, most engineers nowadays are heavy software users, whether it be virtual machines, graphic user interfaces (GUIs) or coding software such as C# or Python. We will dig deeper into this point later on.
Another notion that I keep hearing is that engineers are anti-social and lack communication skills. This might be true for a fraction of the population but one needs to be a strong communicator to be truly successful in this field.
In order to understand this point further, it’s important to understand what the “engineering field” entails.
Provided my experience in this domain, I am here to debunk certain myths related to engineering (mostly EE). Below, we delve into some key misconceptions regarding the field and what the realities are today.
Most engineers are coders
Nowadays as an engineer, it’s hard to get by without having some sort of programming experience. It doesn’t matter what programming language it is, it’s crucial to be familiar with basic programming concepts so that one can pick up other languages without too much trouble.
My preferred language is Python but I often need to read through C code in order to understand algorithms written by our software/firmware team so that I can access these algorithms using APIs in Python. I don’t necessarily write C code but my programming knowledge helps immensely to grasp the logic beneath the code.
Around 75% of my technical work entails coding, out of which 50% is used for test automation and debug while the other 50% is used for data analysis. The most common programming language I use is Python, for both testing and data analysis.
Don’t get me wrong, we do work with a lot of testing equipment and automation hardware but all of the hardware can nowadays be controlled via software in the form of GUIs or C#/Python/LabView code. Secondly, we can do most of the work remotely by logging into virtual machines. The pandemic has only accelerated the adoption of such methods which have now become a commonplace.
Most of the physical hardware are maintained by technicians and generally require very less tampering. Yes, we do need to have knowledge of the hardware but we don’t necessarily always need to manually turn knobs or wire things.
We rarely solder or work hands-on with assembly components
Only during urgent times, we might replace passive components such as capacitors or resistors ourselves but 95% of the time there are dedicated soldering/assembly experts who are entrusted with this responsibility. Handing the job over to these experts ensures that the assembly is clean and quick.
The people in-charge of soldering have surgical precision which is crucial due to the varying sizes of the components, some not even visible to the naked eye without a microscope.
Yes, there are engineers who have exceptional soldering skills but most of the time you can get away with little to no knowledge of soldering. Furthermore, automated soldering is becoming common especially for large-scale assemblies and batch orders, which makes the need to know soldering even less.
Most engineers do not work in factories
Typically, engineers work in regular office settings, even the ones who deal with hardware. That is because most of the key engineering disciplines such as design, test, applications, characterization and marketing don’t require regular interactions with the hardware itself.
For example, test and characterization teams mostly deal with software and are essentially developers/coders. Designers, on the other hand, use industry-standard software for running simulations with even less interaction with equipment.
The exception to this rule would be engineers who work in quality or manufacturing or production where the nature of the work requires one to drive equipment manually or monitor them. However, most if not all production testing and manufacturing is done through automation with minimal human interaction.
Today, we have millions of ICs being fabricated, packaged and tested every quarter allowing companies to scale their operations and revenue as a result. There are technicians/operators for both handling and maintaining the equipment. An e-commerce equivalent of this environment could be Amazon’s fulfillment warehouses which is filled with automated robots and a handful of employees for supervision.
Now that we have discussed some automation, that’s a helpful segue into the next point.
Most tasks can be automated or performed remotely
As already mentioned, almost all of production and manufacturing is automated today.
Furthermore, every single equipment used in an engineering lab can be automated and used virtually by creating a USB/ethernet/GPIB interface to the computer. There are several options to control the exchange of information across this interface using ready-made GUIs by the equipment vendors or through general-purpose programming languages such as Python or C#.
Establishing a connection between the hardware and the computer serves two key purposes:
- Virtual/remote access: One can now access the hardware from anywhere with internet connection
- Automation and scaling: Since the hardware can be access through code, it can be incorporated into the testing plan and scaled/automated without human intervention. We often leave tests running overnight and the data would be ready for review in the morning.
A good portion of the work is non-technical
Engineers do not simply spend the entire workday looking at schematics or running experiments. More than 50% of the day-to-day work is spent in the following:
- Data collection, data infrastructure and analysis
- Communication including emails, instant messaging, phone calls, virtual meetings etc.
- Documentation whether it be on Powerpoint, Excel, JIRA, Confluence, Github/Gitlab/Bitbucket etc.
- Planning/scheduling meetings and usage of testing platforms
- Mentoring, coaching and training
Hence, a substantial amount of general and soft skills come into play in an engineering role. This only increases as one moves up the hierarchy from junior engineer to senior engineer to manager to director and so on.
This also depends on the size of the company. Bigger companies are likely to require better documentation, communication and infrastructure as there are several layers to navigate, sometimes across various teams. For smaller companies, any documentation or data is easier to access due to fewer layers.
Engineers are essentially problem solvers
Be it business problems or technical problems, engineers are at the heart of it.
A part of my work involves something called “failure analysis” (root cause analysis) where we dig into issues customers are observing with a specific part or a large sample of parts. The complexity of the issue could range from trivial to significant where engineers from various disciplines would need to collaborate as a scrum team.
Certain issues could be highly ambiguous in nature where a customer might want answers to difficult questions. One such situation arose when one of our tier 1 customers asked us to provide them with the true failure rate as well as the worst case value for a certain specification for our part. They wanted this information to gauge what the exposure for a certain known issue was for parts they had already deployed in the “field” or cell towers.
Note: We had recently release a test in production which could screen for a certain spec. However, the customer was concerned about their large quantity of parts that were already deployed which hadn’t been tested with the screen.
Both the aforementioned questions required the collection and analysis of a large sample size of data for us to make a proper estimation. However, the methodology to arrive at these metrics required was different. Here they are:
- True failure rate: Get back parts from production that fail the metric of interest that was being tested with the new screen. Note the initial sample size of the productions lots. Test the returned parts using customer settings to see if they fail or not. The parts that still fail are the true positives while the others are false positives. The true positives provide the actual failure rate when divided by the original sample size.
- Worst case value: Pick out parts from a large sample size that may have shipped to the customer but ones that do not fail the new test screen. Re-test these parts using the appropriate settings and determine the worst failing value.
Other issues might require more creative debug strategies and resolutions. In our case, the three most common types of resolutions to a customer issue are:
- Test screen coverage
- SW change on the customer platform
- Chip design change
Out of the above three, design change is the costliest in terms of money, time and effort, and therefore is the least desirable outcome from our company’s perspective. The second best option is a SW change, however customers sometimes are reluctant to adopt this resolution as they would need to roll it out across a large number of parts which might be costly for them. Hence, the ideal solution for both parties is a test screen.
On the other hand, if a certain issue is highly critical with a high failure rate, the best solution might be a design change regardless of the cost. Hence, depending on the criticality of the issue, we pick the appropriate resolution.
Most engineers are good communicators
It’s impossible to succeed as an engineer without having decent communication skills. An important aspect of the work involves collaborating with various groups, presenting key findings, leading projects and providing recommendations to stakeholders.
Yes, the work might be more task-oriented early on in one’s career but as one’s seniority level increases, the responsibilities also increase along with the visibility, making it imperative to develop good communication skills.
A big part of my work as a senior member of the team is to convince people to adopt a certain solution, in other words negotiation. This is one of the most underrated soft skills in my opinion and requires strong communication skills.
Another part of my work is to strike a balance between technical detail and high-level summaries, especially when working on customer issues. As part of the product/test team, my first level of contact is with our marketing and quality teams, who serve as buffers between the more technical engineers (such as myself) and the customer.
These three internal teams work together to convert the jargon-heavy results into concise and clear verbiage to the customer with minimal details. We sometimes call this “wordsmithing” and can be considered more of an art than a technical skill.
The best engineers know how to balance business and technical needs
There exists a tendency in engineering to get bogged down by details, which is in fact a stereotype that is justified. It is sometimes enticing to dig into the technical details of a problem and get lost in it without having the big picture in mind.
It basically comes down to a tradeoff between time, money and quality. If digging deep improves quality for the customer, then the additional time or money spent in doing so could be justified. However, if a viable solution can be found without having to spend a lot of time, that could prove to be a more favorable business decision.
We frequently encounter such issues at work. For example, a designer likes to find the exact circuit or transistor in the chip which could be the root cause of the problem. However, if a high-level symptom of the problem can be reproduced easily, it could lead to a viable test screen which could lead to a quicker resolution for the customer.
Even when it comes down to a test solution, decisions need to be made with respect to quality, cost and revenue. Creating a stringent test condition could lead to good parts being rejected in production causing a greater yield hit. This is essentially the same as having false positives and can negatively affect the revenue.
On the other hand, if a solution incurs a high test time, that could increase the cost of testing significantly. Something as small as a 1sec increase in test time could lead to hundreds of thousands of dollars worth of increased cost over the course of a quarter due to the sheer volume of parts being tested in production.
Hence, there are several underlying business and financial considerations that come into play as part of the technical work.
Most engineers are well-rounded individuals
We don’t just spend time working in labs or discussing nerdy topics. In fact, I detest nerdy jokes, especially ones directly related to work.
A lot of my colleagues are well-rounded and have a plethora of hobbies such as:
- Hiking
- Playing musical instruments
- Investing
- Cycling
- Fishing
- Flying (yes, a plane)
- Travelling
- Going to concerts
- Gaming
- Going to bars/restaurants
- Streaming movies/shows/documentaries
Some even have unusually unique skills. One person is a certified diver, another is a car expert and was the go-to person for diagnosing car issues, while another person is in the process of getting a real-estate broker’s license. We also had a certified yoga instructor and a life-guard.
You get my point.
Conclusion
As evident from the points above, engineers tend to adopt various roles depending on the company and industry. One cannot simply be good at circuit design or communication. There has to be a balance across various skills.
A designer who is not good at explaining their simulations to others such as test engineers or less technical folk such as managers, will not be able to get their message through and as a result will not converge to the best solution when solving a problem.
The case is the same for technical skills such as programming or data analysis. One needs to be comfortable with these skills along with more traditional engineering skills such as circuit design or lab testing. As we move rapidly towards a digitized world, aspects such as automation and virtual machines are going to become more common and therefore key to improving the efficiency of work.
Having said that, most successful engineers encompass the above key characteristics and tend to adopt these important skills. I would encourage people to talk to their engineering friends and family members to discover what they do on a day-to-day basis and to learn about their experiences. Being an engineer myself, I personally love to learn about other professions and get into the details.
Hopefully, I was able to shed some light on the realities of the engineering world with a focus on EE. I would love to hear what other engineers think about these points. I would also love to know what different perceptions other professionals had and if they may have changed after reading this post. Take care!
