44 Netflix Python Developer Interview Questions & Answers

I would normally combine lazy deletion with bounded periodic cleanup. A read checks the expiry time and removes an expired entry, while periodic cleanup removes expired entries that are never read again. For a large cache, I would consider an expiration heap or a timing wheel to avoid repeatedly scanning the full dictionary. Reads, writes, and cleanup must follow one synchronization policy, such as one shared lock or one asyncio event loop owner.

The practical default is lazy deletion plus bounded periodic cleanup. Each entry stores a value and an expiry time from time.monotonic. A read treats the entry as missing when the expiry has passed and removes it while holding the cache lock. Lazy deletion is efficient for active keys, but expired keys that are never accessed can remain in memory.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Periodic cleanup solves that problem. It should inspect only a limited number of entries or run within a time budget, so one cleanup pass does not create a long pause. A full dictionary scan costs time proportional to the number of stored entries.

For larger caches, an expiration heap keeps the earliest expiry at the top. Insertion and removal cost logarithmic time. Updating a key can leave stale heap records, so cleanup must compare each heap record with the current dictionary entry before deleting anything.

A timing wheel groups expiries into time buckets. It can reduce scheduling cost at high volume, but expiry precision is limited by the bucket interval. A background thread suits synchronous code. An asyncio task suits a cache owned by one event loop. Every design needs controlled shutdown, memory limits, and cleanup metrics.

Common mistakes include using only lazy deletion, which allows untouched expired entries to consume memory, and scanning the entire dictionary too often, which can create latency spikes. Another mistake is using time.time for elapsed lifetime when clock changes can affect expiration decisions. Developers may also assume the GIL makes a multi step check and delete sequence safe. It does not provide the required cache level atomicity. Heap implementations often forget to reject stale expiry records after a key is updated. Background cleanup also needs a stop mechanism, bounded work, error handling, and metrics.

Start with lazy deletion plus bounded periodic cleanup as the default. Then compare a full scan, an expiration heap, and a timing wheel using cleanup cost, memory retention, expiry precision, synchronization, and implementation complexity.

I would keep the dict private and protect every put, get, and delete operation with the same threading.Lock. Each method would acquire the lock with a with statement, complete the entire dict operation, and release the lock automatically. This makes each public method appear atomic to other threads using the store. I would not depend on the global interpreter lock because it does not provide a clear application level guarantee for a sequence of dict actions.

I would place the normal dict inside a class and create one threading.Lock for the store. Every public method must use that same lock. Put acquires the lock and stores the value. Get acquires the lock and returns the value or a supplied default. Delete acquires the lock, checks for the key, removes it, and returns whether removal happened.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

The with statement releases the lock even if a dict operation raises an exception. While one thread holds the lock, other threads calling these methods wait. This makes each complete method call appear atomic to callers that use the class correctly.

I would not rely on the global interpreter lock. Runtime details may make some individual dict actions safe from memory corruption, but a sequence such as check then delete can still race without application synchronization.

Average dict lookup, insertion, and deletion are constant time. Lock waiting can increase latency under contention. The store uses linear memory for its entries and constant extra synchronization memory. It is suitable for a small store shared by threads in one process. It does not synchronize separate processes or servers. Returned mutable values also need their own protection if threads modify them.

The class owns one private dict and one private threading.Lock. Put, get, and delete all acquire the same lock. Put stores a value. Get returns the stored value or the caller supplied default. Delete performs both the key check and the removal while holding the lock, then returns True when the key existed or False when it did not. Keeping the complete operation inside one protected block prevents another thread from changing the dict between related steps. The code protects the dict structure, but it does not automatically protect later mutation of a mutable object returned by get.

A common mistake is assuming that the global interpreter lock makes every dict workflow thread safe. Another mistake is using a different lock in each method, because those locks would not coordinate access to the same dict. Developers may also place the key check outside the protected block and lock only the deletion, which creates a race between the two actions. Exposing the internal dict is unsafe because callers could modify it without using the lock. Holding the lock during slow file access, network access, callbacks, or other unrelated work creates unnecessary contention. Another mistake is calling a public locked method from inside another block that already holds this non reentrant lock, because the same thread can then block itself.

Start with the design: one private dict and one shared lock around every complete public operation. Explain that check and delete must use one locked block. Then mention contention, mutable returned values, and the fact that this design protects threads in one process only.

