Netflix Senior Mobile Developer Interview Preparation Guide

Overview (MVVM responsibilities)

• View: UI rendering, user interactions, simple input validation (formatting), binds to ViewModel. No business logic.
• ViewModel: Exposes observable state, input validation rules, transforms Model data for UI, coordinates calls to domain/model layer, handles UI state (loading, errors).
• Model / Domain: Networking, repositories, business rules, data mapping, persistence.

Where things belong

• Validation: complex business validation → ViewModel/domain; UI-only formatting → View.
• Networking & mapping: Model/Repository layer.
• UI rendering: View.

Data flow & bindings

• View observes ViewModel (LiveData / StateFlow on Android; Combine / @Published on iOS). User action -> View calls ViewModel method -> ViewModel updates state, calls repository -> repository returns Model -> ViewModel maps to UI state -> View updates automatically.

Concrete Kotlin example (login)

// ViewModel (Kotlin, Android + coroutines + StateFlow)
class LoginViewModel(private val repo: AuthRepository): ViewModel() {
  private val _ui = MutableStateFlow(LoginUiState())
  val ui: StateFlow<LoginUiState> = _ui

  fun onEmailChange(e: String) { _ui.value = _ui.value.copy(email = e, emailError = validateEmail(e)) }
  fun onLogin() = viewModelScope.launch {
    if (_ui.value.emailError != null) return@launch
    _ui.value = _ui.value.copy(loading = true)
    val res = repo.login(_ui.value.email, _ui.value.password)
    _ui.value = _ui.value.copy(loading = false, error = res.error, success = res.isSuccess)
  }
}

• View (Activity/Fragment) collects StateFlow and renders UI.
• Repository does network + mapping; domain applies business rules.

Bindings/Observers

• Android: StateFlow/LiveData observed in lifecycle-aware scope.
• iOS: Combine / @Published with sink/assign on main queue.
• This keeps UI reactive, testable, and separates concerns.

Overview / Key states

• Launched: app process created, initialization runs.
• Foreground (active): user interacting; UI active.
• Background: not visible but running limited tasks (e.g., fetch, location).
• Suspended (iOS) / Cached (Android): process kept in memory, no CPU; system may kill.
• Terminated: process destroyed by user or OS.

Common callbacks / events

• Android: onCreate → onStart → onResume (active); onPause → onStop → onDestroy (teardown). onSaveInstanceState called before potential kill.
• iOS (AppDelegate/SceneDelegate): applicationDidFinishLaunching / sceneWillEnterForeground → sceneDidBecomeActive; applicationWillResignActive → applicationDidEnterBackground → applicationWillTerminate. applicationDidEnterBackground gives short execution window.

System constraints

• Background execution time limited (iOS ~ few seconds unless background modes; Android ~ background execution limits / foreground services required for long-running tasks).
• Memory reclamation: OS may kill background/suspended apps when low memory.
• Battery and network policies: Doze (Android), App Nap (iOS) reduce CPU/network in background.

How this affects resource & UX decisions

• Save critical state in onPause / applicationWillResignActive and persist in onSaveInstanceState / applicationDidEnterBackground so users resume seamlessly.
• Release heavy resources (camera, GPS, large caches) on background to reduce memory pressure and battery.
• Use background modes sparingly; offload long tasks to backend or use WorkManager / BGTasks with proper constraints.
• Use foreground services with clear notification for user-facing long tasks.
• Test kill-and-restore flows to ensure consistent UX.

Example: stop camera and checkpoint draft in onPause, restart camera in onResume; schedule uploads with WorkManager/BGTask to respect OS limits.

A good spike has five parts, and the order matters: frame the uncertainty as a falsifiable question, scope and timebox it, set deliverables and a success threshold before you start, run it, then interpret the result including the case where it's inconclusive. Skipping the "before you start" steps is what turns a spike into an unfalsifiable exercise where any result gets rationalized afterward as "directionally promising."

