Amazon Senior Mobile Developer Interview Preparation Guide

Direct answer

On iOS, the choice is between the Keychain (encrypted, potentially hardware-backed) and NSUserDefaults (plain, unencrypted); on Android, it is between the KeyStore plus EncryptedSharedPreferences (encrypted, potentially hardware-backed) and plain SharedPreferences (unencrypted). The rule of thumb is simple even though the platform details are not: anything that grants access to a user's account or funds (a refresh token, an Application Programming Interface, API, key) belongs in the encrypted, hardware-backed option; anything that is genuinely non-sensitive (a UI preference, a feature flag) is the only thing that belongs in the plain option.

Structured elaboration

The four options compared

Why short-lived access tokens don't appear as a strong candidate for any persistent store above

A short-lived access token (an OAuth2 bearer token, typically valid for minutes to an hour) is deliberately designed to be cheap to lose; the standard pattern is to keep it in memory only (a variable in the running app process) and let it disappear when the app is killed, re-deriving a new one from the persisted refresh token on next launch. Persisting a short-lived token defeats the point of it being short-lived in the first place: the whole design assumes it is not worth protecting as carefully as the long-lived refresh token that can mint new ones.

Rotation pattern that applies across all four

Regardless of platform, the pattern for anything long-lived (refresh tokens, API keys) is: generate or receive a new value from the server, write it to the encrypted store, confirm the write succeeded, only then discard the old value; on any read failure or decryption failure (a device restore to different hardware, a corrupted keystore after an OS update), treat it as "credential unavailable" and force a fresh login rather than silently falling back to an unencrypted store, which would quietly reintroduce the exact risk the encrypted store exists to avoid.

Worked example

A finance app needs to persist a refresh token after login. On iOS: store it in the Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly (device-only, requires the device to be unlocked to read), which both excludes it from iCloud backup and requires a successful unlock to access, so a stolen but locked device does not expose it. On Android: generate a KeyStore-backed AES key with setUserAuthenticationRequired(true) if the app wants to require a recent biometric/PIN check before decryption, use that key to write the refresh token into EncryptedSharedPreferences, and exclude that preference file's backing file from Android's auto-backup configuration (android:allowBackup scoped, or an explicit backup-rules exclusion) so a cloud backup restored to a different device cannot yield a usable token even if the ciphertext were somehow extracted, since the wrapping key never leaves the original device's secure hardware.

Trade-offs and pitfalls

• Storing a refresh token in plain SharedPreferences/NSUserDefaults "temporarily, to be fixed later." This is the single most common real-world finding in a mobile security review; "temporary" code paths persisting credentials in plaintext routinely ship to production because the encrypted alternative feels like more setup work.
• Assuming hardware-backing is guaranteed. Not every device has a Secure Enclave equivalent or StrongBox; code should not assume hardware backing succeeded without checking, since silently falling back to software-only key storage changes the actual threat model without anyone deciding that on purpose.
• Letting sensitive data ride along in a cloud backup unintentionally. The default behavior for both platforms' encrypted stores is not automatically "excluded from backup"; that has to be configured explicitly, and skipping it means a token can end up recoverable from a backup on a completely different, possibly attacker-controlled, device.
• Treating KeyStore and EncryptedSharedPreferences as interchangeable on Android. KeyStore holds keys, not arbitrary token values; a common confusion is trying to store a token string directly in KeyStore, which is not what it is designed for, rather than using it to protect a value stored in EncryptedSharedPreferences.

Brief approach
Use WeakReference to hold Activity (or listener) so the callback doesn't keep it alive. Always copy weakRef.get() to a local strong variable and check for null before use — the reference can be cleared by GC at any time.

Kotlin example

// Worker posts a callback later; hold Activity weakly
class MyWorker {
  private var listenerRef: WeakReference<Activity>? = null

  fun setListener(activity: Activity) {
    listenerRef = WeakReference(activity)
  }

