A Mobile Sync Interview Exercise With Conflicting Edits

TL;DR

• Use this fictional mobile-sync prompt: a field-service app lets workers edit a job note while offline.
• For the exercise, give each edit an identity and the record version on which it was based.
• Run the two edits in both arrival orders, repeat either operation, disconnect after server acceptance and restart the client before acknowledgment.

Make the conflict concrete

Use this fictional mobile-sync prompt: a field-service app lets workers edit a job note while offline. Two devices start from the same version, make different edits and reconnect in the opposite order from when the edits were made. The interviewer asks how the app should resolve the conflict.

First ask what the note represents. Free text, a checklist, an assignment and an approval state have different conflict risks. A single merge rule for the whole record can preserve one field while silently damaging another.

Do not begin with “last write wins” without defining last according to which clock and why that outcome serves the user. Device clocks can differ, and arrival order is not necessarily edit order. More importantly, even a perfectly known order may not make overwriting the earlier contribution acceptable.

Track the base version

For the exercise, give each edit an identity and the record version on which it was based. When an update arrives, compare that base with the current server state. This lets the system distinguish an ordinary update from one built on stale information.

These are design options to discuss, not a production-ready protocol. Explain the data and workflow assumptions that make each option safe enough for the fictional task.

Walk through a worked conflict

Device A changes “replace filter” to “inspect filter before replacement.” Device B appends “customer requested afternoon visit” to its older copy. Replacing the entire note with whichever copy arrives last can lose either the instruction change or the scheduling context.

A field-aware or operation-aware model may preserve some independent changes. But if both users rewrite the same instruction, an automatic textual merge can still produce a misleading sentence. Retain the competing versions and show a resolution workflow where human judgment is necessary.

The interface should explain that a conflict occurred and identify the relevant versions without exposing unrelated private data. A silent success message is inappropriate if the user's text was discarded. Decide whether unresolved conflicts block other work or can be resolved later, based on the task's consequences.

Separate retries from new edits

After reconnecting, the device may resend an operation because it never received the acknowledgment. Stable operation identity helps distinguish that retry from another deliberate edit. Persist enough processing state to make the chosen retry semantics meaningful across worker restarts.

A server acknowledgment should identify what was accepted and which resulting version the client should use. The client should not delete its local pending edit merely because it opened a network connection. Likewise, a conflict response should preserve the user's work until it is resolved or explicitly discarded.

Describe what happens after application restart, device loss or partial synchronization. You do not need to solve every platform detail in one interview, but identify which local data must survive for the proposed workflow to hold.

Include deletion and authorization

Now let one device delete the job while another remains offline editing it. Decide whether the late edit can recreate the job, is rejected or enters a recovery flow. A deletion marker and retention policy may be needed to recognise stale operations; simply removing the current row can erase the evidence required to make the decision.

Authorization must also be checked when processing an offline edit. Permission at the time of download does not necessarily authorise a later update after membership changes. Explain how the app preserves the local work for an appropriate user-facing outcome without accepting an unauthorised write.

Our system design frameworks guide can help you show the separate roles of versioning, conflict policy and access control.

Test permutations rather than one happy path

Run the two edits in both arrival orders, repeat either operation, disconnect after server acceptance and restart the client before acknowledgment. Add the deletion and permission-change cases. For each, state the resulting record, the remaining local work and the message the user sees.

If your chosen rule depends on a field being independent, test a counterexample where it affects another field. A schedule change may invalidate an earlier assignment or approval even if the database columns differ.

Finish by stating which conflicts resolve automatically and which require a person. In a mock interview session, practise explaining that boundary before naming an algorithm. The useful design preserves user intent as far as the task allows and makes unavoidable uncertainty visible instead of treating synchronization as a silent overwrite contest.