Assess the work
Mobile engineer interview scorecard: offline work and interrupted sync
Assess an inspection app that must preserve work in a basement with no signal, recover when an acknowledgement is lost and explain a server-side reassignment without hiding or overwriting the user’s notes. Score only evidence elicited by the timed core prompts.
Run a bounded 60-minute mobile discussion
This is a discussion about one native field-inspection workflow, not a coding-speed test or validated selection instrument. State whether the role's path is iOS/Swift or Android/Kotlin. Both are valid; candidates need not demonstrate both. Share scenario, timing and adjustment contact in advance; rate independently before discussing evidence.
| Minutes | Scored competency | Fixed core prompt | Stop rule |
|---|---|---|---|
| 0–5 | Orient, unscored | “What facts would you clarify before deciding what the app promises offline?” | Read the scenario; clarify only supplied facts and terms. |
| 5–16 | Local persistence and lifecycle | “What must be saved for this visit to be safe to leave, close and reopen? Where would you draw the acknowledgement boundary?” | Capture persisted records, save boundary and a lifecycle check; stop at minute 16. |
| 16–28 | Retry and duplicate prevention | Reveal timeout-after-possible-commit. “What is the safe retry behavior, and what must client and service agree on?” | Capture operation identity, unknown outcome and service contract. |
| 28–40 | Conflict and reconciliation | Reveal reassignment revision 13. “What do you preserve, compare and ask the service to resolve?” | Capture base/local/server state and a non-destructive next step. |
| 40–51 | User feedback and recovery | “What should the technician see now, what action is safe, and what should happen after the app restarts?” | Capture truthful status and accessible recovery; add no second failure. |
| 51–57 | Platform/account boundary | “The technician signs out with a visit still queued. What must remain available, and who decides what may sync later?” | Capture account, privacy and retention ownership without inventing policy. |
| 57–60 | Close, unscored | “Which unresolved product or server decision would you verify first?” | Do not create a new scored competency. |
Global stop rule: move on at each stage boundary. If a prompt is missed, mark that competency NO and use the same follow-up opportunity for candidates in the stage. Optional library discussion is unscored and does not replace a core prompt.
Interviewer references: Android's offline-first data layer; Apple on persistence across launches and background transfers. Framework behavior does not decide product conflict or feedback policy.
Give the candidate the complete scenario
The packet contains all scenario facts and instructions, without interviewer-only anchors.
The candidate artifact is self-contained for printing.
This is a 60-minute design discussion, not a coding-speed test. Choose the role’s iOS/Swift or Android/Kotlin path; you are not required to know both. Explain assumptions and recovery choices using the supplied facts.
Scenario: inspection saved in a basement
A field-service app downloads technician Mara's assigned inspection, Visit V-418, from the service before she enters a basement. The visit is at server revision 12. She records three observations and two photo attachments, then taps “Finish inspection” without network signal. Product says the inspection must remain usable offline; the team has not specified whether photos must upload before the visit can be considered complete.
The app confirms one edit locally. The operating system then terminates the app. When Mara reopens it, the visit must show what was retained and what is still pending. No server request is confirmed yet.
Later, signal returns. A submission request times out. The service may have committed the inspection, but the app received no response. The client can retry. A dispatcher has also reassigned the visit, creating server revision 13 while Mara was offline. The merge contract for observations and reassignment is not supplied.
Explain what you would persist, send or retry, what you need from the service owner, and what Mara should see at each point. You may ask for any stated fact to be repeated. Do not assume device time settles the conflict. This is discussion only; no live app, account, code or customer data is involved. No particular database, sync library, cloud or architecture is required.
Score local persistence and lifecycle reasoning
Fixed prompt, 5–16: “What must be saved for this visit to be safe to leave, close and reopen? Where would you draw the acknowledgement boundary?”
Seek a distinction between transient view state and visit observations/attachment references that must survive. Candidate should explain what a local-save confirmation means, how to avoid a partial record that appears complete, and how to test process termination and relaunch with synthetic data. The prompt does not specify whether photo upload is required before task completion; expect that missing product rule to be named.
Fixed follow-up: “Which exact information should be present after reopening, and what is still unknown?” Stop at minute 16; do not score a framework name without a durability boundary and test.
Probe account, authorization and queued-work boundaries
Fixed prompt, 51–57: “The technician signs out with a visit still queued. What must remain available, and who decides what may sync later?”
Local persistence does not bypass authorization or define retention. Look for the account owner, server authorization check, local-display boundary and product/security policy needed before deciding whether queued work remains, is blocked for the same user or is removed under a defined rule. The candidate should not invent company policy or put customer data in logs.
Fixed follow-up: “What should happen if a different technician signs in on the same device before the queue is resolved?” Record the policy question and a safe interim state; do not prescribe deletion or cross-account sync without a stated rule.
Stage the unknown outcome and server conflict
Stage 1, minute 16: the process ended after a local edit. Ask what is recoverable and what “saved” may honestly mean.
Stage 2, minute 16–28: “The submission request timed out. The service may already have committed it. What is the safe retry behavior, and what must client and service agree on?” Look for durable pending intent and stable identity or an equivalent service contract. A timeout alone does not establish rollback.
Stage 3, minute 28–40: reveal revision 13 and dispatcher reassignment. “What do you preserve, compare and ask the service to resolve?” The base revision, local notes and incoming assignment are distinct facts. Do not reward replacing notes or inventing whether the technician may submit after reassignment.
Stage 4, minute 40–51: “What should Mara see now, what action is safe, and what should happen after the app restarts?” Expect distinct local-save, waiting, unknown/retrying and needs-review states.
Stopping rules: add no new conflict facts, do not claim a server merge contract, require a named library, or shorten later prompts to recover time. Ask the same fixed question and follow-up for each candidate.
Android's offline-first documentation treats local writes, queued writes and conflict resolution as separate choices. Apple documents persistent storage and background sessions, but neither mechanism promises a particular sync result or execution time: Android offline-first, Apple ModelContext and Apple background transfers.
Rate only the evidence each timed prompt elicited
Write the stated choice, assumption or question before rating. Scores describe evidence for the brief's scope; do not total them or turn them into an automated recommendation. An omitted interviewer prompt is a process gap, not a candidate failure.
Worked calibration
Partial retry evidence: The candidate says “try again when online” but cannot tell whether the first request committed, does not retain a pending operation identity and does not ask how the service recognizes replay. Rate retry 1 if the fixed prompt and follow-up leave duplicate-effect risk unresolved. If they retain a stable operation ID, mark outcome unknown and request an idempotent service response, that is at least 3 for the stated evidence; do not require a particular token format.
NO example: If the agenda ends before sign-out is discussed, mark the account-boundary dimension NO with “prompt not reached.” Do not infer it from local-storage reasoning.
Scale: 1 = material gap remains after the fixed prompt; 2 = partial evidence with a meaningful gap; 3 = workable evidence for this role's stated scope; 4 = level 3 plus independent handling of an important interaction; NO = not enough fair evidence. Record the reason for NO. Do not convert it to zero or infer it from another score.
| Competency and eliciting prompt | 1 · Gap | 3 · Meets this role | 4 · Strong evidence |
|---|---|---|---|
| Local persistence and lifecycle, 5–16 | Treats visible screen state or a request callback as durable, or cannot explain what survives leaving and reopening. | Identifies visit data and pending edits that must persist locally, states when the UI can claim “saved on this device,” and proposes a process-recreation check. | Separates durable records from transient UI state, covers partial writes/attachments and recovery, and ties acknowledgement to a tested save boundary. |
| Retry and duplicate prevention, 16–28 | Assumes timeout means no commit or retries a non-idempotent action without identifying duplicate consequences. | Labels the outcome unknown, retains the operation for retry, and asks for stable request identity or equivalent service-supported deduplication. | Explains response loss, repeated delivery and changed payload; preserves the original operation and verifies the canonical result. |
| Conflict and reconciliation, 28–40 | Overwrites local notes from revision 13 or selects a winner from device clock alone. | Preserves base, technician edits and server revision; identifies overlapping fields and proposes a domain-owner resolution path. | Defines a field-aware merge or explicit review state, records provenance/version and makes retry safe after resolution. |
| User feedback and recovery, 40–51 | Shows “complete” or an indefinite spinner while save/sync is unknown and offers no safe next step. | Distinguishes saved locally, waiting, retryable failure and needs review; explains status after restart and an accessible recovery action. | Pairs each state with what the user can safely do, exposes last confirmed sync and ensures failures do not hide retained work. |
| Platform/account boundary, 51–57 | Assumes queued work can sync after sign-out without checking identity, authorization, retention or policy. | Names the account/data boundary and asks the owner to define whether queued work is retained, blocked or removed. | Connects local access, logout, credentials, pending operations and diagnostics to explicit owners and a verifiable transition. |
For every dimension, 2 means relevant reasoning is present but a significant issue remains or the candidate needs substantial prompting. NO means the timed prompt was skipped, interrupted, unclear or changed by an adjustment so evidence was not fairly elicited. Record why and arrange the same follow-up for candidates in that stage.
Interviewers score independently, then discuss recorded evidence and role boundaries. If an answer depends on unspecified photo, reassignment or retention policy, credit the candidate for naming the owner and record it as an open job-design question.
Print the self-contained interviewer packet
Use the packet for job-related evidence and follow the organization's candidate-data access and retention rules.
This artifact repeats scenario facts, timed prompts, anchors and blank evidence sheet.
Mobile engineer interview: offline field inspection, fixed 60-minute agenda
This is a 60-minute design discussion, not a coding-speed test. Choose the role’s iOS/Swift or Android/Kotlin path; you are not required to know both. Explain assumptions and recovery choices using the supplied facts.
| Minutes | Scored competency | Fixed core prompt | Stop rule |
|---|---|---|---|
| 0–5 | Orient, unscored | “What facts would you clarify before deciding what the app promises offline?” | Read the scenario; clarify only supplied facts and terms. |
| 5–16 | Local persistence and lifecycle | “What must be saved for this visit to be safe to leave, close and reopen? Where would you draw the acknowledgement boundary?” | Capture persisted records, save boundary and a lifecycle check; stop at minute 16. |
| 16–28 | Retry and duplicate prevention | Reveal timeout-after-possible-commit. “What is the safe retry behavior, and what must client and service agree on?” | Capture operation identity, unknown outcome and service contract. |
| 28–40 | Conflict and reconciliation | Reveal reassignment revision 13. “What do you preserve, compare and ask the service to resolve?” | Capture base/local/server state and a non-destructive next step. |
| 40–51 | User feedback and recovery | “What should the technician see now, what action is safe, and what should happen after the app restarts?” | Capture truthful status and accessible recovery; add no second failure. |
| 51–57 | Platform/account boundary | “The technician signs out with a visit still queued. What must remain available, and who decides what may sync later?” | Capture account, privacy and retention ownership without inventing policy. |
| 57–60 | Close, unscored | “Which unresolved product or server decision would you verify first?” | Do not create a new scored competency. |
Scenario facts for Visit V-418
- Mara downloads Visit V-418 at server revision 12 before entering a basement.
- She records three observations and two photo attachments without signal. Product requires offline use but has not decided whether photos must upload before “complete.”
- One local edit is confirmed. The operating system terminates the app. On reopen, retained and pending work must be distinguishable; no server request is confirmed yet.
- After signal returns, submission times out after the service may have committed it. The client can retry.
- A dispatcher reassignment creates server revision 13. The merge contract for observations and assignment is unspecified.
Fixed prompts and evidence to record
- 5–16, persistence: “What must be saved for this visit to be safe to leave, close and reopen? Where would you draw the acknowledgement boundary?” Follow-up: “Which exact information should be present after reopening, and what is still unknown?”
- 16–28, retry: “The submission request timed out. The service may already have committed it. What is the safe retry behavior, and what must client and service agree on?” Record stable identity, unknown outcome and deduplication contract.
- 28–40, conflict: “Revision 13 shows a dispatcher reassignment. What do you preserve, compare and ask the service to resolve?” Record base/local/server state, changed fields and non-destructive resolution.
- 40–51, feedback: “What should Mara see now, what action is safe, and what should happen after the app restarts?” Record truthful saved/waiting/unknown/review state and accessible recovery.
- 51–57, account: “The technician signs out with a visit still queued. What must remain available, and who decides what may sync later?” Follow-up: “What if another technician signs in on the same device?” Record account and retention owners; do not invent policy.
Role-specific anchors
Scale: 1 = material gap remains after the fixed prompt; 2 = partial evidence with a meaningful gap; 3 = workable evidence for this role's stated scope; 4 = level 3 plus independent handling of an important interaction; NO = not enough fair evidence. Record the reason for NO. Do not convert it to zero or infer it from another score.
| Competency and eliciting prompt | 1 · Gap | 3 · Meets this role | 4 · Strong evidence |
|---|---|---|---|
| Local persistence and lifecycle, 5–16 | Treats visible screen state or a request callback as durable, or cannot explain what survives leaving and reopening. | Identifies visit data and pending edits that must persist locally, states when the UI can claim “saved on this device,” and proposes a process-recreation check. | Separates durable records from transient UI state, covers partial writes/attachments and recovery, and ties acknowledgement to a tested save boundary. |
| Retry and duplicate prevention, 16–28 | Assumes timeout means no commit or retries a non-idempotent action without identifying duplicate consequences. | Labels the outcome unknown, retains the operation for retry, and asks for stable request identity or equivalent service-supported deduplication. | Explains response loss, repeated delivery and changed payload; preserves the original operation and verifies the canonical result. |
| Conflict and reconciliation, 28–40 | Overwrites local notes from revision 13 or selects a winner from device clock alone. | Preserves base, technician edits and server revision; identifies overlapping fields and proposes a domain-owner resolution path. | Defines a field-aware merge or explicit review state, records provenance/version and makes retry safe after resolution. |
| User feedback and recovery, 40–51 | Shows “complete” or an indefinite spinner while save/sync is unknown and offers no safe next step. | Distinguishes saved locally, waiting, retryable failure and needs review; explains status after restart and an accessible recovery action. | Pairs each state with what the user can safely do, exposes last confirmed sync and ensures failures do not hide retained work. |
| Platform/account boundary, 51–57 | Assumes queued work can sync after sign-out without checking identity, authorization, retention or policy. | Names the account/data boundary and asks the owner to define whether queued work is retained, blocked or removed. | Connects local access, logout, credentials, pending operations and diagnostics to explicit owners and a verifiable transition. |
For every dimension, 2 means relevant reasoning is present but a significant issue remains or the candidate needs substantial prompting. NO means the timed prompt was skipped, interrupted, unclear or changed by an adjustment so evidence was not fairly elicited. Record why and arrange the same follow-up for candidates in that stage.
Optional unscored discussion: SwiftData, Room, background scheduling, conflict algorithms or a second native platform. None replaces the timed core or changes these ratings.
Role / level: ____________________________________ Date: ______________
Candidate identifier: __________________________ Interviewer: __________________
Evidence sheet
| Competency and prompt time | Observed words, choices and assumptions | Rating | Missing evidence / consistent follow-up |
|---|---|---|---|
| Local persistence and lifecycle, 5–16 | 1 / 2 / 3 / 4 / NO | ||
| Retry and duplicate prevention, 16–28 | 1 / 2 / 3 / 4 / NO | ||
| Conflict and reconciliation, 28–40 | 1 / 2 / 3 / 4 / NO | ||
| User feedback and recovery, 40–51 | 1 / 2 / 3 / 4 / NO | ||
| Platform/account boundary, 51–57 | 1 / 2 / 3 / 4 / NO |
Independent debrief notes
Evidence tied to the role outcome:
______________________________________________________________
Different readings and relevant anchor:
______________________________________________________________
Prompt missed or fair follow-up needed:
______________________________________________________________
Open product, service or support boundary:
______________________________________________________________
Before using this scorecard
- Choose iOS/Swift or Android/Kotlin for the role; dual-platform breadth is not presumed.
- Have product, API and field-operations owners review the policy gaps.
- Dry-run timing and wording; no candidate pilot or validation is claimed.
- Share the format in advance and offer a reasonable adjustment path.
- Keep notes under the organization's access and retention rules.
This is a structured discussion aid, not a validated test, legal advice or automatic candidate ranking. People make the hiring decision and remain accountable for consistent administration.