Netflix Backend Developer (Entry Level) Interview Preparation Guide

Brief framing — why avg vs worst-case matter
Average-case guides expected latency under normal traffic; worst-case bounds matter for SLAs, DoS resilience, and tail latency. For a public API you must protect against attacker-controlled inputs that could force worst-case behavior.

Algorithm comparison

• Quicksort

  • Average: O(n log n)
  • Worst: O(n^2) (bad pivots)
  • Memory: O(log n) stack average; in-place
  • Stability: not stable (unless modified)
  • Notes: fast in practice but vulnerable to adversarial payloads unless randomized pivots or introspection used.

• Mergesort

  • Average: O(n log n)
  • Worst: O(n log n)
  • Memory: O(n) extra for merging (can be O(1) in linked-list variants)
  • Stability: stable
  • Notes: predictable worst-case and stable—good for APIs where consistent latency and order-preserving behavior matter.

• Heapsort

  • Average: O(n log n)
  • Worst: O(n log n)
  • Memory: O(1) extra; in-place
  • Stability: not stable
  • Notes: predictable time and low memory but typically slower constant factors than quicksort.

Adversarial inputs & production choice

• For attacker-controlled lists, avoid algorithms with exploitable worst-case (plain quicksort). Use randomized quicksort or introsort (switch to heapsort when recursion deep) to combine quicksort speed and safe worst-case.
• If stability and reproducible ordering are required, use mergesort (or stable external sort) despite higher memory.
• Also enforce size limits, rate-limit, validate input, and set timeouts to protect API from resource exhaustion.

Choose: introsort or randomized quicksort for speed + safety; mergesort when stability or constant worst-case latency is prioritized.

Direct answer. The database load comes from having to scan or index-skip past every row before the offset, so the fix is to stop asking the database to count through rows it is about to throw away: either replace offset with keyset pagination, or add a covering/composite index that makes the skip itself cheap, or materialize a pre-sorted read model so the "deep page" query is a direct lookup instead of a scan.

Mitigation 1: keyset (cursor) pagination. As covered in the pagination-comparison sub-area, this eliminates the "skip N rows" cost entirely by anchoring on the last row seen instead of a row count; the cost of fetching page 10,000 becomes roughly the same as page 1. Cost to you: you lose the ability to jump straight to an arbitrary page number, only "next" and "previous" remain meaningful; client changes: any UI built around numbered page links (1, 2, 3 ... 47) needs to become a "load more" or "next" pattern instead.

Mitigation 2: a covering composite index. If you cannot give up numbered pages (say, an admin tool genuinely needs "jump to page 400"), a composite index on exactly the columns used for filtering, sorting, and the primary key lets the database satisfy the query entirely from the index without touching the underlying table rows at all, which is meaningfully cheaper than a table scan even though the offset cost itself does not disappear. Cost to you: extra storage and slightly slower writes (every index has to be maintained on insert/update); client changes: none, numbered pages keep working exactly as before.

