Software Engineering & Development

How to get hired as an embedded software engineer in 2026-27

Updated 6 October 2026 · 57 min read · by SkillSculptor

The short answer

To get hired as an embedded software engineer in 2026 or 2027, prove three things: that your C is register-level rather than tutorial-level, that you can reason about what an RTOS does to timing and concurrency, and that you have personally found a bug with a debug probe, a logic analyser or an oscilloscope rather than only with print statements. No licence or certification gates this job, but two filters do: most postings ask for a degree in electrical, computer or software engineering, and in defence, aerospace and space the binding gate is legal, because export-controlled programmes require US person status and many roles also require a security clearance that only a sponsoring employer can start. Firmware hiring is strongest in AI datacentre hardware (board management controllers, power sequencing, thermal control, optical and network module firmware), defence and space, medical devices, industrial and energy systems, robotics and semiconductor platform teams, while consumer connected products are the weakest segment. The loop is usually a logistics screen, a C and debugging screen with a practising firmware engineer, a driver or state-machine exercise, a design round about partitioning, update paths and power budgets, and a "this board does not boot, what do you check" round that software-only candidates fail by starting at the code instead of at the power rails.

What the role ownsThe software that runs on the product rather than on a server: startup code and bootloaders, device drivers written against a register map, the task structure and timing of a real-time system, communication over UART, SPI, I2C, CAN, USB, Ethernet or a radio, power and thermal behaviour, field update and recovery, and the manufacturing and test hooks. The job is defined by constraints that do not exist in application software: kilobytes instead of gigabytes, deadlines measured in microseconds, no reliable way to attach a debugger once the product has shipped, and hardware that can itself be the bug.
Licence or certificationNone. No licence, registration or board exam governs embedded software work, and the Professional Engineer licence used in some electrical engineering practice plays essentially no part in firmware hiring. A relevant engineering degree is the de facto filter instead. The only credentials employers genuinely recognise are functional safety certification of the TUV Rheinland FS Engineer type in safety-critical shops and vendor AUTOSAR training in automotive, and neither substitutes for evidence of shipped work. In defence and space the binding requirement is legal rather than educational: export-controlled work requires US person status under ITAR and EAR (a citizen or a lawful permanent resident, not citizens only), while a security clearance is normally restricted to US citizens.
Equipment and time to job-readyYou need a bench, and it is cheap compared with the rest of engineering: one or two development boards (an STM32 Nucleo or Discovery, a Nordic nRF52 or nRF54 development kit, an ESP32 board, plus a Raspberry Pi or BeaglePlay class board for the Linux side), a debug probe that speaks SWD or JTAG, a logic analyser with protocol decode, a basic oscilloscope, a multimeter and a soldering iron. That is low hundreds of dollars, not thousands. For a working software engineer moving across, expect several months of evenings on hardware to reach a portfolio that survives an interview. From no engineering background it is a degree-shaped path, or a side entrance through test, manufacturing or technician work.
Typical hiring processA recruiter or hiring manager screen (20 to 30 minutes, and it usually settles US person status, clearance, location and on-site expectations), a technical screen run by a practising firmware engineer (45 to 60 minutes of C, volatile, concurrency and one debugging story), a practical exercise (write a driver from a register map excerpt, a table-driven state machine, or a framed-protocol parser, sometimes on a real board they ship you or in an emulator such as Renode), an embedded systems design round, a hardware and debug round, and a manager conversation. Three to six weeks end to end is normal. A cleared defence role can add months between offer and start date while the investigation runs.
PayThere is no occupation code specific to firmware, so read the sources rather than trusting a quoted band. In the US, the Bureau of Labor Statistics Occupational Employment and Wage Statistics series covers this work across 15-1252 (software developers), 17-2061 (computer hardware engineers) and 17-2071 (electrical engineers), with medians published by state and metro area. Live postings in pay-transparency jurisdictions (Colorado, California, New York, Washington, Illinois and others) describe the current market better than any survey, and Levels.fyi is useful for the large semiconductor, autonomy and cloud-hardware employers. The pattern to expect: silicon vendors, AI infrastructure and autonomy pay above medical and defence for the same years of experience, and defence trades pay for stability and the value of a clearance.
Resume length and formatOne page up to roughly eight years, two beyond that. Reverse chronological, plain headings, no photo, no skill bars. Add a platforms block near the top that names exact silicon families, RTOS, buses and standards, because at primes and tier-1 suppliers an applicant tracking system and a non-technical recruiter screen on those literal strings. Every project line names the product, what you owned, and a number with a unit on it. Keep a link to a repository that contains a build system, host-side unit tests and a README with a scope or analyser capture in it.
Evidence that landsA bug you found that was not in your code, described with the instrument you used to prove it. Then measurements, in your own real numbers: sleep current before and after you fixed a floating pin and a peripheral left clocked, boot time before and after you deferred a flash scan, image size before and after you squeezed it to fit a substitute part, an over-the-air update shipped to a fleet with a rollback path that was actually exercised, the number of board revisions you brought up from bare schematic to running firmware. Every figure needs a unit and a method, because you will be asked how you measured it.
What changed by 2026Four things. The firmware job market moved toward AI datacentre hardware, defence, space, robotics and power electronics, while consumer IoT shrank. Zephyr moved from an alternative to a mainstream default for new microcontroller products alongside FreeRTOS, so devicetree and Kconfig fluency now appears in postings. Machine learning inference on microcontrollers and small neural accelerators became an ordinary product line item rather than a research project. And product security obligations hardened: signed updates, a software bill of materials and a vulnerability handling process are now procurement questions rather than nice-to-haves, driven partly by the EU Cyber Resilience Act and the UK product security regime, whose phase-in dates you should check against the current text rather than quoting from memory.

The jobs hiding behind the title "Embedded Software Engineer"

"Embedded software engineer" and "firmware engineer" are used interchangeably by most employers, and both cover at least five distinct jobs with different stacks, different interviews and different pay. Applying to all of them with one resume is the most common reason a strong candidate gets no replies. Read five postings carefully and you can usually tell within two sentences which of these the team actually needs.

The split that matters most is microcontroller work versus embedded Linux work. On a microcontroller you are writing code that owns the whole chip: there is no operating system underneath you unless you put one there, memory is measured in kilobytes, and a mistake can hang the product in a customer's hands. On an application processor running Linux you are working with the kernel, devicetree, a bootloader and a build system that assembles a whole root filesystem, and the hard problems are drivers, boot time, power management and integration. Both are embedded. The day-to-day skills overlap maybe half.

