“Design a smart home app” is a senior+ mobile system design that combines protocol heterogeneity, real-time control, automations, and the unique reliability expectations of “the lights need to turn on now.” Google Home, Apple Home, Amazon Alexa, Samsung SmartThings, Home Assistant are the references. The interview tests how you reason about an ecosystem of mismatched protocols.
Clarify scope
- Single-protocol or multi-protocol (Matter, Zigbee, Z-Wave, Thread, BLE, Wi-Fi)?
- Voice control included?
- Automations (routines, geofence)?
- Hub-on-device or cloud-hub?
- Multi-user (family) support?
Protocol landscape in 2026
- Matter: the unifying standard; runs over Wi-Fi or Thread; Apple/Google/Amazon all support
- Thread: low-power mesh for battery devices; Matter-friendly
- Zigbee: still common; older but huge installed base
- Z-Wave: niche; primarily security devices
- Wi-Fi: for cameras, larger devices
- BLE: direct-control devices (locks, light switches)
Architecture overview
- Device discovery (mDNS / Matter onboarding / vendor-specific)
- Pairing with credentials
- Local control via hub or direct connection
- Cloud control as fallback or for remote access
- State sync between local and cloud
- Voice / app interface
Local vs cloud control
The defining architectural choice:
- Local-first: Apple Home, Home Assistant, Hubitat. Faster, more reliable, more private. Limited to Wi-Fi/Thread/Zigbee with hub.
- Cloud-first: Alexa, original Google Home. Easier setup, broader compatibility, dependent on internet for everything.
- Hybrid: Modern Google Home and SmartThings — local execution where possible, cloud as fallback.
Device discovery and pairing
- Matter: scan QR code / 11-digit code; ephemeral BLE for commissioning; Wi-Fi or Thread credentials passed
- Wi-Fi devices (vendor-specific): SoftAP mode, app connects, credentials shared
- BLE devices: direct app pairing
- Onboarding UX is the highest-friction part of smart home; design it carefully
State sync
- Each device has a state model (on/off, brightness, color, lock/unlock, etc.)
- State updates pushed via WebSocket / MQTT / vendor protocols
- Optimistic local updates for responsiveness
- Conflict: latest-write-wins per attribute
- “Phantom” updates from physical button presses must propagate
Automations and scenes
- Routine: ordered list of actions (“turn off lights, lock door, set thermostat”)
- Trigger: time, location (geofence), device event, voice
- Conditions: only run if X (someone home, time of day)
- Local execution preferred; cloud fallback
- Visual editor for routines (modern apps trend toward “if this, then that” style)
Geofencing
- iOS / Android geofence APIs trigger when entering or leaving regions
- Use significant-location-change for battery efficiency
- Latency tolerance: a few minutes is acceptable for “I am home”
- Privacy: location stays on device; only events transmitted
Voice control
- Native: “Hey Siri / Hey Google / Alexa” with smart home skill
- App-launched voice using Apple Speech / Android Speech
- Wake-word detection on-device for privacy
- Cloud transcription + intent recognition
Notifications
- Door/window opened
- Motion detected
- Camera person/package detection
- Routine failure (“could not unlock door”)
- Device offline / battery low
- Per-device opt-in granular
Multi-user / family
- Per-member presence (geofence)
- Per-member access controls (kids cannot disarm alarm)
- Shared automations
- Activity log of who did what
Reliability expectations
The unforgiving part:
- “Turn off the lights” in 1 second — local execution helps
- Door locks must work when internet is down
- Hub must be redundant or local-fallback
- Failure modes must be obvious to the user
Privacy considerations
- Camera footage: local-stored vs cloud-stored — disclose
- Voice recordings: history, retention, deletion options
- Activity log: who can see who did what
- Third-party device access: explicit permissions; revocable
Camera and video
- RTSP or proprietary stream from camera
- WebRTC for live view from app
- HLS for recorded clips
- On-device ML for person/package detection (Apple Home, modern devices)
- Encrypted storage and transmission
Edge cases interviewers love
- Internet drops; user wants to turn off lights — local execution if possible
- Hub crashes; how is failure visible?
- Two users issue conflicting commands
- Device firmware update mid-routine
- Family member added; what is shared automatically vs requires consent
What separates senior from staff
Senior candidates draw the protocol-and-state architecture. Staff candidates address the local-vs-cloud tradeoff, the multi-protocol bridging, and the reliability expectations. Principal candidates raise the multi-user privacy story and the operational reality of supporting hundreds of device types.
Frequently Asked Questions
Will Matter solve everything?
Helps but does not erase legacy devices. Most users have a mix of Matter, Zigbee, Wi-Fi, and BLE devices. Apps must handle the heterogeneity for years.
What about Home Assistant?
The OSS reference architecture for local-first smart home. Worth studying as a comparison. App layer of Home Assistant is a useful reference for the multi-protocol UX.
How do I handle camera streaming bandwidth?
Lower-resolution preview by default; full resolution on tap. Adaptive bitrate. Edge compute (on the camera) for motion detection to avoid streaming when nothing is happening.