Embedded / IoT Engineer
Embedded/IoT Engineer means writing and debugging firmware — C/C++ in the overwhelming majority of postings, with Python showing up constantly too but almost always as a secondary tooling/test-automation language, not the primary deliverable — for microcontrollers, embedded Linux targets, and the hardware underneath them, across consumer IoT, industrial/robotics, automotive, medical-device, and aerospace/defense contexts. It's not "knowing RTOS theory and interrupts cold" — practitioners describe it as a live-diagnostic discipline measured by speed under pressure: can you find why a $2M production line just crashed at 3 AM, not just explain memory models in the abstract. Bus-level protocol work (CAN, SPI, I²C, UART) is close to universal, RTOS and embedded Linux roughly split the field, and a real minority slice touches FPGA/VHDL/Verilog. One thing that surprises people going in: a meaningful share of postings — even some consumer-facing ones — require US-person status or security-clearance eligibility because of export-control rules, not just the obvious defense-prime roles.
What matters most for this role
Power/memory/real-time constraints are 'hard constraints, not nice-to-haves'; 'your elegant software design is worthless' if it violates them, with routine hardware bring-up debugging via oscilloscopes/logic analyzers/JTAG.
Diagnostic speed across fundamentally different failure domains (hardware, firmware, protocol, timing) is the actual hiring bar — 'a problem-solving discipline, not knowledge recall.'
EE/CompE backgrounds commonly preferred over pure CS; the field spans bare-metal MCU, embedded Linux, RF/wireless, and safety-critical domains requiring a second formal discipline.
Writing/debugging firmware in C/C++ is the dominant language requirement across nearly every posting reviewed and is the actual shipped deliverable.
Success criteria frame field diagnostic ability under pressure as core ('why their $2M production line just crashed at 3 AM'), though not necessarily a formal page rotation like SRE/security.
A day in this role
Expect to own firmware for a specific product or subsystem end-to-end — design, implementation, test, and deployment/OTA support, not just code-to-spec. Hardware bring-up and validation work is constant: getting firmware running on a new PCB revision, debugging with oscilloscopes, logic analyzers, or JTAG when something fails and it's not yet obvious whether the cause is hardware or code, usually alongside an electrical engineer doing the same triage from the other side. You'll write and integrate drivers for communication protocols (UART, SPI, I²C, CAN, BLE, or cellular depending on the domain), and a real chunk of your week goes to resource-constrained optimization — power draw, memory footprint measured in kilobytes, and real-time deadlines that don't bend. Power and battery-life work in particular shows up as its own named responsibility on wearables, robotics, and EV postings, not just a footnote under "optimization." Testing has gotten more formalized than the old stereotype suggests, too — plenty of teams run Hardware-in-the-Loop and Software-in-the-Loop rigs with real CI/CD pipelines for firmware, layered on top of the compliance-driven validation (medical, automotive, aerospace) most software engineers never encounter. A widely-cited rule of thumb in this field: the first 90% of a project is coding, the second 90% is debugging — schedule accordingly.
Comp structure
Typical: $195K
Comp here splits three ways, not two. Big tech and tech-adjacent embedded roles (Google, Amazon, Nvidia) report medians in the $200K-$270K range. A second tier — VC-backed hard-tech, robotics, and defense-tech startups riding the current funding boom, companies like Anduril, 1X, Figure, Skydio, Aurora, and Waabi — currently list embedded/firmware roles in roughly the $150K-$300K range with equity explicitly called out, a comp profile much closer to mainstream big-tech/high-growth-startup SWE pay than embedded's reputation suggests. A third tier — legacy industrial, medical-device, automotive, and defense-prime employers, think Boeing or Broadcom — runs lower and more cash-heavy: postings currently list roughly $80K-$230K depending on level, with thinner or no equity. That third tier is real and still common, but it's one segment among several now, not the default shape of embedded comp — worth knowing so you don't walk in assuming either "it's all $270K big-tech money" or "it's all defense-contractor cash-only."
▸ Data notes▾ Data notes
▸ Full compensation breakdown by level and company tier▾ Full compensation breakdown by level and company tier
Compensation by Company Tier
Total compensation (base + bonus + annualized equity) across five company tiers, at each career level. The same role pays very differently depending on where you take it.
embedded-iot-engineer · total comp (base + bonus + annualized equity) · P25–P75 band, P50 median
Equity Reality Check
The guaranteed money (base + bonus) against the equity upside. Startup equity is illiquid — the equity figure is annualized paper value at vest, not cash in hand.
Examples of real job postings
snapshot from 2026-07-12Real postings from the research corpus behind this archetype. Click one to read the actual listing.
How to test this cheaply
Get a cheap dev board (Arduino, ESP32, or similar) and build something small end to end — sensor input, a wireless protocol, a real-time constraint you have to hit — to see whether hardware-software boundary debugging feels engaging or frustrating.
Because self-taught entry here is genuinely harder than in mobile or web (there's no "ship an app to the store" equivalent low-cost proof point), also consider whether you can shadow or pair with an embedded engineer for a bring-up session before committing further — it'll surface the hardware-debugging temperament question faster than solo tinkering alone.
Do this role, or hire for it? Rate how much each trait actually matters. Role-holder and hiring-manager ratings are kept separate, and no single rating changes the model; ratings are aggregated with anti-gaming thresholds before they factor in.