Amazon Mobile Developer Interview Preparation Guide - Mid Level

Purpose & high-level difference

• iOS Keychain: encrypted system store for small secrets (passwords, tokens, keys). Integrates with Secure Enclave for hardware-backed keys and supports accessibility flags and access groups.
• Android Keystore: API for generating/storing cryptographic keys in a protected environment (Keymaster/HSM or StrongBox). Keys can be hardware-backed; actual secret blobs are typically encrypted with these keys and stored in app storage.

When to use Keychain/Keystore vs UserDefaults/SharedPreferences

• Use Keychain/Keystore for all sensitive secrets: OAuth tokens, refresh tokens, API keys, private keys.
• Never store secrets unencrypted in UserDefaults/SharedPreferences — these are plaintext and easily read if device compromised.
• For convenience, you may store encrypted blobs (ciphertext) in SharedPreferences/UserDefaults but keep keys in Keystore/Keychain.

Basic best practices

• Prefer hardware-backed keys (Secure Enclave / Keymaster / StrongBox) when available.
• Use platform access controls:
  • iOS: appropriate kSecAttrAccessible (e.g., WhenUnlockedThisDeviceOnly) and access groups for app suites.
  • Android: set userAuthenticationRequired / auth validity, require biometrics if needed.
• Perform encryption: derive symmetric keys stored in Keystore and use AES-GCM to encrypt token blobs before storing.
• Avoid hardcoding secrets in app binary; fetch ephemeral secrets from backend when possible.
• Implement rotation and short-lived tokens: use refresh tokens stored securely and rotate keys periodically.
• Handle backup: use “ThisDeviceOnly” options to prevent automatic backups if required.
• Protect against backups, root/jailbreak detection, and implement logging/monitoring for suspicious access.

Example pattern:

• Generate AES key in Keystore/Keychain (hardware-backed).
• Encrypt token with AES-GCM.
• Store ciphertext in SharedPreferences/UserDefaults; keep key protected by Keystore/Keychain.

This ensures confidentiality, hardware protection, and manageable rotation.

Direct answer

Expand a right pointer across s while counting how many characters of t's required multiset you currently hold; once the window contains every required character with at least its needed count, shrink from the left one character at a time, recording the shortest valid window each time before it breaks validity, then keep expanding. Because both pointers only move forward and a running counter tracks validity instead of rescanning the window's contents, the whole search is $O(|s| + |t|)$ time using space proportional to the alphabet of t. The same expand-and-contract skeleton generalizes directly to "longest window with at most K distinct characters": instead of tracking whether every required character is present, you track how many distinct characters are currently in the window and shrink whenever that count exceeds K instead of whenever the window is valid, then record the window's length after every expansion rather than the shortest valid window.

Approach

• Build need, a count of each character required by t, and track required = len(need), the number of distinct characters that must be satisfied.
• Expand right across s, incrementing have[char]; whenever a character's count in have first reaches its required count, increment formed.
• Whenever formed == required (the window is currently valid), record the window if it's the shortest seen, then shrink from the left, decrementing have for the character leaving the window and decrementing formed if that drop takes it below the required count.

from collections import Counter, defaultdict


def min_window(s: str, t: str) -> str:
    """O(len(s) + len(t)) time, O(distinct chars in t) space."""
    if not s or not t:
        return ""
    need = Counter(t)
    required = len(need)
    have: dict[str, int] = defaultdict(int)
    formed = 0
    left = 0
    best_len, best_left, best_right = float("inf"), 0, 0

    for right, ch in enumerate(s):
        have[ch] += 1
        if ch in need and have[ch] == need[ch]:
            formed += 1

        while formed == required:
            if right - left + 1 < best_len:
                best_len = right - left + 1
                best_left, best_right = left, right
            left_ch = s[left]
            have[left_ch] -= 1
            if left_ch in need and have[left_ch] < need[left_ch]:
                formed -= 1
            left += 1

    return "" if best_len == float("inf") else s[best_left:best_right + 1]


def longest_k_distinct(s: str, k: int) -> int:
    """Same expand/contract skeleton, generalized to: longest window
    with at most k distinct characters. O(len(s)) time, O(k) space."""
    if k == 0:
        return 0
    counts: dict[str, int] = defaultdict(int)
    left = 0
    best = 0
    for right, ch in enumerate(s):
        counts[ch] += 1
        while len(counts) > k:
            left_ch = s[left]
            counts[left_ch] -= 1
            if counts[left_ch] == 0:
                del counts[left_ch]
            left += 1
        best = max(best, right - left + 1)
    return best


