You're building a battery-powered sensor node that has to run for a year on a small battery. What firmware techniques would you use to make the battery last?
technical-conceptual · Junior level · software-engineering, embedded-iot
What the interviewer is really asking
Assesses practical understanding of low-power firmware design — duty cycling, sleep modes, interrupt-driven wakeups, and measuring the power budget — rather than reciting datasheet numbers.
What to say
- Lead with duty cycling: the radio and CPU should be off the vast majority of the time, with the part spending most of its life in a deep-sleep mode that draws microamps rather than the milliamps of active mode.
- Describe how the device wakes: an interrupt or a low-power timer, not a busy-wait, so the CPU only spins up for a valid event, takes a reading, transmits, and goes back to sleep.
- Mention that you'd actually measure it — profile the current in each state and compute an average so you can see which state dominates the budget, since the radio transmit burst is often the biggest single drain.
What to avoid
- Suggesting you keep the CPU running and just 'optimize the code,' which misses that sleep mode current, not instruction count, dominates a sensor node's lifetime.
- Polling a sensor or the network in a tight loop instead of sleeping and waking on an interrupt.
- Quoting battery life without ever measuring current draw, or ignoring that a single frequent radio transmission can swamp everything else.
Example answers
Strong: I'd keep the node in deep sleep almost all the time, drawing microamps, and wake on a low-power timer or a sensor interrupt to take a reading and transmit. The radio burst usually dominates, so I'd batch readings and transmit less often. I'd put a current meter on each state, work out the duty-cycle-weighted average, and check it against the battery's capacity to confirm a year is realistic.
Weak: I'd lower the clock speed and write efficient code so the CPU uses less power, and pick a bigger battery if it's not enough.