5 skills you need to start a career in IoT

Auf dieser Seite

Understanding the nitty-gritty of sensors
Paying close attention to UI
Gaining experience in programming languages
Understanding wireless stacks and communication protocols
Proficiency in cloud programming and architecture
Five areas of an IoT system
Four components of an IoT product
References

IoT work sits where hardware, networking and software meet, so the entry skills are spread across all three. Whether you are fresh out of university or switching from another engineering job, these five are where I would start. The ordering and emphasis are my opinion. The protocol and cloud details are checked against the sources at the end.

Understanding the nitty-gritty of sensors

Sensors collect data from the physical world, and nothing else in an IoT system works without them. You will pick and wire them into your projects, so learn the common types first, such as temperature, motion and moisture sensors. Then learn the parts that bite later. Calibration, data accuracy and power management decide whether a device gives good readings for months or drifts and drains its battery in a week.

Paying close attention to UI

Most IoT products end up in front of someone who has never heard of a broker or a gateway. A clear interface is what makes the device usable for them. Learn the basics of layout, typography and color, and get comfortable with a prototyping tool such as Figma. A rough prototype in front of stakeholders early will save you from building the wrong screen.

Gaining experience in programming languages

Two languages cover most of what I have seen in IoT projects, Python and C/C++. Python is quick to write, so it suits prototypes, scripts and backend work. C/C++ is the usual choice for firmware on constrained devices, where memory and power are tight. A typical project touches both the firmware side and the server side, so learn enough of each to read the other team's code.

Understanding wireless stacks and communication protocols

Devices have to talk to each other, and wireless stacks define how they form a network. Zigbee is a low-power mesh network. Thread is one too, based on IEEE 802.15.4 and carrying IPv6. Bluetooth Mesh does the same job for Bluetooth Low Energy devices. Wired links matter just as much. I2C, SPI, 1-Wire, UART, Modbus and DALI are how you connect to sensors, actuators and lighting.

For messaging between devices and servers, learn MQTT early. It is a publish/subscribe protocol designed for small code footprints and tight bandwidth. Three ideas carry most of the weight.

Topics are case-sensitive and use "/" to separate levels, so home/kitchen/temperature and Home/Kitchen/Temperature are different topics.
Subscribers can use wildcards. "+" matches one level and "#" matches everything below a level.
QoS 0 means at most once, QoS 1 means at least once (duplicates are possible), and QoS 2 means exactly once.

You can try all three against a local Mosquitto broker. Start a subscriber in one terminal, then publish from another.

mosquitto_sub -h localhost -t "home/+/temperature" -q 1 -v
mosquitto_pub -h localhost -t home/kitchen/temperature -m 21.5 -q 1

The subscriber prints the topic and payload. Publish to home/garage/temperature and it matches the same filter. Publish to home/garage/humidity and it does not.

Check your broker's limits before you design around QoS 2. AWS IoT Core supports QoS 0 and 1 only, and when a client asks for QoS 2 the broker sends no acknowledgement. If your devices must tolerate duplicates anyway, design the message handlers to be idempotent from the start.

You will spend more time debugging these links than writing application logic, so the effort pays back.

Proficiency in cloud programming and architecture

The cloud is where IoT data usually gets stored and processed. You need two skills here, writing code against cloud services and designing how the pieces fit together.

Cloud programming

Pick one platform and learn it properly. AWS IoT Core and Azure IoT Hub are managed IoT services. AWS IoT Core speaks MQTT, HTTPS and LoRaWAN, and Azure IoT Hub provides a device identity registry, device twins and message routing. Check which platform your target employers use, because the services are not interchangeable. Google Cloud is a cautionary example. Google retired its IoT Core service on August 16, 2023, so teams on that platform now assemble their own pipeline from general services or partner products. One platform learned well still transfers better than three learned halfway, but keep your device code behind a thin layer so a vendor change does not mean a firmware rewrite.

Cloud architecture

Architecture is about structuring the application so it uses cloud resources efficiently. Think about data flow, scalability, redundancy and security. Good architecture keeps costs down and lets the system handle more devices without a rewrite.

Five areas of an IoT system

This is the lifecycle model I use when scoping a project. It is not an industry standard, and other authors split it differently.

Data ingestion. Sensors and devices send data to a central repository for processing.
Data analytics. The data is analyzed for patterns and trends, using techniques like machine learning and statistical analysis.
Device provisioning. Devices are configured to join the network, which means credentials and device-specific settings. Azure offers the IoT Hub Device Provisioning Service to enroll many devices at a time.
Device management. Once provisioned, devices need monitoring through their whole life. AWS IoT Jobs, for example, can send remote operations such as firmware updates, reboots and certificate rotation to a group of devices.
Security. Connected devices are exposed to attack. Both AWS IoT Core and Azure IoT Hub authenticate devices with credentials, and Azure supports X.509 certificates over TLS for devices that can manage them.

Knowing all five lets you see how your piece fits into the end-to-end system.

Four components of an IoT product

Same caveat as above, this is a working model and not a formal standard.

Devices. The physical objects that collect and transmit data, from simple sensors to industrial machinery. Know what each can and cannot do before you pick hardware.
Gateways. A gateway sits between devices and the cloud. It can aggregate data, translate protocols and do some processing locally. Azure's documentation notes that some devices are reachable only through your cloud services, for example behind a firewall.
Cloud. The infrastructure to store, process and analyze the data, as covered above.
UI/UX design. The interface decides whether people adopt the product or give up on it.