All jobs / Mobile developer

Networking interview questions

Networking questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. The backend adds a field to a response and the shipped app starts failing to parse it. What should the client have done?

   The strongest answer: Ignored fields it does not know and required only the ones it uses, so a new server field is harmless — and failed loudly only when a field it needs is missing or the wrong type

   Why it works: Exactly — tolerant about what you accept, strict about what you actually need. That is what lets a server move.

   • Unknown fields must be harmless.
   • Require only what you use.
   • Ignore what you do not know.
   • Fail loudly on a missing required field.

2. A feed can be tens of thousands of items. How do you load it?

   The strongest answer: Page or cursor-load, virtualize the window, and cancel in-flight work for rows that scrolled away — do not fetch the world into an array

   Why it works: Exactly. Window the data and the views. Prefetch a little; do not ingest the corpus.

   • Cursor / page the API.
   • Virtualize the viewport.
   • Cancel work for offscreen rows.
   • Same idea as a virtualized web list.

3. A notes app edits offline and later meets a server that also changed. What do you do?

   The strongest answer: Queue the local mutation, detect the conflict on sync, and give a product rule — merge, last-write, or ask the user — do not silently drop either side

   Why it works: Exactly. Offline is a distributed-systems problem. Queue, detect, decide — in the product, not in a coin flip.

   • Persist a mutation queue.
   • Detect server-side versions / etags.
   • Have an explicit merge rule.
   • Never drop a write silently.

4. How do you avoid re-downloading a list that rarely changes, without showing stale data for ever?

   The strongest answer: The server sends a validator such as an ETag; the client sends it back and a 304 means reuse what it already has. A max-age says how long it may skip asking at all

   Why it works: Right — validation keeps the round trip but drops the payload, and freshness is a server decision you honour.

   • Validate instead of re-downloading.
   • Store the validator with the response.
   • A 304 means reuse what you have.
   • max-age decides when to ask again.

5. You are choosing how a field-sales app syncs. What do you put in the design doc?

   The strongest answer: Authoritative server versions, a mutation queue, conflict rules, and a story for partial upload / photo retries — not “eventual consistency” as a slogan

   Why it works: Exactly. Sync is a protocol. Write the rules and the failure modes.

   • Versioned records + a queue.
   • Named conflict rules.
   • Retry for large blobs.
   • Do not hide this behind a slogan.

6. On launch the app fires six requests at once. The access token has expired, and some users end up logged out.

   What is happening, and what do you build?

   The strongest answer: Six parallel failures each start their own refresh, and if the server rotates refresh tokens the later ones spend a token already used. Allow one refresh in flight, queue the callers, then retry each once

   Why it works: Exactly — it is a concurrency bug, not an auth bug, and single-flight plus one retry is the whole fix.

   • One refresh in flight.
   • Queue the callers; refresh once.
   • Retry each request exactly once.
   • Log out only when refresh fails.

7. Three apps will all work offline. What do you standardise?

   The strongest answer: A sync protocol, conflict rules, queue semantics, and observability (pending / failed / conflict counts) — not three clever local databases that cannot explain themselves to support

   Why it works: Exactly. Offline at org scale is a protocol and a support story.

   • One protocol, named conflicts.
   • Visible queue metrics.
   • Do not couple apps via a shared process.
   • Support must be able to explain a stuck sync.

8. The API was down for ten minutes. It fell over again the moment it returned, and the traffic was the app retrying.

   What do you change in the client?

   The strongest answer: Back off exponentially with jitter so phones do not return in step, cap the attempts, honour a Retry-After when the server sends one, and do not retry what cannot succeed, such as a 400 or a 403

   Why it works: Right — jitter is the part people forget, and it is what breaks the synchronised wave the outage created.

   • Never come back in step.
   • Exponential backoff with jitter.
   • Cap attempts; honour Retry-After.
   • Do not retry what cannot succeed.