Embedded software engineering, or firmware engineering, remains a mystifying branch of software for a lot of folks. Programming MCUs (microcontrollers) has always had a higher barrier to entry than mobile/web development, and it will likely stay that way despite the barrier being lowered by the growing popularity of MCU kits (e.g. MSP432, STM) and DIY boards (Arduino/BeagleBoard/Rasp Pi).
As a near-2-year-veteran (!) in embedded software with no embedded background, I wanted to leverage my experience to help others break into the wonderful world of embedded software/firmware engineering! Note this post is geared towards working professionals. Don’t panic students, I got a tailored post coming for y’all in a few weeks.
Move within your current company
If this is applicable, it is the easiest road and one that worked for me. Coming off of a 2-year-rotational program, I wanted to exit into software engineering. I found a firmware engineer opening for my current team, and fortunately got an offer. What helped me the most, despite my lack of experience in embedded (let alone professional software development outside of personal projects) was the fact that I was rated as a top performer (back when GE was still rating employees) in my last 2 projects under 2 different managers. This conveyed to the interviewers that:
- I wasn’t going to be a bad fit (GE is a huge company, but its culture is pretty uniform throughout)
- I can hit the ground running without a transition period to get setup and accustomed to GE’s operations
- I was a proven capable performer that was validated by 2 other GE managers
I’d like to think I killed the interview, but the points mentioned above gave me an advantage in eventually receiving an offer. It’s like the 2nd-degree-rule in dating; before Tinder existed, you often met your significant other through your friends because you (and that person in turn) have been validated as a decent human being by your friend. As a corollary, here’s a secret that one of my mentors in college let me in on — you can change 3 things at any point in your career: company, role, and industry. It’s relatively easy to change 1 of these, difficult to change 2, and near impossible and rarely good to change all 3. By staying at your company but moving to an embedded team, you’d only be changing 1 of these (2 if you’re coming from non-engineering) which is very doable.
But my company doesn’t have embedded teams…
Unfortunately, most companies don’t works on embedded software. Again, don’t panic. Keep calm and read along because getting an embedded job outside of your current company is very doable. Similar to getting a software engineering job as a non-techie, you should set a 3-6 month timeline for yourself to work on the below. As of now, there doesn’t exist an embedded-bootcamp to leap-frog your way into an embedded role. Over the next few months, focus on items below to land that embedded development job:
- Target companies of interest
- Go through Patrick’s Intro to Embedded playlist on YouTube
- Start (and finish) a small Arduino project
- For serious applicants only: Skim through Elecia’s Making Embedded Systems
Target companies of interest
Search LinkedIn & Glassdoor for jobs with keywords “embedded engineer” or “firmware engineer”. This should cover ~85% of embedded software engineer jobs for your city. Some companies list embedded roles as “software engineer/developer” but doing this search should give you an idea of which companies are hiring embedded engineers. Better yet, think of your favorite electronics/hardware and see if its company hires in your area. In my case, a list for Boston could be: GE, Sonos, Formlabs, Mathworks, iRobot, RSA, plus the myriad of MIT hardware startups that seemingly pop-up every other month.
Once you have a list of 10+ companies that have embedded roles available, reach out to engineers at these companies (great if they’re embedded, but anyone in engineering is ok) and ask about their work as well as any embedded work at the company. This is a good opportunity for you to see if the job interests you and possibly get a referral.
Patrick’s Intro to Embedded playlist on YouTube
This series was a godsend for me when I first started my current role as a firmware engineer at GE. I don’t know Patrick personally and you don’t either; he’s no Ph.D in CE from MIT or a principal engineer at Google but he is hands-down, the best teacher for embedded concepts on the web. He masterfully teaches the most fundamental topics that every embedded engineer should know. His series on AVR is to embedded systems what K&R is to C. Go through as much of the series as you can and take notes.
Every video is insightful and I really recommend getting an AVR and a basic electronics kit (or an Arduino kit since these come w/ basic sensors, breadboards, resistors/caps/transistors, and wires) and following his examples along. If you can’t afford to do so, the video series is still incredibly helpful and will give you a basic understanding of MCU programming and its lingo.
Start (and finish) an Arduino project
If you’ve already gone through Patrick’s videos, finishing an Arduino project would be icing on the cake for your resume and a serious weapon for your interviews. Finishing a personal Arduino project shows serious initiative and passion to companies you’ll interview with. Many engineers dismiss Arduino as not accurately portraying the rigors/constraints of real-world embedded development since Arduino software framework abstracts all driver-level code. This is hogwash; whether firmware engineers would like to admit it or not, the end is near for hand-crafted device or protocol drivers. As MCU power consumption and price continue to decrease while demand for out-of-the-box-programmability increase (due to increased pool of hobbyists wanting to get involved with embedded development), I think open-source drivers will soon be the norm and drastically reduce time spent by embedded engineers on hardware-level code.
All that to say, doing an Arduino project mimics enterprise embedded development similar to how building an iOS app on your own would mimic enterprise iOS development; it’s still incredibly helpful. Start small — go through the basic Arduino training projects and gradually combine features until you’re comfortable enough to pursue your own project. Here’s some inspiration — don’t get discouraged; these projects, like Rome, weren’t built in a day.
Reading Elecia’s Making Embedded Systems
This is extra-credit for the truly determined embedded-hopefuls. This book (and her podcast) was my primer as a new embedded engineer. It concisely covers the basics of what embedded development is about. If you’re new to embedded, thoroughly trying to understand every page of this book would be overkill. Read every word but don’t sweat the intricacies of the code/syntax. Understand the major concepts in each chapter, skim the boring/hard parts (likely they’re boring because you haven’t seen its applications in the real world; that’s ok), and look up stuff on Wikipedia if you get stuck.
I’ve blatantly excluded a most popular suggestion by embedded folks to others trying to enter the field — LEARN C. While C is still the lingua franca in embedded, the industry is slowly heading towards higher-level languages and model-based-programming. Of course you should have experience in at least one programming language: C, C++, Java, Python, Matlab, etc. But learning C isn’t a must-have-requirement. As many others expressed eloquently, a programming language is a tool. Not unlike other software roles, more important traits for a good entry-level embedded software engineer are an ability to understand/communicate/solve complex problems, passion, and an understanding of the embedded environment. Plus, what if you spent a majority of your time trying to master C but your dream company uses microPython? Studying C is never a waste of time. I think every developer should be familiar with C and low-level assembly. But if you already knew Python, you likely would have been a better off spending that time working on an Arduino project.
The last 1.5 years I’ve spent working as an embedded engineer have been incredibly exhilarating. It’s a great time to enter this amazing field. You still have to nail your interview though, but more to come on that later.