Mitigation 3: a denormalized, pre-sorted read model or materialized view. For a specific hot query shape (say, "the most recent 10,000 items in category X"), maintain a separate table that already holds exactly that sorted slice, refreshed on a schedule or via change-data-capture (a process that watches the database's write log and streams every insert/update out to other systems as it happens, instead of re-querying the source table on a timer), so a deep-page request against it is a cheap direct read rather than a live aggregation over the full dataset. Cost to you: the read model can be slightly stale, and you now have a second copy of the data to keep in sync; client changes: usually none, the client is still calling the same paginated endpoint, the difference is invisible to it.

Choosing between them. Keyset pagination is the right default whenever the client's actual need is "keep scrolling", not "jump to page 400" specifically; the composite index is the right minimal fix when you must keep numbered pages and the dataset is not so large that index-only scans are still too slow; the materialized read model is worth the operational cost only when one specific deep-page query shape is hit often enough, and is expensive enough even with a good index, to justify maintaining a second, purpose-built copy of the data.

Direct answer

A cascading failure is when one component's failure increases load or latency on the components that depend on it, and that increased load causes those components to fail too, propagating outward until a large part of the system is affected, even though only one component actually broke in the first place. The mechanism is almost always resource exhaustion: threads, connections, or memory tied up waiting on the failed component instead of being freed quickly.

Walkthrough: C fails, B overloads, A degrades

flowchart LR
  A[API Gateway] -->|rate limit and timeout| B[Order Service]
  B -->|bulkhead pool: payments| C[Payment Service]
  C -.fails.-> B
  B -->|circuit breaker opens| D[Fallback: queue order for async retry]
  A -->|circuit breaker opens| E[Fallback: 503 with Retry-After]
  B -->|isolated pool: other deps unaffected| F[Inventory Service]

1. C (Payment Service) fails, hanging instead of returning errors quickly, perhaps due to a downstream outage of its own.
2. B (Order Service) calls C without a tight timeout. Each call to C now blocks for far longer than normal, tying up a thread or connection from B's pool for the duration.
3. B's resource pool exhausts. As more requests arrive at B, more threads get stuck waiting on C, until B has no capacity left to serve any request, including ones that don't even touch C.
4. A (API Gateway) calls B, and B is now slow or unresponsive for everything, so A's calls to B start timing out or queueing too, degrading A's own capacity in turn.

Worked example: how fast does B's pool actually exhaust?

Little's Law relates the number of requests in flight to the arrival rate and the time each spends being processed:

Say B receives 500 requests per second, and under normal conditions each call to C takes 50ms:

25 concurrent requests is a light load on a typical connection pool. Now C hangs, and B's HTTP client has no explicit timeout of its own, falling back to a default of 30 seconds:

If B's thread pool has 200 threads, the time to exhaust it entirely is:

Under 400 milliseconds. That's how quickly a single hung dependency with no timeout turns into total unavailability for a service handling 500 requests per second: the pool never gets close to steady-state at the 30-second hang time, it simply fills with stuck requests almost instantly and stays full.

Protections at each layer

• At B, calling C: a tight, explicit timeout (measured in low hundreds of milliseconds, not the client library's 30-second default) so a hung call fails fast and frees the thread quickly; a circuit breaker that opens after a run of failures or timeouts, so B stops even attempting calls to C once it's clearly down, and falls back to queueing the order for later processing; a bulkhead, a dedicated connection pool just for calls to C, so exhaustion from C-related calls doesn't consume the threads B needs to serve requests that don't touch C at all (like inventory checks).
• At A, calling B: the same pattern one layer up, a timeout on calls to B, a circuit breaker that trips once B's error rate or latency crosses a threshold, and a fallback (a fast 503 with Retry-After rather than a hung request) so A's own capacity isn't consumed waiting on a B that's already struggling.

Trade-offs & pitfalls

Timeouts that are too aggressive cause false-positive failures under normal, brief latency variance; timeouts that are too loose don't prevent the cascade fast enough, as the Little's Law example shows. Bulkheads cost real resources (a dedicated pool per dependency uses more total connections or threads than one shared pool) in exchange for isolation, so they're worth applying to the dependencies most likely to fail or most likely to take down unrelated traffic if they do. The most common mistake is only protecting the first hop (B to C) and assuming that's sufficient; as the walkthrough shows, without protection at the A to B hop too, the failure still reaches A once B is degraded, just one layer later.

Direct answer

Put every element into a hash set, then only start "walking" a run from numbers that are the start of a run, meaning their predecessor (x - 1) is not in the set. From each such start, walk forward through x+1, x+2, ... while each is present, and track the longest walk seen. Because a hash set gives $O(1)$ average membership checks and every element is only ever walked once across the whole algorithm, this runs in average $O(n)$ time without sorting.

Structured elaboration

Approach. Sorting first would cost $O(n \log n)$, which is worse than the $O(n)$ bound the problem asks for; the hash set gets you constant-time "is this the start of a run" and "is the next number present" checks that a sorted array cannot beat once you account for the sort itself.

def longest_consecutive(nums):
    """
    Return length of longest consecutive sequence in nums.
    Average O(n) time, O(n) space.
    """
    if not nums:
        return 0
    s = set(nums)
    best = 0
    for x in s:
        if x - 1 not in s:          # only start counting at a run's beginning
            length = 1
            cur = x + 1
            while cur in s:
                length += 1
                cur += 1
            best = max(best, length)
    return best

Why the x - 1 not in s check keeps it linear. Without it, every element would try to walk its own run, redoing the same work as its predecessors: for a run of length L you'd do $1 + 2 + \dots + L = O(L^2)$ work instead of $O(L)$. The start-of-run check means the inner while loop only ever fires from a true run start, and every element is visited by exactly one such walk (the one belonging to its run), so total inner-loop work across the whole array is bounded by n, not by the number of runs times their lengths.

Worked example

nums = [100, 4, 200, 1, 3, 2]
print(longest_consecutive(nums))

Output: 4

Trace: the set is {100, 4, 200, 1, 3, 2}. Only 100 (no 99), 200 (no 199), and 1 (no 0) are run starts. From 1: 2, 3, 4 are all present, giving a run of length 4 (1,2,3,4). From 100 and 200: no successor present, so length 1 each. The longest is 4.

Trade-offs & pitfalls

Key points

• Sorting-based solutions (sort, then scan for consecutive runs) are simpler to reason about and use no extra hash-set memory, but they cost $O(n \log n)$ from the sort itself, which is asymptotically worse than the hash-set approach for large n.
• The hash-set approach only pays off because you resist the temptation to walk a run from every element; the "start of run" gate is what keeps total work linear instead of quadratic in the worst case (e.g., one giant consecutive run).
• Average-case linear time relies on the hash set having O(1) average operations; under adversarial hash collisions (a concern in security-sensitive contexts) a hash set's worst case degrades, whereas sorting's $O(n \log n)$ worst case is guaranteed regardless of input.

Complexity

• Time: average $O(n)$ (building the set is O(n); every element is visited by the inner while loop at most once across the whole run).
• Space: $O(n)$ for the hash set.

Edge cases

• Empty array: returns 0 immediately.
• Duplicates: the set naturally deduplicates, so [1, 2, 2, 3] still returns a run length of 3, not 4.
• All elements identical: every element is its own non-start except one value, giving a run length of 1.
• Negative numbers or gaps: the algorithm works unchanged since it relies only on integer successor relationships, not on sign or magnitude.

Direct answer. An index-only scan happens when every column the query needs (both filtered and returned) is present in the index itself, so the engine never has to visit the underlying table; it also requires the storage engine's per-page visibility bookkeeping to confirm that the rows found in the index are current and visible to the query, without checking the table itself.

Structured elaboration. The "covers every needed column" requirement is straightforward: if the query selects or filters on a column the index doesn't include, at least a partial fallback to the table is required. The visibility requirement is the less obvious half: most multi-version storage engines don't store full row-visibility information directly in a secondary index, so they maintain a separate summary (often called a visibility map) that tracks, per page of the table, whether every row on that page is definitely visible to all current and future transactions. Only when the relevant table pages are marked fully visible can the engine skip visiting the table at all; otherwise it still needs to check the table's visibility bookkeeping for at least those uncertain pages, which downgrades the scan to a partial (still much cheaper than a full) table visit.

To check whether a specific query and index actually achieve an index-only scan, look at the plan itself: engines that support this typically label the node distinctly (an "index only" or equivalent tag) and, when running with actual statistics, separately report how many table-heap fetches were still required despite the label; a nonzero number of "heap fetches" on an otherwise index-only node tells you the visibility condition, not the column-coverage condition, is the thing failing.

Worked example. A table with heavy UPDATE or DELETE activity, whose maintenance process hasn't caught up (background vacuuming lagging behind write volume, for instance), can have a fully qualifying covering index and still show a plan that visits the table for most or all rows, purely because the visibility bookkeeping is out of date. Catching up that maintenance process restores the fast path without touching the index or the query at all.

Trade-offs and pitfalls. It's easy to build a technically-covering index, see it isn't producing an index-only scan, and wrongly conclude the index definition is wrong; check the visibility-maintenance angle before redesigning the index, since that's the more common real-world cause on write-heavy tables.

Direct answer

Treat "legal needs three weeks but the team wants one week" as a scope problem, not a speed problem. Split the release into what can ship without new legal review and what genuinely needs sign-off, then give legal a narrow, well-defined ask for the second piece instead of asking them to review everything faster. The team ships on time, and the risky piece launches on its own review-driven schedule.

Structured elaboration

Find out what is actually blocking legal

"Legal sign-off" is rarely one undivided review. Ask legal directly which specific elements are new or unreviewed, and which are unchanged from something already approved. Most releases are a mix, and the review clock usually belongs to a small fraction of the surface area.

Split the release along that line

Everything that reuses already-approved language, patterns, or flows ships in the one-week window. Anything net-new that legal has not seen goes behind a feature flag (a toggle that keeps new code hidden from users until you're ready to turn it on) and ships later, once sign-off lands, decoupled from the original deadline.

Reduce legal's per-item cost, do not just ask for speed

A vague "please review this flow" invites a slow, open-ended read. A redlined diff (a side-by-side markup showing exactly which words changed from the last approved version, like tracked changes) against previously-approved language, with a one-paragraph explanation of what changed and why, is something legal can turn around fast because the review surface is small and explicit.

Keep everyone honest about the split

Do not quietly ship around legal's concern and call it done. Tell legal what you are shipping now, what is gated, and why you drew the line there, and let them confirm or push back on the boundary itself, not just react to a missed deadline.

Worked example

A signup redesign is due in one week. It includes a new consent checkbox asking users to opt into sharing data with a third-party analytics partner, and the copy for that checkbox has never been reviewed (legal quotes three weeks because it touches data-sharing language that needs a compliance read). Everything else in the redesign, the new layout and the reworked field order, is unchanged from an already-approved pattern used elsewhere in the product.

The split: ship the redesign now using the existing, already-approved consent copy and opt-in behavior unchanged. Put the new third-party-sharing consent language and checkbox behind a flag, off by default. Send legal a one-page diff: exactly the new sentence, what data it covers, and why it is being added, instead of the whole signup flow. The redesign ships in the one-week window. The new consent copy ships later, whenever legal actually signs off, on its own timeline, without ever having blocked the rest of the release.

Trade-offs and pitfalls

A flag-gated split adds real overhead: someone has to remember to remove the flag, and a half-shipped feature can linger longer than planned if nobody owns closing the loop. It also only works when the risky piece is genuinely separable. If the new element is load-bearing, meaning the whole flow depends on it, forcing a split creates a worse product than waiting.

The biggest pitfall is doing the split unilaterally and only telling legal afterward. That reads as shipping around the reviewer even when the intent was reasonable, and it burns the relationship needed for the next time this happens. The senior move is proposing the boundary and getting legal's explicit agreement on it before the ship date, not after.

Direct answer

I ran a six-week test of a new onboarding email sequence, hypothesizing that adding a short personalized video would raise activation, and by week four the data was inconclusive rather than clearly negative, which is the harder call: deciding whether to keep running for a real signal or stop because the result had stopped being informative. I stopped at week five, explained the decision and the reasoning to the two stakeholders who had sunk real time into producing the videos, and made sure what we'd learned about the underlying segment behavior carried into the next attempt instead of being lost with the failed one.

The hypothesis, design, and timeline

The hypothesis was that a short, personalized video early in onboarding would raise activation among users who had signed up but not completed setup, based on a pattern we'd seen in a smaller pilot. I designed a six-week A/B test with a defined minimum sample size calculated up front, specifically so I wouldn't be tempted to call it early or late based on how the numbers happened to be trending on a given day.

How I made the stop-or-continue call

By week four, the treatment group's activation rate wasn't meaningfully different from control, but the sample was also smaller than planned because a tracking issue had silently dropped a portion of the treatment group's data for the first ten days, which meant the result was underpowered (we didn't have enough clean data left to trust a negative result either way, not that the result was actually bad), not simply negative. I spent part of week four determining whether that was an environmental problem, the tracking gap, rather than a genuine sign the video didn't work. Extending the test to compensate was one option; I decided against it, because even a clean extension wouldn't have told us anything about the actual hypothesis with confidence by a reasonable date, and continuing mainly to avoid calling it a failure would have been the wrong reason to keep going.

What I did with what I'd learned

I stopped at week five and told the two people who had built the videos directly: the specific reason, an underpowered and contaminated dataset rather than a clear negative result, and that the honest conclusion was "inconclusive," not "the idea doesn't work." Rather than letting the attempt just end there, I salvaged what was usable: the clean portion of the data still showed a real behavioral pattern in how users engaged with onboarding content at all, which fed directly into redesigning the next attempt's tracking and targeting before we tried a similar idea again.

Trade-offs and pitfalls

The trade-off in a stop-or-continue call like this is sunk cost against real signal: the video work represented real time from real people, and there's pressure to keep going just to justify that investment rather than to actually learn something. The pitfall I watch for is treating "inconclusive" and "failed" as the same thing when explaining the decision, since conflating them either overstates how wrong the idea was or understates how little the test actually proved either way.

Direct answer

Trunk-based development (short-lived branches merging to a single trunk frequently, often multiple times a day) keeps the pipeline simple and CI throughput high, at the cost of needing strong automated testing and usually feature flags to hide incomplete work. GitFlow-style long-lived feature and release branches give more isolation for large, risky changes, at the cost of expensive merges, more parallel pipeline runs to maintain, and slower, more complex releases.

Structured elaboration

With trunk-based development, every merge to main is small and frequent, so the pipeline's job is straightforward: validate each small change quickly and keep main always releasable. CI throughput tends to be high (many small, fast pipeline runs) and merge conflicts are rare because branches don't live long enough to diverge much. The cost is that you can't hide an in-progress, half-built feature behind a long-lived branch; you need feature flags to merge incomplete work into main safely, and your test suite has to be trustworthy enough that a fast merge-time pipeline can actually catch regressions, because there's no lengthy release-branch stabilization period to catch what the automated checks missed.

With GitFlow (or similar long-lived branch models: develop, release branches, hotfix branches), each branch effectively needs its own pipeline configuration and its own build/test runs, multiplying the CI surface area. Merges from a long-lived feature branch back into develop or main are larger and more likely to conflict, and the pipeline has to handle merge-back validation as a first-class event, not just individual commits. The benefit is genuine isolation for large or risky work, and a natural place (the release branch) to stabilize before a release without disrupting ongoing development on develop.

Rollback complexity differs too: with trunk-based development and small frequent merges, a bad change is usually one small commit, so reverting it (or rolling forward with a fix) is fast and low-risk. With long-lived release branches, a bad release can bundle many changes together, making it harder to isolate and revert just the offending one.

Trigger strategy: monorepo versus multi-repo. In a monorepo, a single trunk-based merge event still has to trigger only the pipelines for the services actually affected by that commit, so the trigger layer needs path-based or dependency-graph-based filtering; without it, a trunk-based monorepo pipeline naively rebuilds and retests everything on every merge, which quickly destroys the fast-feedback benefit trunk-based development is supposed to provide. In a multi-repo layout, each repository's own push/PR trigger is already scoped to that one service for free, but a change to a shared library published from one repository doesn't automatically re-trigger every dependent repository's pipeline the way a single monorepo merge event would; that has to be handled explicitly, typically via a webhook from the shared library's publish step or an automated dependency-bump PR into each consumer, which is inherently slower and less atomic than the monorepo case. This is one reason teams doing trunk-based development at scale with many interdependent services often lean toward a monorepo: it keeps the 'one merge, one coordinated trigger fan-out' property that GitFlow-style long-lived branches and multi-repo layouts both make harder to get for free.

Worked example

A team of 40 engineers shipping a consumer product with strong test coverage and feature-flag infrastructure adopts trunk-based development: everyone merges small changes to main multiple times a day, CI runs in under 10 minutes, and incomplete features ship dark behind flags until they're ready to turn on. Contrast a team maintaining an on-premise enterprise product with quarterly releases and customers who need release notes and a stabilization window: a release-branch model fits better, because the business process (not just the pipeline) genuinely needs a period where only bug fixes land before a release ships.

Trade-offs and pitfalls

The most common mistake is picking trunk-based development because it's the trendier answer without having the test coverage or feature-flag discipline to back it up, which just means broken code lands on main more often. The opposite mistake is defaulting to long-lived branches out of habit when the team's actual release cadence and risk profile would be better served by trunk-based development with flags; the tell is a team that dreads 'merge day' because branches have diverged so far that the merge itself is the risky event, not the code.

Problem: top-10 products by avg rating last 30 days under heavy writes. Goals: fast aggregate reads without slowing writes.
Schema changes and indexes:

• Add a write-optimized summary table reviews_agg(product_id, window_day date, review_count int, rating_sum int, rating_avg float) updated incrementally.
• Maintain recent-window rolling buckets, e.g., daily or hourly buckets, then compute 30-day averages by aggregating these buckets.
• For low-latency leaderboard, maintain a materialized view or in-memory cache (Redis/KeyDB) keyed by day and product with sorted sets for top-N.
  Implementation:
• On insert of review, write to reviews table (append-only) and asynchronously push a lightweight event to a background worker/queue (Kafka/RabbitMQ).
• Worker updates reviews_agg: increment count and sum for current day using atomic DB statements (UPSERT) or update via idempotent increments.
  Indexes:
• Primary key on reviews_agg(product_id, window_day) for fast upsert.
• Index on reviews_agg(window_day, rating_avg DESC) to compute top-N per day; or maintain precomputed leaderboard in cache (sorted set by avg).
  Why this helps:
• Heavy writes: main write stays append-only with minimal synchronous work; aggregation is handled asynchronously, avoiding write contention and expensive full-table scans.
• Aggregation: computing top-10 for last 30 days becomes a small aggregation over 30 rows per product (or precomputed daily scores), or merging top lists from cache shards.
  Edge cases:
• Ensure idempotency and eventual consistency; provide fallback exact query (slower) if aggregator lag is unacceptable. Use background workers with retries and metrics.

Clarify goals & constraints
Serve new release without cache stampede, keep latency stable, allow quick rollback, work with distributed cache (Redis/ElastiCache) and CD/CI pipeline.

High-level approach

• Use versioned cache keys (app:v{N}:key) so new code reads a fresh namespace.
• Pre-warm new namespace with controlled background writes before switching traffic.
• Gradually shift traffic (canary → ramp) while throttling invalidation of old entries.
• Monitor health & metrics; rollback if latency/error thresholds exceeded.

Orchestration steps

1. Build release vN and deploy to blue/green environment (green = new).
2. Start new app pointing to cache namespace prefix app:vN: (config flag).
3. Pre-warm: run a background worker that reads authoritative source (DB) and writes hot keys into app:vN: at controlled RPS (e.g., 10% of steady-state read QPS). Prioritize top-K hot keys from prior analytics.
4. Canary traffic: route 1–5% of user traffic to green for 10–15 minutes. Green reads app:vN:, misses trigger pre-warm async fills; on miss green can optionally read old namespace app:vN-1: as fallback to avoid latency spike.
5. Throttled invalidation/retire: once metrics stable, gradually increase traffic and begin TTL-reduction on old namespace keys (set expire/soft-ttl) and/or delete hot keys in batches (e.g., 100 keys/sec) to avoid bursts.
6. Full cutover: when error/latency/throughput are within thresholds for X minutes, switch all traffic to green and mark app:vN-1: for lazy delete after a safe window.
7. Rollback path: re-route traffic to vN-1 immediately. New namespace can be discarded. If rollback occurs, stop pre-warm jobs and restore previous cache writes.

Health checks & observability

• Track p95/p99 latency, cache hit ratio, origin DB RPS, error rates, and CPU/memory on cache nodes.
• Define guards: abort/cancel cutover if p99 latency increases >30ms or DB RPS > 2x baseline for 5m, or error rate >0.5%.
• Use synthetic probes for critical endpoints during canary.

Safety details / edge cases

• Fallback reads: on miss in vN try vN-1 synchronously only for low-QPS paths; otherwise serve stale or degrade gracefully.
• Rate-limit background pre-warm to avoid DB overload; use exponential backoff on DB errors.
• Avoid global cache flush. Prefer namespacing + TTL or batched deletes.
• Ensure distributed config rollout so both app and workers use consistent namespace flag.

Why this works
Versioned keys avoid immediate invalidation spikes. Pre-warming reduces cold misses. Throttled deletes and canary ramp limit DB and cache pressure. Health checks provide automated safety and fast rollback.