Design a Smartwatch Sensor Subsystem
Design the sensing subsystem of a smartwatch that measures heart rate and activity all day and during workouts. This is a system-level question that spans hardware, firmware and algorithms rather than a distributed-systems one.
Constraints: the watch has a battery of roughly 1 Wh that must last well over a day, so continuous sensing gets a budget of a few milliwatts on average; the sensor window on the back is a few square centimetres; and readings must hold up on a moving, sweating wrist across skin tones, ages, tattoos, cold weather and loose straps. A wrong heart rate shown confidently is worse than no reading.
Cover: which sensors you choose and why; the trade-offs among accuracy, power, size and reliability; the architecture from sensor to application processor; the signal processing and how it stays robust; how hardware and firmware are integrated and calibrated; how you validate and debug the system; and how you work with component suppliers on quality.
Hints
Hint 1
Optical heart rate (PPG) is dominated by LED power and corrupted by motion. Those two facts drive everything: adaptive LED current and sampling rate for the power budget, and an accelerometer sampled on the same clock as the noise reference for artifact rejection.
Hint 2
Keep the application processor asleep. An always-on low-power sensor hub samples, buffers in hardware FIFOs, runs the first stage of signal processing, and wakes the main processor only in batches or on events.
Hint 3
Output a confidence with every reading, and define validation before you build: reference devices, a participant matrix that covers skin tone and activity, recorded raw datasets you can replay through every new firmware build.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.