The third flavour is regulated and safety-critical firmware, where the code is a minority of the work. The majority is requirements, traceability, review records, structural coverage and justified deviations under ISO 26262, DO-178C, IEC 62304 or IEC 61508. Engineers who find this unbearable should avoid it honestly rather than take the job and resent it. Engineers who can run it without strangling the schedule are scarce and well paid.

The fourth is platform and silicon enablement: bring-up of new chips and boards, bootloaders, power management firmware, board management controllers, DDR and clock initialisation, and the software development kits everyone else builds on. This is where the deepest hardware debugging lives. The fifth is embedded test and automation, writing the Python rigs, instrument control and hardware-in-the-loop farms that verify everything else. It is consistently undervalued by candidates and is the most realistic side entrance into the field.

Choose one primary flavour, name it in your summary line, and let the other evidence be secondary. "Firmware engineer, Cortex-M and Zephyr, low-power sensor products" gets read. "Software engineer with experience in many technologies" does not.

Which industries are actually hiring embedded engineers in 2026-27

The honest shape of the market: embedded hiring did not boom the way application software did at the start of the decade, and it did not collapse the way application software did afterwards. It moved. The money followed physical infrastructure, defence and automation, and away from consumer connected gadgets. If you spent the years to 2022 building a connected consumer product, the jobs in your exact niche are thinner now and the jobs two sectors over are not.

AI datacentre hardware is the clearest growth area and the one most candidates overlook, because the job adverts say "firmware" and not "AI". Every accelerator tray, power shelf, cooling loop, optical transceiver and network interface card in a modern rack runs firmware, and at the scale these are being built that is a great many board management controllers, power sequencing state machines, thermal control loops, telemetry paths and manufacturing test fixtures. The stack is usually C, embedded Linux or an RTOS, OpenBMC, I2C and PMBus, SPI flash layouts, Redfish interfaces, and a great deal of bring-up. If you can debug a power rail coming up in the wrong order, you are employable here.

Defence, space and aerospace are hiring heavily, both at the traditional primes and at the newer defence technology companies, and this is the sector where the first gate is not technical. Export-controlled programmes require US person status under ITAR and EAR in the United States, with similar nationality rules elsewhere, and many roles additionally require a clearance that takes months to process. The technical world is its own: DO-178C design assurance levels, VxWorks, Green Hills INTEGRITY, DDC-I Deos or a bare-metal partitioned system, MIL-STD-1553, SpaceWire and CCSDS packet formats, radiation-tolerant parts, and a testing culture that assumes you cannot patch the product after launch.

Medical devices hire steadily and pay for discipline rather than speed. The work is governed by IEC 62304 for the software lifecycle inside an ISO 13485 quality system, with risk management under ISO 14971, and the submission paperwork is part of the engineering job rather than a separate department's problem. Premarket cybersecurity expectations for connected devices in the United States now include a software bill of materials and a plan for monitoring and patching known vulnerabilities, so secure update design has become routine medical firmware work. Treat the regulatory specifics as something to verify against current guidance before you quote them, because that is exactly the material that changes.

Automotive is split. European original equipment manufacturers and tier-1 suppliers went through real restructuring, and generic ECU application work is not the growth story it was. What is hiring is software-defined vehicle platform work (zonal controllers, service-oriented architecture over automotive Ethernet and SOME/IP, over-the-air update infrastructure), power electronics and battery management, and ADAS. The toolkit is CAN and CAN FD, LIN, UDS diagnostics, AUTOSAR Classic for deeply embedded ECUs and Adaptive on high-compute nodes, ISO 26262 with ASIL targets, and Lauterbach debuggers rather than a hobby probe.

The rest of the honest list: robotics and automation (warehouse, agricultural, surgical, humanoid) where the interesting problem is the split between a real-time microcontroller and a Linux brain; industrial and energy, including inverters, grid equipment, electric vehicle charging and battery systems, governed by IEC 61508 and IEC 62443; semiconductor vendors who need board support packages, drivers and software development kits for every new part; test and measurement; and consumer IoT, which is the weakest segment and the most price-sensitive. Contract design houses and engineering consultancies deserve a specific mention as an entry route: you will ship several products in two years and come out with a portfolio that a single-product company takes much longer to give you.

What actually gates the job: a degree, a bench, and sometimes your passport

Start with what does not gate it. There is no licence to practise embedded software engineering, no board exam, no registration and no continuing education requirement. The Professional Engineer licence that exists in electrical and mechanical practice plays essentially no part in firmware hiring. There is also no certification ladder of the kind cloud and networking have, and buying one will not move you. The two exceptions worth money are functional safety certification of the TUV Rheinland FS Engineer type, recognised in automotive, industrial and medical safety work, and vendor AUTOSAR training in automotive, where the ecosystem is specific enough that formal exposure helps. Both read as supporting evidence, never as a substitute for having shipped something.

What does gate it, more than in web or application development, is a degree. Most postings ask for a bachelor's degree in electrical engineering, computer engineering, computer science or a related field, and the preference order at hardware companies usually runs electrical and computer engineering first. The reason is not snobbery. The job sits on top of circuits, signals, timing and power, and the people who struggle hardest are those who have never had to think about a rising edge or a current budget. If you do not have the degree you need a compensating story: hardware you built, a repository with real register-level code in it, an upstream contribution, or a technician, test or manufacturing role that put you in a lab.

The second real gate is legal, and it surprises people. A large share of the highest paying and most stable embedded work in the United States is export controlled, which means the employer can only consider a US person as defined by ITAR and EAR, regardless of how good you are and regardless of your work authorisation. US person includes lawful permanent residents and certain protected individuals, not only citizens, so do not rule yourself out on a green card. A security clearance is the separate and stricter gate: it is normally restricted to US citizens, it is a background investigation that only a sponsoring employer can initiate, it takes months, it involves a detailed personal history questionnaire, and access to sensitive compartmented information may add a polygraph depending on the agency. Candidates who already hold an active clearance have a real advantage. The correct move is to state your status in the first line of the first email: active Secret, previously cleared and within the reinstatement window, US citizen without clearance, US person without citizenship, or not eligible for export-controlled work. Leaving it ambiguous wastes a month of your life.