1. Frame the uncertainty as a falsifiable question. Not "let's explore whether we can support real-time sync with this partner," but "we believe webhook round-trip latency to this partner's sandbox API will be under 2 seconds for most events; if true we build on webhooks, if false we fall back to polling."

2. Scope and timebox. Pick the smallest test that would actually move your confidence on that specific question, and box it in days, not weeks, for example a 3-day spike. If you can't state the timebox in days, the scope is still too broad.

3. Deliverables and success criteria, locked before you run anything. Deliverable: a working prototype demonstrating the round trip against the partner's sandbox for at least 50 test events. Success criterion: round-trip latency under 2 seconds for at least 90% of those events. Writing the threshold down before you see any data is what makes the result mean something; otherwise any outcome gets reinterpreted as good enough after the fact.

4. Run it, then interpret three possible outcomes, not two. A spike doesn't just pass or fail, it can also come back inconclusive, and you need a predefined response for that case too, not an improvised one. Take a debugging example rather than a build example: an on-call engineer spikes a 3-day investigation into a flaky checkout failure, hypothesizing database connection-pool exhaustion. The spike adds pool-utilization metrics and retry logging. The result: pool utilization is near saturation during 2 of the 5 observed failures, but not the other 3, an inconclusive signal, neither confirmation nor rejection. The predefined response for exactly this case: don't declare the root cause found, apply a cheap mitigation anyway (widen the connection pool, since it's low-cost and directionally justified even under uncertainty), extend the observation window by a week with the logging left in place, and open a tracked follow-up so the open question doesn't silently disappear once the immediate pressure is off.

5. Communicate the result either way, and frame it as roll-forward or rollback. Even a null or inconclusive result is a shipped learning. Write two paragraphs, what was tried and what was learned, and share it with adjacent teams so nobody re-runs the same spike next quarter. State explicitly whether the mitigation is staying (roll-forward, with the criteria that would make you revert it) or whether you're reverting it (rollback, and why).

For a bigger ambiguous decision, chain spikes with a decision gate between each rather than running one big test. For example, validating whether a new ranking approach will actually help: stage 1, hand-sample and manually review 20 examples (cheap, a day); gate, if the signal looks real, proceed to stage 2, an offline evaluation against a held-out set, possibly using synthetic data to cover edge cases the real data doesn't have enough of; gate, if the offline eval is still positive, proceed to stage 3, a small live A/B test on a slice of real traffic. Each gate is a checkpoint where you can stop cheaply instead of committing the full test upfront.

The trap: running the spike without a threshold defined in advance. Without that, whatever the spike produces gets described as "promising" or "a good sign" regardless of the actual numbers, because nobody agreed beforehand on what would have counted as a failure.

Direct answer

Pick the problem based on real impact rather than visibility, build a small credible first result to earn the standing to push further, and keep going despite resistance or a lack of formal authority by making the cost of the status quo concrete to the people who could actually unblock you.

Structured elaboration

1. Recognize scope beyond a quick fix: this is bigger than something you can just quietly do alone, so the approach itself has to build support along the way, not only execute in isolation.
2. Start with something small and contained you can do inside your own access, rather than asking for a broad mandate up front, to demonstrate the problem is real and the direction is right.
3. Use that early proof to make the cost of doing nothing concrete to whoever's buy-in or code you actually need, rather than arguing the point in the abstract.
4. Where you hit resistance or lack formal authority, address the actual objection, whose time it costs, whose code it touches, rather than repeating the same pitch louder.
5. Track and report the measurable impact once resolved, so the initiative reads as a delivered result, not just a completed effort.

Worked example

A nightly model-retraining pipeline had been intermittently failing for weeks, and the team's workaround was to manually re-trigger it each morning, so it never showed up as a real incident. Nobody owned it because the pipeline crossed a job built by data engineering and a model owned by the machine learning team, and each side assumed the other was tracking it. Tracing one failure to a schema change upstream that the retraining job was not handling, a contained fix was built in a day, adding validation and a clear error message for just that one failure mode. Showing the data-engineering lead the actual failure logs alongside the manual-retrigger pattern in the on-call history, a cost that had been invisible because nobody had tallied it, earned the buy-in to extend the validation to the other failure modes over the following week, something the team had been reluctant to prioritize when it was framed as a routine review request rather than shown as an ongoing cost. The manual re-triggering stopped being needed within two weeks of the fix landing.

Trade-offs and pitfalls

A common wrong turn is trying to fix an entire cross-team problem in one large change before anyone trusts you with it, which tends to stall on review and ownership questions. Another is treating initial resistance as a final no rather than a signal the cost is not yet visible; a credible small result often changes the conversation more than repeating the ask. Also watch for claiming full ownership of a fix that genuinely needed another team's sign-off, which undermines the trust you are trying to build.

Direct answer

Default to a diagnostic question or a hint first, since that's the cheapest intervention and preserves ownership of the solution. Escalate to pairing when hints aren't moving them or they're clearly missing a building block they can't discover alone in reasonable time. Reserve stepping in directly for cases bounded by a hard constraint: a real deadline, cost, safety issue, or someone else being blocked by their block.

Decision framework

Start with a diagnostic question, not a hint. "What have you tried, and what's your current hypothesis?" tells you whether they're missing information, missing a concept, or just haven't structured their attempts yet. This costs almost nothing and often unblocks people on its own.

Escalate to pairing when the pattern repeats. If they're cycling through the same failed approach without adjusting, or they're missing a conceptual piece they genuinely can't discover unaided in the time available, sit with them. Let them keep driving; you're there to redirect attention, not take over.

Escalate to stepping in directly only under a real constraint. A hard deadline, a cost or safety issue, someone else waiting on this to move, or clear signs of demoralization (not just frustration) are the legitimate triggers. "I could solve this faster myself" is not one of them; that's true of almost every delegation ever made.

Time-box the struggle explicitly. Instead of leaving it open-ended, agree on a checkpoint: "take another thirty minutes with this angle, then let's regroup regardless of where you land." This protects both their learning and the actual delivery timeline.

Debrief after any intervention, at any level. Even a small hint deserves a quick "here's the reasoning trap you were in" afterward, so the moment converts into a transferable lesson instead of just an unblock.

Worked example

Someone you're mentoring has been stuck for a while and comes to you for help. You ask what they've tried and what they currently believe is going wrong. Their answer reveals a specific reasoning gap, not a knowledge gap, so you give a pointed hint rather than the answer itself. They make progress but hit a second wall later, closer to a real deadline, and this time you sit down and pair with them directly, letting them stay at the keyboard while you ask redirecting questions. Once it's resolved, you debrief separately from the fix itself: what was the actual reasoning trap, and what's the general takeaway for the next similar problem, distinct from the specific bug.

Trade-offs and pitfalls

Defaulting to stepping in because it's faster erodes the person's own problem-solving muscle over time and can create a pattern where they escalate immediately instead of trying, because they've learned help arrives fast if they ask.

Refusing to intervene out of a rigid "let them struggle" stance burns real time and morale, and can backfire if they land on a fragile or outright wrong solution through persistence rather than understanding, and you didn't catch it.

The honest trade-off with hints: they preserve the person's ownership of the solution, but they slow things down and risk letting someone loop past the point where struggle is still productive into the point where it's just frustration with no learning attached.

A subtler failure mode worth naming: a "hint" that's actually the answer in disguise. It looks like coaching and feels generous, but the person doesn't actually earn the insight, and you won't be able to tell the difference from watching them succeed.

Kotlin null-safety overview

• Kotlin types are non-null by default: val s: String = "hi". To allow null: val s: String? = null.
• Compiler forces you to handle nullable types to avoid NPEs.

Common operators & patterns

• Safe-call ?. — call only if not null, returns null otherwise:

val len = user?.name?.length

• Elvis ?: — provide a default when left side is null:

val display = user?.name ?: "Anonymous"

• Non-null assertion !! — force unwrap, throws NPE if null (avoid except for quick checks):

val must = user!!.id

• Smart casts — if (s != null) { /* s treated as non-null */ }

lateinit vs lazy

• lateinit var (mutable, non-null) — for vars initialized later (e.g., view references, injected deps). Useful in Android components where lifecycle supplies value:

lateinit var binding: ActivityMainBinding
override fun onCreate(...) {
  super.onCreate(...)
  binding = ActivityMainBinding.inflate(layoutInflater)
}

• val lazy { } (immutable, thread-safe by default) — deferred initialization on first access, good for expensive computations or singletons:

private val repo by lazy { RepoImpl() }

When to use which

• Use lateinit for lifecycle-initialized, mutable properties (views, DI fields) where you guarantee init before use.
• Use lazy for read-only, possibly expensive initialization that you want only when needed.

Keep !! rare; prefer safe-call + Elvis or explicit checks to provide robust Android code.

Situation & goals
Design mobile-first observability for network flows to detect latency, failures, retries, payload issues, and correlate client/server for root-cause while protecting user privacy.

What to collect

• Metrics (aggregated): request latency percentiles (p50/p90/p99), success rate, retry/count, bytes sent/received, connection type (4G/5G/Wi‑Fi), battery level and app foreground/background.
• Logs (event-level, minimal): request id, endpoint, HTTP status, error codes, retry count, net type, timestamp, SDK version. Avoid body payloads.
• Traces: distributed trace id, span id for client request, DNS/connect/SSL/app+server span durations.

Sampling & volume control

• Always sample 100% for failures and errors.
• Trace/sample spikes: tail-based sampling keeping all p99 latency traces; for normal successful requests use probabilistic sampling (e.g., 1–5%).
• Rate-limit client logs per device (e.g., 100/day) and aggregate metrics on-device before upload.

PII avoidance

• Never log raw user identifiers, auth tokens, or location coordinates. Hash or bucket sensitive fields (e.g., user id -> HMAC with rotation; location -> city/region only).
• Use allowlists for headers and strip Authorization/Cookie/personal fields before sending.
• Encrypt telemetry in transit and at rest; respect user opt-in and provide telemetry toggles.

Correlation strategy

• Issue a cryptographically random correlation_id on client per request; include it in request header (X-Correlation-ID) and telemetry.
• Client emits trace/span with that id; server logs and traces echo it. Use backend ingestion to join client metrics + server spans on correlation_id and timestamp window.
• Example: client sends X-Correlation-ID: abc123; if server receives none, backend injects and returns it so client can reconcile.

Practical notes

• Use mobile-friendly SDKs (OpenTelemetry mobile + backend APM), batch uploads, retry with exponential backoff, and document retention and privacy policies.

Ownership model — value vs reference types

• Swift value types (struct, enum) have copy semantics: assigning or passing copies the value logically. Reference types (class) share identity and are reference-counted (ARC).
• Many standard value types (Array, Dictionary, String) use a reference-counted mutable buffer under the hood plus copy-on-write (CoW) so copies are cheap until mutation.

How CoW works internally

• A value type holds a pointer to a heap-allocated buffer object that contains storage and metadata (count, capacity, element storage).
• The buffer is reference-counted by ARC. Multiple value instances can point to the same buffer.
• Before an in-place mutation, the runtime checks buffer uniqueness:
  • For Swift-managed buffers it uses isKnownUniquelyReferenced(&buffer) to test ARC count.
  • For bridged ObjC storage there are other checks (bridging/copying).
• If not unique, the mutating operation allocates a new buffer and copies elements (deep copy of storage), then mutates the new buffer. This preserves value semantics.

When mutations trigger copying

• Any mutating operation that would change contents or capacity (append, remove, sort, inout mutation) triggers the uniqueness check.
• read-only operations don’t copy.
• reserveCapacity can preemptively allocate unique storage to avoid repeated copies.

Designing a custom CoW collection

• Use a private final class Storage { var elements: UnsafeMutableBufferPointer<Element>; var count, capacity } and expose a struct wrapper.
• Always run guard isKnownUniquelyReferenced(&storage) in mutating methods and call makeUnique() to clone when needed.
• Provide reserveCapacity to pre-allocate and avoid repeated realloc/copies.
• Keep storage contiguous when possible for performance and bridging with C APIs.
• Avoid unnecessary copies: minimize intermediate mutations, implement in-place algorithms when unique, use move semantics where supported.
• Consider thread-safety: CoW uniqueness checks are not synchronization; concurrent mutations require external synchronization.
• Benchmark with realistic workloads and use Instruments to inspect allocations and refcounts.

Result: correct CoW yields cheap reads and isolated writes; proper Storage design, uniqueness checks, and capacity management avoid surprising copies and keep performance competitive on mobile.

Direct answer

A code-review checklist for defensive, production-quality standards should be short enough that reviewers actually use it every time, and should focus on the handful of items that correlate most directly with real production incidents: error handling, observability, resource leaks, secrets management, idempotency, and input validation, each with a concrete one-line test a reviewer can actually apply while reading a diff.

Structured elaboration

1. Error handling. Does every external call (network, database, file system) have explicit failure handling, and is there no bare, silent catch-and-ignore? This matters because a swallowed exception is one of the most common root causes of "the system silently stopped working and nobody noticed for days".

2. Observability. Does this change add or preserve logging/metrics for its new failure paths, not just its happy path? A new code path with no visibility into whether it's failing in production is effectively unmonitored the moment it ships.

3. Resource leaks. Are file handles, database connections, and locks acquired in this diff guaranteed to be released even when an exception occurs (via try/finally, a context manager, or the language's equivalent)? This matters because a resource leak in an error path specifically (the path least likely to be exercised in normal testing) is a classic source of a slow production degradation that only appears under sustained load or over a long uptime.

4. Secrets management. Does this diff introduce any hardcoded credential, API key, or token, or log anything that could contain one? This is a fast, mechanical check (often automatable via a pre-commit secret scanner) but still worth a human's attention, since scanners miss secrets embedded in less obvious places like a debug log statement.

5. Idempotency. If this diff adds or touches an operation that could be retried (by a client, a queue redelivery, or an internal retry mechanism), is that operation actually safe to run more than once? This matters because a non-idempotent operation that silently becomes retriable somewhere in the call stack is a duplicate-side-effect bug waiting to happen, often not caught until production traffic patterns exercise the retry path that testing never did.

6+. Input validation and the remaining prioritized items. Does every externally-supplied input reaching this code get validated at a clear boundary, rather than trusted implicitly? Beyond these top items, a fuller checklist includes: test coverage for the new failure paths specifically (not just the happy path), whether any deprecated or discouraged pattern was introduced, and whether the change includes a rollback plan for anything touching a schema or a stateful migration.

Why these six, and why prioritized. Each is chosen because it maps directly to a common, real production-incident root cause, and they are ordered so a reviewer under time pressure who only gets through the first three still caught the highest-impact categories.

Worked example

A pull request adds a new endpoint that calls an internal payments service and writes a record to a local database. Applying the checklist: (1) error handling: the diff has a bare except: pass around the payments call, flagged; (2) observability: no log line exists for the payments-call failure path, flagged; (3) resource leaks: the database connection is correctly used inside a context manager, passes; (4) secrets: no hardcoded credentials found, passes; (5) idempotency: the endpoint is a POST that creates a payment record with no idempotency key, and the client-facing API documentation doesn't mention retry safety, flagged as a real production risk given payments-adjacent code specifically; (6) input validation: the request body is validated via a shared schema, passes. Three of six items are flagged, and the two most severe (the swallowed exception and the missing idempotency key on a payments-adjacent endpoint) block the merge, while the missing log line is a required fix but not necessarily a hard blocker if paired with a fast-follow commitment.

Trade-offs and pitfalls

A checklist with thirty items reliably gets skimmed rather than actually applied under normal review-time pressure; keeping it to the highest-impact handful, with a concrete one-line test for each, is what makes it something a reviewer genuinely runs through on every diff rather than something referenced once and then forgotten. The most common failure mode for a checklist like this is treating it as a one-time training exercise rather than something enforced consistently: without periodic reinforcement (referencing it explicitly in review comments, tracking how often flagged items actually get raised) it tends to fade from active use within a few months of being introduced.

Clarify constraints & goals

• Low latency on mobile, per-region data residency, GDPR consent & erasure, CDN caching allowed only when policy permits, pseudonymize PII.

High-level architecture

• Regionally partitioned backend (EU, US, APAC) — each with its own data stores, model training pipelines, and policy enforcement services.
• Global API gateway routes by user region (geo/consent) to regional cluster.
• Hybrid recommendation: lightweight on-device model + regional real-time ranking service for personalization.
• Consent & Data Controller service replicated regionally; deletion queue + CDC to propagate erasures.

Core components & responsibilities

• Mobile SDK (iOS/Android)
  • Collects telemetry only after explicit consent, exposes consent UI, local opt-out, and stores pseudonymous ID in secure enclave/Keychain.
  • Maintains local model + encrypted feature cache; falls back to server if local model cold.
• Ingestion & Pseudonymization
  • Client sends PII hashed + per-region salt (never raw PII); hashing done client-side for immediate pseudonymization.
  • Server-side double-hash with region key before storage; store mapping only in region.
• Regional Storage & Training
  • Data never leaves region; training pipelines run in-region. Use synthetic or aggregated exports for global meta-analytics.
• Real-time Ranking Service
  • Stream feature store + low-latency RPC; supports TTL-based cached candidate lists.
• CDN & Asset Caching
  • Tokenized signed URLs containing region scope + short TTL; CDN configured per region. Only cache non-PII assets or assets that are personalized via tokenizable parameters. CDN edge checks token validity and user consent via signed cookies when allowed.
• Consent Management & Erasure
  • Central consent service delegates to region. Erasure request triggers:
    • In-region deletion of raw and pseudonymous records
    • Invalidate caches / purge CDN tokens
    • Notify downstream systems via durable deletion queue; confirm via audit log.
• Policy Enforcement Points
  • Client SDK (consent capture, initial pseudonymization)
  • API Gateway (route based on geo/consent, reject cross-region writes)
  • Ingestion pipeline (double-hash, region-tagging)
  • Storage layer (enforce residency ACLs)
  • CDN edge (validate region tokens, TTL)
  • Deletion service (orchestration + audit)

Mobile-specific design decisions

• Perform initial hashing client-side using platform crypto (Secure Enclave / Android Keystore) to avoid raw PII leaving device.
• Ship compact TensorFlow Lite / CoreML model for immediate personalization; periodically fetch region-signed model updates.
• Use short-lived auth tokens and ephemeral salts for CDN personalization to allow safe caching where permitted.
• Expose clear user settings in-app for consent and deletion; show status of deletion flow.

Trade-offs

• On-device model increases complexity but reduces latency & cross-region data flow.
• Strict residency increases operational cost (multi-region infra) but simplifies legal compliance.

Key metrics

• 95th percentile recommendation latency, consent coverage %, deletion SLA compliance, CDN cache hit rate per region, audit log completeness.

This design gives mobile apps fast, privacy-preserving personalization while enforcing per-region residency and GDPR obligations through multiple policy enforcement points.