if __name__ == "__main__":
    print(min_window("ADOBECODEBANC", "ABC"))  # BANC
    print(min_window("a", "a"))                  # a
    print(min_window("a", "aa"))                 # "" (t needs two a's, s has one)
    print(longest_k_distinct("eceba", 2))        # 3 ("ece")
    print(longest_k_distinct("aa", 1))           # 2

Running this prints BANC, a, an empty string, 3, and 2, matching the standard cases for both the minimum-window problem and its at-most-K-distinct generalization.

Key points

• formed turns "is the window currently valid" into an $O(1)$ check; comparing the full have and need dictionaries on every step instead would cost $O(|\text{alphabet}|)$ per step and push the total cost to $O(n \cdot |\text{alphabet}|)$.
• The order of operations when shrinking matters: decrement have[left_ch] first, then compare it against need[left_ch], since a character's count can only just have dropped below its required count on the step where it's removed.
• For the K-distinct generalization, a character's entry must be fully deleted from counts once its count reaches zero, not left behind as a zero-count entry, since len(counts) is exactly what's being used as the distinct-character signal, and a stale zero-count key would be wrongly counted as still present.
• Related but structurally different: the fixed-multi-word-length "concatenation of all words" variant (finding all starting indices where a substring is an exact concatenation, in some order, of every word in a given list of equal-length words) does not fit this expand/contract template, because the target window size is known upfront (number of words times word length). It's typically solved as a fixed-size sliding window checked against a word-count map, sliding by one word-length at a time, rather than a variable window driven by a validity condition that grows and shrinks.

Complexity

min_window: $O(|s| + |t|)$ time (right and left each advance across s at most once in total; building need is $O(|t|)$), $O(|t|)$ space for need and have (bounded by the distinct characters in t). longest_k_distinct: $O(|s|)$ time, $O(k)$ space (at most $k+1$ distinct characters tracked at once).

Edge cases

• t longer than s, or t requiring more of a character than s contains: no valid window exists, return an empty string.
• Either input empty: guarded explicitly at the start.
• t with repeated characters: Counter naturally tracks the required multiplicity, not just distinct presence.
• For the K-distinct generalization: k = 0 means no window is possible (return 0); k at least as large as the number of distinct characters in s means the entire string is the answer.

What a heap dump is

A heap dump is a snapshot of every live object on a process's managed heap (for a garbage-collected runtime such as the JVM, Java Virtual Machine) at one instant, including each object's fields, size, and references to other objects. It's effectively a full memory census you can load into an analyzer afterward.

When to capture one in production

• When heap usage is trending toward an OOM (Out Of Memory, when the process is killed or fails because it exceeded available memory) and you need to identify exactly which objects are being retained.
• When you have a specific, already-suspected leak and need to confirm which class is actually growing.
• At the moment of an OOM itself, many runtimes support a "dump heap automatically on OOM" flag, so you capture the exact state that caused the failure instead of trying to reconstruct it afterward.

Live heap dump vs allocation sampling

• A live heap dump captures everything CURRENTLY retained, exactly, you see every live object and its reference chain. The cost is real: taking one is expensive, it commonly triggers a full stop-the-world pause (the runtime freezes application threads to take a consistent snapshot) and produces a large file, so it's not something to do routinely, only for a deliberate, specific investigation.
• Allocation sampling instead records a statistical sample of allocation call sites over time (WHERE objects are being created), with much lower overhead, low enough to run continuously or on demand without freezing the process. It tells you where churn is happening, which is great for finding an allocation hotspot driving GC (garbage collection) pressure, but it does not give you the full retained-object graph a heap dump gives you.

Minimizing production impact

• Default to allocation sampling for ongoing, low-overhead visibility.
• Reserve full heap dumps for one deliberate capture, ideally on a single canary instance pulled out of the load balancer's rotation first, not across the whole fleet simultaneously.
• Use dump-on-OOM flags so the one dump you actually need gets captured automatically, without needing to guess the right moment.

Direct answer
A repeatable way to shape a real story into a principle-mapped interview answer: start from the story, not the principle; identify which one or two principles it most naturally demonstrates; structure the telling so the actions carry the evidence rather than announcing the principle by name; close with a concrete, ideally measurable result; and only state the principle's name explicitly if the interview format specifically calls for it.