  fun doWorkAsync() {
    Thread {
      // ... work ...
      val activity = listenerRef?.get() // copy to strong ref
      activity?.runOnUiThread {
        // safe to access UI; activity may be null -> no-op
        it.title = "Done"
      }
    }.start()
  }
}

Key points & GC semantics

• Always call get() and immediately store result in local variable; it may become null between calls.
• A WeakReference does not prevent GC: when the only references to the Activity are weak, GC may clear it and get() returns null.
• Clearing can happen between get() and use — check null and avoid long operations using that object.
• For reliable lifecycle handling prefer lifecycle-aware patterns (LifecycleObserver, LiveData) when you need guaranteed delivery.

Direct answer

Quickselect adapts quicksort's partitioning to find just the k-th largest element without fully sorting: after one partition step around a pivot, the pivot's final position tells you whether the answer lies to its left or right, so you only ever recurse into one side instead of both. That halves (in expectation) the work at each level rather than branching into two recursive calls, which is what brings the expected time down from sorting's $O(n \log n)$ to $O(n)$. A heap of size k is the better choice instead when you cannot, or do not want to, mutate the input in place, or when the data arrives as a stream and you need the running top-k as you go rather than a single final answer.

Structured elaboration

Why quickselect is expected O(n)

A single partition around a random pivot costs $O(n)$ and places the pivot at its correct sorted position, with everything smaller to its left and everything larger to its right. If that position is the one you are looking for, you are done; otherwise you recurse into only the one side that must contain the target index, discarding the other side's work entirely. With a reasonably balanced pivot (true on average for a random pivot), the total expected work follows the recurrence $T(n) = T\!\left(\frac{n}{2}\right) + O(n) = O(n)$ (expected), the same halving-geometric-series pattern that makes binary search $O(\log n)$, except here the per-level cost is $O(n)$ rather than $O(1)$, and only one recursive branch is taken rather than a binary search's implicit single branch. This is the key difference from quicksort, which must recurse into both sides to sort everything, giving $O(n \log n)$.

Why a heap of size k instead

• Streaming input: if elements arrive one at a time and you must always be able to report the current top k, quickselect does not apply directly, since it needs the whole array in hand to partition; a size-k min-heap updates in $O(\log k)$ per new element and always reflects the current top k.
• Avoiding in-place mutation: quickselect partitions the input array in place; if the caller cannot have their array reordered, a heap that only reads elements avoids that side effect (at the cost of $O(k)$ extra space).
• Worst-case guarantee: a naive quickselect has a worst case of $O(n^2)$ on an adversarial or unlucky pivot sequence (randomizing the pivot choice makes this astronomically unlikely, not impossible); a heap of size k guarantees $O(n \log k)$ in every case.
• k close to n: when k is large relative to n, a heap of size k approaches $O(k)$ extra space that is not much smaller than the array itself, and quickselect's in-place approach becomes the more memory-efficient option; when k is small, the heap's small extra space is a non-issue and its worst-case guarantee is attractive.

A related, absorbed framing: this is a selection-algorithm family, not a one-off trick

The same "avoid a full sort" idea generalizes. Finding the k-th smallest value in a matrix whose rows and columns are each sorted uses a min-heap over the smallest untried cell in each row (or a binary search directly over the value range, counting how many matrix entries are $\le$ a candidate value in $O(n)$ per probe) rather than flattening and sorting the whole matrix. And when memory, not just time, is the binding constraint (as in a memory-constrained k-smallest-elements variant), quickselect's in-place partitioning is preferable to a heap precisely because it needs no auxiliary structure beyond the input array itself.

Worked example

import heapq
import random


