Amazon Mobile Developer (Junior Level) Interview Preparation Guide

Direct answer

I weigh the security benefit against the friction a customer will actually feel, using numbers where I can. Then I look for the lowest-friction way to get most of the protection, and I roll it out in stages with measurements and an exit. Security wins when the risk is serious and not otherwise reducible, but how it ships is a customer-experience decision.

How I weigh it

1. Risk removed. What attack or loss does the change prevent, how likely, and for whom? Ask security for a specific scenario, not "best practice."
2. Friction added. Which customers feel it, how often, at what moment (signing in daily versus a rare admin action), and what do they do when annoyed (abandon, call support, work around it)?
3. Cheaper routes to the same protection. Apply the strict control only where risk is high (risk-based or step-up checks: ask for an extra proof only when something looks unusual or the action is sensitive), remember trusted devices, or give a smoother factor.
4. Who carries the cost. Friction on a signup flow costs conversion; friction in an enterprise admin flow costs support calls.

Three related cases

Worked example (illustrative): rolling out MFA to 100,000 accounts

• Stage 1: 5% of accounts (5,000), chosen to include small and large customers. Track setup completion, lockout-related support contacts, and sign-in success.
• Gate: advance only if the thresholds agreed beforehand with security and support are met. Illustrative thresholds: at least 80% of prompted accounts finish setup (4,000 of the 5,000), no more than 10 lockout-related support contacts a week (2 per 1,000 accounts), and sign-in success falls by no more than 1 percentage point. Miss any one and I pause, fix the cause, and rerun the stage.
• Stage 2 and 3: widen, with in-app explanation of why, then move from encouraged to required on a published date. Keep a rollback and an exception path for customers with real blockers.

Pitfalls

Do not frame it as security versus customers. Do not roll out to everyone at once. Do not set a "will not hurt conversion" bar with no measurement behind it.

Approach summary
Propose layered changes: reduce JS-native roundtrips by batching/coalescing, relocate frequent logic to native, and use JSI/Hermes for direct, low-latency paths (bypass bridge).

1) Batching / coalescing

• Buffer frequent small events (sensor samples, animation deltas) on JS or native side and send in frames (e.g., 16ms/60Hz) or when buffer full.
• Example pattern (JS): collect and flush on requestAnimationFrame or setInterval.

// collect and flush example
const buffer = [];
function onSensor(sample) { buffer.push(sample); }
function flush() {
  if (buffer.length===0) return;
  NativeModules.Sensors.receiveBatch(buffer);
  buffer.length = 0;
}
requestAnimationFrame(flush);

• Use compact binary formats (ArrayBuffer/TypedArray) to minimize serialization cost.

2) Move logic to native

• Implement filtering, aggregation, sampling, interpolation on native (Swift/Kotlin/Objective-C) so only necessary updates reach JS.
• Expose higher-level APIs to JS (e.g., startSmoothStream({rate:50, filter:true})).

3) JSI / Hermes / TurboModules

• Implement critical paths via JSI with host objects so JS can call into native functions synchronously without async bridge overhead.
• Example: create a JSI animation host that applies transforms and writes directly to native views or Skia canvas.
• Use Hermes for lower GC latency and faster FFI.

4) Additional patterns

• Use one-shot events + shared memory: share a NativeArrayBuffer for sensor frames; JS reads via JSI without copying.
• Throttle and backpressure: drop frames when JS busy.
• Profile and measure: CPU, wall-clock, energy (Instruments / Systrace).

Trade-offs

• Native/JSI increases complexity and maintenance. Favor incremental rollout: batch first, then native, then JSI for hottest path.

Situation & goal
Design a push-driven sync trigger so server tells mobile apps “new data” while avoiding battery drain, background limits and thundering-herd.

High-level strategies

• Interest-based routing: subscribe devices to topics/segments (user, conversation, interest tags). Only notify relevant clients.
• Stagger + jitter: add randomized delay (e.g., 0–30s jitter) per-device or per-topic to avoid simultaneous wake-ups.
• Batching: coalesce rapid events on server into one notification window (e.g., 1–5s buffer); send one trigger for multiple changes.
• Exponential backoff / client-side rate-limits: if app recently synced, ignore additional triggers for a cooldown; server tracks last-sync timestamp per-client and respects minimum interval.

