Embedded Design Engineer

An embedded design engineer develops the electronics and software that sit inside physical products - things like car control units, medical devices, industrial sensors, smart meters, drones and consumer gadgets. The work combines designing or selecting the hardware (microcontrollers, circuit boards, sensors) with writing the low-level software, usually in C or C++, that makes that hardware do something useful. Most work in-house for product manufacturers, or for design consultancies that build products on contract for other companies.

Approximate graduate salary

Typically around GBP 28,000-36,000 to start, though this varies widely by employer, sector and location - large defence, semiconductor and automotive employers and London or Cambridge-based roles tend to sit at the upper end or above it, while smaller firms and regional manufacturers often start lower.

What you'd actually do

Writing and debugging firmware in C (sometimes C++, occasionally Rust or assembly) that runs directly on a microcontroller - for example code that reads a temperature sensor, filters the reading and sends it over a communications bus to another part of the system
Working with a development board or prototype on the desk, flashing new code onto it dozens of times a day and watching what happens
Using test equipment - oscilloscopes, logic analysers, multimeters, bench power supplies - to work out why a signal looks wrong or why a board draws more current than expected
Reading datasheets and reference manuals: microcontroller documentation runs to thousands of pages, and finding the right register setting or timing requirement is a genuine daily task
Reviewing schematics and circuit board layouts with hardware colleagues, or producing them yourself in a tool such as Altium or KiCad if the role leans hardware
Writing test code and running it on the bench or in an automated rig, and logging and investigating defects raised by test or production teams
Sitting in design reviews and sprint-style planning meetings with mechanical, software and systems engineers, because an embedded product only works if all three disciplines line up

How graduates get in

Graduate schemes at engineering and technology companies - common in automotive, aerospace, defence, semiconductors and industrial equipment. These usually run for one to two years with rotations across hardware, firmware and test.
Direct entry to a named graduate or junior embedded engineer post. This is very common in smaller firms and design consultancies, which often hire one or two graduates at a time outside any formal scheme rather than running a scheme at all.
A placement year or summer internship during your degree, converted into a graduate offer. This is one of the most reliable routes - embedded teams value anyone who has already worked with real hardware.
Moving across from a technician or apprenticeship background, including degree apprenticeships in electronic engineering, which are increasingly used by larger manufacturers.
Converting from a software or physics background by building a demonstrable portfolio - personal projects on Arduino, STM32, ESP32 or Raspberry Pi Pico, contributions to open-source firmware, or a university project involving real embedded code. Less conventional, but it does work, particularly at smaller companies that care more about what you can show than your degree title.
A master's or PhD in a specialist area (signal processing, RF, control systems, power electronics) for roles in research-heavy or safety-critical domains. Not required for most jobs.

What employers ask for

A degree in electronic engineering, electrical and electronic engineering, computer engineering, computer science or a closely related subject. The subject matters more here than in many graduate careers - employers generally expect you to have studied electronics or low-level computing somewhere. Physics and maths graduates do get in, usually with strong project evidence.
Typically a 2:1, though this varies: larger schemes and defence primes often filter at 2:1, while smaller firms frequently take a 2:2 if you interview well and can talk convincingly about a project you built.
Practical C programming. This is close to non-negotiable - most interviews include questions on pointers, memory, bitwise operations and how C maps onto hardware.
Evidence that you have actually built something physical. A final-year project, a placement, a robotics or Formula Student team, or a home project all count.
For defence, aerospace and some space roles, UK nationality and eligibility for security clearance, which can take months to come through. Worth checking before you apply.
Chartered engineer status (CEng, via the IET or IMechE) is not needed to start, but many employers expect you to work towards it and some roles are advertised as being on an accredited graduate development scheme.

Skills that matter

C programming close to the hardware

Most embedded firmware is written in C and you need to understand pointers, memory layout and how writing a value to a register physically changes what a chip does.

Debugging with physical instruments

When firmware misbehaves there is often no error message - you work out what happened by probing signals with an oscilloscope or logic analyser and reasoning backwards.

Reading and interpreting datasheets and schematics

Nearly every problem is eventually solved by finding the relevant paragraph in a manufacturer's documentation, so comfort with dense technical reference material is a daily advantage.

Understanding communication protocols such as I2C, SPI, UART and CAN

These are the standard ways chips and modules talk to each other inside a product, and almost every embedded project involves getting at least one of them working reliably.

Systematic, hypothesis-driven problem solving

Embedded bugs can come from software, hardware, timing, power or electrical noise, and you need a disciplined way of isolating which layer is at fault rather than guessing.

Version control and disciplined documentation

Firmware is shipped inside products that may be hard or impossible to update later, so teams rely on Git, code review and clear records of exactly which build went into which unit.

Where it leads

Graduate or junior embedded engineer: working on well-defined tasks - a driver for one peripheral, a test rig, a bug list - with a senior engineer reviewing your work.
Embedded engineer: owning a subsystem end to end, specifying it, writing it, testing it and supporting it through production. Most people reach this within a few years, though it depends heavily on how much hands-on product work you get.
Senior engineer: leading the technical design of a whole product's firmware, mentoring juniors, making the architecture calls and dealing with awkward integration and certification problems.
From senior level the path forks. One branch is technical - principal engineer, technical lead, systems architect or deep specialism in areas like safety-critical software, RF, power electronics or security. The other is managerial - engineering manager, head of engineering, or programme management. Timelines vary a lot and depend as much on company size as on ability.
Common sideways moves include field applications engineering (working with semiconductor customers), technical sales, hardware or FPGA design, test and verification, or starting a consultancy. Embedded skills also transfer well into robotics, automotive autonomy and IoT product management.

What people get wrong

“It's basically a software job, just on smaller computers.”

The hardware is not an abstraction you can ignore. You routinely care about how much current a chip draws, whether a signal has enough time to settle, electrical noise from a nearby motor, and whether the board will pass EMC testing. Engineers who treat the hardware as someone else's problem tend to struggle.

“You spend your days writing new code.”

A very large share of the work is debugging, reading documentation, testing and integration. It is normal to spend days chasing one intermittent fault that only appears when the device gets warm or when two things happen at once.

“Modern tooling has made it easy - you just use a vendor library and it works.”

Vendor libraries and auto-generated configuration code get you a demo running quickly, but production work means dealing with constrained memory, timing deadlines, power budgets, chip errata (documented bugs in the silicon itself) and products that must run unattended for years.

“Embedded work is a narrow niche with limited options.”

It sits inside almost every physical product sold - cars, medical equipment, energy infrastructure, trains, agricultural machinery, audio gear, payment terminals. The sector spread is wide, and engineers move between industries more often than you'd expect.

Where this varies

The balance of hardware and software differs enormously between employers, and the job title is used loosely. At some companies "embedded design engineer" means almost entirely firmware in C with no circuit design at all; at others it means schematic capture, PCB layout and board bring-up with only light coding. Read the advert carefully and ask at interview. Sector matters too: safety-critical industries such as automotive, medical devices, rail and aerospace involve heavy process, traceability and standards work (functional safety standards, design documentation, formal verification), which some engineers find reassuring and others find slow. Consumer electronics and start-ups move faster with far less paperwork but more schedule pressure. Geographically, embedded work clusters around Cambridge, Bristol, the Thames Valley, the Midlands (automotive), Scotland's central belt and the North West, with plenty of smaller pockets elsewhere - it is less London-centric than many graduate careers.

General guidance about the role across the UK market, not about any specific employer. Entry routes and requirements vary — always check the individual job advert.