Outside defence, the gate is a bench. You do not need a laboratory, and the usable kit is cheap: a couple of development boards, a real debug probe, a logic analyser, a basic oscilloscope, a multimeter and a soldering iron. A power measurement tool is the one luxury item worth buying if your interest is low-power work, because a sleep-current figure in microamps is a claim you cannot make without one. Build it, use it, photograph it, and talk about what you learned on it.

Time to job-ready, honestly. A working software engineer with solid C can be interview-ready for a junior or mid-level firmware role in roughly three to six months of consistent evening work, provided the work is on hardware rather than reading. An application developer whose C is weak should budget longer and treat C as the first project rather than a prerequisite to skim. Someone with an engineering degree and no firmware experience is often one good internship or one design house job away. Someone with no technical background is looking at a degree or a long route through technician work, and should hear that plainly rather than be sold a bootcamp.

What "strong C" means to an embedded interviewer

Every embedded job description asks for C and almost every candidate claims it, so the screen is designed to separate people who have written C from people who have written C against hardware. The questions are not obscure. They are about the handful of language features that only matter when memory is mapped to physical devices and when the compiler's idea of your program differs from the machine's.

volatile is the canonical question and it is asked in nearly every loop, so prepare it properly. Be able to say what it actually guarantees (the compiler will not cache, elide or reorder accesses to that object relative to other volatile accesses), where it is required (memory-mapped peripheral registers, a variable written by an interrupt handler and read by main, a flag shared with a DMA engine), and critically where it is not sufficient: it does not give you atomicity, it does not give you a memory barrier on a core that buffers or reorders writes, and it does nothing about cache coherency with DMA on a Cortex-A or a Cortex-M7 with the data cache enabled. A candidate who says "volatile tells the compiler the value can change" has repeated a slogan. A candidate who says "volatile plus a critical section or an atomic, because a read-modify-write of that register is three instructions and an interrupt can land in the middle" has done the job.

The rest of the C that gets tested: fixed-width types from stdint.h and why int is not a specification, unsigned arithmetic and integer promotion traps, bit manipulation (set, clear, toggle, test, extract a field, build a field), structure packing and alignment and why a packed struct laid straight over a wire protocol is a trap on some architectures, endianness and where you convert, pointer arithmetic, function pointers for dispatch tables and driver interfaces, const placement and what it puts in flash, static for linkage and for lifetime, the linker script and the sections it defines, where initialised data comes from at reset, stack versus static allocation, and why many shops forbid dynamic allocation after initialisation. Know what undefined behaviour means in practice rather than as a theoretical hazard, because an optimising compiler will punish you for it on a part with no memory protection.

The coding exercises recur across companies, so practise writing them cleanly on a blank page with no compiler to lean on. A single-producer single-consumer ring buffer, where the interesting half is the conversation about what makes it safe without a lock. A table-driven state machine for a protocol or a device power-up sequence. A framed-protocol parser fed one byte at a time, with length, checksum and resynchronisation after a bad frame. A driver skeleton written from a register map excerpt you are handed. Debouncing a mechanical switch. Fixed-point arithmetic and why you avoid floating point on a part with no hardware floating point unit. memcpy, and then the follow-up about alignment and overlapping regions. Bit reversal and population count. None of this is algorithmic trickery, and candidates who prepared on abstract puzzle sites are routinely surprised by how concrete it is.

C++ in embedded deserves a straight answer. A substantial share of production firmware uses it, usually as a deliberately restricted subset: no exceptions, no runtime type information, no heap after startup, templates and constexpr for zero-cost abstraction over registers, classes for driver interfaces. Automotive and aerospace layer MISRA C++ or the AUTOSAR C++14 guidelines on top. If a posting says C and C++, the interview will probe whether you understand what each feature costs in code size and determinism, not whether you know the standard library.

Rust, also straight. It is real in embedded and it is still a minority. The ecosystem (embedded-hal, probe-rs, RTIC, Embassy) is good, a qualified compiler toolchain for functional safety exists in Ferrocene, and some teams have shipped production firmware in it. But the overwhelming majority of paid embedded work is maintaining and extending large C codebases, and leading with Rust in an interview for one of those jobs reads as a candidate who wants to rewrite rather than ship. Treat Rust as a differentiator you mention second: it signals that you think about ownership and memory safety, which makes your C better, and it opens the small number of roles that use it. It does not replace being good at C.

RTOS, timing and concurrency: what that round really tests

"I have used FreeRTOS" is the most common unsupported claim on an embedded resume, and interviewers know it, so the follow-up is immediate and specific. The round is not about an API. It is about whether you can reason about what runs when, what happens when two things want the same hardware, and what the worst case is rather than the typical case.

Start with the model. Be able to explain what an RTOS actually gives you: a scheduler that chooses which task runs based on priority, a context switch that saves and restores register state, and primitives for communication and mutual exclusion. Be able to explain preemption and why a higher priority task becoming ready interrupts a lower one mid-work. Then be able to argue the other way, because "why did you not use an RTOS" is a real question with a real answer: a superloop with a timer tick and a small event queue is simpler, more predictable, smaller, and entirely adequate for a lot of products, and choosing it deliberately is a senior signal rather than a naive one.

The concurrency failures are the meat. Priority inversion and how priority inheritance in a mutex addresses it, and why a semaphore used as a mutex does not. Deadlock from two tasks taking two mutexes in opposite orders. The interrupt-safe API split and what actually goes wrong when you call a blocking or non-ISR-safe function from an interrupt handler. Deferring work out of an interrupt to a task, a work queue or a bottom half, and why interrupt handlers should be short. Queues, mailboxes, event groups, stream buffers and direct task notifications, and when each is the right choice. Two tasks sharing an I2C bus and what you put around it. A race condition you actually hit, and how you proved what it was.

Then timing, which is where hard real-time stops being a slogan. Interrupt latency and jitter and what contributes to each. Interrupt priority and nesting on the Arm NVIC. The cost of a critical section, and why disabling interrupts for a long stretch is a bug even when it appears to work. Worst-case execution time, and why the average case is irrelevant to a deadline. Rate monotonic reasoning about whether a task set is schedulable. Stack sizing per task, how you measure the high-water mark, how you detect an overflow (a canary pattern, a memory protection unit guard region, the RTOS stack checker) and what an overflow looks like when it goes undetected: corruption that surfaces somewhere unrelated. And watchdogs done properly, where each task checks in and a supervisor kicks the hardware watchdog only when all of them have, rather than a single kick from the idle loop that keeps a hung product alive.

