Netflix Mobile Developer (Mid-Level) Interview Preparation Guide

Brief overview
Use short-lived access tokens (JWT, ~5–15 min) + long-lived refresh tokens (days–weeks) stored securely on device. Access tokens authenticate API calls; refresh tokens obtain new access tokens when expired.

Where to store tokens

• iOS: Keychain (use accessibleWhenUnlockedThisDeviceOnly for sensitive items).
• Android: Android Keystore + EncryptedSharedPreferences or Jetpack Security.
• Cross-platform: react-native-keychain / flutter_secure_storage backed by platform keystores.
  Never store tokens in plain SharedPreferences, NSUserDefaults, or files.

Refresh flow

1. App detects 401 or access token expiry.
2. Send refresh token to /oauth/token (over TLS) with client ID and grant_type=refresh_token.
3. Server validates and returns new access token ± rotated refresh token.
4. Persist rotated refresh token securely and retry original request.

Use refresh-token rotation (issue a new refresh token each time and mark old one invalid) to limit replay.

Handling failed refresh

• On invalid/expired refresh: clear local tokens, require interactive re-login.
• Implement exponential backoff for transient network errors.
• Detect repeated failed refresh => prompt user and escalate (2FA).

Revocation & logout strategies

• Server-side revocation list or store token metadata (token id, user id, device id, token version).
• Support per-device revocation: associate refresh token with device_id; logout remote device deletes that token.
• Immediate logout: server invalidates token id; client clears secure storage.
• Lost/stolen device: allow user to view active devices and revoke specific device tokens; optionally rotate user password or increase token version to invalidate all.
• Use short access lifetimes + refresh rotation + device lists to minimize exposure.

Extra mobile considerations

• Always use TLS, pin certificates where appropriate.
• Minimize token exposure in logs and crash reports.
• Consider biometric-protected key for especially sensitive apps.

I turn a strategic roadmap into a team plan by translating outcomes into sequenced, capacity-aware work.

My approach:

1. Break the roadmap into epics (large chunks of related work broken down into smaller, shippable stories) or milestones tied to measurable outcomes.
2. Identify dependencies across teams and place them on the critical path (the chain of dependent tasks whose combined duration sets the earliest possible finish date, so a slip anywhere in that chain delays the whole plan).
3. Estimate using actual team capacity, not idealized capacity, and reserve buffer for unplanned work.
4. Sequence work so early items unlock later ones and reduce risk quickly.
5. Recheck whether the plan fits the team’s sustainable pace.

I avoid overcommitting by making trade-offs visible. If the roadmap has more work than the team can support, I push for explicit choices: what is in, what is out, and what can move later. I also keep room for learning, because the plan should be realistic enough to execute, not so packed that one surprise breaks everything.

The strongest plans are not the most ambitious ones; they are the ones the team can actually deliver with confidence.

Worked example
Say the roadmap's quarterly goal is "launch self-serve onboarding." I'd break that into three epics: build the account-setup flow, build the guided first-project wizard, and build the in-app upgrade prompt. Against a team of five engineers with a realistic capacity of about 30 person-days a week after accounting for on-call and code review, the account-setup flow (estimated 25 person-days) and the wizard (estimated 20 person-days) sit on the critical path because the upgrade prompt depends on both finishing first, so those two get sequenced first and the upgrade prompt follows in the back half of the quarter, with a one-week buffer reserved before quarter-end for whatever surprise inevitably shows up.

Situation & quick diagnosis

• ANR symptoms: “App not responding” while foreground Service does work. Likely synchronous disk/network IO or heavy CPU on the main thread.
• First step: reproduce with same inputs and device/OS where ANR occurred.

Logs & traces to collect

• /data/anr/traces.txt (or bugreport) — full thread dump showing main thread stack and blocking call.
• logcat around timestamp (filter for “ANR in”, “BroadcastQueue”, “ActivityManager”).
• Perfetto/Android Studio System Trace to see CPU, thread scheduling, and long main-thread spans.
• systrace and timer events to correlate UI jank and IO.
• Dump of open files or socket activity if network stuck.