Server-side rate limiting & prioritization

• Prioritize urgent vs informational: assign priority flag; only high-priority sends immediate trigger. Low-priority go to batched queue.
• Global and per-user QPS caps to protect APNs/FCM and backend.
• Backpressure: if backend overloaded, convert non-critical pushes to silent flags to be pulled later.

Platform background limits

• iOS: content-available pushes can be throttled by the OS; don't rely on guaranteed delivery or execution time. Use VoIP/pushkit only when appropriate and allowed.
• Android: data messages may be blocked under Doze/Background restrictions—use high-priority sparingly; prefer WorkManager for guaranteed background work after wake.
• Always design for missed pushes: implement periodic background fetch or resume-on-open full sync.

Payload vs wake-only

• Wake-only (minimal): send no data when server simply needs client to fetch latest; best when payloads large, sensitive, or when you want server-side consistency checks.
• Small payload (delta): embed tiny JSON (version id, changed IDs, lightweight delta) when it reduces round-trips and fits platform limits; ensure payload < 4KB for APNs.
• Never include sensitive data in push; treat pushes as hints only.

Client implementation patterns

• On receiving trigger: check lastSyncTime, apply jitter, decide to full/paged/delta sync.
• Ack/heartbeat: client optionally confirms sync success so server can stop retrying.
• Retry/backoff policy: exponential backoff with random jitter on failed syncs.

Metrics & instrumentation

• Track push delivery, wake callbacks, sync latency, battery impact, and failed/queued notifications to tune jitter, batch windows and rate limits.

This design balances responsiveness with battery and platform constraints by combining targeted routing, jittered delivery, server and client rate-limiting, and choosing payload vs wake-only on a per-priority basis.

Clarify scope & goals

• Target screens, timeline, platforms (Compose for Android, SwiftUI for iOS), OS min versions. Goal: incremental migration, zero-touch regressions, ability to roll back.

High-level plan

1. Strangler pattern: wrap new declarative views inside hosts (ComposeView/AndroidView, UIHostingController/UIViewRepresentable) and vice-versa where needed.
2. Migrate one feature/module at a time (non-critical first), expand based on stability.

Interoperability strategies

• Android: use ComposeView inside existing Activities/Fragments; expose View-based APIs for measurement/events. For backwards, use AndroidView to host Views in Compose.
• iOS: host SwiftUI in UIHostingController; use UIViewRepresentable/UIViewControllerRepresentable to wrap legacy UI.
• Shared contracts: define ViewModel interfaces (Flow/LiveData or Combine/Observable) for state/events so both UIs consume same business logic.

Incremental rollout & feature toggles

• Add runtime feature flags (remote + local) per screen or component to switch implementations.
• Canary releases: user cohort targeting, A/B metrics collection.

Testing & QA

• Unit tests for ViewModels and business logic before UI swap.
• Snapshot tests for pixel regressions (Paparazzi/Shot for Android, iOS snapshot testing).
• E2E tests covering user flows with both old and new UIs (Espresso/XCUITest).
• Performance benchmarks: measure jank, memory, startup with new components.

Performance & safety

• Keep heavy work off the main thread; reuse existing optimizations (lazy lists, image caching).
• Monitor frame drops, allocation rate. Roll back toggle if regressions exceed thresholds.

Rollback & deployment

• Feature flags + kill-switch allow immediate rollback without app update.
• Maintain compatibility layer for telemetry and analytics.
• Gradual ramp with health dashboards (crash-free rate, ANR, CPU/frame metrics).

Collaboration with Designers & QA

• Create design tokens and component spec that both systems implement.
• Designers validate visual parity via storybook-like catalog (Compose Preview/SwiftUI Previews).
• QA test matrix includes old vs new comparisons, spotlighting input, animation, accessibility.

Risks & trade-offs

• Short-term complexity from two UI stacks; mitigate via clear contracts and cleanup plan to remove legacy code after full migration.

