An IoT device maker advertises for a 'software engineer, C and Python'. Hundreds of applications arrive from web developers and manual testers. After a fortnight of screening, nobody on the pile has written an interrupt handler or read a datasheet end to end. The search did not fail for want of talent. It failed at the first line of the brief.
Software roles inside electronics firms are odd hybrids. They live between a board on the bench and a service in the cloud. This guide covers where to begin when hiring them, and how our IT specialised recruitment work approaches the problem. For the wider people picture, see the electronics and embedded systems sector page.
Name the software roles you really have
- Firmware engineers: bare-metal or RTOS code on microcontrollers, peripheral drivers, bootloaders and power management.
- Embedded Linux developers: board support packages, device tree work, kernel drivers and Yocto or Buildroot images on application processors.
- Cloud and backend developers: device provisioning, telemetry ingestion, dashboards and over-the-air update services.
- Mobile app developers: pairing, commissioning flows and user controls for connected devices.
- Test automation engineers: scripts that drive test jigs, simulate devices and run regression on every firmware build.
- Build and release engineers: continuous integration for firmware, image signing and release records.
A small firm may fold several of these into one person. Decide which combination you need now, and which pieces can be learned after joining.
Begin with the brief, not the portal
- 1
Describe the product first
List the chip family, the operating environment, the radios, the sensors and the cloud platform the developer will touch.
- 2
Separate must-have from learnable
Interrupt discipline, tight memory budgets and datasheet reading are slow to teach. A particular vendor's IDE usually is not.
- 3
Describe the bench
Will they use an oscilloscope, a logic analyser and a debug probe daily? Say so. It filters out people who want pure application work.
- 4
Name the neighbours
Hardware designers, test technicians, the cloud team or customers. This tells candidates what the job feels like day to day.
- 5
Check pay role by role
App and cloud developers are priced against software firms; firmware engineers against chip vendors and product companies. Benchmark each on its own.
- 6
Fix the assessment before sourcing
Agree who will review code and which exercise they will use before the first CV lands.
Product and stage: ________.
Processor or microcontroller family: ________.
Bare metal, RTOS or embedded Linux: ________.
Buses and radios in use: ________.
Bench tools used daily: ________.
Needed on day one: ________.
Can be learned in the first months: ________.
Sits beside: ________.
Technical assessor and exercise: ________.Where these developers gather
Firmware and embedded Linux people cluster in a few pockets: chip vendor ecosystems, automotive and industrial electronics teams, design houses and university labs that build real hardware. Open-source driver patches, hobby boards and public repositories show real work. Cloud and app developers are easier to find and harder to keep, since software firms court them constantly. Referrals from your own engineers often beat every other channel, provided the brief is sharp enough for them to recognise the right person.
Assessment that resembles the job
- A short driver or interrupt routine with a planted race condition, to be found and explained.
- A captured SPI or UART trace showing a failed handshake, with the question of what went wrong.
- A design chat about how a device should accept an over-the-air update without bricking in the field.
- For cloud roles, a discussion of thousands of devices reporting at once and what happens when one falls silent.
- For app roles, a walk through a Bluetooth pairing flow and its failure cases.
Keep exercises short and live where you can, and ask candidates to reason aloud. An engineer the candidate will respect should run the technical round, because strong candidates judge the firm by the quality of its questions. Our post on briefs and skills tests for specialist roles covers the general method for any business.
Making the offer land
Developers with embedded depth often hold two offers at once. Move from final round to written offer inside a few days. Spell out the lab access, the hardware they will own, the hybrid pattern and the learning budget, not only the salary. Mention the boards on the roadmap; a candidate weighing a bank's app team against your gateway product wants to know what they will actually build.
Plan the first month before the joining date. Order the laptop, the debug probe and repository access in advance. Pick a small first fix on a real product, such as a driver timeout or a flaky sensor read, so the new developer ships something in week two. A developer who spends ten days waiting for a dev kit starts rereading the other offer.
Role descriptions matter as much as sourcing. See role design for connected device makers and how embedded design houses define engineering roles for writing a role the right people will recognise.