Know the specific systems, by tier. FreeRTOS is the microcontroller kernel you are most likely to meet and the one to be fluent in. Zephyr became a mainstream default for new products and brought a different model with it: devicetree for hardware description, Kconfig for configuration, west for workspaces, a driver model with in-tree and out-of-tree modules, and a release cadence that means the version matters. ThreadX, Micrium and SafeRTOS appear in products that needed a commercial or pre-certified kernel. VxWorks, INTEGRITY and QNX appear in aerospace, defence and automotive. On the Linux side, know what PREEMPT_RT changes and what it does not, that it now lives in the mainline kernel rather than as an out-of-tree patch set, and that "real-time Linux" means bounded latency rather than guaranteed microseconds.

The strongest evidence in this area is a measurement. Toggle a GPIO at the start and end of a critical path, catch it on a scope or a logic analyser, and report the number. Capture a SEGGER SystemView or Tracealyzer trace and show the task switches and interrupt timings. A sentence of the form "the control loop met its 1 kHz deadline with measured margin, and here is the worst case I saw across an overnight soak" ends the conversation in your favour, with your own numbers in place of the shape.

Hardware debug: the evidence that separates embedded candidates

This is the section to invest in, because it is where the hiring decision usually gets made and where most candidates are thin. Application software bugs are in the code. Embedded bugs are in the code, in the hardware, in the silicon errata, in the vendor library, in the power supply, in the timing between two devices, in a connector, or in the environment. The job is finding the bug wherever it is, which means the interview tests whether you have ever found one that was not yours.

Know the instruments and what each is for. A debug probe over SWD or JTAG (J-Link, ST-Link, CMSIS-DAP, or a Lauterbach TRACE32 setup in automotive) with GDB, OpenOCD, pyOCD or probe-rs behind it, for breakpoints, watchpoints and memory inspection. Real-time transfer or SWO and ITM for low-overhead instrumentation, which is what you use when a UART printf would change the timing enough to hide the bug. ETM instruction trace when you need to know how you got somewhere. A logic analyser with protocol decode for a bus transaction that looks fine in software and wrong on the wire. An oscilloscope for anything analogue in nature: a slow rise time, a glitch on a reset line, a supply sagging when a motor starts, ringing on a long trace. A power profiler for current. A CAN or USB analyser where those buses apply. A thermal camera for the rare and memorable cases.

Be able to walk a hard fault from symptom to cause without notes, because it gets asked. Attach the debugger or read your stored crash record, recover the stacked exception frame, read the fault status registers (the configurable fault status register, the hard fault status register, the bus fault and memory management fault address registers), identify the faulting instruction, and classify it: a null or wild pointer dereference, an unaligned access, a stack overflow that ran into another region, a call through an uninitialised function pointer, or an imprecise bus fault from a buffered write that landed somewhere unhelpful. Then the part that marks out a professional: you stored a crash record in retained RAM or a flash log and shipped it, so that a field failure reports itself instead of coming back as a unit nobody can diagnose.

The board-does-not-boot round is close to universal. You are given a scenario and asked what you check, in order, and the interviewer is listening for a disciplined sequence rather than a lucky guess. Power rails in sequence and at the right voltages. Reset asserted and released cleanly. The clock source actually oscillating. Boot mode straps and pull resistors. Whether a debugger can attach at all, and what it tells you if it cannot. Whether you are in the bootloader or the application. Whether you reached main, which you prove with a GPIO toggle as the first line rather than with a print statement that needs a configured peripheral. Whether you are faulting inside clock or memory initialisation. Then bisect: stub out initialisation steps until it boots, add them back one at a time. Software-only candidates tend to start guessing at code. Hire-worthy candidates start at the power rails.

Prepare three debugging stories and rehearse them until they are tight, because you will be asked for at least one and the quality of the story carries disproportionate weight. The best set covers three different causes. One bug that turned out to be hardware (a floating input, a missing pull-up, a brown-out under load, an interference-induced reset, a marginal crystal, a cold joint) and how you proved it was hardware rather than asserting it. One timing or concurrency bug found with an instrument (a missed CAN frame, an I2C peripheral stretching the clock longer than your driver tolerated, a DMA completion racing a buffer reuse). And one intermittent bug that reproduced every few hours, where the interesting content is how you built the instrumentation to catch it rather than the fix itself.

Each story needs the same four parts and no more: the symptom as the customer saw it, the hypothesis you formed and why, the measurement that confirmed or killed it, and the fix plus how you verified it in the field. Keep the numbers, and keep them yours. The shape to aim for is "it reset about once a day in the field, I suspected a supply dip because the resets correlated with the compressor starting, I triggered on the brown-out detector output and caught the dip on the 3V3 rail, we added bulk capacitance and raised the detector threshold, and the fleet ran for months with no unexplained resets". That is worth more than any list of technologies.

Safety, security and the process work that decides senior offers

In regulated industries the difference between a mid-level and a senior embedded engineer is rarely more C. It is whether you can carry a feature through the process without the process eating the schedule. If you are aiming at automotive, aerospace, medical, rail or industrial safety work, this section decides your level and your pay, and the vocabulary is worth knowing even if you intend to stay commercial.

The standards map to industries: ISO 26262 in automotive, with Automotive Safety Integrity Levels from A to D driving how much rigour applies; DO-178C in airborne systems, with design assurance levels A to E, structural coverage requirements that reach modified condition and decision coverage at the top level, and DO-330 for qualifying the tools you rely on; IEC 62304 for medical device software, with safety classes that scale the required documentation, sitting inside an ISO 13485 quality system and ISO 14971 risk management; IEC 61508 and its sector derivatives for industrial functional safety with SIL targets; EN 50128 in rail. You do not need to know them all. You need to know which one applies to the job you are applying for, and what it actually demands of a working engineer.

What it demands, concretely: requirements that are written, reviewed and uniquely identified; traceability from each requirement to the code that implements it and the test that verifies it, usually managed in DOORS, Polarion, Jama or codebeamer; tests derived from requirements rather than written to match the code; coverage measured on the target or on a qualified host equivalent; static analysis run with findings either fixed or formally deviated with a recorded justification; configuration management where a released build can be reconstructed years later; and impact analysis before a change, so you can state what the change could break and what must be retested. The reason seniors are paid for this is judgement: knowing which of those activities protects the patient or the driver and which has become theatre, and being able to argue the distinction with evidence.