This plan enables safe, measurable, incremental migration while preserving performance and providing fast rollback paths.

Requirements & goals

• Fast smooth scrolling, low memory, minimal network, quick appearance of images, cancel wasted work on cell reuse.

High-level architecture

• UI layer (FeedCell) → ImageLoader API → MemoryCache (NSCache) → DiskCache (file store with LRU index) → NetworkFetcher (URLSession with prioritized tasks).
• Worker pool for decoding/downsampling off main thread (OperationQueue/GCD).

Components

• MemoryCache: NSCache keyed by URL+size; stores UIImage. Auto-evicts on memory pressure.
• DiskCache: on-disk files with metadata (lastAccess). LRU eviction by total size (e.g., 100MB).
• NetworkFetcher: URLSession with configurable concurrent ops, exponential backoff, conditional GET (ETag).
• Decoder: background downsampling using CGImageSourceCreateThumbnailAtIndex with max pixel dimension to reduce memory.
• Request Manager: maps requests to in-flight operations, supports deduplication and priorities.

Eviction policy

• Memory: NSCache + count/totalCostLimit (cost = pixels * bytesPerPixel).
• Disk: LRU by lastAccessTime, evict when total > limit.

Cancellation & reuse

• FeedCell calls imageLoader.load(url:size:priority) -> returns CancellableToken.
• On prepareForReuse call token.cancel(). Loader cancels network/decoder op if no remaining subscribers.
• Deduplicate: multiple subscribers share same operation; only cancel when all cancel.

API surface (Swift example)

protocol Cancellable { func cancel() }
final class ImageLoader {
  func load(url: URL, targetSize: CGSize, priority: Int, completion: @escaping (Result<UIImage,Error>)->Void) -> Cancellable
  func prefetch(urls: [URL], targetSize: CGSize)
  func clearMemoryCache()
}

Off-main-thread decoding/downsampling

• Fetch raw Data -> feed to CGImageSource on background queue -> create downsampled CGImage -> UIGraphicsImageRenderer for correct scale -> return UIImage on main thread.
• Use Image I/O to avoid allocating full-size bitmaps.

Measuring & optimizing scrolling

• Metrics: FPS (Core Animation instrument), Main thread CPU, Allocations, Memory growth, network bytes.
• Tools: Instruments (Time Profiler, Core Animation, Allocations), Network profiler.
• Optimizations:
  • Downsample to cell size, avoid extra layout work.
  • Prioritize visible cells, prefetch next N cells.
  • Limit concurrent decoders to avoid CPU spikes.
  • Use progressive loading placeholders and fade-in to mask late images.
  • Batch disk reads and use mmap/efficient IO.
  • Use compressed image formats (WebP/HEIF) if supported.

Trade-offs

• Stronger downsampling reduces quality but improves performance; tune per device.
• Disk TTL vs storage limit: prefer size-based LRU for predictable disk use.

This design balances responsiveness, memory, network efficiency and offers a simple, testable API for feed cells.

Clarify requirements
I’d design a cursor-based API optimized for mobile infinite-scroll: small payloads, low latency, deterministic ordering, and robust handling of dataset changes.

Request parameters

• GET /v1/items
• Query:
  • cursor (string, optional) — opaque server token
  • limit (int, optional) — client requested page size
  • snapshot_id (string, optional) — optional read-consistent snapshot token
    Example: GET /v1/items?cursor=abc&limit=25

Rules

• Server enforces max_limit = 50.
• Default limit = 20.
• Cursors are opaque, time-limited (e.g., 24h) and include last-seen item id + sort key + snapshot metadata (signed).

Sample JSON response

{
  "items": [
    {"id":"i123","title":"A","updated_at":"2026-02-28T10:00:00Z"},
    {"id":"i122","title":"B","updated_at":"2026-02-27T09:00:00Z"}
  ],
  "next_cursor":"eyJpZCI6Iml122Iiwi...signed"},
  "has_more": true,
  "limit": 20
}

Handling expired/invalid cursors

