Mobile Developer Interview Questions: State, Failure, and Performance

Mobile developer interview preparation should include what happens when a user loses connectivity, leaves a screen, or returns after the operating system stops the app. Explain the user-visible contract before naming a library.

Android's offline-first guidance discusses local and network data, write strategies, and synchronization. It is Android guidance, not an iOS implementation recipe. The following original scenarios are architecture discussions, not production-ready code.

A user edits a note offline. What does saved mean?

Clarify whether the product promises local durability, synchronization across devices, or both. Those are different states.

For this fictional note app, assume a successful local write preserves the edit on the device, while another device sees it only after synchronization. A useful answer separates "saved on this device" from "synced." It also explains what the UI shows if synchronization fails.

Follow-up: What if the app closes before the network response arrives? Discuss how the pending operation can be recovered and how a retry avoids creating a duplicate logical edit. Do not equate a request being sent with it being accepted.

Two devices edit the same note. What happens next?

Ask what the product is allowed to discard and what the user expects. The correct conflict behavior for a personal note may differ from a shared approval record.

For the exercise, propose preserving both versions for review when automatic merging is unsafe. Explain the cost: more visible complexity and a user decision. Do not present "last write wins" as universally harmless or assume device clocks establish a reliable ordering.

A screen stutters. How do you investigate?

Define the action and environment first: scrolling a list, opening a screen, or updating text. Reproduce the same action and inspect the relevant platform performance tools before blaming a particular visual effect.

State a hypothesis, isolate the work that changes, and compare like conditions. A faster desktop simulator does not establish performance on a constrained phone. Explain how you would preserve the intended interaction while testing a lower-cost implementation.

How do you handle a response arriving after navigation?

Identify which state the response belongs to. A search result for an old query should not overwrite the current query's results. Discuss cancellation where available and a validity check before applying results; cancellation alone may not resolve every race.

Give a small sequence: query A starts, query B starts, B completes, then A completes. Explain which result should remain visible and how you would test it.

An illustrative answer might be:

I would associate each request with the query and screen state that initiated it. Before applying a response, I would check whether it still belongs to the current view. In this sequence, B remains visible. I would test both response orders and a navigation away before either response completes, rather than only testing a fast successful request.

This answer states an invariant: old work must not overwrite the result for the current request. The exact mechanism depends on the framework and ownership of the state; the interview answer should explain that choice, not merely name a cancellation API.

How would you test the offline workflow?

Turn the promised behavior into observable checks. For the fictional note app above:

Situation	Expected behavior to verify
The local save succeeds without connectivity	The note survives closing and reopening the app; the UI does not claim server synchronization
The connection returns and the server confirms the write	The pending state clears and the server version contains the intended edit
The server accepts the edit but the acknowledgment is lost	Retrying does not create a second logical edit
A second device changes the same note	The chosen conflict policy is applied without silently discarding a version the product promises to preserve

Describe how you would arrange each condition and inspect the result. "Test offline mode" is too vague to reveal whether you tested persistence, transport failure, retries, or conflicts. Also distinguish an automated test of the data layer from a device test of what the user actually sees.

What would stop a release?

Choose criteria tied to the change: data loss, broken authentication, an unrecoverable migration, or a critical interaction regression. Explain who owns the decision and how staged rollout or rollback fits the platform and data constraints.

Use technical interview preparation to practice explaining tradeoffs aloud. For broader fundamentals, see technical interview questions, while keeping platform-specific claims grounded in the documentation for the stack being discussed.