Device Capabilities interview questions
Device Capabilities questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
The feature is “attach a photo to a report”. Do you build a camera screen inside the app?
The strongest answer: Not first. Hand off to the system camera or photo picker: users know it, it needs far less access, and there is much less to maintain. Build capture in-app only if the flow truly demands it
Why it works: Exactly — the hand-off is less code, less permission and a UI the user has used a hundred times.
- Hand off before you build.
- Prefer the system camera or picker.
- Ask only for what the flow needs.
- Build capture only when required.
A step-counting screen keeps draining the battery long after the user has moved on to another screen. What do you check first?
The strongest answer: Whether the sensor listener is unregistered when the screen stops. Registration follows the screen’s lifecycle — start when it becomes visible, stop when it does not — and the sample rate should be the slowest that works
Why it works: Right — a sensor you forgot to stop is a background drain with no UI, and the rate is the other half of the cost.
- Register with the screen, unregister with it.
- Start when visible, stop when hidden.
- Pick the slowest usable rate.
- Never leave a sensor running.
The feature is “attach one photo.” Which permission story is right in 2026?
The strongest answer: Use the system photo picker / share sheet so I do not need broad storage or full photo-library access — ask for more only if the product truly needs a gallery browser
Why it works: Exactly. Least privilege. The picker is the default; broad access is a review and trust cost.
- Prefer the system picker.
- Ask for library access only when you browse it.
- Purpose strings must match.
- Do not hoard the camera roll.
You add biometric unlock. What else must exist?
The strongest answer: A passcode fallback, a clear lockout, and a server session that still expires — biometrics unlock a local key, they do not replace authz
Why it works: Exactly. Local unlock + real session expiry + a fallback. Never ship templates off-device.
- Fallback passcode.
- Session still expires on the server.
- No biometric data on your API.
- Unlock a key; do not replay a password.
Product asks for location “always” so a map feels snappier. What do you do?
The strongest answer: Challenge the need: while-in-use is the default; always is a review, battery, and trust cost with a visible disclosure — I will not add it for a snappier first paint
Why it works: Exactly. Always-location is a product and policy decision, not a performance trick.
- Default to while-in-use.
- Always needs a real feature and a disclosure.
- Foreground services need an honest notification.
- Do not use location as a cache for UI speed.
A delivery app asks for the highest-accuracy location updates continuously so the map pin never lags. How do you decide what to request?
The strongest answer: By what each moment needs: highest accuracy and fastest updates only while the user is actively following the map, coarser and slower otherwise, and no updates at all when nothing is using them
Why it works: Right — accuracy is a dial you turn per screen and per state, not a setting you choose once for the app.
- Accuracy is a battery setting.
- Match accuracy to the moment.
- Slow down when nothing is watching.
- Stop updates you are not using.
Product wants the app to notice NFC tags as the user walks past them, with the app closed. What do you tell them?
The strongest answer: Reading a tag is a deliberate tap: the user brings the phone to the tag. The system may launch the app from a tag it recognises, but an app cannot sit in the background scanning for tags
Why it works: Right — and that reframes the product question: design a flow around a tap, and use the tag to launch the right screen.
- A tap is a user gesture.
- The user brings the phone to the tag.
- No background scanning for tags.
- Design the flow around the tap.
A field app talks to a Bluetooth sensor. In the lab it is solid; in the field users say it “just stops”.
How do you design the connection?
The strongest answer: As a state machine that expects to lose the link: scan, connect, discover, subscribe — and on a drop, reconnect with backoff and rebuild the subscriptions. Bluetooth off and out of range are states, not crashes
Why it works: Exactly — the field is interference, range and a phone that sleeps, so the design has to make losing the link ordinary.
- Assume the link will drop.
- Model it as a state machine.
- Rediscover and resubscribe on reconnect.
- Back off instead of scanning forever.