def kth_largest_quickselect(nums: list[int], k: int) -> int:
    """
    Return the k-th largest value (k=1 is the maximum).
    Expected O(n) time, O(1) extra space (in-place partition, iterative).
    Worst case O(n^2) on adversarial pivots; randomized pivot makes that
    astronomically unlikely rather than eliminating it.
    """
    if not (1 <= k <= len(nums)):
        raise ValueError("k out of range")
    target = len(nums) - k  # index of the k-th largest in sorted-ascending order
    lo, hi = 0, len(nums) - 1
    while True:
        pivot_idx = random.randint(lo, hi)
        nums[pivot_idx], nums[hi] = nums[hi], nums[pivot_idx]
        pivot = nums[hi]
        store = lo
        for i in range(lo, hi):
            if nums[i] < pivot:
                nums[i], nums[store] = nums[store], nums[i]
                store += 1
        nums[store], nums[hi] = nums[hi], nums[store]
        if store == target:
            return nums[store]
        elif store < target:
            lo = store + 1
        else:
            hi = store - 1


def kth_largest_heap(nums: list[int], k: int) -> int:
    """Min-heap of size k. O(n log k) time, O(k) space."""
    heap: list[int] = []
    for x in nums:
        if len(heap) < k:
            heapq.heappush(heap, x)
        elif x > heap[0]:
            heapq.heapreplace(heap, x)
    return heap[0]


if __name__ == "__main__":
    random.seed(0)
    data = [3, 2, 1, 5, 6, 4]
    print("quickselect k=2:", kth_largest_quickselect(data.copy(), 2))
    print("heap k=2:", kth_largest_heap(data, 2))
    bigger = [7, 10, 4, 3, 20, 15]
    print("quickselect k=3:", kth_largest_quickselect(bigger.copy(), 3))
    print("heap k=3:", kth_largest_heap(bigger, 3))

Running this prints:

quickselect k=2: 5
heap k=2: 5
quickselect k=3: 10
heap k=3: 10

For [3, 2, 1, 5, 6, 4] sorted descending (6, 5, 4, 3, 2, 1), the 2nd largest is 5, and both methods agree. For [7, 10, 4, 3, 20, 15] sorted descending (20, 15, 10, 7, 4, 3), the 3rd largest is 10, and again both methods agree. The pivot choices inside quickselect are randomized but seeded (random.seed(0)), so this exact sequence of calls reproduces this exact output every time it is run.

Complexity

• Quickselect: expected time $O(n)$, worst case $O(n^2)$; space $O(1)$ extra (partitions in place, iteratively rather than recursively here).
• Heap of size k: time $O(n \log k)$ in every case; space $O(k)$ for the heap.

Edge cases

• k outside the range [1, len(nums)] is invalid input and should raise rather than silently returning a wrong value.
• Duplicate values are handled correctly by both methods, since partitioning and heap comparisons work on values, not identity.
• k equal to 1 (the maximum) or k equal to n (the minimum) are valid boundary cases worth checking by hand.
• An already-sorted or reverse-sorted array is exactly the input that most threatens a non-randomized quickselect's worst case; randomizing the pivot is what defends against it.

Trade-offs & pitfalls

The most common wrong turn is presenting quickselect as strictly superior because of its better expected time, without naming its $O(n^2)$ worst case or its requirement to mutate the input array in place; both are real costs that the heap approach avoids. A second common gap is forgetting that quickselect only gives you the k-th value itself, not the k values above it in order: if you also need the actual top-k list, you still need one more pass (or a heap) to collect everything on the correct side of the final partition. A third pitfall, specific to this absorbed question family, is treating "kth largest in an array" and "kth smallest in a sorted matrix" as needing the same algorithm: the matrix's extra structure (both rows and columns already sorted) is exactly what makes a heap-over-candidate-cells or binary-search-over-values approach effective there, and quickselect's partitioning does not directly apply to a two-dimensional sorted structure the same way.

Situation & Goal
A recent OS upgrade broke our background-job API causing scheduled jobs and push-token registrations to be lost. Goal: detect affected users, restore critical functionality, notify when necessary, compensate server-side, and prevent recurrence.

Detect affected users