How to read traces

• Look for main thread stack frames: blocking disk IO (FileInputStream.read, RandomAccessFile), network (HttpURLConnection.connect/execute), ContentResolver.query, or synchronized waits.
• Check Binder threads for long IPC.

Code-level fixes (concrete APIs & patterns)

• Never perform IO on main thread. Use Kotlin coroutines with Dispatchers.IO or a dedicated Executor:

val serviceScope = CoroutineScope(SupervisorJob() + Dispatchers.Main)

fun doWork() {
  serviceScope.launch {
    val result = withContext(Dispatchers.IO) {
      // disk or network call
      myRepository.fetchAndSave()
    }
    // back on Main if needed
  }
}

• Use lifecycle-aware scopes (lifecycleScope in components) or create a Service-scoped CoroutineScope and cancel in onDestroy().
• For periodic/deferrable background work, use WorkManager (setForegroundAsync for foreground-required work) to leverage system scheduling and retries.
• Use HttpClient with timeouts (OkHttp: call.timeout, connectTimeout) and non-blocking libraries.
• For database use Room with suspend DAOs or RxJava; do queries on Dispatchers.IO.
• Avoid synchronized/blocking locks on paths accessed by main thread.
• If you must do bounded CPU tasks, use Dispatchers.Default and limit concurrency via CoroutineDispatcher backed by a fixed thread pool.

Architectural fixes

• Move heavy processing to a worker layer (Repository) that exposes suspend functions or Flows.
• Use WorkManager for long-running/resilient tasks; use ForegroundInfo for required foreground notification.
• Split responsibilities: Service only coordinates and displays notification; delegate IO to worker threads.
• Add observability: StrictMode.setThreadPolicy to detect accidental disk/network on main thread during dev.

Prevention & best practices

• Add unit/integration tests and instrumentation tests that simulate large payloads.
• Enforce timeouts, cancellation support, and backpressure.
• Monitor in prod via ANR reporting and trace collection; iterate on problematic call sites.

Result: move all blocking IO off main thread, apply lifecycle-aware coroutines/WorkManager, add timeouts and observability; collect traces (traces.txt, perfetto, logcat) to pinpoint and verify fixes.

A cross-platform codebase with native modules has three genuinely distinct code populations, and the right test allocation follows directly from which population each piece of logic lives in.

Shared code: unit tests

Any logic that lives in the shared cross-platform layer (business rules, state management, data transformation, API-client logic) should be unit-tested ONCE, in the shared layer itself, using the cross-platform framework's own testing tools (for example Dart tests for Flutter, or Jest for React Native). This is the highest-leverage layer to invest in, since a bug found and fixed here is fixed for every platform simultaneously, and a test written here verifies every platform at once rather than needing platform-specific duplicates.

Native-specific features: per-platform tests

Any feature that genuinely requires native code, camera access, platform-specific biometrics, deep OS integration, cannot be verified by the shared layer's tests at all, since the actual behavior under test lives entirely in platform-specific code the cross-platform framework doesn't execute. These need dedicated per-platform tests: XCTest for the iOS-native module, an equivalent JVM/Android test for the Android-native module, each verifying that platform's actual implementation of the native feature.

Combining native UI tests with cross-platform end-to-end tests

For the small number of end-to-end journeys that matter most, use the cross-platform framework's own end-to-end tooling, and note these tools don't cross over between frameworks: Detox for React Native, or Flutter's official integration_test package for Flutter (Patrol is a common third-party alternative when a test needs to interact with native permission dialogs or other platform UI outside the Flutter widget tree). Either way, drive the FULL app, including native modules, on both platforms of whichever framework you're on, rather than writing separate native-only end-to-end suites for iOS and Android; this avoids the duplicated effort of maintaining two parallel end-to-end suites for logic that's actually shared. Reserve native-only UI tests for verifying a native module's OWN platform-specific interaction details in isolation (does a native camera permission prompt display correctly on this specific OS version), which the cross-platform end-to-end tooling either can't reliably exercise or can't do so with enough platform-specific precision.

