How to hire an IoT developer: skills, interview questions and costs
IoT projects mix hardware, radio and software, so the right hire depends on where your work sits. This guide explains what IoT developers do, the skills to check, questions to ask, what drives the price and how to get a new developer productive. For work deep inside the device, also see our firmware engineers.
What an IoT developer works on
An IoT system usually has four layers: the device with its sensors and firmware, the connection that carries data, the cloud that receives and stores it, and the app or dashboard people use. Few developers are equally strong in all four. Decide which layers are your main need, then look for depth there and enough knowledge of the rest to work well with the team.
Skills to check
- Firmware: embedded C or C++, interrupts, power modes and memory limits.
- Connectivity: choosing between BLE, Wi-Fi, Thread, LoRaWAN or cellular, and handling dropped connections.
- Cloud: MQTT, device identity, rules that route data, and a platform such as AWS IoT Core or Azure IoT Hub.
- Updates: signed over-the-air updates with a staged rollout and a way back.
- Security: per-device credentials, secure boot and no shared passwords in firmware.
- Debugging: logic analyzers, serial logs and patience with real hardware.
Questions worth asking
- A device in the field keeps dropping off the network. How do you find out why?
- How would you design over-the-air updates so a failed update cannot brick the device?
- How does each device prove who it is to the cloud?
- Battery life is half what we expected. Where do you look?
- Tell me about a product you shipped. What went wrong after launch and how did you fix it?
Good answers mention real tools and measurements and show they have dealt with devices outside the lab.
Example job post
Something like this works: “We are hiring an IoT developer to connect our ESP32-based sensors to the cloud and build the dashboard our customers use. You will maintain firmware in C, send data over MQTT to AWS IoT Core, set up signed over-the-air updates and build alerts. Must have: shipped connected devices, MQTT and embedded C. Nice to have: BLE provisioning apps and a time-series database.” Adapt our software engineer job description template for a fuller version.
What affects the cost
Breadth is the biggest factor: someone who can take a device from firmware to dashboard costs more than a specialist in one layer. Experience with products shipped in volume, regulated industries or low-power design also adds to the price. Location matters as with any remote hire. Remember hardware costs too: development boards and test devices for the developer. At DigiWorks, the developer’s pay and our fee are shown separately.
Choosing the right level
Match the level to the risk. A junior developer can extend dashboards, write test scripts and help with device logs, but should work under someone who has shipped hardware before. A mid-level developer can own a feature from firmware to cloud once the architecture is set. If you are designing a new device, choosing radios and cloud services, or planning how thousands of devices will be updated safely, choose a senior who has been through at least one product launch and the support work that follows it.
Hardware, tools and testing setup
Plan the developer’s kit before day one. They will need the same development boards and sensors you use, a way to flash and debug them, and access to a test account in your cloud platform that cannot touch live devices. Agree how prototypes are shipped and returned, and keep a small fleet of test devices that receives every update first. This setup costs little compared with an update that fails on customers’ devices.
A short paid task
For your final candidates, set a small paid task on cheap hardware or a simulator: read a sensor, publish over MQTT, recover from a lost connection and log what happened. Keep it to a few hours with the same brief for everyone, and read how they handled failures.
Freelance or dedicated
A freelancer is fine for a proof of concept. Once devices are with customers, the work never really stops: updates, new hardware revisions and field issues. A dedicated developer keeps that knowledge with you.
The first three months
In week one, ship the developer the hardware they need and give access to the code, cloud account and test devices. In the first month, they should deliver one small improvement end to end, from firmware to dashboard. By month three, they should own a part of the system and plan the next update or hardware revision with you.
Mistakes to avoid
- Shipping devices without a safe way to update them.
- Using one shared password or key for every device.
- Testing only on a lab Wi-Fi network instead of real conditions.
- Staying on a cloud service that has been retired or is about to be.
For more on building a remote engineering team, read our remote software engineering hiring playbook.