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 & 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.

Clarify goal & approach
I’d use a client-server feature-flag system: a server-side control plane (flags, audiences, rules, metrics) and lightweight mobile SDKs (iOS/Android) that evaluate flags locally with periodic sync + streaming for near-real-time changes.

Architecture & components

• Server: flag definitions, targeting rules, rollout percentages, cohorts, geo map, metrics ingestion & gating engine.
• Mobile SDK: fetch flag config, local evaluator, persistent cache, deterministic bucketing, exposure/event tracking (impression, goal events), offline-safe defaults.
• Metrics pipeline: events -> aggregation -> dashboards -> automated gating rules.

Deterministic bucketing

• Compute bucket = hash( user_id || flag_key ) % 10000 -> maps to 0..9999 ensuring stable assignment across devices.
• If no user_id, fall back to device_id; allow stickiness window for anon users.

Percentage rollouts

• Represent percent as ranges of bucket space (e.g., 0–1999 = 20%). SDK evaluates whether bucket in range.

Cohort & geo targeting

• Server-side audience definitions (attributes: user properties, app version, country, OS). SDK sends attributes on evaluation or enrollment.
• For geo, use device locale + IP-derived country as fallback; server compiles rules into evaluation config.

Metric gating & automation

• Track experiment metrics (DAU, crash rate, conversion) with tagging of exposures and goals.
• Gating engine evaluates pre-defined SLO thresholds and statistical tests (e.g., sequential bayesian or frequentist with stopping rules).
• Automated progression: if effect positive and no adverse signals, increase rollout percentage; automated rollback if crash or negative impact exceeds threshold.

Coordinating flag-driven changes with binary updates

• Use semantic controls:
  • Soft feature: server-only gate; safe to toggle without binary change.
  • Hard feature (requires UI/logic in binary): guard flag plus min_app_version attribute. SDK evaluates and ignores flag unless app version >= required. Server prevents enabling rollout to older binaries.
• Release flow: ship binary with feature behind flag + min_app_version; stagger rollout using flag; once stable, flip default and optionally remove flag in later release.

Mobile-specific considerations

• Minimize SDK size, use async fetch, batch events, respect privacy (PII hashing), handle offline, rate-limit updates, and ensure fast cold-start default behavior.

This approach gives deterministic, auditable experiments, safe staged rollouts, and automated metric-based gating while coordinating app binary dependencies.

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.