Minimizing duplication while maximizing coverage

The discipline that makes this work is asking, for every piece of logic, "does this code path exist identically on both platforms, or does it diverge?" Shared logic gets exactly one test, in the shared layer; genuinely divergent native logic gets exactly one test per platform where it diverges, never both a shared-layer test AND a redundant per-platform test for the same logic. The most common source of wasted effort is testing the SAME shared business logic redundantly inside each platform's native test suite "just to be sure," which adds maintenance cost without adding real coverage, since the shared-layer test already proves that logic correct on every platform that consumes it.

Trade-offs and pitfalls

The trap specific to cross-platform codebases is assuming the shared layer's tests provide FULL coverage of a feature just because most of its logic lives there, when a feature that touches even one native-specific interaction point (a permission prompt, a platform gesture) needs a dedicated native-level test for that specific interaction, layered on top of, not instead of, the shared-layer coverage for the rest of the feature's logic.

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.

Direct answer

Keep a stalled dependency peer-to-peer as long as direct conversation is still making progress. Escalate when you hit a concrete trigger: a scope change that neither side can unilaterally absorb, genuinely conflicting priorities that only someone with visibility into both roadmaps can arbitrate, or a hard deadline-driven blocker where peer-to-peer conversation has already stalled.

Framework

Default: work it peer-to-peer. Most stalls are under-communication or unclear ownership, and a direct conversation or a short written proposal usually unsticks them without anyone else getting involved.

Concrete triggers to escalate.

• Scope change: the fix now requires work neither team budgeted for, and only a manager can reprioritize that.
• Conflicting priorities: both sides are acting rationally from their own team's goals, and the trade-off needs someone with visibility into both roadmaps to arbitrate.
• Hard blocker with a deadline: a fixed external date is genuinely at risk, and peer-to-peer conversation has already stalled past a reasonable window, for example no movement after two direct attempts over several days.
• Repeated pattern: the same kind of stall keeps recurring with the same team, which means the real issue is the working relationship or process, not this one dependency.

What to bring when you escalate. A short brief: what's blocked, what you've already tried peer-to-peer, the realistic options and their trade-offs, and the specific decision you need.

Worked example (applying the criteria)

Situation: your team's deliverable needs a schema change from another team that they've deprioritized for two weeks despite two direct requests.
Applying the criteria: this isn't just a communication gap, direct conversation was already tried twice with no movement. It's a conflicting-priorities case, the other team's roadmap has no room for this without reprioritizing something else, combined with a hard blocker, a fixed external deadline in three weeks that this schema change sits on the critical path for (meaning if this dependency slips, the final deadline slips by the same amount, unlike a dependency with buffer to absorb delay).
Action: escalated to the shared manager with a one-page brief covering what's blocked, the two peer-to-peer attempts and their outcome, and two options: the other team reprioritizes one sprint of work, or your team ships a temporary workaround with known limitations, along with the deadline risk if neither happens within the week.
Result: the shared manager reprioritized one sprint item, unblocking the schema change with two weeks to spare before the deadline. Both teams also agreed to flag scope-affecting asks earlier next time, so the same dependency doesn't reach this point again.

Trade-offs and pitfalls

• Escalating too early over normal friction burns trust and reads as an inability to work horizontally.
• Escalating too late, repeatedly trying peer-to-peer past the point it's actually working, puts the deadline at real risk and looks like poor judgment in hindsight.
• A vague escalation with no options and no specific ask wastes the leader's time compared with a brief that names the decision needed.

Clarify requirements & constraints

• Continuous tracking across background, reboots, process deaths
• Minimize battery; support iOS and Android specifics
• Persist last-known points and resume sessions reliably
• Respect user privacy and OS permission models

High-level architecture

