Amazon Mobile Developer (Entry Level) Interview Preparation Guide

Direct answer

I run the postmortem as a facilitated session with a fixed structure, not an open discussion: reconstruct the timeline first, set a blameless tone explicitly before anyone speaks, dig past the first explanation people offer until I hit the real root cause, and leave with owned, dated action items. The part people underestimate is the follow-up afterward: a postmortem that produces a document but no verified, closed fixes is theater, not a process.

Structured elaboration

Structuring and facilitating the session. I schedule it within a day or two, while memory is still fresh, and invite the people actually involved rather than turning it into a large audience meeting. I open with an explicit line: we're here to understand what let this happen, not to find who to blame. Then I follow a fixed order: reconstruct the timeline of what happened, establish the impact, dig into root cause, list contributing factors, and close with action items. Facilitation matters here more than content: whoever runs the meeting should ideally not be the person most implicated, since the room tends to self-censor around whoever's judgment is being questioned, even unintentionally.

Building psychological safety. I frame questions around the system, not the person: "what made this look like the right call at the time" rather than "why did you do that." I invite the person closest to the problem to speak first, without letting them get cornered, and I separate two things explicitly: the decision may have been reasonable given what was known then, even though the outcome was bad. Conflating those two is what makes people defensive and, over time, makes them stop reporting near-misses at all.

Surfacing the real root cause. The first answer someone gives is almost never the root cause, it's the symptom closest to the surface. I keep asking why, one layer at a time, past the first comfortable stopping point, specifically watching for the group settling on whichever explanation requires the least uncomfortable process change.

Assigning owners and deadlines. Every action item gets one name and one date, and I write it specific enough that "done" is checkable, not vague enough that it just sounds like effort was made.

Following up. I put items on a visible tracker and revisit status at a fixed interval, and I require actual evidence of completion, not a self-reported "done," and I report back to the group that raised the issue so they see it actually closed.

Worked example

Say a Friday deploy of a caching configuration change caused a 40-minute partial outage affecting about 15% of traffic. The first answer in the room is "the config value was wrong." That's true but not useful on its own, so I keep pushing: why did the wrong value pass review? Because the reviewer didn't have deep context on that caching layer. Why was there no automated check to catch it? Because config-only changes never went through the canary rollout process (deploying a change to a small slice of traffic first, so problems surface before everyone is affected) that code changes get, only full code deploys did. That's the real root cause: config changes were quietly exempt from the safety net everything else gets.

Action items from that: extend the canary rollout process to cover config changes, not just code, owned by the deploying engineer's team lead, due in two weeks; require a second reviewer with caching-layer context specifically for changes to that system, owned by the engineering manager, due in one week.

At the two-week follow-up, the canary extension was confirmed live by running a controlled test config change through the new gate and watching it get caught the way a bad change should; the reviewer-routing rule was confirmed closed by pointing to the updated ownership file in the repository, not just someone's word that it was done.

Trade-offs and pitfalls

The most common failure is stopping at the first plausible explanation, which feels like closure but leaves the actual gap in place for the next incident. A close second is letting the meeting turn performative, "lessons learned" language with no real follow-up, which teaches the team that postmortems don't matter and near-misses stop getting reported. Facilitation by the person most implicated tends to make the room go quiet exactly when candor matters most. And a long list of well-intentioned action items that nobody actually does is worse than a short list of two or three that get verified done, because it creates the appearance of progress without the substance.

Overview: why conventions matter
As a UI designer I balance brand consistency with platform mental models. Respecting platform conventions reduces user friction and implementation cost.

Key differences (visual & interaction)

• iOS
  • Navigation: bottom tab bar with iOS-style iconography and large title.
  • Gestures: system back-swipe (edge-to-edge).
  • Visuals: lighter typography, rounded iOS system icons, San Francisco metrics.
• Android
  • Navigation: top app bar + navigation drawer or Material Bottom Navigation.
  • Gestures: back button behavior (system/back stack).
  • Visuals: Material elevation, tactile ripple, Roboto/Google iconography.
• Web
  • Navigation: persistent headers, hover affordances, link semantics.
  • Visuals: denser layouts, cursor/keyboard interactions, responsive breakpoints.