Security has become the fast-moving half of this. The baseline buyers now ask for: a secure boot chain where each stage verifies the next against a key held in a protected region, signed firmware images, anti-rollback protection so an attacker cannot force an old vulnerable version, debug interfaces locked in production with a controlled path to re-enable for returns analysis, keys provisioned in manufacturing rather than compiled into the image, authenticated updates, and an update mechanism that cannot brick the fleet. Add a software bill of materials in SPDX or CycloneDX format, because almost no product is only your code: it contains a TCP stack, a TLS library, a Bluetooth stack, a filesystem, an RTOS and possibly a Linux userspace, each with its own vulnerability history that someone has to watch.

On regulation, state the obligation and not the date. The EU Cyber Resilience Act places obligations on products with digital elements covering vulnerability handling, security updates and documentation including a bill of materials, with enforcement phased in. The UK product security regime bans universal default passwords and requires a vulnerability disclosure contact and a stated support period. US premarket expectations for connected medical devices include a bill of materials and a plan for monitoring and patching. IEC 62443 governs industrial automation security. The dates and thresholds in all of these have moved, and amending regulations are exactly the kind of thing changed after any given source was written, so check the current text before you quote a deadline in an interview. Being right about the obligation and explicitly uncertain about the date is the professional answer. Being confidently wrong about a compliance date in front of someone who has been living it is the opposite.

If you are coming from an unregulated background you can build credibility here without a job in the sector. Write requirements for your own project and trace them to tests. Run a static analyser and clear it. Put a signed update with rollback in your bootloader. Generate a bill of materials for your firmware and look up the known vulnerabilities in the components you pulled in. That is a weekend of work and it changes how you sound in a medical or automotive interview from outsider to someone who has met the ideas.

The hiring process, the resume, and where to apply

Who reads your resume depends on the size of the employer, and it changes what you write. At a small or mid-size hardware company the firmware lead reads it directly, often in a batch of thirty, scanning for silicon families, buses, an RTOS, and evidence you have been in a lab. At a defence prime, a tier-1 automotive supplier or a large medical manufacturer an applicant tracking system and a non-technical recruiter screen first, and they match literal strings, so the exact part families and standard numbers must appear in your text. At a semiconductor company expect a hiring manager plus a panel of engineers who each probe a different layer.

The stages, in the order they usually come. A screen of 20 to 30 minutes that covers logistics as much as skills: location and on-site expectation, US person status and clearance where relevant, salary range, and a quick sanity check on your stated platforms. A technical screen of 45 to 60 minutes with a practising firmware engineer, which is C questions, one concurrency or timing question, and "tell me about the hardest bug you have found". A practical exercise, which in this field is often better than a generic coding test: implement a driver from a register map excerpt, write a state machine, parse a framed protocol, sometimes on a development board they ship you or in an emulator such as Renode. A design round where you architect the firmware for a plausible product. A debug or hardware round. A manager conversation about how you work with electrical engineers, mechanical engineers and test.

The design round rewards a specific shape of answer, so prepare a template. Clarify the requirements and constraints first: what is hard real-time, what is the power source, what is the cost target, what is the update story, what is the regulatory context. Then partition: what runs in an interrupt, what runs in a task, what runs on a second processor, what runs in the cloud if anything. Then choose the operating system or the absence of one, and justify it. Then name the hardware interfaces and protocols. Then the state machine and the failure modes: what happens on power loss mid-write, on a sensor going silent, on flash wear-out, on a failed update. Then the test strategy: host unit tests behind a hardware abstraction layer, a hardware-in-the-loop rig, soak testing. Then production: provisioning, calibration, test fixture, serial numbers. Candidates who only talk about features and never about failure modes lose this round.

The resume content that works. One page to roughly eight years. A summary line that names your flavour and your platforms. A platforms block naming exact families, buses, RTOS, tools and standards, because that is what gets matched and what gets read. Then experience in reverse chronological order, where every bullet names the product, your ownership, and a number with a unit. Firmware is unusually generous with honest numbers: microamps, milliseconds, kilobytes, interrupts per second, units shipped, board revisions brought up, coverage percentage, defect escapes. Use your own real ones and know how each was measured, because you will be asked.

What gets ignored or actively hurts. Skill-rating bars and percentage proficiencies. A language list that mixes C with HTML and Java, which reads as a new graduate padding. Soft-skill paragraphs. A long list of vendor libraries you called once. Describing an Arduino sketch as professional firmware work, which is fixable: reframe the same project at the register and timing level, say what you measured, and it becomes credible. And any claim of RTOS or safety-standard experience that collapses under a single follow-up question, which is the fastest way to lose an interviewer's trust for the rest of the loop.

Where to actually look. Generic job boards aggregate embedded roles badly because the titles vary so much, so go direct: careers pages at semiconductor vendors, defence primes and the newer defence technology companies, medical device manufacturers, tier-1 automotive suppliers, test and measurement firms, server and power hardware vendors, robotics companies, and the contract design houses in your region. Search by part number and by standard rather than by job title, because "STM32 firmware", "nRF52", "Zephyr", "CAN FD", "IEC 62304", "OpenBMC" and "Yocto" surface postings that the words "embedded engineer" miss. And use the open-source route deliberately: a merged Zephyr driver or board port, a U-Boot or Linux patch, a fix in a widely used stack. It is public, dated, reviewed by strangers, and more persuasive than anything you can claim about yourself.

One structural note about the search. Embedded teams are small, often a handful of engineers rather than a department, which means openings are sporadic and referrals carry disproportionate weight. Volume applying works worse here than in web development. Twenty carefully targeted applications with a cover note that names the product and the specific problem you could help with will beat two hundred generic ones, and attending one regional embedded or open-source hardware event will often beat both.

Working with AI in this role

What an embedded software engineer has to know about AI in 2026-27

Begin with the honest calibration, because for this role the hype and the observable change are different sizes. The core of embedded work has not been automated and is unusually resistant to it. Bringing up a new board, working out why a bus transaction looks correct in the debugger and wrong on the analyser, reasoning about interrupt latency, proving that a field reset is caused by a supply dip rather than by your code, and signing off a safety argument all require being in the room with the hardware, with ground truth that does not exist as text. A model cannot see your oscilloscope. Generation has not removed the bench, and the sectors hiring firmware hardest in 2026 are the ones AI itself created the demand in.