• Server-side: scan job-execution and push-delivery logs for gaps since upgrade time; query last-known job run timestamps and token refresh timestamps.
• Client-side: add a diagnostic on next app cold-start that reports current OS version, background registration status, and last scheduled-job ID.
• Example diagnostic payload:

{ "user_id": "...", "os_version":"14.5", "bg_jobs_registered": false, "push_token": null, "last_job_ts": null }

Re-schedule critical jobs

• Prioritize critical jobs (billing, location uploads). Server enqueues compensating tasks for users missing runs.
• Push a targeted silent update (or require app update if API changed) that re-registers/rehydrates schedulers on startup.
• On app startup, detect missing schedules and call platform APIs (WorkManager / BGTaskScheduler) to recreate.

Re-register push tokens

• Server forces token refresh by sending a silent push (where supported) prompting app to call registerForRemoteNotifications; otherwise prompt user on next app open.
• Backfill server records: accept client-sent token with versioning and timestamp.

User notification

• For non-critical features, show an in-app banner explaining service disruption and asking user to open app to restore.
• For critical failures (missed billing, safety alerts) send email + push (if token exists) with clear remediation steps.

Server-side compensations

• Execute missed workflows server-side where possible (resend notifications, run batch jobs).
• Flag affected accounts for manual review if automated compensations can't cover.

Safeguards to prevent recurrence

• Add migrations: on OS-detect + app-launch, run idempotent re-registration of background tasks and token registration with exponential backoff.
• Versioned job registry persisted to disk; reconcile with server on start.
• CI: add OS upgrade simulation tests and release-canary to subset of users.
• Monitoring: alert on sudden drop in job registrations or push token churn; include SLOs and dashboards.

Measurable outcomes

• Triage window <24h, automated re-registration success rate target 95%, user-notified only for unresolved cases.

This plan balances immediate recovery, user communication, and long-term resilience.

Framework: triage against named criteria, name what gets cut to make room, and bring evidence rather than urgency to the negotiation.

1. Criteria to evaluate importance. Customer impact: how many users are affected and how severely (blocking versus merely degraded). Revenue: whether direct dollars are at risk right now, such as a paying customer being blocked, versus a longer-term opportunity. Regulatory: whether there's real legal, compliance, or security exposure with a hard external deadline and no room to negotiate. It also helps to note effort and blast radius (is the issue getting worse) alongside these three, but customer impact, revenue, and regulatory exposure are the primary triage lens here.

2. Negotiating trade-offs with PM and support. Bring the triaged list with evidence, ticket counts, an estimated revenue figure, the regulatory deadline, rather than opinions about what feels urgent. State the trade-off explicitly: if items X and Y go in, name exactly which currently planned items get pushed out to make room. Let PM own the final business-priority call while you own the technical risk and effort estimate. When PM and support disagree, get specific about what each is actually optimizing for (support wants ticket volume down, PM wants a feature commitment kept) and look for the sequencing that clears the highest-severity item from each list first, rather than picking a side.

3. Communicating the revised plan to the team. A short, explicit revised sprint plan: what's added, what's cut or deferred (named specifically, not "some lower-priority items"), why (the criteria used), and who to talk to if someone disagrees, delivered in the next standup or a written summary, not buried inside a ticket update where it will be missed.

Worked example, points on the same basis throughout (story points, a relative unit teams use to size the effort/complexity of a piece of work, not hours worked, measured against a demonstrated 30-point sustainable velocity, meaning the number of story points this team has reliably completed per sprint and can be trusted to complete again). Sprint has 30 points planned. Two bugs and a feature request arrive together. Bug 1 causes a hard crash for 5% of users during checkout, high customer impact and direct revenue exposure estimated at roughly $40K/week from the resulting drop-off in the checkout funnel, sized at 3 points. Bug 2 is a cosmetic misalignment on a settings page, affecting all users but non-blocking, no revenue impact, 1 point. A compliance-mandated audit-log field has a regulatory deadline in 10 days, 8 points. Triage: Bug 1 (customer impact and revenue) and the compliance feature (regulatory, hard deadline) go in; Bug 2 stays out and is logged for next sprint since it fails all three criteria. That adds 11 points (3 for Bug 1 plus 8 for the compliance feature); the negotiation with PM names the specific two to three lower-priority backlog items being pushed out to make room, rather than silently pushing the sprint to 41-plus points (the original 30 plus the 11 just added) against a demonstrated 30-point velocity.