When I follow platform conventions

• Example iOS: Use native back-swipe and large title on iPhone: users expect it, and enforcing a brand-only back control would feel foreign.
• Example Android: Use a Material FAB (Floating Action Button, the round button anchored bottom-right for the primary action) and ripple for the primary action on an Android handset.
• Example Web: Preserve hover states and keyboard-focus outlines for accessibility.

Documenting exceptions in a cross-platform design system

• Create an “Platform Patterns” section per platform with:
  • Rationale: why follow native convention (usability, expectations).
  • Visual tokens: platform-specific colors, typography, elevation.
  • Components: canonical variations (e.g., TabBar_iOS vs BottomNav_Android) with specs: dimensions, spacing, iconography, motion.
  • Do/Don’t examples and code snippets (or links to platform component libraries).
  • Implementation notes: props/variants, accessibility requirements, and testing checklist.

This approach ensures brand coherence where it matters while surfacing clear, justified exceptions for platform-native behavior.

A strong answer to this question demonstrates that you correctly diagnosed a SPECIFIC, mobile-particular testing gap, not a generic "we needed more tests" observation, and that you drove the change with evidence rather than just opinion.

How to structure the STAR response

Situation and problems observed: describe a concrete, mobile-specific gap, for example a team that had solid backend test coverage but almost no automated coverage on the mobile client itself, relying instead on manual QA passes before each release, which was becoming a release-cadence bottleneck as the app grew, or a team whose existing mobile UI tests were so flaky that they were routinely ignored, effectively providing zero real signal despite real engineering time spent maintaining them.

Changes you proposed: be specific about WHICH level and WHY, for example proposing a foundational layer of unit tests for the app's view-model and business-logic layer first (highest value per hour invested, since almost none currently existed), rather than jumping straight to UI test automation, or proposing a specific fix to the flaky UI suite's root cause (unstable selectors, missing explicit waits for async work) rather than simply asking for "more reliable tests" in the abstract.

How you prioritized and implemented them: describe a realistic, incremental rollout, for example starting with the highest-traffic, highest-risk screens first (login, checkout) as a pilot to demonstrate value before asking for broader team buy-in, and pairing the technical change with a process change (a definition-of-done requirement for new features to include unit tests) so the improvement didn't erode again once the initial push ended.