• Mobile client (platform-specific modules) + backend for uploads + local persistence (SQLite/Room/CoreData + encrypted blob)
• Location manager component abstracts platform APIs; Session manager handles start/stop, state, and batching

Persistence & resume

• On each location update write compact record to local DB and append to a persistent session state (session id, startedAt, desiredAccuracy, samplingStrategy, lastPointTimestamp).
• On app start, boot receiver (Android: BOOT_COMPLETED + ForegroundService restart intent; iOS: use background fetch/Significant-Location-Change + background processing) inspects session state and restarts tracking if flagged.

Handling process death & backgrounding

• Android: use a sticky Foreground Service only while active tracking is requested; request START_STICKY on O/S where permitted. Use WorkManager (or JobScheduler) for deferred uploads and periodic heartbeat when app not foreground.
• iOS: register for background location updates with allowsBackgroundLocationUpdates and use Significant Location Change to wake app after termination; persist state to resume.

Permissions & UX

• Android: request ACCESS_FINE_LOCATION +/- ACCESS_BACKGROUND_LOCATION with two-step flow (foreground first then background), explain need; request POST_NOTIFICATIONS if showing persistent notification.
• iOS: request WhenInUse then escalate to Always with clear rationale; include in-app settings and privacy screen.

Battery optimization & switching strategy

• Default to power-efficient modes: Significant-Change API / passive listeners or geofencing for low-frequency tracking.
• Adaptive sampling: increase sampling when speed > threshold or user enters geo-fence; reduce to coarse intervals when stationary.
• Foreground Service: enable when high-frequency/real-time tracking required (navigation, live sharing). Show persistent notification (Android) or visible UI (iOS) per policy.
• Offline batch uploads: when network optimal (Wi‑Fi or unmetered) or battery above threshold and device charging; otherwise queue with WorkManager/BackgroundTasks and exponential backoff.

Edge cases & security

• Handle permission revocation by pausing session and notifying user.
• Encrypt local storage; sign uploads; include retry and deduplication logic.
• Test across OEM battery optimizations and iOS background kill scenarios; document expected limitations.

This design balances reliability (persistence + boot/restart handlers) with battery efficiency (adaptive sampling, OS low-power APIs, batching) and complies with platform permission flows.

Approach overview
I’d secure on-device data and transports with layered controls: strong encryption at rest, authenticated transport (TLS + pinning), robust token lifecycle, safe key backup/restore, and clear trade-offs for multi-device syncing.

Encryption at rest

• Use platform keystores to hold keys (Android Keystore, iOS Secure Enclave) and never hard-code keys.
• For DBs, use SQLCipher with a key derived from a keystore-wrapped key. Example flow: generate AES key in Keystore → export wrapped key → SQLCipher uses unwrapped key only in-memory.
• For files, encrypt with AES-GCM; store IV/metadata alongside ciphertext.

TLS & certificate pinning

• Enforce TLS 1.2+/strong cipher suites and HSTS on server.
• Use certificate pinning (public-key or SPKI pins) for high-risk apps to mitigate CA compromise. Implement graceful pin rotation (backup pins, remote-configred pins) to avoid lockout.
• Prefer dynamic pin updates signed by your key for recoverability.

Token refresh patterns

• Use short-lived access tokens + refresh tokens. Store refresh tokens in secure storage (Keystore/Secure Enclave).
• Implement refresh with rotating refresh tokens (issue new refresh token on use, revoke old).
• Detect replay/compromise by checking device fingerprint / token binding when possible.

Key backup & restore

• Backups should be encrypted with keys user controls (password-derived or platform-managed encrypted backups like iOS Keychain Sync with iCloud Keychain, Android Backup with encrypted vault).
• For passwordless, use end-to-end encrypted backup: encrypt with a user passphrase-derived key (PBKDF2/Argon2) and store ciphertext server-side.

Multi-device trade-offs