What did change, concretely, is in three places. The first is code generation, and embedded has an unusual amount of the boilerplate generation handles well: register definition structs from a datasheet table, a HAL call sequence, a state machine skeleton, CMake and Kconfig plumbing, a host-side test harness, a Python script that drives a bench instrument or parses a log. It also fails in ways specific to this domain, and knowing the failure list is the actual skill. Generated firmware routinely invents register and bit-field names that do not exist on your part, mixes up two versions of a vendor HAL, targets a sibling chip variant with a different peripheral, omits volatile, calls the non-interrupt-safe version of an RTOS function from an interrupt handler, puts a blocking delay or a dynamic allocation somewhere neither is allowed, gets byte order wrong, and is silently unaware of the errata sheet. All of that compiles. Several items on that list will pass a casual review and fail in the field.

The second change is in what employers ask about. Expect a question about whether and how you use an assistant, and expect the interesting half to be about limits rather than enthusiasm. In a safety-critical codebase, code with no identifiable rationale is a traceability problem: every line still has to map to a requirement and be covered by a requirements-based test, and the generator does not do that work. In an export-controlled programme, pasting source into an external service can be a compliance incident rather than a productivity choice, and the same is true of a customer's proprietary design under NDA. Teams differ widely on tooling policy, so ask in writing which rounds permit an assistant, and in a take-home say plainly what you generated and what you changed. Reviewers can usually tell, honesty costs nothing, and being caught costs the offer.

The third change is AI inside the product, which is the part that moves a resume. Running small models on constrained hardware stopped being a research exercise: quantised networks for keyword spotting, anomaly detection on vibration or current signatures, predictive maintenance, gesture and presence detection, sensor fusion, and vision on application processors with a neural accelerator are now normal product features. The toolchain is real and named: LiteRT for Microcontrollers (the renamed TensorFlow Lite for Microcontrollers), ExecuTorch, CMSIS-NN, microTVM, Edge Impulse as a workflow, and vendor paths including STM32Cube.AI, NXP eIQ and TI Edge AI, running on Cortex-M with DSP extensions, Arm Ethos-U class accelerators, or a discrete accelerator on the Linux side. The firmware engineer's contribution is almost never the model architecture. It is the budget: how many kilobytes the tensor arena needs, how many cycles and milliseconds an inference costs, what it does to the power envelope and the thermal headroom, how the model gets updated in the field, and what the system does when inference is wrong.

One more market observation worth acting on. The largest single AI-driven change to embedded employment is not inside the firmware, it is the hardware AI runs on. Datacentre buildout at this scale created sustained demand for board management controller firmware, power sequencing and power shelf control, liquid cooling and thermal control loops, optical transceiver and network interface firmware, telemetry and manufacturing test. The work is C, Linux or an RTOS, I2C and PMBus, SPI flash and bring-up, and it is often advertised with no mention of AI at all. If you want to be where the hiring is, that is where it is, and your existing low-level skills transfer directly.

Shipping a quantised model on a constrained target and reporting the real budget

This is the most differentiating AI skill an embedded candidate can hold in 2026-27, because the shortage is not people who can train a model, it is people who can make one fit inside a part with a couple of hundred kilobytes of RAM and a battery. Hiring managers want the engineer who knows the inference cost before the feature is committed to a datasheet, and who can say which problems belong on the microcontroller at all. It carries a judgement component too: small on-device models are good at classification, keyword spotting, anomaly detection and simple regression on sensor data, and are the wrong tool for anything needing language understanding or broad context.

Show it: Take one real signal you can capture on your own bench (accelerometer data from a motor, current draw from an appliance, audio) and put a quantised classifier on a microcontroller end to end. Report four numbers you measured rather than estimated: flash and RAM footprint including the tensor arena, inference latency in milliseconds or cycles, energy per inference, and accuracy against a held-out set captured on the same hardware. Then be able to say what you tried that did not fit, and whether int8 quantisation cost you accuracy and how much.

Reviewing AI-generated firmware for the defects it reliably produces

Generation is cheap and uniform now, so the scarce skill is catching what it gets wrong, and in firmware the cost of missing one is higher than in a web service because you cannot roll back a product in someone's hands and the symptom may appear months later as a field return. Debugging and code-review rounds have become more common in embedded loops partly for this reason: interviewers want the person who finds the problem before it merges.

Show it: Be able to list the recurring defect classes without hesitating: invented register or bit-field names, a HAL version or chip-variant mismatch, a missing volatile, an interrupt-unsafe RTOS call inside a handler, dynamic allocation or a blocking delay where neither is allowed, unbounded stack use or recursion, a buffer shared with DMA without cache maintenance, endianness errors in a protocol, a missing error path on a bus transaction, and no awareness of the errata. In a review round, announce the categories you are checking before you start reading. On the resume, one line about a defect class you systematically eliminated, with your own number on it.

Using assistants where they actually pay in this job: the bench-adjacent work

The productivity gain in embedded is real but it is not mostly in the firmware. It is in the surrounding scaffolding firmware engineers habitually under-build because it is not the interesting part: test rigs, log parsers, instrument control, fixture scripts, protocol decoders, documentation and release notes. A candidate who used the tooling to raise their test coverage and bench automation has a better story than one who used it to write drivers faster, and a better artefact to show.

Show it: Build a hardware-in-the-loop harness for your own project: a Python script that flashes the board, drives inputs, reads results over a serial or network link, and reports pass or fail, wired into continuous integration. Add host-side unit tests behind a hardware abstraction layer so the logic can be tested without the board. Say in the interview which parts you generated and which you wrote, and what the harness caught that manual testing had missed.

Knowing the compliance and confidentiality limits on assistant use

This is a question senior interviewers in regulated and export-controlled industries ask deliberately, and a wrong answer is disqualifying in a way that a weak technical answer is not. Safety-critical code needs traceability to requirements and justification for design decisions, which generated code does not come with. Export-controlled and NDA-covered source has rules about where it may be sent. Generated or copied code also carries licensing and provenance questions that feed straight into the software bill of materials your customer now asks for.

Show it: Be able to state the three constraints in your own words: traceability and review obligations in a safety lifecycle, export control and confidentiality limits on what source may leave the building, and provenance and licensing of code that enters your image. Ask the interviewer what their policy is, which demonstrates you know there is one. If you have worked somewhere with a written policy, describe how it was enforced in practice rather than in theory.