Metrics used to measure success: use metrics you can honestly derive from the situation, such as the manual QA cycle time before and after (if it's a release-bottleneck story), or the automated suite's pass-rate stability and rerun rate before and after (if it's a flakiness story), described honestly and specifically rather than with an invented precision figure; if you don't have an exact number from memory, describe the direction and rough magnitude of the change honestly (for example, manual QA time dropping from most of a release cycle to a small fraction of it) rather than fabricating a specific percentage.

Handling resistance: name a real, specific form of resistance and how you addressed it with evidence rather than authority, for example a teammate skeptical that unit-testing view-model logic was worth the time investment, addressed by pointing to a specific recent bug that a proposed test would have caught, or a product manager concerned that adding tests would slow down an already tight release schedule, addressed by showing that the pilot screens' review and QA time actually DECREASED once automated coverage existed, turning the argument from "tests slow us down" to "tests are what let us go faster."

Trade-offs and pitfalls

The pitfall in this story is claiming credit for a purely technical fix without acknowledging the process and buy-in work required to make it stick; testing improvements that aren't paired with a process change (definition of done, code-review expectations) tend to erode once the person who pushed for them moves on, and naming that explicitly is itself a sign of senior-level thinking about sustainable change, not just a one-time fix.

Direct answer

Expand a window from the right, adding each new element to a running sum. The moment the running sum reaches or exceeds the target, record the window's length as a candidate answer and shrink from the left for as long as the sum still qualifies, since every valid window found this way is a candidate for the minimum. Track the smallest length seen across the whole single pass.

Structured elaboration

Approach

def min_subarray_len(s, nums):
    n = len(nums)
    left = 0
    window_sum = 0
    best = n + 1
    for right in range(n):
        window_sum += nums[right]
        while window_sum >= s:
            best = min(best, right - left + 1)
            window_sum -= nums[left]
            left += 1
    return 0 if best == n + 1 else best

Why this requires positive numbers (the question's explicit ask)

The sliding-window technique relies on the running sum changing MONOTONICALLY as each pointer moves: adding an element (moving right) can only ever increase the sum, and removing an element (moving left) can only ever decrease it, if and only if every element is positive. That monotonicity is exactly what justifies greedily shrinking the window without ever needing to re-check a wider window later: once the sum drops below the target after removing the leftmost element, removing MORE elements from the left is guaranteed to keep it below target too, since removing a positive number is always a strict decrease. If the array could contain zero or negative values, adding an element to the right would no longer guarantee the sum increases, so a window that currently fails the threshold might still succeed if extended further, and the greedy shrink-from-the-left step is no longer safe. The standard fallback for arrays with negative numbers is prefix sums combined with a monotonic deque, or, for exact-sum variants, prefix sums indexed in a hash map.

Variant: count subarrays with product strictly less than k

A related ask uses the identical two-pointer skeleton, but tracks a running PRODUCT instead of a sum, and counts how many valid windows END at each right pointer rather than tracking a minimum length:

def num_subarrays_product_less_than_k(nums, k):
    if k <= 1:
        return 0
    left = 0
    product = 1
    count = 0
    for right, x in enumerate(nums):
        product *= x
        while product >= k:
            product //= nums[left]
            left += 1
        count += right - left + 1
    return count


def brute_force_count(nums, k):
    """O(n^2) reference: enumerate every subarray's product directly, with
    no window-shrinking logic to trust. Used only to cross-check the
    two-pointer version above, not as the real answer."""
    n = len(nums)
    count = 0
    for i in range(n):
        product = 1
        for j in range(i, n):
            product *= nums[j]
            if product < k:
                count += 1
    return count

The key insight that makes the counting step correct: for a fixed right pointer, every subarray from index left..right, left+1..right, ..., all the way to right..right, is also valid, since removing elements from the front of a window whose product is already below the threshold (with all-positive elements) can only make the product smaller or equal. So the count of newly valid subarrays ending exactly at right is right - left + 1, added once per right-pointer step. This again relies on positive integers for the same monotonicity reason as above.

Worked example

Executed with python3 s81.py (both the two-pointer function and the brute-force reference defined above):

min_subarray_len(s=7, nums=[2, 3, 1, 2, 4, 3]) = 2
min_subarray_len(s=100, nums=[1, 2, 3]) = 0

The window [4, 3] sums to 7 in exactly 2 elements, the shortest possible; with a target of 100 and a maximum possible total sum of 6, no window can ever reach it, so the function correctly returns 0.

num_subarrays_product_less_than_k(nums=[10, 5, 2, 6], k=100) = 8
brute_force_count(nums=[10, 5, 2, 6], k=100) = 8

The brute-force reference (shown above) agrees exactly: 8 qualifying subarrays out of 10 possible non-empty subarrays for a 4-element array.

Trade-offs and pitfalls

• The two-pointer approach is O(n) time and O(1) extra space; that is the entire value proposition over a brute-force O(n^2) (or worse) scan, and interviewers expect BOTH the working code AND the positivity argument for why the greedy shrink is valid, not just code that happens to pass test cases.
• A common bug in the counting variant is omitting the if k <= 1: return 0 guard: with k <= 1, no product of positive integers can ever be strictly less than k, and the main loop's while product >= k shrink condition would otherwise push left past right and read a stale or out-of-range element.
• It is easy to conflate "smallest window that reaches a target" (this problem, returning a length) with "count every window satisfying a condition" (the other variant, returning a count); keep straight which of the two output shapes a given question is actually asking for, since the bookkeeping each one needs is different even though the window-management code looks nearly identical.

Clarify goals & constraints

• Mobile-first: offline read, incremental sync, low bandwidth, rich media support, battery friendly.
• Strong personalization, low latency, consistent UX across iOS/Android.

High-level architecture

• Server: ingestion -> user/profile store -> ranking/personalization service -> feed store & precomputed offline bundles -> CDN for media.
• Client: local DB (SQLite/Room/CoreData), media cache, sync engine, offline queue, rendering layer.

Feed generation

• Server-side personalization for primary ranking (models, context signals) to minimize client CPU/bandwidth.
• Client-side filtering for ephemeral signals (muted topics, local preferences) to adjust server-ranked feed without full re-rank.

Storage & sharding

• Shard feed store by user-id prefix; hot-users routed via consistent hashing. Use per-shard caches (Redis) for hot items; long-term in columnar/NoSQL store (Cassandra/DynamoDB).

Precomputed bundles for offline

• Build per-user delta bundles: recent N items + attachments metadata + thumbnails + content HTML/JSON. Compress (gzip) and sign. Store in object store; expose via signed URLs.

Pagination & delta sync

• Cursor-based pagination with server cursors and client opaque tokens.
• Delta sync: client provides last-sync-token; server returns additions, updates, deletes as an ordered delta stream. Use compact protobuf/CBOR for payloads.

Media optimization

• Store multi-resolution thumbnails, progressive JPEG/AVIF; generate video HLS with low-bitrate renditions.
• Client fetch policy: lazy load high-res on view; prefetch low-res thumbnails for next M items. Use range requests and conditional GETs (ETag).

Client eviction & prefetch

• Local storage budget per user (e.g., 500MB). LRU for articles; pinning for saved items. Adaptive eviction: consider battery, network (on cellular be conservative).
• Prefetch rules: on Wi‑Fi + charging => aggressive (next 50 items + media low-res). On cellular => only metadata + thumbnails for next 5 items. Respect data saver toggle.

Security & consistency

• Signed bundles, TLS, token-based access. Conflict-free updates via last-write-wins for read-only feed items; server authoritative for personalization.

Mobile implementation notes

• Use background fetch (iOS background fetch/URLSession, Android WorkManager) to download deltas and media respecting OS constraints.
• Expose incremental updates as observable streams to UI; batch DB writes to avoid jank.

This balances server heavy ranking for accuracy with client-side agility to support offline, low bandwidth, and rich media on mobile devices.

Direct answer

Yes. I pick a story where I moved from caring about the elegance of the solution to caring about what the person using it was trying to do, and I show three concrete changes: what I built, what I prioritized, and what I traded away. I tell it in STAR order (Situation and Task, Action, Result), the standard structure for behavioral interview stories.

Situation and Task

I was the engineer on an ordering app used by small cafe owners at the counter during rush hour. I took pride in a clever offline sync design (the app keeps taking orders without internet and merges them with the server when the connection returns). Then I spent a shift watching an owner use the app and saw that what she dreaded was a lost order when the connection dropped, not anything about how sync worked.

Action

• Engineering decisions: I replaced my clever conflict-resolution design (the rules for what happens when two edits to the same order collide) with a simpler one that always kept both versions of an order and flagged the clash in plain words for a human to resolve in seconds. Example: the counter phone edits an order to 2 lattes while offline, a helper's tablet edits the same order to 3 lattes while offline. The clever design silently kept one and lost the other. The simple one shows "Order 41: 2 lattes or 3 lattes? Tap the right one." It was less elegant and much easier to trust.
• Prioritization: I moved a planned refactor (restructuring code without changing what it does) behind a fix that made a half-saved order visible on screen, because that failure cost the owner money in real time.
• Trade-offs: I accepted slightly clunkier code and a delayed internal cleanup to protect the owner's rush hour, and I said so openly to the team.

Result

Support complaints about lost orders dropped from about a dozen a month to two or three (illustrative; use your own measured figures), and the owners I had watched started using offline mode with confidence. I also began asking "who is on the other end of this change?" in design reviews.

Pitfall

Avoid vague "I love our users" language. The proof is a decision you made differently, and a cost you knowingly paid.

Direct answer

Treat it as a wait-for cycle hunt, in this order: (1) capture every thread's stack while the app is actually hung, (2) write down, for each blocked thread, what it holds and what it waits for, and look for a cycle, (3) reproduce on demand with timeouts and a lock-order checker, (4) fix by giving the single connection one owner and making every UI read asynchronous, so no thread ever blocks waiting for it, (5) prove the fix with a stress harness. The architecture change matters more than any single lock fix: the root cause is that the main thread and a worker pool compete synchronously for one resource.

Terms

A deadlock is a set of threads each waiting for something another thread in the set holds, so none can proceed. A wait-for graph draws an arrow from a thread to the thread holding what it wants; a cycle means deadlock. Lock ordering is a rule that every thread takes locks in the same global order, which makes a cycle impossible. A thread dump (stack trace of every thread) shows where each thread is stopped. A main thread hang on mobile also surfaces to users as a frozen UI, or an ANR (Application Not Responding) on Android.

Step 1: capture thread dumps at the moment of the hang

• iOS: attach the debugger, pause, and run thread backtrace all in lldb. Look at the main thread and every sync worker.
• Android: after an ANR, Android writes trace files on the device; Android's documentation shows adb root, adb shell ls /data/anr and adb pull /data/anr/<filename> (older releases use one /data/anr/traces.txt). From the field, ApplicationExitInfo (an Android API that lets the app ask the system why its previous process ended; Android 11 and later) reports app exits including ANRs. During development, StrictMode flags accidental I/O on the main thread.
• Capture at least three dumps, a few seconds apart. A thread that is in the same frame in all of them is stuck, not just slow.

Step 2: read the dumps as a wait-for graph

For each thread note: the frame where it is parked (lock acquire, dispatch_sync, semaphore wait, synchronized, Object.wait), what it already holds, and what it waits for. Then check the shapes this scenario can take:

1. Lock-order inversion (ABBA). Thread 1 takes lock A and then wants lock B; thread 2 takes lock B and then wants lock A. Each holds what the other needs, so neither can move. Here A is the state lock and B the connection: the sync worker holds the state lock and wants the connection; the main-thread read holds the connection and wants the state lock. The demo below produces exactly this.
2. Pool starvation. A concrete case: a pool has 4 threads. Thread P1 holds the connection and, inside its transaction, submits a sub-task to the same pool and waits for its result. Threads P2, P3 and P4 are each blocked waiting for the connection. The sub-task is queued but no pool thread is free to run it, so P1 never finishes and never releases the connection. There is no second lock; the cycle goes through the thread pool.
3. Main-thread hop. A worker holding the connection calls into the main thread synchronously (DispatchQueue.main.sync, or on Android runOnUiThread plus a latch that the worker waits on) while the main thread waits for that connection. The worker waits for the main thread, and the main thread waits for the worker.

Inspect, in the source, every place that acquires the connection and every place that does something else while holding it (callbacks, logging that touches the UI, a second lock, a pool submit). List the acquisitions as an ordered table (lock A then B, per code path). Two paths with opposite orders are the bug. Also grep for synchronous main-thread database reads: sync, runBlocking, .get() on a future, allowMainThreadQueries.

Step 3: make it reproducible

An intermittent deadlock hides until timing lines up. In debug builds, wrap lock acquisition in a timed acquire (for example NSLock.lock(before:)) and when it times out dump all stacks and fail loudly. Add a lock-order checker that records the order each thread takes locks and asserts on an inversion even when the timing did not deadlock this run. Run the sync under a stress test with many workers and main-thread reads firing at random times.

Step 4: fix

Code level:

• One global lock order, written next to the lock declarations, and no callbacks, no UI work, no other lock acquisitions while the connection is held.
• Keep transactions short; never hold the connection across network I/O.

Architecture level:

• Give the connection to one owner: an actor or serial queue on iOS, Room's single database object with suspend DAO functions on Android (Room is Android's SQLite wrapper library, and a DAO, data access object, is the interface where you declare the queries). Android's documentation says Room does not support database access on the main thread, so DAO queries must be asynchronous: suspend functions for one-shot queries and Flow for observable ones.
• The UI observes data (a Flow, or an actor-backed model updated from the owner) and never performs a synchronous read.
• If read latency under writes matters, SQLite's WAL mode (write-ahead logging: writes are appended to a separate log file and merged into the database later, so readers can keep reading the old data meanwhile) allows readers and a writer to proceed at once. SQLite's documentation says readers do not block writers and a writer does not block readers (it adds that this is mostly true), and that only one writer exists at a time. Use separate read connections only if you need that concurrency, because every extra connection reintroduces the question of who waits for what.

Safe DB access example, run

The Swift below was compiled with Swift 6.0.3 in a swift:6.0 Linux container (aarch64), in Swift 5 language mode (-swift-version 5) because the demo uses a global mutable array. Part 1 reproduces the ABBA deadlock with timed acquires. The two semaphores exist only to force the bad timing: syncHasState is signalled once the sync worker holds the state lock, and uiHasConnection once the UI stand-in holds the connection, and each thread waits for the other's signal before asking for its second lock. Without them one thread might finish both acquisitions before the other starts, and the deadlock would not appear. The lock(before:) timeouts let each thread give up after 1 s and report instead of hanging forever. Part 2 is the fix: an actor stands in for the single connection, eight background tasks queue 800 writes of 2 ms each, and the "UI" awaits reads without ever blocking a thread.

import Foundation

// ---------- Part 1: the deadlock, with timeouts so the demo can report it ----------
let stateLock = NSLock()      // protects sync bookkeeping (pending uploads, cursors)
let connectionLock = NSLock() // the single SQLite connection
let syncHasState = DispatchSemaphore(value: 0)
let uiHasConnection = DispatchSemaphore(value: 0)
let report = NSLock()
var lines: [String] = []
func log(_ s: String) { report.withLock { lines.append(s) } }

let group = DispatchGroup()
DispatchQueue.global().async(group: group) {       // background sync worker
    stateLock.lock()                               // order: state, then connection
    syncHasState.signal(); uiHasConnection.wait()
    if connectionLock.lock(before: Date().addingTimeInterval(1)) {
        connectionLock.unlock(); log("sync: got both locks")
    } else { log("sync: stuck waiting for the connection while holding state") }
    stateLock.unlock()
}
DispatchQueue.global().async(group: group) {       // stands in for the UI thread's synchronous read
    connectionLock.lock()                          // order: connection, then state
    uiHasConnection.signal(); syncHasState.wait()
    if stateLock.lock(before: Date().addingTimeInterval(1)) {
        stateLock.unlock(); log("ui: got both locks")
    } else { log("ui: stuck waiting for state while holding the connection") }
    connectionLock.unlock()
}
group.wait()
let stuck = lines.filter { $0.contains("stuck") }.count
print("threads stuck for the full 1 s timeout (at least 1 means deadlock):", stuck >= 1)

// ---------- Part 2: one owner for the connection, no thread ever blocks on it ----------
actor Database {
    private var rows: [String: Int] = [:]          // stands in for the SQLite connection
    func read(_ key: String) -> Int? { rows[key] }
    func write(_ key: String, _ value: Int) {
        usleep(2_000)                              // a 2 ms transaction
        rows[key] = value
    }
}
let db = Database()

// Background sync: many concurrent tasks, each takes turns on the actor.
let syncTask = Task {
    await withTaskGroup(of: Void.self) { g in
        for w in 0..<8 {
            g.addTask { for i in 0..<100 { await db.write("k\(w)", i) } }
        }
    }
}

// "UI": reads are awaited, never blocking the thread that issues them.
var worstMs = 0.0
var reads = 0
for _ in 0..<200 {
    let t0 = Date()
    _ = await db.read("k0")
    worstMs = max(worstMs, Date().timeIntervalSince(t0) * 1000)
    reads += 1
    try await Task.sleep(nanoseconds: 1_000_000)
}
await syncTask.value
print("reads completed:", reads)
print("final k0:", await db.read("k0") ?? -1)
print(String(format: "worst read latency while 800 writes queue up: %.1f ms", worstMs))

On a sample run it printed:

threads stuck for the full 1 s timeout (at least 1 means deadlock): true
reads completed: 200
final k0: 99
worst read latency while 800 writes queue up: 39.5 ms

The first line is true by construction: the semaphores force each thread to hold its first lock before either asks for its second, so at least one of them always times out. The lines array records which thread reported "stuck". Both threads start waiting at nearly the same moment, so both can time out; but when one times out slightly earlier it releases its first lock and the other then succeeds and logs "got both locks", so only one "stuck" line appears. Which of the two outcomes you get, and which side reports, depends on timing and on how many CPUs are available (with several CPUs both threads can report "stuck", while with one CPU a single "stuck" line is the usual result). That is why the test prints whether at least one thread was stuck rather than how many, and why a real deadlock that depends on timing like this looks intermittent in production. The worst awaited read took tens of milliseconds and varied from run to run: the read queues behind pending writes inside the actor, but no thread is blocked, so the UI thread keeps drawing. If a delay of that size matters to a screen, serve it from an in-memory copy the owner updates, or add a read connection under WAL.

Android equivalent:

// Room runs suspend DAO queries off the main thread for you. @Upsert (Room 2.5.0 and later) inserts a row, or updates it if the key already exists.
@Dao interface SyncDao {
    @Query("SELECT * FROM item WHERE id = :id") suspend fun item(id: Long): Item?
    @Query("SELECT * FROM item ORDER BY updatedAt DESC") fun observeItems(): Flow<List<Item>>
    @Upsert suspend fun upsertAll(items: List<Item>)
}

class ItemRepository(private val dao: SyncDao, private val io: CoroutineDispatcher = Dispatchers.IO) {
    val items: Flow<List<Item>> = dao.observeItems()          // UI collects this; no blocking read
    suspend fun sync(remote: List<Item>) = withContext(io) {  // network parsing off the main thread
        dao.upsertAll(remote)                                  // one short write
    }
}

Verify the fix

• Run the same stress harness against the old and new code; the old one must hang or time out at least once so you know the test can fail.
• On iOS run it under Thread Sanitizer; on Android run with StrictMode enabled and fail the test on a main-thread violation.
• In production watch the ANR rate or hang rate and the p95 of database call duration for two releases after the change.

Common mistakes

• Fixing one lock order and leaving the main-thread synchronous read, so pool starvation still deadlocks.
• Increasing the pool size to hide starvation.
• Adding a second connection without deciding who waits for whom.

Summary / recommendation
For a memory‑critical Android app, prefer redesign (process isolation + careful memory pools) over relying on android:largeHeap. largeHeap is a stopgap that hides problems and worsens OS-level memory pressure; use it only when impossible to refactor.

android:largeHeap — Pros / Cons

• Pros: Quick to enable; reduces immediate OOMs for large images.
• Cons: Encourages memory bloat; Android treats it per-process but overall system memory pressure increases; poorer multitasking (other apps get killed); no battery benefit — larger heaps increase GC pauses and CPU for GC, increasing energy use; hard to reason about across OEM variants.

Separate process / process isolation — Pros / Cons

• Pros: Limits blast radius (e.g., heavy image pipeline in a dedicated process); Android can kill/restart it independently; improves UI responsiveness and reduces main process OOMs. Good for background syncs or batch work.
• Cons: IPC overhead (Binder) and serialization costs; increased APK complexity, lifecycle coordination, and testing; two processes double baseline memory footprint (code and native libs), affecting overall memory and battery.

Native memory pools (NDK) — Pros / Cons

• Pros: Predictable, manual allocation (e.g., pooled bitmaps, native allocators) reduces Java heap pressure and frequent GC; can use mmap/ashmem to share buffers across processes; often lower CPU/GPU copy cost -> battery savings.
• Cons: Unsafe (leaks crash process), platform differences, debugging harder; asset lifetime must be carefully managed; increases code complexity.

Trade-offs & practical guidance

• Start by profiling (Android Studio Memory Profiler, dumpsys meminfo).
• If large allocations are transient, use pooled native buffers + Bitmap pooling (inSampleSize, BitmapFactory options, Bitmap re-use).
• Use a separate process for non-UI heavy work (e.g., worker process for transforms/sync) when isolation and restartability matter; mitigate IPC cost with shared ashmem or file descriptors.
• Reserve android:largeHeap as last resort with clear monitoring and timeboxed mitigation plan.

Maintainability / testing

• Prefer patterns that keep behavior deterministic: pool + clear contracts, small IPC surface, thorough integration tests. Document ownership of native memory and lifecycle to avoid hidden leaks.

Approach overview
Maintain a persistent per-item state store (SQLite/Room/CoreData) with statuses: pending, in-flight, success, retryable-failed, permanent-failed. Each uploaded item has server-assigned id or client-id and server error code recorded.

Reconciliation & eventual consistency

• On response, mark the 70 as success; update local store and remove from retry queue.
• For 30 failures, map error codes to categories:
  • Permanent (e.g., 4xx invalid data) → permanent-failed; show actionable error.
  • Transient (e.g., 5xx, network timeout, rate-limit) → retryable-failed with retry metadata.
• Use idempotent requests (include client-id, version) so retries are safe.

Retry scheduling (battery-efficient & crash-safe)

• Persist backoff state (attempt count, nextAttemptAt).
• Use OS-friendly background execution:
  • Android: WorkManager with backoffPolicy = EXPONENTIAL_BACKOFF and constraints (unmetered/network type, charging optional).
  • iOS: BackgroundTasks (BGAppRefreshTask / BGProcessingTask) scheduling nextAttemptAt, respecting system.
• Implement exponential backoff with jitter; cap attempts and switch to user-triggered retry when cap reached.
• Pause retries on low-battery or roaming; resume when constraints satisfied.

Progress & UX for partial success

• Show a progress bar: succeeded / total and a collapsible details list per item with icons for success, retrying, failed.
• For partial success: show “70 uploaded, 30 need attention” with an action “Retry all” and “Review errors”.
• For permanent failures, include inline edit or discard option.
• Provide unobtrusive background retry indicator and allow user to opt-out.

Crash / resume safety

• All queue and metadata persisted atomically; on app start, reconcile with server status for in-flight items (query server for item ids) to resolve ambiguous states.
• Use idempotency tokens so resumed retries don't duplicate server-side effects.

Monitoring & metrics

• Track retry rates, battery impact, and user-initiated retries; tune backoff and caps from real usage.

High-level tradeoffs

• Monorepo: single source for iOS/Android + core library — easier refactors, single dependency graph, atomic changes. Downsides: larger CI surface, tooling complexity.
• Multi-repo: clear ownership, smaller checkouts, simpler per-repo pipelines. Downsides: cross-repo coordination, harder refactors, version drift.

CI design goals

• Fast feedback per team
• Run only affected builds/tests
• Safe promotion of shared artifacts
• Manage breaking API changes without blocking clients

Detect affected projects

• Use path-based change detection plus dependency graph.
• Example (PR pipeline):

git fetch origin main
git diff --name-only origin/main...HEAD > changed.txt

• Map paths to modules (core/, android/app/, ios/) and traverse module deps (Gradle / CocoaPods / SPM manifests or a precomputed graph).

Minimal builds/tests

• For each affected module run:
  • Static checks + unit tests
  • For mobile: run JVM unit tests and iOS Swift unit tests
  • Only run instrumented/emulator/real-device tests for apps or when platform-specific code changed
• Use build caching (Gradle remote cache, Bazel) and incremental compilation.

Promote shared artifacts safely

• Publish core library artifacts to internal registries (Maven for Android, binary SPM/CocoaPods for iOS) with semantic versions and metadata about source commit.
• CI flow:
  • On core-only PR: run build + full test matrix, then publish to a "canary" channel (e.g., 0.x-canary) and create a release candidate.
  • App pipelines can opt-in to canary or pin stable semver.
• Automate artifact signing and provenance.

Manage breaking API changes

• Enforce semver and require major-version bump for breaking changes.
• Provide CI compatibility job that checks downstream repos/apps by running consumer build/test against the PR branch (lightweight: unit-tests + smoke app build). Use feature flags or dual-api shims so core can keep backward compatibility for one major.
• Add linter/generator that flags incompatible changes (missing symbols, changed method signatures).
• Communicate via automated migration notes and codemods in PR.

Tooling recommendations

• Monorepo: Bazel or Gradle with composite builds + remote cache
• Multi-repo: small repo + automated cross-repo test runner (CI job that checks downstream)
• Use artifact registry, semantic release, feature flags, and automated migration tooling.

This approach keeps mobile teams independent while enabling safe, auditable shared-library evolution.