• Convenience vs security: sync keys across devices improves UX but increases attack surface.
• Options: per-device keys with server-side wrapped sync tokens (safer, more complex UX), or user-managed passphrase for E2E backup (secure but requires user involvement).
• Consider session management: allow device revocation, audit logs, and push notifications on new device adds.

Final practices

• Minimize decrypted lifetime in memory, apply secure wipe, use code obfuscation, and test against threat models (MitM, device compromise).

Approach (brief)
Use Swift's static let for the shared instance (lazy, initialized once, thread-safe) with a private initializer. For testability, depend on a protocol and allow injecting an instance.

Code

import Foundation

protocol NetworkManaging {
    func request(_ url: URL, completion: @escaping (Data?, URLResponse?, Error?) -> Void)
}

final class NetworkManager: NetworkManaging {
    // Thread-safe singleton instance
    static let shared = NetworkManager()

    // Private to prevent external initialization
    private init() {}

    // Example method
    func request(_ url: URL, completion: @escaping (Data?, URLResponse?, Error?) -> Void) {
        URLSession.shared.dataTask(with: url) { data, resp, err in
            completion(data, resp, err)
        }.resume()
    }
}

Why this is thread-safe and preferred

• static let is initialized lazily and atomically by Swift runtime — safe across threads without locks.
• Simplicity and zero runtime overhead compared to manual locking.
• Fits iOS patterns: shared resources (network clients, caches) are easily accessible and consistent app-wide.

Making it testable

• Code against NetworkManaging and inject either NetworkManager.shared or a mock in tests.
• For more control, provide an initializer (internal) or a factory to create non-singleton instances for tests; use dependency injection in view models/controllers.

Direct answer: Pair the technical telemetry (page load time itself, and related signals like Time to Interactive) with user-experience and business metrics that plausibly sit downstream of faster loading, such as bounce rate, session continuation rate, and conversion or engagement for the affected pages, so the story connects "we made it faster" to "and here is what that was worth."

Structured elaboration

• Technical telemetry: confirm the underlying change actually worked as intended first (page load time itself, broken down by percentile since a mean can hide a long tail of still-slow loads, and Time to Interactive if the perceived responsiveness matters more than raw load completion).
• User-experience metrics: bounce rate on the affected pages (a faster page should reduce abandonment before content is even seen) and session continuation rate (whether users who land on a faster page go on to view additional pages), since these sit closer to the user's actual experience than the raw millisecond figure.
• Business metrics: conversion rate or engagement metric relevant to the affected pages, connecting the technical improvement to something the business ultimately cares about, since "page load time went down" alone does not answer whether the change mattered.
• Connecting a technical improvement to a business metric: state the expected causal chain explicitly (faster load reduces abandonment, which increases the population that reaches a conversion-relevant page, which should raise conversion volume even if conversion RATE among those who stay is unaffected) so the business-metric result can be interpreted correctly rather than treated as a black box.

Worked example: After optimizing image assets, p95 page load time drops from 3.8s to 2.1s. Bounce rate on the optimized pages drops from 42% to 37%, and session continuation (viewing a second page) rises correspondingly. Conversion rate among users who reach the page is roughly unchanged, but conversion VOLUME rises because more users now stay long enough to reach the conversion-relevant page at all, consistent with the expected causal chain (faster load reduces abandonment, more users convert as a result of surviving to see the offer, not because the offer itself became more persuasive). Reporting the result as "conversion rate is unchanged" alone would understate the change's value; reporting it as "conversion volume rose because fewer users bounced before ever reaching the offer" tells the accurate story.

Trade-offs and pitfalls: The most common mistake is reporting only the technical metric (page load time) and treating the business case as self-evident, which fails to persuade stakeholders who want to know what the speed improvement was actually worth. The other common mistake is reporting only a business metric like conversion rate without connecting it to the specific expected mechanism (reduced abandonment, not increased persuasiveness), which can make a real and correctly-attributed win look smaller than it is if the wrong intermediate metric (conversion rate instead of conversion volume) is used to judge it.