I would use a dictionary that maps each key to two parallel lists. One list stores sorted timestamps and the other stores the matching values. When timestamps arrive in order, a write appends to both lists. A read uses bisect_right on the timestamp list and returns the value at the previous position. This gives constant average key lookup, constant amortized append, and logarithmic search for a key.

I would map each key to two Python lists. The first list stores timestamps in sorted order. The second list stores the matching values at the same indexes. For example, the key theme could have timestamps 10, 20, and 30 with values light, dark, and system.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

When writes for one key arrive in nondecreasing timestamp order, set can append to both lists. Python list append has constant amortized cost. To read a value, get uses bisect_right from the standard library. It finds the position after the last timestamp that is less than or equal to the requested timestamp. Moving one position left gives the correct value. If the position is zero, no value existed at that time.

The dictionary gives constant average lookup by key. Binary search gives logarithmic lookup among the versions for that key. Memory grows with every stored timestamp and value. The main limitation is unordered input. Inserting an older timestamp into the middle of a Python list takes linear time because later elements must move. In production, I would define duplicate timestamp behavior, validate ordering, and add retention rules if history can grow without a limit.

The VersionedKeyValueStore keeps a dictionary from each string key to a VersionHistory object. Each history contains a timestamp list and a value list. The lists always have the same length, and matching indexes describe one version. The set method rejects a timestamp that is older than the latest timestamp for that key. It then appends the timestamp and value. Equal timestamps are allowed, so a later write at the same timestamp becomes the value returned for that timestamp. The get method uses bisect_right on the timestamp list. The returned position is after every timestamp that is less than or equal to the requested time. The value at the previous index is therefore the newest valid version. The method returns None when the key does not exist or when the requested timestamp is earlier than the first version. An ordered write has constant amortized time. A read takes logarithmic time in the number of versions for that key. Memory use is linear in the total number of stored versions.

A common mistake is scanning every version from the beginning, which makes each read linear instead of logarithmic. Another mistake is storing timestamps in an ordinary dictionary without maintaining an ordered sequence, because finding the nearest earlier timestamp then requires extra work. Candidates may also forget the case where the requested time is earlier than the first version. Other mistakes include letting the timestamp and value lists become different lengths, accepting unordered writes without accounting for linear insertion cost, leaving duplicate timestamp behavior undefined, and assuming that Python dictionary insertion order can replace timestamp search.

State the data structure first: a dictionary from each key to sorted timestamps and matching values. Then explain ordered append, bisect_right, the earlier than first timestamp case, duplicate timestamp behavior, and the cost of unordered insertion. Use one small example throughout the explanation.

I would define one edge rule first: X to Y means X must happen before Y. Then I would strip each string, match it against the supported formats with full regular expression matching, convert every match into that same direction, and store destinations in a set. The examples produce B to A, C to A, and B to D. Sets remove duplicate edges, while invalid values are returned as structured errors instead of being guessed or silently ignored.

I would first define one graph rule: an edge from X to Y means X must happen before Y. This removes ambiguity when different text forms describe the same dependency.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Each value is checked to confirm that it is a string, stripped of surrounding spaces, and matched against one of three supported patterns. Full matching is important because it rejects extra unknown text instead of accepting only part of a line. For install A after B, the edge is B to A. For C to A, the edge is C to A. For B before D, the edge is B to D.

The graph uses a dictionary whose values are sets. A set stores each destination once, so repeated dependency strings do not create duplicate edges. Destination nodes are also added with empty sets so every known node appears in the graph.

Malformed values are collected with their position, original value, and reason. The parser does not guess their meaning. Production code can then reject the whole request or continue with valid entries according to an explicit policy. Cycle detection, including self dependencies, should run as a separate validation step after parsing.

The code defines three compiled regular expression patterns for the supported formats. Every successful match produces two named values called earlier and later. The graph stores an edge from earlier to later, which always means that earlier must run first. A dictionary maps each node to a set of destination nodes, so repeated inputs create only one edge. The destination is also added as a key even when it has no outgoing edges. Empty strings, values that are not strings, and unsupported formats are collected in an error list. For the sample input, the graph contains B to A, B to D, and C to A. The repeated C to A input appears only once.

