The Real Reason Embedded Engineering Jobs Are Disappearing
A critique of the "just upskill" narrative and an honest look at market contraction, structural barriers, and the shifting center of product development.
Shawn Hymel recently published a piece called “How to Get an Embedded Job When AI Is Taking Junior Programming Work.” I follow Shawn’s work and respect what he’s built in the embedded community. His article is well-researched, his data on declining entry-level postings is solid, and his practical advice (learn hardware, build complete systems, don’t rely entirely on AI) is genuinely useful. I’m not here to dismiss what he wrote.
I’m here to add what he left out.
The article frames the problem as a skills gap: AI is compressing junior programming tasks, so engineers need to move up the value chain toward system-level thinking. That’s not wrong, exactly. But it’s incomplete in ways that matter, especially for someone trying to figure out where they fit in this industry. I’ve spent my career in embedded software across aerospace, service companies doing embedded projects for other firms, and agritech, developing sensors and systems for agricultural and environmental applications. I started in assembly and worked my way up. What I’ve seen over the past three years is not just a skills shift, but a structural contraction, and it has causes that go well beyond AI.
What Shawn gets right
I want to be fair. Shawn’s article cites real data. Entry-level tech hiring dropped roughly 25 percent from 2023 to 2024. Compared to 2022, entry-level postings are down about 34 percent. Only around 15 to 18 percent of tech job postings are now truly entry-level. These numbers match what I’ve been seeing and hearing from colleagues.
His practical recommendations are also sound. Learning to code is still a baseline requirement. Understanding hardware, reading datasheets, and working with real physical constraints is what separates embedded engineers from pure software developers. Building complete end-to-end projects rather than isolated pieces demonstrates the kind of integrative thinking companies claim to want. And learning to work with AI as a collaborative tool rather than treating it as an oracle is sensible advice for anyone in the field.
His analogy to CNC machining is useful too. When CNC tools became widespread, the value of manually operating a mill declined, but the need for machinists didn’t disappear. It moved up a level, toward people who could design parts, program machines, and troubleshoot when things went wrong. Shawn argues that something similar is happening with programming and AI.
The problem is that this framing assumes the factory is still open and still hiring. It assumes there are jobs waiting for people who successfully make the shift. In many cases, there aren’t.
Markets that were never real
I worked in agritech, specifically in sensor and system development. I watched vertical farming companies raise enormous amounts of capital on promises of AI-optimized food production, fully automated growing environments, and sensor-driven precision agriculture. Then I watched them collapse (See: “Plenty’s AI Post-Mortem: What Went Wrong in the Vertical Farm?”). The embedded engineering work was real enough: we built real hardware, wrote real firmware, solved real integration problems. But the business proposition was built on wishful thinking, and when the economics failed, all the engineering jobs vanished regardless of how skilled anyone was.
IoT was similarly inflated. Predictions of a trillion connected devices generated years of hiring and investment. What actually materialized was far more modest, and many of the companies that hired embedded engineers to build connected sensor networks no longer exist. Those engineers didn’t become obsolete. Their employers did.
This is a speculative capital misallocation story, rather than an AI replacement story. Cheap money inflated embedded hiring in certain sectors, and the correction has been brutal. The skills haven’t lost their value. The businesses that funded those skills have disappeared or contracted severely.
I used to be contacted regularly by recruiters looking for embedded engineers. I wasn’t on the market, but the messages came anyway. That stopped. Many recruiters in this space have lost their jobs entirely. Service and consulting companies that handled embedded projects for other firms have gone under. When someone like Shawn talks about a 34 percent decline in entry-level postings, it’s easy to read that as “the bar is higher.” But the bar is higher within a pool that has also shrunk substantially. Those are two different problems, and the second one matters more.
The gates around what remains
Shawn’s article positions embedded systems as uniquely resilient because the work is tied to hardware and the physical world. He’s correct about the nature of the work. AI struggles with the messy realities of embedded development: reading logic analyzer traces, understanding why a bus is locking up, diagnosing signal integrity problems, reasoning about power sequencing. These are genuinely hard to automate.
But he doesn’t discuss who actually gets to do this work, and under what conditions.
Take defense aerospace. It’s one of the largest employers of embedded engineers in the United States. I’ve worked in it. Most positions require security clearance, which in practice means U.S. citizenship and a lengthy investigation process. The talent pool that can access these jobs is restricted by design. It circulates among a small number of prime contractors and their subcontractors. If you’re inside that pool, you’re relatively insulated from market fluctuations. If you’re outside it, you don’t exist to that industry, regardless of your technical ability or how many impressive projects are in your portfolio.
This doesn’t just affect individual engineers. It shapes the entire defense industrial base. A restricted talent pool that doesn’t refresh itself from the broader market becomes insular. The same people move between the same companies. There’s less cross-pollination from other industries, less pressure to adopt new tools and methods, and less exposure to how development is done elsewhere. The result is exactly what recent conflicts have exposed: a defense industry that is too expensive, too slow, and increasingly out of step with how effective systems are actually built.
Then there’s medical devices. The gates here are different but no less real. FDA regulations create a barrier of specialized knowledge: ISO 13485, IEC 62304, design controls, verification and validation processes that go far beyond what a competent embedded engineer from another industry would typically know. Companies prefer to hire people who already have this regulatory experience rather than invest in bridging someone from aerospace or agritech. The talent pool is small, concentrated geographically, and tends to circulate internally.
What this means in practice is that even the stable, well-funded sectors that Shawn points to as resilient can’t function as safety nets for the broader embedded engineering workforce. The jobs exist, but the gates are high and the capacity is limited. The engineer who spent five years building agricultural sensors or IoT devices can’t simply walk into defense or medical devices because they’ve built a strong portfolio. The structural barriers are real, and no amount of personal skill development removes them.
The elephant in the room
Shawn doesn’t discuss the competitive position of U.S. product development at all, and this is a significant omission. The United States used to be the center for new product development. It has gradually lost that position, and the shift has accelerated in recent years.
China’s embedded engineering and hardware development capabilities have advanced remarkably fast, and it’s not just about cost anymore. It’s about velocity. When PCB fabrication, component sourcing, assembly, and testing are all concentrated in the same region, the iteration cycle compresses dramatically. You can go from concept to prototype to production in a fraction of the time it takes when your supply chain spans continents. This speed of iteration isn’t just a manufacturing advantage. It’s an engineering development advantage. The people doing the work spend more time with actual hardware and less time waiting for boards, which means they accumulate the very kind of hardware-software integration experience that Shawn and I both agree is irreplaceable.
The U.S. still has strengths in certain high-reliability niches. But for the consumer electronics, industrial IoT, and general product development that used to generate volume embedded hiring, the center of gravity has shifted. This is a structural, long-term trend. It is not something individual engineers can upskill their way out of.
A note on other industries
Someone reading this might ask: what about automotive, industrial automation, consumer devices? These sectors do involve embedded engineering. But I’ve been on LinkedIn for a very long time, and even when the job market was good I rarely saw posts for embedded positions in these industries. Some startups surfaced now and then, but nothing consistent. I don’t know exactly why. It could be that much of the core R&D has already moved overseas. It could be that the work happens quietly inside a handful of large firms and is filled through internal pipelines rather than public postings. It could be that the embedded work exists but has been absorbed under other titles and buried inside larger teams.
I’m speculating. What I can say is that if the jobs aren’t visible, they functionally don’t exist for most people looking. Many younger engineers search for jobs online. They don’t have the networks to hear about unlisted positions or the industry connections to get referrals into closed hiring loops. When we talk about the health of the embedded job market, it matters whether the jobs are actually findable.
What recent wars have revealed
This is where I want to introduce something that gets almost no discussion in career advice articles.
The war in Ukraine and the conflicts involving Iran have demonstrated something uncomfortable about the U.S. defense model. The United States has spent decades building a system optimized for technological superiority through massive budgets and long development timelines: expensive aircraft, billion-dollar ships, satellite systems that take fifteen years to field. This model is being countered effectively by mass-produced, cheap, rapidly iterated systems that don’t try to match the high end but bypass it entirely.
Ukraine didn’t have a decades-long acquisition process. They had weeks. What emerged was a decentralized model of defense development: small teams adapting commercial drone platforms, writing firmware for custom flight controllers, integrating off-the-shelf sensors and munitions, fielding systems immediately, and iterating based on what worked or failed. The cycle was sometimes measured in days. This is embedded engineering at its most demanding: hardware-software integration under real-world constraints where failure has immediate consequences. And it worked.
Iran, operating under sanctions with limited access to advanced components, developed drone and missile systems that are relatively crude by Western standards but cheap, producible at scale, and strategically effective. The cost asymmetry is the point. A twenty-thousand-dollar drone that requires a two-million-dollar interceptor to destroy creates an unsolvable economic equation for the defender, no matter how sophisticated the interceptor.
The irony here is sharp. The world is demonstrating that the kind of embedded engineering Shawn describes (system-level thinking, hardware-software integration, practical debugging, rapid iteration) is strategically decisive. But the U.S. institutions that employ embedded engineers at scale are not structured to operate this way. They are structured for complexity, long timelines, and institutional process. The talent that could do this work exists. The gates keep it out, and even if the gates opened, the institutional model can’t effectively use it.
The entry-level contradiction
Shawn’s article assumes there is such a thing as an entry-level embedded engineer whose limited-scope work can now be done by AI, and who needs to upskill to remain relevant. I would argue this role was always somewhat mythical.
Real embedded engineering requires a synthesis of software and hardware understanding that only comes through experience. You can’t learn to debug a signal integrity problem or reason about interrupt priority inversion from a textbook. You learn it by building systems, watching them fail, and figuring out why. This takes time. There is no clean entry ramp, and there never really was. The “junior” engineers who were writing driver boilerplate and test cases were often not being systematically trained to become system-level engineers. They were performing a narrow function, and now that the function is increasingly automated, the pipeline was never going to fill the senior roles anyway.
Companies have also been contributing to the confusion by hiring software engineers straight out of school and giving them the title “embedded engineer” while their work has almost nothing to do with hardware. This is especially common in embedded Linux roles, where the OS and board support package abstract the hardware away, and what remains looks a lot like application programming. These engineers may be perfectly competent software developers, but when a real hardware problem appears, they’re lost. That doesn’t make them bad engineers. It makes them specialists in a layer that has drifted far from the physical world. But it also means the title “embedded engineer” now covers such a wide range of actual work that it’s almost meaningless as a signal to the labor market.
The same pattern shows up in adjacent fields. Robotics requires much of the same hardware-software integration that embedded engineering does, and new titles have appeared (autonomy engineer, mechatronics engineer, robotics software engineer) that suggest growth. But the underlying dynamic is the same. The visible jobs were concentrated at startups funded by the same cheap capital that inflated IoT and agritech. When that funding retreated, the hiring contracted. The stable robotics work that remains tends to sit inside the same gated sectors (defense, large industrial automation firms) with the same barriers to entry. New titles don't change the structural reality.
I would also add that system-level thinking, the very thing Shawn identifies as the future of the field, is not something everyone develops simply by accumulating years. It is a cognitive disposition. I have worked with senior engineers who never developed it and stayed deep in their narrow specialties. I have also met relatively inexperienced engineers who naturally gravitated toward integrative thinking but lacked the experience to trust their instincts yet. The hiring process doesn’t measure this well. It filters for keyword checklists: five years of C, experience with I2C, RTOS familiarity. The system thinkers often don’t make it past the initial screening, while engineers who match the checklist but can’t reason across boundaries move forward.
Where Shawn’s advice fits (and where it doesn’t)
Shawn’s recommendations are not bad advice. They’re actually quite good within their frame. Learning hardware deeply, building complete projects, showing your design reasoning, mastering debugging, and learning to work with AI rather than depending on it are all things that will make someone a better engineer. A strong portfolio of real, end-to-end projects that resemble actual products will absolutely help in an interview.
But these recommendations assume that the only barrier is individual preparation. They don’t address the structural realities: the gates around defense and medical hiring, the collapse of entire market segments that used to employ embedded engineers in volume, the long-term shift of product development away from the United States, and the simple fact that there are fewer jobs to compete for regardless of how well-prepared you are.
If you are young or transitioning into this field and someone tells you to “just build a portfolio and think at the system level” without also explaining the gates and the market contraction, they are giving you incomplete advice. It may help you in an individual case. It will not solve the larger problem.
A more honest picture
Embedded engineering as a discipline is not dying. The underlying skills (understanding how hardware and software interact, debugging real systems under real constraints, making design tradeoffs with incomplete information) are more consequential than they’ve ever been. The world is demonstrating that these skills can be strategically decisive in ways that should humble anyone who thinks AI is about to make engineers obsolete.
But the labor market for embedded engineers in the United States is fragmented, gated, and contracting. It is fragmented because the title now covers too broad a range of work, from bare-metal firmware to what is effectively Linux application programming. It is gated because the stable sectors that remain require credentials, clearances, or specialized experience that most engineers don’t have and can’t easily acquire. It is contracting because the speculative investment that inflated hiring in IoT, agritech, and related sectors has retreated, and because the center of product development has shifted to regions that can iterate faster and cheaper.
Shawn Hymel’s article is a useful piece of tactical advice for someone determined to enter the field regardless of these conditions. It is not an honest assessment of those conditions. Both things can be true.
I don't have a full picture of where all this is heading. I'm reporting what I've seen and what the patterns look like from where I stand.
If you’re reading this as a student or someone early in your career, I don’t want to leave you with just pessimism. The skills Shawn describes do matter. Build systems, not just code. Learn to read a schematic and a datasheet. Put yourself through the experience of debugging something that fails in a way you don’t understand and don’t give up until you’ve found the root cause. Learn to evaluate AI-generated code with skepticism and verify it against reality. These things will make you a better engineer, and being a better engineer does increase your odds.
But also understand that your individual preparation exists within a larger system that is not currently functioning in your favor. That’s not your fault. It’s not a reflection of your potential. And acknowledging it honestly is the first step toward making better decisions about where and how to invest your efforts. If the most impactful embedded work increasingly happens outside traditional institutions (in smaller teams, in faster-moving environments, in places without the gates I’ve described), then maybe the question isn’t just “how do I get hired” but “where is the work actually happening, and how do I get close to it.”