• If cursor expired/invalid -> 400 with code CURSOR_INVALID or CURSOR_EXPIRED and include fallback instructions:
  • Suggest first-page link (cursor omitted) or include a fresh snapshot token.
    Response example:

{"error":"CURSOR_EXPIRED","message":"Cursor expired; retry from start or use snapshot token"}

Mitigating duplicates/missing items

• Stable ordering: order by (primary sort key desc, unique id) to guarantee deterministic tiebreaker.
• Optional snapshot_id: server can provide a snapshot token to read a consistent view for the session; if provided, server serves from that snapshot to avoid missing/duplicated items.
• Server-side tombstones: keep deleted items as tombstones for a TTL so cursors remain valid; they can be skipped client-side but help preserve offsets.
• Client-side dedupe: mobile client should deduplicate by item id when appending pages.
• Idempotent cursors: encode last-seen item id + sort position to resume exactly.

Mobile considerations

• Keep payload small (only necessary fields).
• Preload next page when user nears end.
• Backoff and retry on cursor errors; show lightweight UI refresh if resync required.

This approach balances mobile performance, simplicity, and consistency when the underlying dataset mutates.

Approach overview
Describe client-side throttling as a cooperative layer: limit request rate locally (token/leaky bucket), respect server signals (Retry-After, 429), queue non-urgent work, and surface graceful degradation to users.

Token-bucket vs Leaky-bucket

• Token-bucket: tokens added at rate r, request consumes token; supports bursts up to bucket size. Good for user-initiated actions that can burst (e.g., search).
• Leaky-bucket: fixed outflow rate; smoothes traffic strictly — simpler if you must strictly pace background syncs.

Practical mobile implementation (Kotlin pseudo)

// simple token-bucket
class TokenBucket(val capacity: Int, val refillPerSec: Double) {
  var tokens = capacity.toDouble()
  var last = System.nanoTime()
  fun tryConsume(n:Int=1):Boolean {
    val now = System.nanoTime()
    tokens = min(capacity.toDouble(), tokens + (now-last)/1e9*refillPerSec)
    last = now
    if (tokens >= n) { tokens -= n; return true }
    return false
  }
}

Retry / Backoff

• Honor Retry-After and 429: parse header, schedule retry after suggested delay.
• If missing, use exponential backoff with full jitter to avoid stampedes:
  backoff = random(0, base * 2^attempt)

Queueing & Background Work

• Classify tasks: real-time (UI) vs opportunistic (sync, prefetch).
• Keep a persisted queue (SQLite/Room, file) for background jobs; drain when network unconstrained and tokens available.
• Integrate with OS background constraints (WorkManager / BGTasks).

UX & Graceful Degradation

• Surface minimal, actionable feedback: inline "Try again later" or spinner with countdown when Retry-After known.
• Disable or de-prioritize non-critical features (image prefetch, analytics) under throttling.
• Offer offline fallbacks: show cached content, save actions locally and sync later; show clear status (e.g., "Limited connectivity — background sync paused").

Monitoring & Telemetry

• Log 429s, Retry-After usage, queue length and retry attempts to help tune token rates server-side.

This approach preserves battery/network, avoids server penalties, and keeps users informed while maximizing useful behavior.

Answer (UI Designer perspective)

Affordances

• Use visible, touch-friendly affordances: raised buttons, clear outlines, large hit areas. Avoid relying solely on small text links for primary actions.
• Visual cues (shadows, depth, contrast) indicate tappability across devices.

Hover states

• Provide hover-only enhancements (tooltips, subtle elevation) but ensure primary cues don’t depend on hover: replicate important info on touch via persistent labels or focus states.
• Use focus styles for keyboard and accessibility.

Target sizes

• Minimum interactive target: 44–48 px (mobile) and 32 px acceptable on dense pointer UIs. Add spacing to prevent accidental taps.
• Expand hit area beyond visible control when needed.

Gestures

• Support simple, discoverable gestures (tap, double-tap sparingly, swipe with clear affordance). Don’t overload with complex gestures; provide alternative controls for critical actions.
• Distinguish drag vs. scroll with clear handles and threshold delays.

Feedback