Common mistakes are reversing the meaning of after, storing destinations in a list and keeping duplicate edges, using partial matching, forgetting nodes that have no outgoing edges, and silently dropping malformed values. Another mistake is assuming that successful parsing proves the dependency graph is valid. Parsing builds the graph, while cycle detection and self dependency checks are separate validation steps.

State the edge direction before discussing code. Translate each sample into that direction, explain why sets remove duplicate edges, and show how malformed values are reported. Finish by saying that cycle detection happens after parsing.

I would define the contract first, take a stable snapshot of the input sequence, validate every element, and apply one small pure function to each string. In this example, I normalize Unicode with NFC, remove surrounding whitespace, and use casefold for consistent case matching. I preserve element order and count, return an empty list for empty input, and raise clear errors for invalid values. The work is proportional to the input and output text, and new memory is required because Python strings are immutable.

I would begin with an explicit contract. The function accepts a sequence of strings, preserves element order and count, and returns a new list. It rejects a bare string because Python would otherwise treat it as a sequence of characters. It copies the sequence into a tuple so validation and transformation use the same snapshot.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Each value is passed to one small helper. The helper applies Unicode NFC normalization, strip, and casefold. NFC gives canonically equivalent text a consistent representation. Strip removes surrounding Unicode whitespace. Casefold provides stronger Unicode case matching than lower. It is not locale specific, and some characters can expand. For example, the German sharp s becomes ss.

Empty input returns an empty list. Empty strings remain in their original positions. The function does not mutate the caller's sequence or strings. Python strings are immutable, so normalization, trimming, and case conversion can create new string objects.

I would test ordinary text, composed and decomposed Unicode, whitespace only values, empty input, invalid containers, invalid elements, preserved order, and repeated calls. Time is O of the total input and output characters plus the number of elements. Extra memory is O of the snapshot, result references, and output characters.

The code defines one public function and one small pure helper. The public function rejects a bare string and any value that is not a sequence. It copies the sequence into a tuple, then validates every element before producing any transformed result. The helper applies NFC normalization, removes surrounding whitespace, and applies casefold. The list comprehension preserves order and produces exactly one output for each input element. For the example input, the output is ["café", "strasse", ""]. Empty input returns an empty list. Time is O of the total input and output characters plus the number of elements. Extra memory is O of the tuple snapshot, result references, and produced string data.

Common mistakes include accepting a bare string and processing one character at a time, trusting type hints as runtime validation, using lower when Unicode case matching is required, deleting empty results without documenting that element positions will change, converting the values to a set and losing order, mutating the caller's list, and claiming constant memory even though new containers and strings are created. Another mistake is overwriting original display text with a comparison form.

State the contract first. Then explain validation, the exact Unicode operations, preserved order and count, empty input behavior, tests, and complexity. Mention that Python strings are immutable and that casefold is useful for matching keys but may not be suitable for displayed text.

I would use collections.OrderedDict for key lookup and least recently used ordering, plus an integer that tracks the total stored weight. A successful get moves the key to the most recently used end. A put validates the weight, replaces any old entry, updates the total, and removes least recently used entries until the cache fits. Lookup and order updates are constant time on average. One put may remove several entries, so its immediate cost depends on the number of evictions.

I would store each key in an OrderedDict with its value and weight, and keep a separate total_weight integer. The first item is the least recently used entry, and the last item is the most recently used entry.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

A successful get moves the key to the end with move_to_end. A missing key returns None. A put rejects a negative weight and rejects an item that is heavier than the full limit. It then removes any old version of the key, subtracts its old weight, inserts the replacement, and adds the new weight. If the total becomes too large, popitem with last set to False removes old entries until the cache fits.

Lookup, insertion, deletion, and moving an existing key are constant time on average. A put that evicts k entries takes O(k) time. The cache uses O(n) bookkeeping memory for n entries and also keeps references to all cached keys and values.

Mutable values can grow after insertion, so stored weights may become stale. Zero weight entries can grow without affecting the limit. Shared access needs a lock because get and put both change cache state.