A second, shorter example from a different discipline. A data science team reprioritizing which model-quality issues to fix before a report ships uses the identical three criteria: does the error touch customer-facing numbers (impact), does it touch a metric tied to revenue reporting (revenue), and is there a compliance or audit reason it must be correct by a specific date (regulatory), and communicates the same way, an explicit statement of what gets cut to make room.

The trap. Silently stacking the new bugs and the feature request on top of the existing sprint, without naming what comes out, is the weak answer. It looks responsive in the moment but blows the sprint commitment and erodes trust once the team can't explain why velocity tanked.

Direct answer
Most large employers that codify their interview values name broadly similar underlying traits, even when their specific vocabulary differs: a customer or user-first orientation, taking ownership beyond a narrow scope, moving with appropriate urgency, holding a high quality bar, and being trustworthy and transparent recur across nearly every published framework, just under different labels.

Structured elaboration

Worked example
The table above is itself the worked example. A strong candidate should be able to reproduce a table like this from memory for whichever specific company's list they are asked about, translating each of that company's named principles onto one of these five underlying traits, rather than treating an unfamiliar company's vocabulary as an entirely new set of ideas to learn from scratch.

Trade-offs and pitfalls
Treating every company's list as identical is itself a mistake; the values differ in emphasis, and in what is explicitly left off the list. A company whose published list omits any explicit ownership language may culturally deprioritize individual initiative in favor of process, for example, and that is worth noticing rather than flattening away. A candidate who can only speak the vocabulary of one company, fluent in one set of terms but unable to translate the same underlying trait into a different company's language, reads as having memorized rather than internalized the competencies involved.

Overview (goal)
I would build a layered, signal-driven test pyramid that balances fast feedback with broad-device reliability: heavy unit tests, focused integration tests on emulators, and curated UI tests on real devices.

Test coverage targets

• Unit: 70–80% logic/code paths (view models, utilities, validators)
• Integration: 15–25% (network layer, DB, platform-API glue)
• UI/E2E: 5–10% (critical user flows: auth, payments, onboarding, camera/location)

Mocking & stubbing

• Use dependency injection to swap real services for mocks in unit tests (Mockito/KMock for Android, Cuckoo/Mockingbird for iOS, or Dart mockito for Flutter).
• For integration tests, use contract-mocks and a local mock server (WireMock, MockWebServer) simulating latency, errors, auth tokens.
• For hardware (camera/GPS), provide platform-level stubs and simulated sensor data.

Device farm strategy

• Emulators/simulators run on every PR for fast feedback.
• Device farm (Firebase Test Lab, AWS Device Farm, BrowserStack) runs nightly and pre-release suites covering: top 30 devices by usage + 3 OS versions per platform, at least one low-end device per major OEM.

Test data management

• Use deterministic seeded test DBs and tokenized test accounts.
• Isolate state per test using fixtures and teardown; use feature flags to enable test-only endpoints.
• Encrypt and rotate sensitive fixtures; store in CI secrets.

Flaky detection & quarantine

• Track flaky tests via CI history (failure rate >5% flagged).
• Auto-quarantine flaky tests to a “flake” pipeline and notify owner; require flaky-fix within SLA (e.g., 2 sprints) or move to manual regression.
• Capture full device logs, screenshots, and video on failure to aid triage.

CI reporting to developers

