Embedded Firmware Engineer

If you've worked in regulated or safety-critical environments, that's a plus - you'll already understand the level of rigour expected.

Experience with comms protocols like UART, RS232 or CAN will help, especially when you're digging into system behaviour.

If you've touched test frameworks, automation, or built test setups before, even better.

Basic electronics knowledge goes a long way here - being able to read a schematic or understand what the hardware's doing will make your life easier.

Exposure to C#, or .NET is useful, but not essential. Tools & environment

You'll be working with embedded C/C++, standard version control (Git), and a mix of debugging and test tools. Nothing overly restrictive - the focus is on getting the job done properly. The practical bits

This is for someone who's comfortable getting hands-on. Someone who can plug into a board, trace a fault, challenge assumptions, and help ship something solid.

You'll be in the guts of embedded systems, working alongside engineers who actually build the thing. Code, hardware, firmware - all of it. The brief is simple: make sure it works properly, under real conditions, not just in theory. What you'll be doing

You'll sit inside a multi-disciplinary engineering team, not off to the side.

Day to day, that means validating embedded software and firmware running on real hardware - not simulators alone. You'll be setting up tests, breaking things (on purpose), figuring out why they broke, and working with the people who wrote the code to fix it.

You'll help shape how testing is done - environments, tooling, approach. If something's clunky or inefficient, you'll be expected to improve it.

There's a strong system-level angle here too. You'll be looking at fully integrated products - software, electronics, and mechanical elements all working together - and making sure they behave as they should in the real world.

It's an Agile setup, so you'll be part of stand-ups, reviews, and the usual cadence. Nothing ceremonial - just enough structure to keep things moving.

And yes, you'll document what matters: what you tested, what failed, what got fixed. What you need to bring

You've worked with embedded software, low-level stuff, typically in C or C++. You understand how it interacts with hardware because you've seen it, not just read about it.

You've done testing, validation, or debugging in a real system - not just writing test cases in isolation. You know how messy things get when hardware's involved, and you're comfortable operating in that space.

You understand the software lifecycle, but more importantly, you know where testing actually adds value within it.

This role suits someone who's practical. You don't wait for perfect specs - you get stuck in, investigate, and move things forward. Useful extras (not deal-breakers)