The implementation uses one OrderedDict named entries. Each key maps to a tuple containing the value and its recorded weight. The current total is stored in total_weight. A successful get moves its key to the end, which marks it as most recently used. A put first validates the supplied weight. An item heavier than max_weight is rejected before existing state is changed. When a key is updated, the old entry is removed and its old weight is subtracted before the replacement is inserted. If the cache becomes too heavy, popitem with last equal to False repeatedly removes entries from the least recently used end. The method returns None for a missing key and returns True or False from put to show whether the item was accepted. Because None can also be a cached value, callers that need to distinguish a miss from a stored None value should use a separate membership method or a unique sentinel. The recorded weight does not update automatically when a mutable value changes.

Common mistakes include evicting by item count instead of total weight, forgetting to subtract the old weight when replacing a key, and failing to update recency after get. Another mistake is removing an existing value before checking whether its replacement is too heavy to fit. Some implementations scan a normal dictionary to find an eviction target, which makes eviction slow. It is also wrong to assume recorded weight changes automatically when a mutable value grows. Allowing unlimited zero weight entries can cause real memory growth even though total_weight stays within the limit. A missing key and a cached None value are also indistinguishable when get returns None unless the caller checks membership separately.

State the eviction rule first. Then explain the two pieces of state: an OrderedDict for lookup and recency, and an integer for total weight. Walk through a key replacement and a put that evicts several entries. Finish with the O(k) eviction cost, O(n) bookkeeping memory, retained object memory, stale weight risk, zero weight limitation, and thread safety requirement.

I would write a few small tests that each check one behavior, then run them after every meaningful code change. I would start with a normal case, then test boundary, empty, and invalid inputs when they apply. I would use specific assertions such as assertEqual and assertRaises. When a failure is unclear, I would add one temporary print for the relevant input and result, but I would keep the assertion so the test still fails visibly.

I would create small tests before changing too much code. Each test should verify one clear behavior. I would begin with a normal input, then add empty input, boundary values, and invalid input when they apply. Python includes the unittest module, which provides test cases and assertions such as assertEqual, assertTrue, and assertRaises. When an assertion fails, the test runner marks the test as failed and shows the test name, failure details, and traceback. This gives useful evidence even without a debugger.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

I would run the tests after each meaningful change with unittest.main. I would use descriptive test names so the failing behavior is easy to identify. When the cause is still unclear, I would add one temporary print near the relevant value. The print should show only the input, intermediate value, or result needed for diagnosis. It must not replace the assertion.

I would not catch AssertionError or place a broad except block around a test. That can hide a real failure and make incorrect code appear successful. In production, I would keep tests deterministic, remove temporary prints, and run the same suite in automated checks.

The example tests a function that normalizes a username. Each test method checks one behavior. The first test checks normal text. The second checks surrounding spaces. The third checks the empty string case. The fourth verifies that a value that is not a string raises TypeError. One temporary print shows the input and result for focused diagnosis, while assertEqual still decides whether the test passes. unittest.main runs the tests and reports failures with tracebacks. No exception handler catches assertion failures, so an incorrect result remains visible. The function processes the input text and creates normalized string values, but this cost belongs to the function being tested rather than to the testing technique itself.

Common mistakes include putting several behaviors in one test, checking only the normal case, using vague assertions, and giving tests unclear names. Another mistake is printing values without asserting the expected result. Candidates may also catch AssertionError or use a broad except block, which can hide failures. Temporary prints should be focused and removed after the cause is understood. Tests should also avoid dependence on random values, shared mutable state, network access, or execution order unless those dependencies are controlled.

Explain the test order before writing code. State the expected behavior, add one small test, run it, and use the failure message as evidence. Mention that prints help diagnosis, but assertions decide success or failure.

I choose the Python execution model from the workload, but I design correctness separately. Threads are useful for blocking input and output work. Asyncio is useful for many cooperative network tasks. Processes are usually the safer default for CPU intensive Python work when true parallel execution is needed. In a normal CPython build, the GIL limits Python bytecode execution, but it does not make compound updates thread safe. Free threaded CPython builds can run threads in parallel, which makes explicit synchronization even more important. For reliability, I use timeouts, limited retries, idempotency keys, transactions, durable queues, and restart safe workers because a timeout or crash can cause the same operation to run more than once.