• Immediate visual (pressed state), haptic (mobile), and audible feedback where appropriate. Debounce actions and show loading states to prevent repeated taps.

Design tokens: separate pointer and touch spacing, hover, pressed, focus states in the system so components adapt per input modality.

Approach (brief)
Explain routing with a stable routing key (deep link or screen id) in the push payload, handle app lifecycle on device, and validate/untrust payloads before navigation.

Backend payload design — examples

• APNs (iOS) — include custom data under aps and custom keys:

{
  "aps": { "alert": { "title": "New message", "body": "Tap to open" }, "badge": 1, "sound": "default" },
  "route": "chat",
  "route_id": "12345",
  "sender_id": "alice"
}

• FCM (Android) — use data for custom routing (use data-only for consistent delivery):

{
  "to": "...",
  "data": {
    "route":"chat",
    "route_id":"12345",
    "sender_id":"alice"
  },
  "notification": { "title":"New message", "body":"Tap to open" } // optional
}

Prefer data payloads (FCM) or silent pushes + local display to ensure consistent handling.

Including deep-links / routing identifiers

• Use a canonical routing key (e.g., route, route_id, params JSON).
• Optionally include full URI deep-link (myapp://chat/12345) for direct navigation across platforms.
• Keep keys small and versioned (route_v=1) for future changes.

App lifecycle behavior

• Foreground: system may not show banner (iOS); handle notification in-app callback and navigate immediately after validation.
  • iOS: userNotificationCenter:willPresentNotification
  • Android: onMessageReceived when app in foreground (data message)
• Background / Not running:
  • Tapping notification launches app with original payload via launch options (iOS) or intent extras (Android). Parse payload in initial routing code (scene:willConnect / activity intent).
  • If using silent pushes to fetch content, ensure you present a visible notification after fetching.
• Note: iOS may coalesce/modify payload; FCM notification messages are handled by system tray and may not include data to app when killed—use data-only or both notification+data carefully.

Security & validation

• Treat all payload fields as untrusted. Validate IDs server-side before navigation.
• Don’t include sensitive data in payloads (tokens, PII). Fetch details from backend once app is opened using authenticated API calls.
• Protect deep-link handlers: require authentication checks and fallback flows (login screen) if user not authorized.
• Prevent injection: canonicalize route strings, whitelist allowed routes, and avoid executing payload as code.
• Rate-limit automatic navigations to avoid UX abuse and phishing-like flows.

Implementation notes (mobile dev best practices)

• Centralize notification parsing and routing in one place (NotificationRouter).
• Add telemetry: record notification-impression, tap, and routing success/failure.
• Test across OS versions and cold start scenarios.

Direct answer

A PII-safe logging helper redacts common sensitive patterns (emails, Social Security numbers, credit card numbers) from a message before it is ever written to a log, using compiled regular expressions applied consistently across every log call, while also enforcing structured fields (a correlation ID, a job or request identifier), log-level discipline, and an extensibility point for adding new redaction patterns as new sensitive-data types are identified.

Structured elaboration

Redaction via compiled regex patterns. A small set of well-tested regular expressions, compiled once and reused (not recompiled on every log call, which would be wasteful), match common PII shapes: an email address pattern, a Social Security number pattern (\d{3}-\d{2}-\d{4}), and a credit-card-like sequence of 13 to 16 digits (allowing spaces or dashes as separators, since real card numbers are often written with them). Each match is replaced with a fixed [REDACTED] marker before the message is passed to the underlying logging framework.

Performance considerations. Compiling patterns once at startup (not per-call) and running them against every log message adds a small, roughly-constant regex-matching cost per log call; for a very high-throughput logging path this is measurable but usually acceptable, since the alternative (an actual PII leak into a log aggregation system with far broader read access than the original data source) is a materially worse outcome, and the specific cost can be validated by simply measuring log throughput with and without the redaction step in a realistic load test.

Configuration to extend redaction patterns. New PII patterns identified over time (an internal account-number format specific to the business, for instance) should be addable without modifying the core logging class, via a constructor parameter or configuration file accepting additional patterns, so the redaction logic can grow as new sensitive-data types are identified in practice, not require a code change and redeploy of the core logging utility itself for every new pattern.

Testing and validating at scale. Beyond unit tests confirming each pattern redacts correctly and that non-sensitive messages pass through unchanged, validating "at scale" means running the redaction logic against a genuinely large, realistic sample of actual (or realistically-synthetic) log messages and manually or statistically auditing a sample of the OUTPUT for anything that looks like it should have been redacted but wasn't, since regex patterns can have false negatives on real-world data that a small, hand-written unit test suite won't surface (an international phone number format, a differently-formatted SSN with no dashes).

Structured fields, log levels, and INFO versus DEBUG. Beyond redaction, the logging helper should ensure every log entry carries a correlation ID (tying related log lines from the same request or job together) and a job/run identifier where relevant (for a batch context specifically). INFO-level logging should capture what a normal operator needs to see to understand system behavior (a job started, a job completed, a summary count); DEBUG-level logging can include more granular detail useful only during active troubleshooting, but should still be redacted with exactly the same discipline as INFO, since a DEBUG log accidentally left enabled in production is a very common real-world path by which sensitive data actually ends up in logs.

Differences for a batch job versus a real-time service. A nightly batch scoring job's logging strategy centers on a per-run summary (start time, record count processed, error count, completion status) tagged with a job_id and run_id, since a human reviewing a batch job's logs the next morning wants an overview, not necessarily a line per record. A real-time service's logging centers on a per-REQUEST correlation ID and typically much higher log volume, and needs sampling strategies for very high-traffic endpoints (logging a representative fraction of successful requests at INFO, while still logging every failure) to keep log volume and cost manageable without losing visibility into failures specifically.

Worked example

public class PiiSafeLogger {
    private static final Pattern EMAIL = Pattern.compile("[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}");
    private static final Pattern SSN = Pattern.compile("\\b\\d{3}-\\d{2}-\\d{4}\\b");
    private static final Pattern CREDIT_CARD = Pattern.compile("\\b(?:\\d[ -]*?){13,16}\\b");
    private final List<Pattern> patterns = new ArrayList<>(List.of(EMAIL, SSN, CREDIT_CARD));

    public PiiSafeLogger(List<Pattern> extraPatterns) { patterns.addAll(extraPatterns); }

    public String redact(String message) {
        if (message == null) return null;
        String result = message;
        for (Pattern p : patterns) result = p.matcher(result).replaceAll("[REDACTED]");
        return result;
    }
}

Verification note: a Java Development Kit was not available in this execution sandbox, so the exact class above was not compiled directly; the identical regular-expression patterns and replacement logic were instead executed against an equivalent Python translation (Python's re module uses the same pattern syntax for these specific expressions) and confirmed: an email address embedded in a sentence is fully redacted; a dashed Social Security number is fully redacted; a spaced 16-digit credit-card-like number is fully redacted; a message containing no PII passes through completely unchanged; and a null input returns null rather than throwing. This confirms the REGEX LOGIC is correct; it does not confirm Java-specific behavior (for example, java.util.regex.Pattern's exact semantics versus Python's re), which is a disclosed limitation of this verification, not a claim of full Java execution.

Trade-offs and pitfalls

Regex-based redaction is a strong first line of defense but is not exhaustive: a credit card number with unusual formatting, a non-US identification number format, or a PII field that doesn't match any recognizable pattern at all (a person's name in a free-text field, which has no distinguishing shape a regex can reliably catch) can pass through unredacted; this is exactly why validating "at scale" against a realistic log sample, not just a handful of unit tests, matters, and why some organizations pair regex-based redaction with an explicit ALLOWLIST discipline (only log fields you've deliberately reviewed) for the highest-sensitivity data flows, rather than relying on a denylist-style redaction pattern to catch everything. The most common real-world failure mode is a DEBUG-level log statement, written during development and forgotten, that logs an entire request or record object directly (bypassing the redaction helper entirely, since it wasn't routed through it) rather than going through this centralized logging path, which is why enforcing that ALL logging goes through a single, redacting logger (not calling a raw print or an unwrapped logging framework call directly) is as important as the redaction logic itself.