Structured elaboration

1. Inventory first. Write down six to ten real situations spanning different flavors of experience (a technical trade-off, a disagreement, a mistake, a moment of leading without formal authority, a customer-facing choice).
2. Map second. For each story, ask what your actions actually demonstrated, rather than starting from which principle you want to show. Mapping from story to principle, not the reverse, keeps the story honest.
3. Structure with situation, task, action, result, and put roughly 60 to 70 percent of the telling time in the action section, since that is where the principle actually shows up.
4. Quantify the result where you honestly can. Where you can't, describe a concrete, verifiable change instead of a vague feeling of success.
5. Name the principle explicitly only if the format calls for it. Some interviewers want you to state it directly, in which case one closing sentence is enough; narrating the principle's name throughout reads as reciting rather than demonstrating.

Worked example
Consider a story about restoring a degraded service faster than the standard escalation path would have. Situation: a service degraded during a high-traffic period. Task: the candidate was the person on point. Action: rather than escalating immediately and waiting, they spent the first several minutes gathering the most likely signals, formed a hypothesis, tested it with a small, reversible change, and escalated only once they had evidence rather than a guess. Result: the issue was resolved well inside the window that would have triggered a customer-facing incident, and the candidate wrote up the diagnostic path afterward so the next person facing the same symptom could skip the initial investigation. If the interviewer's principle is framed around ownership or thorough investigation, it is the methodical hypothesis-testing and the follow-up write-up, not a sentence claiming the principle, that demonstrate it.

Trade-offs and pitfalls
Repeating the principle's name throughout a story ("this shows my ownership, which is also ownership because...") reads as reciting rather than demonstrating; state it once, if at all. Choosing a story because it sounds impressive rather than because it honestly demonstrates the specific actions a principle cares about is a common mismatch that a practiced interviewer will probe past. Time-boxing also matters: a detailed answer that never reaches a result is a frequent failure mode, so keep the action section rich but always land on a result.

Clarify & reproduce reliably

• Record device models, Android versions, app build and ProGuard mapping.
• Try to reproduce with emulator images matching older Android (API 19–22) and with low-memory/slow CPU settings.

Collect logs and traces

• Enable adb logcat (adb logcat -v time) and capture before/through rotation; filter by app PID and "AndroidRuntime".
• Capture tombstones / ANR traces on device (adb bugreport).
• Enable StrictMode and set ThreadPolicy/ VmPolicy to catch leaked resources.

Runtime tooling

• Use Android Studio profiler (Memory, CPU) during rotation; enable allocation tracking.
• Use systrace / Perfetto to surface scheduling delays and binder delays.
• Reproduce with Instant Run disabled and with proguard symbols to ensure stacktrace readability.

Breakpoint & instrumentation

• Add try/catch + logging around onSaveInstanceState, onRestoreInstanceState, onCreate, onResume.
• Instrument ViewBinding/ findViewById points to log nulls. Add null-check assertions.
• Insert short Thread.sleep to expose race conditions between background tasks and UI restore.

Common culprits to check

• NullPointer from view binding after setContentView mismatch or using stale binding in fragments.
• Race conditions: background callbacks updating UI after config change — ensure lifecycle-aware observers (Lifecycle, LiveData, coroutines with viewLifecycleOwner).
• Memory pressure: older devices may kill process; check savedInstanceState null handling and restore defensive checks.
• Fragment transactional state loss: avoid commitAllowingStateLoss; use commitNow if immediate.

Next steps

• Reproduce with minimal sample activity; bisect code to isolate offending change.
• Fix: defensive null checks, cancel background tasks in onDestroy/onStop, use lifecycle-aware components, defer heavy work, and test across target older APIs.

Direct answer