The practical rule is to choose concurrency for throughput and design reliability for repeated execution. Threads share memory and work well with blocking input and output libraries. In a normal CPython build, the GIL usually allows one thread to execute Python bytecode at a time, but a compound read, change, and write operation can still interleave. Shared mutable state therefore needs a Lock, Queue, transaction, or ownership rule. Free threaded CPython builds can execute Python threads in parallel, so code must not depend on the GIL for safety.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Asyncio runs tasks cooperatively on an event loop. It works well when tasks await nonblocking operations. A slow blocking call can stop progress for other tasks on that loop. Processes provide separate memory and can use multiple CPU cores, but they add memory use, process startup, and data transfer costs.

Reliability requires assuming that work may run again. A timeout does not prove that the first attempt failed. I retry only temporary failures, apply a limit and delay, and use an idempotency key for state changes. The service stores the key and result durably in the same transaction as the business update. Durable queues, acknowledgements after commit, and restart safe workers allow recovery without creating duplicate effects.

Common mistakes include treating the GIL as a lock for application state, depending on behavior that changes in a free threaded build, and protecting only one step of a multi step invariant. Other mistakes include using a normal in memory dictionary as durable duplicate protection, using a threading lock between separate processes, calling blocking code directly on an asyncio event loop, and sharing an asyncio lock across threads. Reliability mistakes include retrying permanent errors, retrying without a limit, assuming a timeout means no work completed, acknowledging a queue message before data commits, and storing the idempotency record separately from the business update. These errors can cause races, blocked event loops, lost work, or duplicate effects.

Start with the workload choice, then separate concurrency from correctness. Compare threads, asyncio, and processes in a few sentences. State that the GIL is not an application synchronization mechanism and mention free threaded CPython. Finish with one concrete failure case: a request times out after the server commits, the client retries, and an idempotency key plus one transaction prevents a duplicate update.

I would combine normal unit tests, repeated concurrent stress tests, and controlled scheduling tests. I would start workers together with a Barrier, use Events, Barriers, or test hooks to force risky execution orders, capture worker exceptions, log useful context, and assert exact results and invariants. The Python interpreter lock does not make a complete read, change, and write sequence automatically thread safe. Passing tests increase confidence, but they cannot prove that every possible schedule is safe.

I would test race conditions in three layers. First, I would write normal unit tests for the shared object in one thread. This confirms its rules before concurrency makes failures harder to diagnose.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Next, I would run many threads against the same object. A Barrier can release the workers together. Repeating the test and temporarily reducing the thread switch interval creates more chances for operations to overlap. Every worker exception must be collected and reported in the main test thread.

I would assert exact results and important invariants. For a counter, the final value must equal the number of completed increments. For a collection, its keys, size, and related totals must remain consistent.

For known risky orders, I would use Events, Barriers, or test hooks to pause execution at a specific point. This makes an unsafe interleaving reproducible instead of depending on luck. Logging should include the round, thread name, operation, and observed state. Pytest can organize the tests, while logging and faulthandler can help diagnose hangs or failures. Stress tests use more processor time and memory for threads, and they cannot explore every schedule. I would run fast checks on each change and larger repeated tests in continuous integration.

The code uses one safe counter and one deliberately unsafe counter. The safe counter protects its complete update with threading.Lock. Its basic test checks normal behavior. Its stress test creates eight workers, releases them together with a Barrier, and makes each worker perform twenty thousand increments. Worker exceptions are captured and raised in the main thread. The thread switch interval is temporarily reduced and then restored. After every round, the final value must equal the exact expected value.

The controlled test uses the unsafe counter with a test hook. Two threads read the same value and then wait at a Barrier before either writes. Both threads therefore write the same next value, so one update is lost. The assertion confirms the reproducible failure. This example covers unit tests, concurrent stress, controlled scheduling, logging, exception handling, and invariant checks. It increases confidence in the safe implementation but does not claim to explore every possible schedule.

Common mistakes include running only one concurrent test, checking only that no exception occurred, and using random sleep calls as the main scheduling method. Another mistake is assuming that the Python interpreter lock makes every shared operation atomic. Developers may also check only the final result while ignoring other broken invariants, forget to join threads, lose exceptions raised inside workers, change the global thread switch interval without restoring it, or create controlled tests that do not actually force the intended execution order. A passing stress test is evidence, not proof that no race exists.

Explain the strategy in layers. Start with unit tests, then synchronized stress tests, then controlled schedules, logging, worker exception handling, and invariant checks. State clearly that Python thread scheduling is not fully deterministic and that repeated passing tests cannot prove the absence of every race.