• Enrich CI with structured reports: per-test pass/fail, stack traces, device model/OS, logs, screenshots, repro steps.
• Post PR comments with unit/integration summary; block merges on failing unit tests, allow flaky-flagged PRs but create a blocking issue.
• Daily dashboard (Grafana) for test health, device coverage, and flaky trends; integrate with Slack for alerts.

Trade-offs & maintenance

• UI tests are slow/expensive—keep them small and high-value. Regularly prune tests and update device matrix based on analytics.
  This strategy gives fast local feedback while ensuring reliability across diverse real devices.

Approach (high level)

• Implement platform-critical pieces natively (background scheduling, resumable uploads, secure enclave/keystore storage). Keep a thin, well-documented JS API that orchestrates sync logic and UI state.

Native responsibilities

• Android: WorkManager for periodic and expedited background work; DownloadManager/WorkManager + okHttp with okhttp’s Call for resumable uploads; EncryptedSharedPreferences / keystore for keys and SQLCipher for DB.
• iOS: BGTaskScheduler / NSURLSession background uploads (supports resumable/background transfers); Keychain + Secure Enclave for keys; SQLCipher/CoreData with encryption.

JS API (thin bridge)

• Provide methods: startSync(), queueRecord(record), getSyncStatus(), pause/resumeSync(), registerSyncHandler(callback).
• Example usage:

// js bridge usage
import Sync from 'native-sync';
Sync.queueRecord({ id, payload });
Sync.startSync();
Sync.registerSyncHandler(status => console.log(status));

Cross-platform storage abstraction

• Use native encrypted SQLite (SQLCipher) behind a JS module that exposes CRUD + change-log/queue APIs. Keep schema & conflict metadata native; expose transactions and stream of pending items to JS.

Handling termination & iOS deep sleep

• Use background-capable transports: NSURLSession background configuration and Android WorkManager with expedited work + foreground notification for long tasks. Persist resumable state (upload offsets, ETag) to encrypted storage. On app relaunch or BGTask run, resume using stored state.
• On iOS, schedule BGProcessingTask with reasonable intervals, request background fetch and push-triggered sync via silent push for urgent wakeups.

Trade-offs: third-party libs vs custom native

• Third-party pros: faster delivery (react-native-background-fetch, react-native-blob, WatermelonDB), community-tested. Cons: less control for edge cases (resumable guarantees), security model, native bugs, dependency bloat.
• Custom native pros: precise control (reliability, encryption), better performance, easier to meet compliance. Cons: longer dev/maintenance cost, cross-platform parity effort.

Notes / Best practices

• Keep JS logic idempotent; store authoritative state server-side with conflict resolution strategy.
• Encrypt keys by KDF + device-specific key; minimize JS exposure of secrets.
• Add instrumentation and robust retry/backoff, and extensive device/OS-specific testing.

Direct answer
A mentoring relationship going badly is rarely one big failure; it's usually a slow accumulation of choices, like taking on too much of the work yourself to protect the outcome, that quietly undercut the mentee's growth. The honest answer names a specific relationship, is candid about what you did (not just what the mentee did), and shows what changed in how you mentor afterward.

What "went badly" usually looks like

• Common patterns: being too directive and doing the hard parts yourself to protect delivery; giving feedback too infrequently or too late to be actionable; misjudging the mentee's actual gap (treating a confidence problem as a skill problem, or the reverse); or disengaging when the relationship got effortful.
• A strong answer picks one specific pattern and owns your part in it, rather than a vague "they weren't a good fit."

What separates a senior answer from a junior one

• Junior answers blame the mentee ("they just weren't receptive") or stay abstract ("communication could have been better"). Senior answers identify a decision you made and trace its actual effect: what you did, what it produced, and why it made sense to you at the time even though it was wrong.
• Senior answers also show what changed structurally afterward, not just an apology or a resolution to "communicate better." Concrete changes: an explicit mentoring agreement up front, checkpoints instead of open-ended availability, deliberately handing over ownership even when it's slower.

How to close it out