I distinguish by pattern, not just output level. Burnout or disengagement usually shows up as a broad decline across previously strong areas, paired with a real change in energy or affect (a person's visible mood and emotional expression). A skill gap is usually narrower, tied to a specific type of task, and doesn't come with that affect change. Once burnout is suspected, the shift is from output-focused coaching to a wellbeing-first conversation and workload adjustment.

Distinguishing signals

The diagnostic move

Because the same output pattern (missed deadlines, lower-quality work) can come from either cause, guessing from behavior alone risks the wrong intervention. More skill-focused coaching aimed at someone who's actually burned out just adds pressure. The reliable move is to ask directly and non-accusatorially rather than only inferring, since it's the fastest way to tell the two apart.

What to do differently once suspected

Shift the conversation from task correction to workload and wellbeing. Reduce scope or redistribute urgent items in the short term rather than expecting normal output immediately. Check in more on process and how they're doing than on deliverables for a while. Point toward available support resources where they exist. Avoid escalating straight to a formal performance conversation while this is unresolved, but also avoid treating it as an indefinite excuse, set an actual review point to reassess rather than letting it run open-ended.

Worked example

A mentee whose work had been consistently strong started slipping across several unrelated tasks, not just one. The decline was recent and came with noticeably less participation in discussions, which pointed away from a narrow skill gap. A direct, private conversation surfaced an unsustainable workload building up over recent weeks. The short-term adjustment was reprioritizing their task list and explicitly deprioritizing anything non-urgent, with a check-in scheduled two weeks out to see whether things had actually improved rather than assuming they had.

Trade-offs and pitfalls

A common mistake is treating every dip in output as a skill or effort problem and escalating straight to a formal process. The stronger approach separates "can't" (skill), "won't" (motivation or disengagement), and "can't sustain right now" (burnout), because they call for different responses, while staying alert that a genuine performance issue can coexist with real burnout, one doesn't automatically rule out the other. It's also a pitfall to assume burnout excuses declining output indefinitely: there still needs to be a check-in cadence, and if it doesn't resolve, it may need to go beyond what a mentor alone can fix, involving a manager or people-ops rather than absorbing an open-ended situation solo.

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

The closure captures self strongly, and self.onUpdate holds that closure, a reference cycle. (Swift manages memory via ARC, Automatic Reference Counting: it frees an object once nothing holds a strong reference to it, using a running count of those references, so a reference cycle where two objects each strongly hold the other keeps that count above zero forever.) Nothing external breaks it, so ARC's retain count never reaches zero and deinit never fires.

Structured elaboration

Fix by capturing weakly: [weak self] in guard let self = self else { return }. The closure no longer contributes a strong reference, so once the owning screen's reference goes away, the object can actually reach zero and deinitialize.

Worked example

Executed to confirm both the leak and the fix, using deinit as ground truth:

final class ViewModel {
    let id: String
    var onUpdate: (() -> Void)?
    init(id: String) { self.id = id }
    deinit { print("\(id) deinitialized") }
    func subscribeLeaky() { onUpdate = { print(self.id) } }
    func subscribeFixed() { onUpdate = { [weak self] in print(self?.id ?? "-") } }
}
func scopeLeaky() { let vm = ViewModel(id: "leaky"); vm.subscribeLeaky(); vm.onUpdate?() }
func scopeFixed() { let vm = ViewModel(id: "fixed"); vm.subscribeFixed(); vm.onUpdate?() }
scopeLeaky(); scopeFixed()

Output: leaky, fixed, fixed deinitialized. "leaky deinitialized" never prints, proving the leak; "fixed deinitialized" fires right after scopeFixed() returns, proving the fix.

Complexity

Not applicable algorithmically; this is an object-lifetime bug, not a performance one.

Edge cases

If the closure must finish work after dismissal (flushing analytics, say), [weak self] can silently no-op too early; [unowned self] or capturing only the needed value fits better when the closure provably can't outlive self.

Trade-offs and pitfalls

[unowned self] skips the guard let but crashes instead of no-op-ing if self is already deallocated.

What the interviewer probes next

How you'd catch this automatically with the Memory Graph Debugger or Instruments' Leaks template, and when unowned beats weak.

Direct answer

Troubleshooting an unfamiliar problem is a loop, not a single step: observe the symptom precisely, form a small set of testable hypotheses ranked by likelihood and cost to check, gather evidence that discriminates between them, isolate the true cause, implement and validate a fix, and decide whether the incident needs a rollback, an escalation, or a written postmortem. The loop repeats: each piece of evidence should narrow the hypothesis set, not just confirm what you already believed.

Structured elaboration

1. Observe the symptom precisely. Write down exactly what is wrong, in falsifiable terms: not "the API is slow" but "p99 latency (the response time slower than 99% of requests, i.e. how bad the worst cases are, not just the average) on POST /orders rose from 80ms to 900ms starting at 14:32 UTC, affecting roughly 3% of requests." Vague symptoms produce vague hypotheses.
2. Form hypotheses before you start digging. List the plausible causes given what changed recently (deploys, config, traffic pattern, dependency versions) and what the symptom rules out. A hypothesis you cannot state is a hypothesis you cannot test.
3. Prioritize by expected information gain divided by cost. A five-minute log grep that could confirm or kill three hypotheses at once beats a one-hour deep profiling session that only speaks to one.
4. Gather evidence that discriminates. Logs tell you what happened at a point; metrics tell you the shape of the problem over time; traces tell you where time went inside one request. Pick the instrument that actually distinguishes your live hypotheses, not the one you're most comfortable with.
5. Isolate the root cause, not just a correlated symptom. A dropped hypothesis should be dropped because evidence contradicts it, not because you got bored of it.
6. Implement and validate the fix against the same evidence that revealed the problem. If you diagnosed via a specific metric, watch that metric recover before declaring victory.
7. Decide what happens next. If customer impact is ongoing and the fix is unproven, roll back first and diagnose second. If a similar failure could recur, or the incident had real impact, write it up so the org doesn't relearn the same lesson.

Worked example

A "the checkout page is slow" report, applied through the loop: symptom precisely stated as "median load time is normal, but a subset of loads takes 8-12 seconds, starting after this morning's deploy." Hypotheses: (a) the new deploy added a blocking call, (b) a downstream dependency degraded independently, (c) the slow subset shares a common attribute (e.g., a specific region or a large cart). A single log query grouping slow requests by attribute would discriminate between (c) and the other two in minutes, before touching a profiler. Suppose it shows the slow requests all hit a newly added inventory-check call to a dependency with no timeout: that both confirms (a) and rules out (b)/(c) as primary causes. Fix: add a timeout and a fallback; validate by watching the p99 metric drop back to baseline over the next hour, not just the fix compiling.

Trade-offs and pitfalls

The biggest failure mode is skipping hypothesis formation and going straight to your favorite tool (attaching a profiler because you're comfortable with it, even when a five-minute log check would have ruled out two hypotheses first). The second is treating the first correlated signal as the cause without checking whether it's actually causal. Under time pressure it's tempting to fix the first plausible thing you see; that's fine as a mitigation, but the loop isn't complete until you've confirmed the metric recovered and understood why, or you will be back debugging the same symptom next week.

High-level approach
I’d build a single source-of-truth Design System (DS) that emits platform-specific component libraries and token packages, plus a web-based catalogue/preview for designers and devs. Key goals: adaptive layout, theme tokens, accessibility defaults, platform variation, and safe incremental rollout.

Component layering

• Core tokens: color, spacing, typography, motion (JSON Schema).
• Primitives: semantic Widgets/Views (ButtonBase, TextBase) with accessibility props and responsive behavior.
• Composed components: Buttons, Cards, Lists using primitives + tokens.
• Platform adapters: thin layer per platform (Swift/Kotlin/ReactNative/Flutter) implementing native affordances while reusing shared logic.

Distribution & versioning

• Token package: published as versioned artifact (npm + artifact repo) with generated platform bindings.
• Component libs: SPM/CocoaPods (iOS), Maven/Gradle (Android), npm for RN. Semantic Versioning + changelogs.
• Incremental rollout: feature flags + runtime token overrides and “opt-in” module versions; canary releases by app build using specific DS version.

CI/CD & token/snapshot pipeline

• Token CI: lint/validate JSON → generate platform code → run unit + snapshot tests.
• Visual snapshots: run per-component screenshots on device farm (iOS Simulators, Android Emulators) and compare (per-theme, per-size, per-accessibility scale).
• CD: automated publish on passing pipelines; gated releases for major changes with beta channels.
• Rollback via package version pinning and remote token overrides.

Developer/designer tooling

• Storybook/Widgetbook-like site with interactive tokens, theme editor, accessibility simulator (dynamic type, TalkBack/VoiceOver), and export code snippets (Swift/Kotlin/JS).
• Token playground that emits downloadable token packages and one-click sample app that pins DS version.
• CLI to sync tokens, run local preview, and scaffold platform adapters.

Trade-offs

• Generating platform code increases build complexity but ensures parity. Native adapters preserve platform UX while maintaining design consistency.

This design balances cross-platform consistency, accessibility-by-default, and safe incremental rollout for mobile apps.