Reading a 2,000-page reference manual with a model rather than instead of one

Embedded documentation is enormous and badly searchable, and this is a genuine time saving: finding which register controls a peripheral clock gate, or which of four timers supports the capture mode you need, across a reference manual, a datasheet, an application note and an errata sheet. The failure mode is equally genuine, because a confidently wrong register description costs you a day on the bench, and models are routinely wrong about specific bit positions and variant differences.

Show it: Adopt a verification habit and be able to describe it: use the assistant to locate the section, then read the register table in the manual itself, then check the errata before writing the code. In an interview, if you quote a peripheral detail, say where you confirmed it. The sentence "I checked the errata and that silicon revision has a known problem with exactly that mode" is one of the most credible things a firmware candidate can say.

Positioning for the hardware that AI runs on

This is a market skill rather than a technical one, and it is worth more to a job search in 2026-27 than most technical additions. The sustained new demand for firmware engineers is in AI datacentre hardware: board management controllers, power sequencing and power delivery, thermal and cooling control, optical and network module firmware, telemetry and manufacturing test. Many candidates never apply because the postings do not mention AI, and the required skills are exactly the ones a competent microcontroller or embedded Linux engineer already has.

Show it: Learn the vocabulary of that world well enough to pass a screen: OpenBMC and Redfish, PMBus and I2C device management, power sequencing and rail ordering, SPI flash layouts and recovery, hot-swap and fault containment, thermal control loops and fan curves, telemetry and out-of-band management. Then map your existing experience onto it explicitly in your cover note: a motor control loop is a control loop, a power rail bring-up is a bring-up, and I2C is I2C whether the device is a sensor or a voltage regulator.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

Mistakes that cost people this job

Listing an RTOS on your resume that you cannot defend under one follow-up question.

Either go deep on one or leave it off. For the one you claim, be ready to explain priority inversion and how a mutex with priority inheritance addresses it, what happens when two tasks share one bus, how you sized each task's stack and how you detected an overflow, which API calls are interrupt-safe and why, and how you measured a deadline being met. If your experience is a superloop, say that and defend it well. A confident bare-metal answer beats a vague RTOS claim every time.

Having no hardware evidence at all: no probe, no capture, no board, no measurement.

Build the cheap bench and use it. One development board, one debug probe, one logic analyser and a multimeter are enough. Then produce the artefacts an interviewer can look at: a decoded bus capture showing the bug and the fix, a timing measurement from a GPIO toggle on a scope, a current measurement before and after an optimisation, and a photo of the setup. Embedded hiring is evidence-based because the work is physical, and a portfolio with no hardware in it reads as an application developer hoping to be let in.

Debugging exclusively with printf and saying so.

Learn the instrumentation that does not change the timing you are trying to measure: RTT or SWO for logging, breakpoints and watchpoints over SWD, a GPIO toggle plus a scope for latency, a RAM event ring buffer dumped on fault, and a trace viewer for task behaviour. Keep printf for what it is good for, and be able to explain the Heisenbug problem: a serial print inside an interrupt handler can hide the race you are hunting by slowing everything down.

A resume that lists languages and vendor libraries but no part numbers, buses or standards.

Add a platforms block with exact families (STM32H7, nRF52840, i.MX 8M Mini, AURIX TC3xx), the RTOS, the buses, the debug tools and any standard you have worked under. At large employers an applicant tracking system and a non-technical recruiter match these literal strings, and at small ones the firmware lead scans for them in ten seconds. Then put a number with a unit on every achievement bullet.

Leaving citizenship, clearance or on-site expectations to be discovered in week four.

Say it in the first message. "US citizen, active Secret clearance" or "US person, green card holder, eligible for export-controlled work but not for a clearance" or "not eligible for export-controlled work, targeting commercial roles" saves everyone the cycle. The same applies to location: if a role needs you at a bench three days a week, find out in the screen rather than after the fourth interview, and do not apply remote-only to a bring-up job and hope.

Treating MISRA C, no-dynamic-allocation rules and traceability as pointless bureaucracy, and saying so in the interview.

Argue the engineering reason instead. Static allocation after initialisation makes memory use provable and removes a class of failure that appears after weeks of uptime in a product nobody can restart. MISRA removes constructs whose behaviour is implementation-defined. Traceability is how a safety argument survives a change three years later. Then show judgement: name one requirement in a process you have worked under that you thought was theatre, what risk it was meant to control, and what you proposed instead.

A portfolio that never goes below Python on a Raspberry Pi, or that is Arduino library calls only.

Go one level down and say so. Write a driver for a sensor from its register map without the vendor library. Configure a timer and a clock tree by hand. Put the same project on a microcontroller with a known flash and RAM budget and report what you used. Arduino is a fine starting point and a bad finishing point: the same project reframed at the register level, with a timing measurement and a memory figure, becomes credible evidence.

Not knowing your own project's numbers when asked.

Before any interview, measure and memorise: flash and RAM used and how much headroom remains, each task's stack high-water mark, your worst-case interrupt latency and how you measured it, average and sleep current, boot time, and the longest soak test you ran. "I do not know, it worked" is the answer of someone who has never had to defend a product. Numbers with units and a stated measurement method are the fastest credibility you can buy.

Jumping straight to a fix in the debug round instead of forming a hypothesis and testing it.

Narrate the loop out loud: symptom, hypothesis, the specific measurement that would confirm or kill it, then the next hypothesis. "I suspect the peripheral is stretching the clock, so I would put the analyser on SCL and look at the gap after the address byte" scores even when the guess is wrong, because the interviewer is scoring your method. Reproduce before fixing, and say how you would verify the fix in the field rather than only on your desk.

Questions people ask

Do I need a degree to become an embedded software engineer?

An embedded software engineer is usually hired with a bachelor's degree in electrical engineering, computer engineering or computer science, and this field screens on the degree harder than web or application development does, because the work sits on top of circuits, timing and power. It is not an absolute requirement. People get in without one through a technician, test or manufacturing route, through a contract design house that hires on portfolio, or by building hardware evidence strong enough to override the filter: register-level code in a public repository, an upstream contribution to Zephyr, U-Boot or the Linux kernel, and a project with measured timing and power numbers. The degree matters most for the first job and in visa pathways, and stops being asked after roughly three years of shipped products.

Is there a licence or certification required to work as an embedded software engineer?