• End on what you'd do differently now, stated specifically enough that it's clear you'd actually behave differently in the next relationship, not just that you feel bad about the last one.

Worked example
During a stretch project with a hard deadline, I mentored a junior engineer by taking over the riskiest parts myself rather than coaching them through it, to keep the timeline safe. That worked in the short term, but it meant they never built confidence handling ambiguity or incidents on their own, and toward the end of the project they told me directly that they felt sidelined rather than developed. That was the moment it became clear the relationship hadn't done what I'd intended, even though the project itself shipped fine.

What I changed afterward: instead of stepping in when something got risky, I started requiring myself to narrate my reasoning out loud and have the mentee drive, only taking over if there was a genuine, immediate risk. I also set an explicit checkpoint (a short regular sync, not just "come find me") so growth stalls would surface early instead of only becoming visible at the end of a project. The relationship after that wasn't measured by how smoothly the project went; it was measured by whether the mentee could handle the next similar situation without me in the room, which is a slower thing to build but the actual point of mentoring.

Trade-offs and pitfalls

• The tempting failure mode is optimizing for the deliverable (visible and rewarded) at the expense of the mentee's growth (slower and less visible), especially under deadline pressure.
• Being self-critical is necessary but insufficient; an answer that's all remorse with no concrete process change reads as unreflective in a different way.
• Watch for over-correcting into never stepping in, which just replaces one failure mode (too directive) with another (abandoning someone to a mistake they can't yet recover from alone).

Approach (brief)
Retry only idempotent methods (GET, HEAD). Use exponential backoff with baseDelay, multiplier (doubling factor), maxDelay and randomized jitter in each retry. Implement as an OkHttp Interceptor, counting attempts and sleeping between retries. Avoid retrying non-idempotent requests by checking request.method and returning immediately.

Kotlin implementation

import okhttp3.Interceptor
import okhttp3.Response
import kotlin.math.min
import kotlin.random.Random
import java.io.IOException
import java.util.concurrent.TimeUnit

class RetryInterceptor(
    private val maxAttempts: Int = 3,
    private val baseDelayMillis: Long = 200,
    private val multiplier: Double = 2.0,
    private val maxDelayMillis: Long = 2000,
    private val jitterFactor: Double = 0.5 // ±50% jitter
) : Interceptor {

    private val idempotent = setOf("GET", "HEAD")

    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        if (!idempotent.contains(request.method)) {
            // Do not retry non-idempotent requests
            return chain.proceed(request)
        }

        var attempt = 1
        var lastException: IOException? = null
        while (attempt <= maxAttempts) {
            try {
                val response = chain.proceed(request)
                // Retry on server errors or network failure only
                if (!shouldRetryResponse(response)) return response
                response.close()
            } catch (e: IOException) {
                lastException = e
            }

            if (attempt == maxAttempts) break

            // compute exponential backoff with jitter
            val exponential = (baseDelayMillis * Math.pow(multiplier, (attempt - 1).toDouble())).toLong()
            val capped = min(exponential, maxDelayMillis)
            val jitter = (capped * jitterFactor * (Random.nextDouble(-1.0, 1.0))).toLong()
            val delay = (capped + jitter).coerceAtLeast(0L)
            try { Thread.sleep(delay) } catch (_: InterruptedException) { Thread.currentThread().interrupt(); break }
            attempt++
        }
        throw lastException ?: IOException("Max retry attempts ($maxAttempts) exhausted")
    }

    private fun shouldRetryResponse(response: Response): Boolean {
        // Successful or client errors shouldn't retry; retry on 5xx
        val code = response.code
        return code in 500..599
    }
}

Why this avoids non-idempotent retries

• Checks method against allowed idempotent set before any retry logic. POST/PUT/DELETE are not retried to avoid duplicate side-effects.

Notes / best practices

• Prefer async/backoff via scheduler (avoid blocking threads) in production.
• Consider honoring Retry-After header and using per-request overrides.