No. An embedded software engineer needs no licence, registration, board exam or continuing education, and the Professional Engineer licence used in some electrical engineering practice plays essentially no part in firmware hiring. There is also no certification ladder worth buying. Two credentials carry real weight in specific sectors: functional safety certification of the TUV Rheinland FS Engineer type in automotive, industrial and medical safety work, and formal AUTOSAR training in automotive. In defence and space the binding requirement is legal rather than educational: export-controlled work requires US person status under ITAR and EAR in the United States (which includes lawful permanent residents, not only citizens), or the national equivalent elsewhere, and many roles additionally require a security clearance that only a sponsoring employer can start.

Which industries hire embedded software engineers in 2026 and 2027?

In 2026 and 2027 the strongest demand for embedded software engineers is in AI datacentre hardware (board management controller firmware, power sequencing, thermal and cooling control, optical transceiver and network interface firmware, telemetry and manufacturing test), defence, space and aerospace, medical devices, industrial and energy systems including inverters, grid equipment and battery management, robotics and automation, and semiconductor vendors who need board support packages and drivers for every new part. Automotive is split: generic ECU application work is thinner after restructuring at European manufacturers and suppliers, while software-defined vehicle platform work, power electronics and ADAS still hire. Consumer connected products are the weakest segment. Contract design houses and engineering consultancies hire continuously and are an underrated entry route.

How much C do I need, and do C++ or Rust matter for embedded jobs?

An embedded software engineer needs C at register level, not tutorial level: memory-mapped I/O, what volatile does and does not guarantee, bit manipulation and field extraction, fixed-width types and integer promotion traps, structure packing and alignment, endianness, linker sections and what happens between reset and main, and why many teams forbid dynamic allocation after initialisation. C++ appears in a substantial minority of production firmware as a restricted subset with no exceptions, no runtime type information and no heap, so expect questions about what each feature costs in code size and determinism. Rust is genuinely in use in embedded and still a minority: it is a differentiator worth mentioning second, it signals that you think about ownership and memory safety, and it does not substitute for being good at C, because most paid embedded work is extending large C codebases.

What does an embedded software engineer interview actually test?

An embedded software engineer interview tests three things that general software interviews do not. First, C against hardware: volatile, bit manipulation, memory-mapped registers, alignment and packing, and a written exercise such as a single-producer single-consumer ring buffer, a table-driven state machine, a framed-protocol parser or a driver written from a register map excerpt. Second, concurrency and timing: priority inversion, interrupt-safe APIs, deferring work out of an interrupt handler, stack sizing and overflow detection, interrupt latency, and how you proved a deadline was met. Third, hardware debugging, which is where most candidates are weak: your best bug story with the instrument named, a hard fault walked from the stacked frame and fault status registers to the cause, and the near-universal "this board does not boot, what do you check" round, which starts at the power rails and not at the code.

How much do embedded software engineers get paid?

There is no occupation code specific to firmware, so an embedded software engineer should read the sources rather than trust a quoted band. In the United States the Bureau of Labor Statistics Occupational Employment and Wage Statistics cover this work across 15-1252 (software developers), 17-2061 (computer hardware engineers) and 17-2071 (electrical engineers), with medians published by state and metropolitan area. Live postings in pay-transparency jurisdictions including Colorado, California, New York, Washington and Illinois describe the current market more accurately than any survey, and Levels.fyi is useful for large semiconductor, autonomy and cloud-hardware employers. The reliable pattern: silicon vendors, AI infrastructure and autonomy pay above medical and defence at the same experience level, defence trades pay for stability and the value of a clearance, and embedded generally sits below top-tier application and machine learning pay while being considerably less volatile.

Do I need a security clearance or US citizenship for embedded jobs?

For commercial embedded software engineering roles in medical, industrial, semiconductor, consumer and AI infrastructure companies, no: there is no citizenship or clearance requirement beyond normal work authorisation. For defence, space and much of aerospace in the United States, an embedded software engineer usually needs US person status under ITAR and EAR because the programme is export controlled, and that includes lawful permanent residents as well as citizens. A security clearance is a separate and stricter gate normally limited to US citizens: it cannot be obtained independently, a sponsoring employer initiates it, it involves a detailed personal history questionnaire and a background investigation, it takes months, and sensitive compartmented access may add a polygraph. Candidates with an active or recently lapsed clearance have a real hiring advantage. State your status in your first message either way, because it decides which half of the market you are applying to.

Can embedded software engineering be done remotely?

Mostly not, and an embedded software engineer should plan for hybrid or on-site work. The job depends on physical access to boards, probes, analysers, scopes and test fixtures, and much of it happens in conversation with electrical and mechanical engineers around a bench. The exceptions are real but narrower than in application software: embedded Linux, board support package, platform and tooling roles can often be done remotely because the hardware can be racked in a lab and reached over the network, and those postings usually say so explicitly. Bring-up, power and timing work is rarely remote. Ask in the screen how many boards each engineer gets and whether there is a hardware-in-the-loop rig, because the answer tells you what the working pattern will really be.

Will AI replace embedded software engineers?

No, and embedded software engineering is one of the better-insulated software disciplines, for a structural reason: the ground truth for an embedded bug often lives outside the text. A model cannot see your oscilloscope, probe a reset line, or know that the silicon revision on your board has an erratum affecting the peripheral mode you chose. What has changed for an embedded software engineer is narrower and specific: generation handles register structs, HAL sequences, build plumbing and test scripts well, so review has become the scarce skill, because generated firmware reliably invents register names, mixes up chip variants, omits volatile and calls interrupt-unsafe functions from handlers. Meanwhile demand went up rather than down, because the datacentre hardware AI runs on is full of firmware, and inference on microcontrollers became a routine product feature that someone has to fit inside a memory and power budget.

How long does it take to become an embedded software engineer?

For a working software engineer with solid C, becoming a hireable embedded software engineer takes roughly three to six months of consistent evening work, provided that work happens on real hardware with a debug probe and a logic analyser rather than in reading. If your C is weak, treat C against a register map as the first project and add a few months. With an engineering degree and no firmware experience, one internship, one design house contract or one internal transfer at a hardware company is usually enough. With no technical background it is a degree-shaped path of several years, or a longer route in through technician, test or manufacturing work, and no bootcamp shortens that honestly.

Put this on a resume in about a minute

Paste your history once and point it at the Embedded Software Engineer posting you are looking at. No account, no card.

Build my resume free More roles

Related roles