An asyncio service holds 10,000 sockets, must keep event-loop lag below 10 ms, and now parses each message for 12 ms in pure Python before the next await; how would you budget and schedule that work?

I would keep each event-loop callback or coroutine step under about 2 ms and move the 12 ms parse off the loop. - The loop runs ready callbacks, advances tasks until an awaited operation suspends, processes timers, and polls the selector, so one 12 ms step already breaks the 10 ms lag target for every socket. - I would split incremental parsing with explicit yield points only if state can be chunked cheaply; otherwise pure Python CPU work belongs in a ProcessPoolExecutor or a native parser, while blocking I/O belongs in asyncio.to_thread. - I would enable loop.set_debug, set loop.slow_callback_duration to 0.005, and schedule a monotonic 10 ms heartbeat to measure p95 and p99 loop lag. - Offloading must be bounded because submitting 10,000 parse jobs merely moves the queue, so I would cap in-flight jobs and reject or pause reads when that cap is reached.

A 16-core pipeline must handle 1,000 items per second, with 40 ms of async network waiting, 20 ms in a synchronous SDK, and 8 ms of pure Python CPU work per item; which concurrency models would you combine?

I would use asyncio for the network stage, a dedicated thread pool for the blocking SDK, and a process pool for the pure Python CPU stage. - At 1,000 items per second, the 40 ms network wait needs about 40 concurrent asyncio tasks, so I would start near 64 rather than create one thread per connection. - The SDK consumes about 20 thread-seconds per second; a 24 to 32 worker ThreadPoolExecutor gives modest headroom if the call spends its time blocked and releases the GIL. - The CPU stage demands 8 core-seconds per second, so I would start a ProcessPoolExecutor with about 10 workers, leaving six cores for the event loop, SDK threads, serialization, and the OS. - Bounded queues between all three stages expose saturation; if pickling the item dominates the 8 ms calculation, I would batch items or pass shared-memory references instead.

On an 8-core host, a pure Python transform takes 40 ms and must run 200 times per second; what throughput would a 32-thread pool provide under the GIL, and what would you change?

A 32-thread pool will stay near one core and roughly 25 transforms per second, so it cannot meet the 200-per-second target. - The GIL permits only one thread at a time to execute Python bytecode in one interpreter; more CPU threads add switching and lock overhead rather than eightfold parallelism. - Eight process workers have an ideal ceiling of 200 transforms per second because 8 divided by 0.040 equals 200, but that leaves no capacity for serialization, the OS, or latency variance. - I would use ProcessPoolExecutor for coarse tasks and either provide about 10 effective cores or reduce the transform below 32 ms to keep an 8-core host near 80 percent utilization. - Threads become viable only if the hot work moves into NumPy or another C extension that releases the GIL, which I would confirm with a 1, 8, and 32 thread benchmark.

A 32-core service spends 70 percent of its 20 ms CPU time in Python and 30 percent in a C extension, and it must grow from 400 to 1,200 requests per second; how would you evaluate free-threaded CPython?

I would adopt a free-threaded build only after proving that the C extension is compatible and that 8 to 32 threads scale toward the 1,200-request target. - I would import the extension and check sys._is_gil_enabled; an extension that does not declare Py_MOD_GIL_NOT_USED through the Py_mod_gil slot can cause the interpreter to enable the GIL again. - The benchmark matrix would compare regular and free-threaded CPython at 1, 8, and 32 threads for throughput, p99 latency, RSS, and single-thread cost, because removing the GIL can trade parallel scaling for per-thread overhead. - I would audit shared Python caches and extension globals for races, add threading.Lock around compound mutations, and update C code to use supported critical-section APIs instead of relying on the GIL. - If the extension is unsafe or scaling flattens before 1,200 requests per second, regular CPython with process workers and shared read-only memory is the lower-risk design.

A request fans out to 12 shards with a 300 ms deadline, one shard raises after 80 ms, and four sibling tasks hold database connections; how should asyncio.TaskGroup handle the work?

I would place the TaskGroup inside a 300 ms asyncio.timeout so a shard failure or the deadline cancels all owned sibling work. - A non-cancellation exception from one child makes TaskGroup cancel the other 11 tasks, wait for their cleanup, and then raise an ExceptionGroup instead of leaving detached tasks running. - Every shard coroutine must release its connection in finally and re-raise asyncio.CancelledError; swallowing cancellation can hold one of the four connections past the request lifetime. - I would keep the task handles created by group.create_task and read results only after the context exits successfully, so no partial response escapes by accident. - If one shard is explicitly optional, that child converts its own expected error into a typed fallback; catching errors outside the group would cancel healthy siblings before that policy is applied.

An async producer emits 5,000 messages per second for a 60-second burst, 20 consumers each process one message in 5 ms, and every message is 2 KB; how would you size asyncio.Queue and apply backpressure?

The consumers sustain 4,000 messages per second, so I would bound the queue near 8,000 items for a two-second waiting budget rather than absorb the full burst. - An unbounded queue gains 1,000 messages per second and reaches 60,000 items, at least 120 MB of payload plus Python object overhead, while maxsize=8000 limits raw payload to about 16 MB. - Producers should await queue.put, and an external producer should get a fast rejection if asyncio.wait_for cannot enqueue within a defined limit such as 100 ms. - Each consumer calls task_done in finally, and shutdown awaits queue.join before cancelling the 20 consumers so accepted messages have explicit completion semantics. - I would publish queue depth, oldest-item age, put-wait time, and rejection count, because depth alone cannot distinguish large cheap bursts from work already missing its deadline.

A Linux process already has 12 native threads and a 300 MB cache when it launches eight CPU workers, and worker startup must stay under 3 seconds; would you use multiprocessing fork or spawn?

I would choose spawn for correctness and meet the three-second target by mapping the cache separately instead of forking the threaded parent. - Fork copies only the calling thread while inheriting locks, sockets, and file descriptors owned by the other 11 threads, so a child can wait forever on a lock whose owner no longer exists. - multiprocessing.get_context with spawn starts a clean interpreter; I would use a main guard and an initializer to create each child's clients, random state, and logging explicitly. - Sending 300 MB as a pool argument would pickle it eight times, so I would expose the cache through a read-only mmap or shared_memory segment that every spawned worker attaches to. - Fork is acceptable only if the pool is created from a deliberately single-threaded preloader before any background thread or network client starts, which is a narrower design than this scenario allows.

Sixteen Python worker processes on a 64 GB host need random read access to the same 12 GB NumPy lookup table, refreshed once per hour, and must start within 10 seconds; how would you share the state?

I would keep one immutable 12 GB backing store and let all 16 workers map it rather than create up to 192 GB of private copies. - A versioned np.memmap file gives every spawned worker an ndarray view backed by the OS page cache; multiprocessing.shared_memory with np.ndarray(buffer=shm.buf) is suitable when the table must not live as a file. - On Linux, preloading before fork also exploits copy-on-write, but the parent must still be single-threaded and even accidental writes can dirty pages until memory approaches 12 GB per worker. - For the hourly refresh, I would build a new immutable version, atomically publish its name, let workers map it between requests, and remove the old mapping only after all users release it. - multiprocessing.Manager and Queue are wrong for random lookups at this size because each access crosses a proxy or serialization boundary; mutable deltas should live in a separate small store.

An asyncio API receives 300 requests per second, each request includes 25 ms of pure Python CPU work, the host has eight cores, and p99 must stay below 200 ms; how would you offload and capacity-plan the step?

I would offload the step to a bounded process pool, but I would also add CPU capacity because the workload already demands 7.5 of eight cores before any overhead. - asyncio.to_thread is unsuitable for this pure Python work under the GIL; the request coroutine should await loop.run_in_executor with a ProcessPoolExecutor. - Eight ideal workers can complete only 320 jobs per second at 25 ms, so 300 requests per second leaves about 6 percent headroom and cannot support a stable 200 ms p99. - I would target roughly 70 percent CPU by using 12 cores with 10 process workers, or optimize the step to about 18 ms, while reserving capacity for the event loop and serialization. - A semaphore would cap submitted jobs near the worker count, a 50 ms admission timeout would reject excess work, and large request bodies would be reduced before crossing the pickle boundary.

An async API must make 600 calls per second through a blocking SDK that takes 80 ms, the upstream permits 50 concurrent calls, and the endpoint p95 budget is 250 ms; how would you size and isolate its thread pool?

I would use a dedicated 50-worker ThreadPoolExecutor with a matching concurrency gate, while acknowledging that the upstream limit leaves almost no throughput headroom. - Little's law gives 600 times 0.080, or 48 concurrent calls, and 50 threads provide a theoretical ceiling of 625 calls per second, only about 4 percent above demand. - The coroutine should acquire an asyncio.Semaphore before loop.run_in_executor, with about a 100 ms acquisition timeout so SDK time plus queueing can still fit inside the 250 ms endpoint budget. - A dedicated executor prevents 50 blocked SDK calls from starving DNS, file, or other default-executor work, and metrics should cover active threads, semaphore wait, SDK latency, and rejections. - This design assumes the SDK blocks on I/O and releases the GIL; if profiles show Python CPU work, threads will not scale, and if 600 calls per second is strict, the upstream cap must rise or requests must be shed.

Design a FastAPI service for 8,000 JSON requests per second with a 150 ms p99 target on 8-vCPU Kubernetes pods: how many ASGI workers and replicas do you start with?

I size ASGI workers from a one-worker load test, then leave enough replica capacity to lose one pod without crossing the latency target. - If one Uvicorn worker sustains 600 RPS at 150 ms p99, I start with 6 workers per 8-vCPU pod and 4 pods: 24 event loops provide 14,400 RPS nominal capacity, while 3 surviving pods still provide 10,800 RPS. - Each worker owns one event loop and multiplexes I/O-bound requests across it; ASGI does not make JSON validation or other CPU work parallel, so 6 workers leave 2 cores for the kernel, sidecars, and burst headroom. - FastAPI lifespan creates one asyncpg pool and one httpx.AsyncClient per worker, so every pool limit is multiplied by 24 and must fit the database and upstream budgets. - I cap in-flight handlers at 200 per worker, bound the accept backlog, return 503 when admission is exhausted, and scale on CPU plus event-loop lag rather than letting unbounded tasks inflate p99.

A Django endpoint receives 4,000 RPS across 8 replicas, spends 20 ms in the synchronous ORM, and makes 2 independent 120 ms HTTP calls: where do you place the sync and async boundary?

I use an async view for the concurrent HTTP work and cross into synchronous Django exactly once for the transactional ORM block. - The 2 HTTP calls run together through one reused httpx.AsyncClient, reducing their wall time from roughly 240 ms to 120 ms without occupying Django threads while sockets wait. - I put the complete 20 ms ORM transaction behind one sync_to_async call with thread-sensitive execution instead of alternating between sync and async for individual queries. - At 500 RPS per replica, the database step needs about 10 concurrent slots by Little's law, so I start with 16 bounded sync worker threads and no more than 16 database connections per replica. - The 2 outbound calls require about 120 concurrent slots per replica, so a 160-slot semaphore and a bounded deadline-aware queue apply backpressure before the HTTP pool saturates.

How would you shut down an asyncio service in Kubernetes when terminationGracePeriodSeconds is 30, requests may run for 10 seconds, and each pod owns 200 background tasks?

I reserve a 25-second application drain window inside the 30-second pod deadline and give every accepted task an explicit owner and cancellation path. - On SIGTERM the process immediately fails readiness and stops accepting new HTTP requests and upgrades, while Uvicorn receives up to 15 seconds to finish requests that were already accepted. - Background work lives in a TaskGroup or tracked task registry; durable jobs stop being claimed, in-flight jobs get 8 seconds to checkpoint, and disposable tasks are cancelled in dependency order. - Every coroutine handles CancelledError only to release its resource and then re-raises it, while finally blocks close asyncpg, httpx, Kafka, and telemetry clients before second 25. - At second 25 I cancel remaining tasks and exit, leaving 5 seconds for Kubernetes enforcement; work that cannot tolerate cancellation belongs in a durable queue, not an untracked create_task call.

An async Python API handles 2,000 RPS on 20 pods with 4 workers each, while PostgreSQL allows 500 connections and an HTTP dependency allows 1,000 concurrent requests: how do you budget asyncpg and httpx pools?

I divide dependency capacity across all 80 worker processes before choosing local pool sizes, because per-process defaults multiply across the fleet. - I reserve 100 PostgreSQL connections for migrations, administration, and other services, leaving 400 for the API, so each asyncpg pool starts at min_size 1 and max_size 5. - A request holds PostgreSQL for 15 ms on average, giving only 30 concurrent database users fleet-wide at 2,000 RPS, so 400 connections are a ceiling rather than a throughput target. - The HTTP call lasts 80 ms on average, giving 160 concurrent calls fleet-wide; max_connections 8 per httpx client allows a 640-call burst while remaining below the upstream limit of 1,000. - I set short acquisition deadlines, expose pool wait time, and never hold an asyncpg connection while awaiting HTTP, since that converts upstream latency directly into database pool starvation.

A Python endpoint has an 800 ms deadline and calls 3 dependencies sequentially: how do you assign end-to-end timeout and retry budgets without exceeding the caller's limit?

I propagate one absolute 800 ms deadline and make every dependency consume a documented slice of the remaining time rather than starting its own independent clock. - I allocate 80 ms to authentication, 180 ms to inventory, 220 ms to pricing, 120 ms to application and database work, 100 ms to network and serialization, and keep 100 ms as tail-latency reserve. - Only the idempotent pricing GET receives 1 retry inside its 220 ms slice: 90 ms for attempt 1, up to 20 ms of jittered backoff, and 90 ms for attempt 2. - An httpx wrapper reads the remaining deadline from a context variable and sets connect, pool, read, and total timeouts to the smaller of that remainder and the dependency cap. - A shared retry token bucket limits retries to 5 percent of original traffic, while non-idempotent writes need an idempotency key before any automatic retry is allowed.

A third-party API permits 600 requests per second with bursts to 1,200 across 40 Python pods, while interactive requests expire after 500 ms: design the fleet-wide limiter.

I enforce the provider's 600 RPS token bucket in Redis and lease small token batches to pods so autoscaling cannot multiply the limit. - One Lua script refills the global bucket from Redis server time, caps it at 1,200 tokens, and atomically leases at most 10 tokens to a pod for 100 ms. - Interactive traffic receives 80 percent of newly available tokens, batch receives 20 percent, and either class may borrow unused capacity so reservation does not waste throughput. - With a 200 ms upstream p95, the fleet needs about 120 concurrent calls at 600 RPS, so each pod starts with a 5-slot semaphore and a queue that drops any item unable to start before its 500 ms deadline. - A 429 with Retry-After freezes new leases for that interval; if Redis is unavailable, pods spend only unexpired leases and then fail closed instead of violating the third-party contract.

Design a Python Kafka consumer for 24,000 messages per second over 96 partitions when each handler takes 20 ms, per-key order must hold, and offsets may be committed every 500 ms.

I preserve order per key with bounded partition-local lanes and commit only the highest contiguous offset whose work has completed. - I run 24 consumer processes with 4 partitions each; every partition hashes keys into 8 sequential asyncio queues, giving 32 handler tasks per process and about 400 messages per second of capacity per partition. - A completion bitmap tracks out-of-order finishes, but the committer advances only across a gap-free prefix every 500 ms, so a slow key cannot cause later unfinished records to be acknowledged. - When any partition queue reaches 1,000 records I pause that partition and resume below 500, while the poll loop continues servicing heartbeats so processing pressure does not trigger a rebalance. - On partition revocation I stop dispatching, allow 10 seconds for lanes to drain, commit the contiguous prefix, and let unfinished records return to idempotent database upserts after reassignment.

A Python batch must process 300 million rows in 6 hours and resume after a restart with less than 2 minutes of repeated work: how do you structure it?

I turn the 6-hour run into durably leased, idempotent chunks whose maximum runtime stays below the 2-minute replay budget. - At the required 13,900 rows per second, I start with 500,000-row primary-key ranges that take about 36 seconds, producing roughly 600 independently restartable chunks. - A job_chunks table stores range, input snapshot, status, attempt, and output checksum; workers claim rows with SKIP LOCKED under a 5-minute lease and heartbeat every 30 seconds. - Each chunk writes through an idempotent upsert and marks itself complete in the same database transaction, so a restart may repeat computation but never duplicate the visible result. - I freeze a high-water mark at job start and reduce worker concurrency when database p95 exceeds 100 ms, trading completion speed for controlled pressure on production traffic.

Design an ASGI WebSocket service for 50,000 concurrent connections, 2 KiB messages, a 200 ms delivery p99, and 8 GiB pods.

I spread 50,000 sockets across 10 pods capped at 5,000 connections each and make every per-connection buffer explicitly bounded. - A 64 KiB base budget per connection consumes about 320 MiB per pod; each socket gets an 8-message send queue, adding at most 16 KiB before the server closes a slow client with code 1013. - The ASGI connection scope supervises one reader and one writer inside a TaskGroup, explicitly cancelling the sibling when either exits so subscriptions, queue memory, and presence state are released. - Redis Pub/Sub is enough for ephemeral fan-out, while delivery that must resume uses Kafka or Redis Streams plus a cursor retained for 60 seconds; no pod-local registry is the sole source of routing truth. - Heartbeats run every 30 seconds, and a draining pod rejects new upgrades, gives clients 20 seconds to reconnect elsewhere, then closes remaining sockets with code 1012.

A Python SDK has 120 endpoints and must expose both sync and async APIs while keeping at least 95 percent of behavior in one implementation: how do you structure it?

I put protocol behavior in a transport-independent core and keep 2 thin I/O shells, rather than running an event loop behind the synchronous API. - Pure request builders, response parsers, pagination state, authentication, and the retry state machine are shared; the core returns the next action without calling a socket or sleep function. - The sync shell owns an httpx.Client and uses time.sleep, while the async shell owns an httpx.AsyncClient and uses anyio.sleep with cancellation; both expose explicit close methods and context managers. - The 120 endpoint methods are generated from one schema into separate typed facades, avoiding hand-maintained duplication while preserving native sync and async signatures. - I run the same 300 contract cases against both facades and add focused tests for thread safety and async cancellation, accepting a small duplicated transport loop to avoid asyncio.run and hidden worker threads.

Python Developer interview questions

100 real questions with model answers and explanations for Senior candidates.

See a Python Developer resume example →

Practice with flashcards

Spaced repetition · Hunter Pass

Questions

asyncpython

I would keep each event-loop callback or coroutine step under about 2 ms and move the 12 ms parse off the loop.

The loop runs ready callbacks, advances tasks until an awaited operation suspends, processes timers, and polls the selector, so one 12 ms step already breaks the 10 ms lag target for every socket.
I would split incremental parsing with explicit yield points only if state can be chunked cheaply; otherwise pure Python CPU work belongs in a ProcessPoolExecutor or a native parser, while blocking I/O belongs in asyncio.to_thread.
I would enable loop.set_debug, set loop.slow_callback_duration to 0.005, and schedule a monotonic 10 ms heartbeat to measure p95 and p99 loop lag.
Offloading must be bounded because submitting 10,000 parse jobs merely moves the queue, so I would cap in-flight jobs and reject or pause reads when that cap is reached.

Why interviewers ask this: The interviewer is evaluating whether the candidate can turn cooperative scheduling into a numerical blocking budget and choose the correct offload path.

asyncconcurrencypython

I would use asyncio for the network stage, a dedicated thread pool for the blocking SDK, and a process pool for the pure Python CPU stage.

At 1,000 items per second, the 40 ms network wait needs about 40 concurrent asyncio tasks, so I would start near 64 rather than create one thread per connection.
The SDK consumes about 20 thread-seconds per second; a 24 to 32 worker ThreadPoolExecutor gives modest headroom if the call spends its time blocked and releases the GIL.
The CPU stage demands 8 core-seconds per second, so I would start a ProcessPoolExecutor with about 10 workers, leaving six cores for the event loop, SDK threads, serialization, and the OS.
Bounded queues between all three stages expose saturation; if pickling the item dominates the 8 ms calculation, I would batch items or pass shared-memory references instead.

Why interviewers ask this: The interviewer checks whether the candidate maps measured wait and CPU time to a hybrid Python concurrency design instead of choosing one model for every stage.

concurrencypythongil

A 32-thread pool will stay near one core and roughly 25 transforms per second, so it cannot meet the 200-per-second target.

The GIL permits only one thread at a time to execute Python bytecode in one interpreter; more CPU threads add switching and lock overhead rather than eightfold parallelism.
Eight process workers have an ideal ceiling of 200 transforms per second because 8 divided by 0.040 equals 200, but that leaves no capacity for serialization, the OS, or latency variance.
I would use ProcessPoolExecutor for coarse tasks and either provide about 10 effective cores or reduce the transform below 32 ms to keep an 8-core host near 80 percent utilization.
Threads become viable only if the hot work moves into NumPy or another C extension that releases the GIL, which I would confirm with a 1, 8, and 32 thread benchmark.

Why interviewers ask this: The interviewer is testing quantitative GIL reasoning, including the difference between a theoretical process ceiling and sustainable capacity.

concurrencypythondecision-making

I would adopt a free-threaded build only after proving that the C extension is compatible and that 8 to 32 threads scale toward the 1,200-request target.

I would import the extension and check sys._is_gil_enabled; an extension that does not declare Py_MOD_GIL_NOT_USED through the Py_mod_gil slot can cause the interpreter to enable the GIL again.
The benchmark matrix would compare regular and free-threaded CPython at 1, 8, and 32 threads for throughput, p99 latency, RSS, and single-thread cost, because removing the GIL can trade parallel scaling for per-thread overhead.
I would audit shared Python caches and extension globals for races, add threading.Lock around compound mutations, and update C code to use supported critical-section APIs instead of relying on the GIL.
If the extension is unsafe or scaling flattens before 1,200 requests per second, regular CPython with process workers and shared read-only memory is the lower-risk design.

Why interviewers ask this: The interviewer checks whether the candidate treats free threading as a measured runtime and extension-compatibility decision rather than automatic multicore speedup.

databaseshardingasync

I would place the TaskGroup inside a 300 ms asyncio.timeout so a shard failure or the deadline cancels all owned sibling work.

A non-cancellation exception from one child makes TaskGroup cancel the other 11 tasks, wait for their cleanup, and then raise an ExceptionGroup instead of leaving detached tasks running.
Every shard coroutine must release its connection in finally and re-raise asyncio.CancelledError; swallowing cancellation can hold one of the four connections past the request lifetime.
I would keep the task handles created by group.create_task and read results only after the context exits successfully, so no partial response escapes by accident.
If one shard is explicitly optional, that child converts its own expected error into a typed fallback; catching errors outside the group would cancel healthy siblings before that policy is applied.

Why interviewers ask this: The interviewer is evaluating exact structured-cancellation semantics, resource cleanup, and the boundary between mandatory and optional child work.

asyncconcurrencydata-structures

The consumers sustain 4,000 messages per second, so I would bound the queue near 8,000 items for a two-second waiting budget rather than absorb the full burst.

An unbounded queue gains 1,000 messages per second and reaches 60,000 items, at least 120 MB of payload plus Python object overhead, while maxsize=8000 limits raw payload to about 16 MB.
Producers should await queue.put, and an external producer should get a fast rejection if asyncio.wait_for cannot enqueue within a defined limit such as 100 ms.
Each consumer calls task_done in finally, and shutdown awaits queue.join before cancelling the 20 consumers so accepted messages have explicit completion semantics.
I would publish queue depth, oldest-item age, put-wait time, and rejection count, because depth alone cannot distinguish large cheap bursts from work already missing its deadline.

Why interviewers ask this: The interviewer checks whether the candidate derives a queue bound from service rate and waiting budget and connects that bound to explicit overload behavior.

concurrencycaching

I would choose spawn for correctness and meet the three-second target by mapping the cache separately instead of forking the threaded parent.

Fork copies only the calling thread while inheriting locks, sockets, and file descriptors owned by the other 11 threads, so a child can wait forever on a lock whose owner no longer exists.
multiprocessing.get_context with spawn starts a clean interpreter; I would use a main guard and an initializer to create each child's clients, random state, and logging explicitly.
Sending 300 MB as a pool argument would pickle it eight times, so I would expose the cache through a read-only mmap or shared_memory segment that every spawned worker attaches to.
Fork is acceptable only if the pool is created from a deliberately single-threaded preloader before any background thread or network client starts, which is a narrower design than this scenario allows.

Why interviewers ask this: The interviewer is testing whether the candidate can reject unsafe fork inheritance while addressing spawn startup and data-transfer costs concretely.

concurrencynumpypython

I would keep one immutable 12 GB backing store and let all 16 workers map it rather than create up to 192 GB of private copies.

A versioned np.memmap file gives every spawned worker an ndarray view backed by the OS page cache; multiprocessing.shared_memory with np.ndarray(buffer=shm.buf) is suitable when the table must not live as a file.
On Linux, preloading before fork also exploits copy-on-write, but the parent must still be single-threaded and even accidental writes can dirty pages until memory approaches 12 GB per worker.
For the hourly refresh, I would build a new immutable version, atomically publish its name, let workers map it between requests, and remove the old mapping only after all users release it.
multiprocessing.Manager and Queue are wrong for random lookups at this size because each access crosses a proxy or serialization boundary; mutable deltas should live in a separate small store.

Why interviewers ask this: The interviewer checks whether the candidate can achieve one physical data copy while accounting for process start method, refreshes, and accidental copy-on-write costs.

asyncpythonapi

I would offload the step to a bounded process pool, but I would also add CPU capacity because the workload already demands 7.5 of eight cores before any overhead.

asyncio.to_thread is unsuitable for this pure Python work under the GIL; the request coroutine should await loop.run_in_executor with a ProcessPoolExecutor.
Eight ideal workers can complete only 320 jobs per second at 25 ms, so 300 requests per second leaves about 6 percent headroom and cannot support a stable 200 ms p99.
I would target roughly 70 percent CPU by using 12 cores with 10 process workers, or optimize the step to about 18 ms, while reserving capacity for the event loop and serialization.
A semaphore would cap submitted jobs near the worker count, a 50 ms admission timeout would reject excess work, and large request bodies would be reduced before crossing the pickle boundary.

Why interviewers ask this: The interviewer is evaluating both the correct async-to-process handoff and the recognition that offloading does not create missing CPU capacity.

asyncconcurrencyendpoints

I would use a dedicated 50-worker ThreadPoolExecutor with a matching concurrency gate, while acknowledging that the upstream limit leaves almost no throughput headroom.

Little's law gives 600 times 0.080, or 48 concurrent calls, and 50 threads provide a theoretical ceiling of 625 calls per second, only about 4 percent above demand.
The coroutine should acquire an asyncio.Semaphore before loop.run_in_executor, with about a 100 ms acquisition timeout so SDK time plus queueing can still fit inside the 250 ms endpoint budget.
A dedicated executor prevents 50 blocked SDK calls from starving DNS, file, or other default-executor work, and metrics should cover active threads, semaphore wait, SDK latency, and rejections.
This design assumes the SDK blocks on I/O and releases the GIL; if profiles show Python CPU work, threads will not scale, and if 600 calls per second is strict, the upstream cap must rise or requests must be shed.

Why interviewers ask this: The interviewer checks quantitative pool sizing, isolation from the default executor, bounded admission, and recognition of an unsustainably narrow capacity margin.

designwsgi-asgiframeworks

I size ASGI workers from a one-worker load test, then leave enough replica capacity to lose one pod without crossing the latency target.

If one Uvicorn worker sustains 600 RPS at 150 ms p99, I start with 6 workers per 8-vCPU pod and 4 pods: 24 event loops provide 14,400 RPS nominal capacity, while 3 surviving pods still provide 10,800 RPS.
Each worker owns one event loop and multiplexes I/O-bound requests across it; ASGI does not make JSON validation or other CPU work parallel, so 6 workers leave 2 cores for the kernel, sidecars, and burst headroom.
FastAPI lifespan creates one asyncpg pool and one httpx.AsyncClient per worker, so every pool limit is multiplied by 24 and must fit the database and upstream budgets.
I cap in-flight handlers at 200 per worker, bound the accept backlog, return 503 when admission is exhausted, and scale on CPU plus event-loop lag rather than letting unbounded tasks inflate p99.

Why interviewers ask this: The interviewer is evaluating quantitative ASGI capacity planning, process isolation, resource multiplication, and explicit backpressure rather than a one-worker-per-core rule quoted without measurement.

ormreplicationhttp

I use an async view for the concurrent HTTP work and cross into synchronous Django exactly once for the transactional ORM block.

The 2 HTTP calls run together through one reused httpx.AsyncClient, reducing their wall time from roughly 240 ms to 120 ms without occupying Django threads while sockets wait.
I put the complete 20 ms ORM transaction behind one sync_to_async call with thread-sensitive execution instead of alternating between sync and async for individual queries.
At 500 RPS per replica, the database step needs about 10 concurrent slots by Little's law, so I start with 16 bounded sync worker threads and no more than 16 database connections per replica.
The 2 outbound calls require about 120 concurrent slots per replica, so a 160-slot semaphore and a bounded deadline-aware queue apply backpressure before the HTTP pool saturates.

Why interviewers ask this: A strong answer minimizes costly boundary crossings, keeps transactional Django code synchronous, and derives thread and connection limits from measured residence time.

asynckubernetes

I reserve a 25-second application drain window inside the 30-second pod deadline and give every accepted task an explicit owner and cancellation path.

On SIGTERM the process immediately fails readiness and stops accepting new HTTP requests and upgrades, while Uvicorn receives up to 15 seconds to finish requests that were already accepted.
Background work lives in a TaskGroup or tracked task registry; durable jobs stop being claimed, in-flight jobs get 8 seconds to checkpoint, and disposable tasks are cancelled in dependency order.
Every coroutine handles CancelledError only to release its resource and then re-raises it, while finally blocks close asyncpg, httpx, Kafka, and telemetry clients before second 25.
At second 25 I cancel remaining tasks and exit, leaving 5 seconds for Kubernetes enforcement; work that cannot tolerate cancellation belongs in a durable queue, not an untracked create_task call.

Why interviewers ask this: The interviewer checks whether readiness, request draining, task ownership, cancellation, and resource cleanup form one timeline that fits the Kubernetes deadline.

asyncconcurrencypython

I divide dependency capacity across all 80 worker processes before choosing local pool sizes, because per-process defaults multiply across the fleet.

I reserve 100 PostgreSQL connections for migrations, administration, and other services, leaving 400 for the API, so each asyncpg pool starts at min_size 1 and max_size 5.
A request holds PostgreSQL for 15 ms on average, giving only 30 concurrent database users fleet-wide at 2,000 RPS, so 400 connections are a ceiling rather than a throughput target.
The HTTP call lasts 80 ms on average, giving 160 concurrent calls fleet-wide; max_connections 8 per httpx client allows a 640-call burst while remaining below the upstream limit of 1,000.
I set short acquisition deadlines, expose pool wait time, and never hold an asyncpg connection while awaiting HTTP, since that converts upstream latency directly into database pool starvation.

Why interviewers ask this: The interviewer wants fleet-wide pool arithmetic, Little's law, and awareness that an await in the wrong scope can pin a scarce connection.

resilienceendpointse2e

I propagate one absolute 800 ms deadline and make every dependency consume a documented slice of the remaining time rather than starting its own independent clock.

I allocate 80 ms to authentication, 180 ms to inventory, 220 ms to pricing, 120 ms to application and database work, 100 ms to network and serialization, and keep 100 ms as tail-latency reserve.
Only the idempotent pricing GET receives 1 retry inside its 220 ms slice: 90 ms for attempt 1, up to 20 ms of jittered backoff, and 90 ms for attempt 2.
An httpx wrapper reads the remaining deadline from a context variable and sets connect, pool, read, and total timeouts to the smaller of that remainder and the dependency cap.
A shared retry token bucket limits retries to 5 percent of original traffic, while non-idempotent writes need an idempotency key before any automatic retry is allowed.

Why interviewers ask this: This tests whether the candidate treats timeouts and retries as finite end-to-end budgets with concrete amplification controls instead of unrelated client settings.

designapidependencies

I enforce the provider's 600 RPS token bucket in Redis and lease small token batches to pods so autoscaling cannot multiply the limit.

One Lua script refills the global bucket from Redis server time, caps it at 1,200 tokens, and atomically leases at most 10 tokens to a pod for 100 ms.
Interactive traffic receives 80 percent of newly available tokens, batch receives 20 percent, and either class may borrow unused capacity so reservation does not waste throughput.
With a 200 ms upstream p95, the fleet needs about 120 concurrent calls at 600 RPS, so each pod starts with a 5-slot semaphore and a queue that drops any item unable to start before its 500 ms deadline.
A 429 with Retry-After freezes new leases for that interval; if Redis is unavailable, pods spend only unexpired leases and then fail closed instead of violating the third-party contract.

Why interviewers ask this: The interviewer is evaluating atomic fleet coordination, bounded local concurrency, deadline-aware backpressure, and the availability cost of honoring an external quota.

kafkadesignpartitioning

I preserve order per key with bounded partition-local lanes and commit only the highest contiguous offset whose work has completed.

I run 24 consumer processes with 4 partitions each; every partition hashes keys into 8 sequential asyncio queues, giving 32 handler tasks per process and about 400 messages per second of capacity per partition.
A completion bitmap tracks out-of-order finishes, but the committer advances only across a gap-free prefix every 500 ms, so a slow key cannot cause later unfinished records to be acknowledged.
When any partition queue reaches 1,000 records I pause that partition and resume below 500, while the poll loop continues servicing heartbeats so processing pressure does not trigger a rebalance.
On partition revocation I stop dispatching, allow 10 seconds for lanes to drain, commit the contiguous prefix, and let unfinished records return to idempotent database upserts after reassignment.

Why interviewers ask this: A strong answer connects partition assignment, task concurrency, ordering, contiguous commits, polling, and backpressure into one at-least-once design.

concurrencypythonbatch

I turn the 6-hour run into durably leased, idempotent chunks whose maximum runtime stays below the 2-minute replay budget.

At the required 13,900 rows per second, I start with 500,000-row primary-key ranges that take about 36 seconds, producing roughly 600 independently restartable chunks.
A job_chunks table stores range, input snapshot, status, attempt, and output checksum; workers claim rows with SKIP LOCKED under a 5-minute lease and heartbeat every 30 seconds.
Each chunk writes through an idempotent upsert and marks itself complete in the same database transaction, so a restart may repeat computation but never duplicate the visible result.
I freeze a high-water mark at job start and reduce worker concurrency when database p95 exceeds 100 ms, trading completion speed for controlled pressure on production traffic.

Why interviewers ask this: The interviewer checks for durable progress, stable partitioning, idempotent publication, bounded replay, and throttling rather than one long cursor and an in-memory offset.

designwsgi-asgiwebsockets

I spread 50,000 sockets across 10 pods capped at 5,000 connections each and make every per-connection buffer explicitly bounded.

A 64 KiB base budget per connection consumes about 320 MiB per pod; each socket gets an 8-message send queue, adding at most 16 KiB before the server closes a slow client with code 1013.
The ASGI connection scope supervises one reader and one writer inside a TaskGroup, explicitly cancelling the sibling when either exits so subscriptions, queue memory, and presence state are released.
Redis Pub/Sub is enough for ephemeral fan-out, while delivery that must resume uses Kafka or Redis Streams plus a cursor retained for 60 seconds; no pod-local registry is the sole source of routing truth.
Heartbeats run every 30 seconds, and a draining pod rejects new upgrades, gives clients 20 seconds to reconnect elsewhere, then closes remaining sockets with code 1012.

Why interviewers ask this: The interviewer is looking for per-socket memory arithmetic, ASGI task lifecycle, slow-consumer backpressure, cross-pod fan-out, and deploy-safe reconnection.

endpointsasyncpython

I put protocol behavior in a transport-independent core and keep 2 thin I/O shells, rather than running an event loop behind the synchronous API.

Pure request builders, response parsers, pagination state, authentication, and the retry state machine are shared; the core returns the next action without calling a socket or sleep function.
The sync shell owns an httpx.Client and uses time.sleep, while the async shell owns an httpx.AsyncClient and uses anyio.sleep with cancellation; both expose explicit close methods and context managers.
The 120 endpoint methods are generated from one schema into separate typed facades, avoiding hand-maintained duplication while preserving native sync and async signatures.
I run the same 300 contract cases against both facades and add focused tests for thread safety and async cancellation, accepting a small duplicated transport loop to avoid asyncio.run and hidden worker threads.

Why interviewers ask this: The interviewer checks for a practical sans-I/O core, native lifecycle semantics in both APIs, and an honest boundary between reusable protocol logic and necessarily different I/O orchestration.

Locked questions

21
A Python API serves 2,000 requests per second at 75 percent CPU, and p99 latency is 180 ms against a 120 ms target. How would you profile it with py-spy under live load?
latencyprofilingapi
22
A deterministic Python batch job processes 10 million records in 22 minutes and must finish within 12 minutes. How would you use cProfile to find and verify the optimization?
optimizationprofilingconcurrency
23
A numerical transform over 50 million float64 values takes 42 seconds in a Python loop, but the container has a 3 GB memory limit. How would you vectorize it without losing the gain to NumPy temporary arrays?
pandasnumpypython
24
A pure-Python parser handles 5 million records in 70 seconds, with 80 percent of samples in one loop, and the target is 15 seconds. How do you choose among Cython, a CPython C extension, and Rust with PyO3?
nativepython
25
A Python API handles 20,000 responses per second with 4 KB payloads, and serialization consumes 30 percent of CPU. How would you choose among stdlib json, orjson, msgspec, and pickle?
serializationapipython
26
Twelve Gunicorn pods with eight workers each serve 5,000 read requests per second for 20 KB objects that cost 40 ms to compute and may be stale for at most 5 seconds. Would you use a per-process cache or Redis?
rediscachingconcurrency
27
An endpoint ranks 100,000 products at 300 requests per second, takes 900 ms, and must reach 200 ms. In what order would you optimize the hot path?
optimizationendpoints
28
A Python CLI takes 1.4 seconds to show help, and the same package gives a serverless function a 1.9-second cold start. How would you reduce import-time startup?
python
29
A Python gateway parses a 2 GB stream into 64 KB frames at 450 MB/s, and profiles show four byte copies per frame. How would you apply memoryview and the buffer protocol to reach 1 GB/s?
pythontypinggateway
30
A SQLAlchemy endpoint returns 500 orders with an average of three lines each, issues 501 SQL statements, and takes 1.6 seconds against a 200 ms target. How would you remove the N+1 cost without creating a row explosion?
sqln+1orm
31
A 5 GB CSV expands to 40 GB in a Python job that has an 8 GB memory limit. How would you redesign the load?
memorypython
32
A long-lived Python worker gains about 300 MB of RSS every hour while processing a stable workload. How would you determine whether live objects are accumulating?
concurrencypython
33
You must hold 8 million small coordinate objects in memory. When would you use __slots__, and when would you choose a different representation?
memoryslots
34
A job must transform 20 million database rows on a 512 MB container. How would you structure generators and chunked streaming?
databasecontainersstreaming
35
A graph processor creates 2 million nodes with parent and child links, and memory is not released promptly after each 6 GB batch. How would you handle cycles, weak references, and finalization?
batchmemoryconcurrency
36
How would you migrate a 500,000-line untyped Python codebase with 18,000 initial mypy errors toward strict checking without freezing feature delivery?
pythontyping
37
A service loads 120 plugins, including third-party implementations you cannot modify. Would you define the plugin contract with Protocol or ABC?
dependenciestyping
38
You have 80 decorated endpoints and repositories for 12 model types. How would TypeVar and ParamSpec keep these abstractions precise?
ooptypingendpoints
39
A Python service receives 20,000 JSON events per second and has a framework-independent domain core. Where would you use Pydantic, dataclasses, and TypedDict?
pythondataclassestyping
40
An untyped payment SDK is imported directly in 60 modules and causes Any to spread through strict mypy code. How would you contain it?
spreadtyping
41
An internal SDK used by 18 services needs one fetch_invoice API with 2 modes: raw returns bytes and parsed returns Invoice. How would you type that public API without making callers cast the result?
api
42
A strict-mypy service receives 25,000 partner JSON messages per minute, reads rows written by 3 schema versions, and calls fully typed internal functions. Where do you still validate at runtime?
schemavalidationtyping
43
A checkout model has 4 status strings and 7 Optional fields, so code can construct a captured payment with no provider reference or ship an unpaid order. How would you redesign the types?
44
A FastAPI service has 9 external dependencies and 120 unit tests now dominated by monkeypatching module globals. How would you rewire it without adopting a DI container?
unitcontainersdependencies
45
A batch worker may open between 1 and 24 input streams plus 8 temporary output files, and cancellation must close every acquired resource within 2 seconds. Which Python lifecycle idiom would you use?
batchresiliencepython
46
A checkout supports Stripe, Adyen, and one local bank, each with 3 different request shapes, while the domain needs authorize, capture, and refund. How would you apply Strategy and Adapter without building a framework?
47
A monorepo contains 12 independently deployed Python services and 5 shared packages, and dependency resolution currently produces different environments on developer laptops and CI. How would you structure pyproject files and uv locking?
deploymentmonorepodependencies
48
An internal library at version 1.7 is imported by 15 services, and a method must change from returning None to returning a Receipt. What SemVer and deprecation sequence would you use over the next 90 days?
49
A Python package needs a pure core, 3 optional features named postgres, s3, and fast, and support for CPython 3.11 through 3.13 on 5 OS-architecture targets. How would you package and test it?
postgresarchitecturepython
50
Eight developers, 3 CI jobs, and 6 production images currently resolve different dependencies across Python 3.11 and 3.12. How would you make virtual environments and interpreter constraints reproducible?
dependenciesvenvpython
51
A FastAPI pod's RSS rises from 420 MB to 1.50 GB in 5 hours at steady traffic, while tracemalloc grows by 1.03 GB and objgraph reports 180,000 retained Response objects. What do you do during the incident?
incidentsframeworksmemory
52
A Pillow thumbnail worker handles 10,000 images/hour, and RSS climbs from 380 MB to 1.82 GB in 6 hours, but tracemalloc adds only 12 MB and objgraph counts stay within 1%. How do you isolate and fix it?
memory
53
An eight-job NumPy batch spike raises a worker from 620 MB to 3.6 GB RSS; after completion tracemalloc falls from 2.9 GB to 410 MB and objgraph returns within 2%, yet RSS remains at 3.2 GB. Is this a leak, and what do you change?
batchnumpymemory
54
After adding a pure-Python JSON canonicalizer, an 8-vCPU service drops from 1,800 to 410 requests/second, p99 rises from 90 to 760 ms, and its 32-thread process uses only 115% CPU. How do you respond?
concurrencypython
55
A fraud endpoint starts receiving 200 KB payloads, CPU rises from 35% to 96%, throughput falls from 720 to 190 requests/second, and py-spy shows 64% of samples in a nested-list duplicate check. What is your production fix?
throughputprofilingendpoints
56
An asyncio API at 450 requests/second suddenly shows 1.8-second event-loop lag, 620 runnable tasks, 18% CPU, and p99 of 2.4 seconds after a release added an S3 metadata check. How do you restore service?
asyncapiaws
57
A websocket service remains healthy at 12% CPU but stops delivering messages: 214 tasks have been pending for over 60 seconds, and task dumps split between lock_a.acquire and lock_b.acquire after a reconnect deploy. How do you resolve it?
deploymentwebsockets
58
An asyncio notification worker's pending-task count grows by 900/hour and RSS by 95 MB/hour; 7,400 tasks are waiting in an HTTP client after 8 hours, although completed-job volume is flat. What do you change?
asynchttp
59
After a response-model change, a FastAPI endpoint's p99 rises from 170 to 930 ms at 600 requests/second, CPU climbs from 48% to 84%, and database spans remain below 20 ms. How do you use live profiling to fix it?
databaseendpointsprofiling
60
A new search filter moves endpoint p99 from 240 ms to 4.8 seconds while median stays at 85 ms and average CPU remains 42%; only 1.3% of requests contain descriptions longer than 30 KB. How do you diagnose and contain it live?
endpoints
61
A Python 3.11 service directly pins starlette==0.36.3, while FastAPI 0.115.0 requires Starlette >=0.37.2,<0.42.0. The resolver rejects the build, but 18 production pods need a security fix within 4 hours. What should you do?
frameworkspython
62
Release 2026.07.12 rebuilt a Python 3.11.9 service after a lock update changed 47 packages, including Pydantic 2.8.2 to 2.10.4, and validation failures rose from 0.2% to 6.4% across 30 instances. What is your response?
pythonvalidation
63
After upgrading HTTPX 0.27.2 to 0.28.1, p95 latency on a Python 3.12 API rises from 180 ms to 510 ms at 900 requests per second, while CPU stays at 42% and outbound connections triple from 120 to 365. How do you decide the fix?
latencyapipython
64
Version 3.6.0 passes 412 tests from the repository, but its wheel deployed to 24 workers raises ModuleNotFoundError for billing.rules because the package directory was omitted; version 3.5.9 works. What should the release owner change?
deploymentpackagingmodules
65
A C extension wheel for fastcodec 1.9.0 is tagged manylinux_2_28_x86_64 and works with glibc 2.35, but 60 Amazon Linux 2 hosts with glibc 2.26 reject it and fall back to a 14-minute source build. What is the safe remediation?
packaging
66
Developers lock dependencies on Python 3.12.4, where async-cache 5.1 selects speedups 2.0 requiring Python >=3.12, but production runs Python 3.11.9 on 40 containers and fails during installation. How should the team resolve the mismatch?
containersdependenciesasync
67
A fresh build of 37 services warns that telemetry-core 4.2.1 is yanked for a data-loss bug, but an exact shared constraint still forces it; 4.2.2 is available and the resolver succeeds when the constraint is removed. What should you do?
68
Internal wheel authcrypto 2.6.0 was built on glibc 2.39 with OpenSSL 3.2, then deployed to 16 Debian 11 hosts using glibc 2.31 and OpenSSL 1.1.1; all workers fail with an undefined SSL symbol on Python 3.11.8. What is the correct recovery?
fundamentalspythondeployment
69
Image 2026.7.4 upgrades NumPy 1.26.4 to 2.0.1 and causes 31% of 80 analytics workers to crash in a compiled plugin, while queued jobs grow from 2,000 to 19,000 in 12 minutes. Which rollback and follow-up are appropriate?
data-structuresnumpyrollback
70
The same commit resolves to 126 packages on a Python 3.12.3 laptop, 129 packages in CI on Python 3.12.5, and 127 packages during deployment because 2 private indexes expose different builds of parserkit 7.4.0. How do you produce a reproducible fix?
reproducibilityindexesdeployment
71
A Python API has a database budget of 40 connections and 12 request-consumer tasks with 20 concurrent requests each. During a traffic spike, pool checkout p95 rises from 8 ms to 4.5 s, 37 connections remain in transaction, and database CPU stays at 42%. What happened, how do you prove the cause, and what are your safe mitigation, durable fix, and verification gate?
databasetransactionsconcurrency
72
An upstream starts returning HTTP 503 for 30 seconds, but your Python service increases outbound traffic from 800 to 4,800 requests per second because 16 instances retry up to 5 times with fixed 100 ms delays. What happened, and what evidence, mitigation, durable fix, and numeric gate do you require?
resiliencehttppython
73
A Celery queue processes 50,000 payment jobs; after a worker outage, 620 jobs run twice and 140 accepted jobs never produce a result. Workers use late acknowledgments, a 60-second visibility timeout, and tasks can run for 180 seconds. How do you diagnose and contain this incident, then prevent recurrence and verify the fix?
resiliencetask-queuesconcurrency
74
A Python Kafka consumer group with 8 members rebalances 23 times in 10 minutes after processing rises to 70 seconds; max.poll.interval.ms is 60,000, offsets are committed before database writes, and an audit finds 310 missing rows plus 480 duplicates. What failed, and how do you prove, mitigate, fix, and gate it?
concurrencypythondatabase
75
A Django endpoint times out after 30 seconds, 65 database sessions wait on row locks, and the blocker has held a transaction for 95 seconds while making a 90-second HTTP call inside transaction.atomic. Database CPU is 35%. What response demonstrates senior judgment?
databasetransactionshttp
76
An asyncio service times out 2,000 requests per minute after 3 seconds; open sockets climb from 300 to 12,000 in 20 minutes, 1,700 tasks remain pending, and the process hits its 16,384 file descriptor limit because an except BaseException block suppresses cancellation. What happened and what do you do?
asyncconcurrencydescriptors
77
A Python service runs 8 process workers with 32 threads each on an 8-core host. At 1,600 requests per second, run queue reaches 70, context switches triple, CPU is 98%, p99 latency is 12 seconds, and throughput falls to 900 requests per second. How do you handle and verify this saturation incident?
concurrencydata-structurespython
78
A cached object with a 10-minute TTL expires at noon; 400 Python workers miss it within 2 seconds, database reads jump from 200 to 18,000 per second, and p95 latency reaches 9 seconds. What happened, how do you prove it, and what mitigation, fix, and gate are safe?
cachinglatencydatabase
79
After 20% of producers deploy schema version 4, Python consumers reject 7,500 of 100,000 messages because status changed from a string to an object and a required field was renamed. The dead-letter queue is growing by 250 messages per minute. What is your incident plan and release gate?
data-structurespythonschema
80
During a deployment, Kubernetes sends SIGTERM with a 30-second grace period to 20 Python workers. Each worker has 40 in-memory jobs, stops after 30 seconds, and 260 of 800 jobs disappear because acknowledgment occurs before processing. How do you respond and prevent another shutdown loss?
kubernetesdeploymentconcurrency
81
After upgrading 24 workers from Python 3.10 to 3.11, 0.7% of messages fail with ValueError because 12,000-digit decimal identifiers are converted to int. How do you diagnose and fix this without weakening the service globally?
python
82
A service processes 25,000 payment callbacks per minute; mypy accepts a cast from response.json() to PaymentEvent TypedDict, but 1.8% fail with KeyError when the provider sends another shape. What should you change?
concurrencycallbackstyping
83
A Python billing job assigns 340 of 2 million payments to the wrong business day and differs from the ledger by one cent on 1,120 rows. Timestamps have 4 different offsets and amounts arrive as decimal strings. How do you repair and verify correctness?
python
84
A release is blocked because 14 of 600 pytest async tests fail only in the full suite about once per 20 runs, usually with a pending-task warning or timeout. How do you investigate without adding retries?
pytestasyncresilience
85
During a security incident, you discover that 6 Python instances called pickle.loads on 12,400 customer-uploaded files over 30 days. What immediate and permanent actions do you take?
incidentspython
86
At 2,200 requests per second, a Python API's p99 rises from 180 ms to 1.4 seconds after user_id and raw paths expand metrics from 80,000 to 4.2 million series, while synchronous JSON logs queue 50,000 records. How do you restore observability without blocking requests?
observabilitymonitoringdata-structures
87
A 5% canary of a new Python image moves p99 from 220 to 680 ms and event-loop lag from 12 to 190 ms at the same 900 requests per second, but errors stay at 0.1%. What do you do before continuing the rollout?
deployment-strategiespython
88
Checkout errors rise from 0.2% to 14% across 36 Python pods for 7 minutes after a release, and an engineer proposes editing a one-line None guard in a running container instead of rolling back. How do you choose between rollback and hotfix?
containersrollbackpython
89
A migration makes customer.timezone non-null on an 80-million-row table while 24 old and 24 new Python workers run together, and old workers neither read nor write the field. How should the migration and runtime rollout be redesigned?
fundamentalspythonmigrations
90
Production CPU reaches 100%, the request queue grows from 300 to 18,000 in 10 minutes across 40 Python workers, but restarting all workers would erase evidence and risk a larger outage. How do you debug the live system safely?
data-structurespythonsystem-design
91
A mid-level engineer investigates a Python worker whose RSS grows by 1.2 GB over 6 hours and patches it by calling gc.collect() every 30 seconds, but an unbounded result cache still holds about 900,000 entries. What do you ask them to do next, and how do you verify the fix without taking the investigation away from them?
cachingpython
92
After a change to an asyncio endpoint, p95 latency rises from 80 ms to 1,900 ms; the handler calls time.sleep(0.2) and makes 3 requests.get calls that each take about 400 ms. How do you mentor the author through a correction and verify that the event loop is no longer blocked?
asyncevent-loopendpoints
93
A mid-level engineer built a validation layer with 3 metaclasses, generated descriptors, and dynamic method injection; adding 1 field now takes about 40 minutes and type checkers expose almost no useful signatures. How do you challenge the design, preserve their ownership, and verify a simpler replacement?
injectionvalidationdescriptors
94
A mid-level engineer opens a 2,400-line PR across 18 files for a billing reconciliation change due in 2 days and says tests would make the deadline impossible. What do you do, and how do you verify delivery without taking the PR over?
estimationreacttesting
95
An engineer reports a 35% parser speedup from 3 runs lasting about 200 ms each, with no warmup, CPU turbo enabled, and a 10 KB fixture although production inputs are near 10 MB. How do you correct the benchmark and let them validate the claim?
validationfixtures
96
During a strict typing migration of a 12,000-line package, a mid-level engineer adds 600 Any annotations and 45 type: ignore suppressions, then introduces 2 runtime import cycles by importing classes only needed for annotations. What do you ask them to change, and how do you verify progress without owning the migration yourself?
migrations
97
A dependency upgrade from cryptography 41 to 44 addresses a CVSS 9.1 advisory but breaks an internal wrapper and 27 tests; one engineer wants an immediate upgrade while another wants to pin version 41 for 6 months. How do you resolve the technical dispute, preserve ownership, and verify the chosen path within 48 hours?
ownershipdependenciestesting
98
A serializer change deployed by a mid-level engineer raises API errors from 0.2% to 18% for 11 minutes, and the engineer says the reviewer approved it. What do you do during and after the incident so they retain ownership while service is restored and the fix is verified?
incidentsownershipapi
99
In a PR review, you tell a mid-level engineer to add an asyncio.Lock around a 2-statement dictionary sequence update, but they point out that the code runs on 1 event-loop thread and contains no await between read and write. The service handles 10,000 concurrent coroutines. How do you correct the review, preserve their ownership, and verify the concurrency claim?
asyncconcurrencyownership
100
A mid-level engineer estimates 8 days to build a Python import pipeline for 1,000,000 rows with retry safety, progress reporting, and resumability, but the business deadline is 3 days. How do you negotiate scope, keep the engineer responsible for the estimate, and verify a defensible delivery?
estimationresiliencepython

Questions

1An asyncio service holds 10,000 sockets, must keep event-loop lag below 10 ms, and now parses each message for 12 ms in pure Python before the next await; how would you budget and schedule that work?

2A 16-core pipeline must handle 1,000 items per second, with 40 ms of async network waiting, 20 ms in a synchronous SDK, and 8 ms of pure Python CPU work per item; which concurrency models would you combine?

3On an 8-core host, a pure Python transform takes 40 ms and must run 200 times per second; what throughput would a 32-thread pool provide under the GIL, and what would you change?

4A 32-core service spends 70 percent of its 20 ms CPU time in Python and 30 percent in a C extension, and it must grow from 400 to 1,200 requests per second; how would you evaluate free-threaded CPython?

5A request fans out to 12 shards with a 300 ms deadline, one shard raises after 80 ms, and four sibling tasks hold database connections; how should asyncio.TaskGroup handle the work?

6An async producer emits 5,000 messages per second for a 60-second burst, 20 consumers each process one message in 5 ms, and every message is 2 KB; how would you size asyncio.Queue and apply backpressure?

7A Linux process already has 12 native threads and a 300 MB cache when it launches eight CPU workers, and worker startup must stay under 3 seconds; would you use multiprocessing fork or spawn?

8Sixteen Python worker processes on a 64 GB host need random read access to the same 12 GB NumPy lookup table, refreshed once per hour, and must start within 10 seconds; how would you share the state?

9An asyncio API receives 300 requests per second, each request includes 25 ms of pure Python CPU work, the host has eight cores, and p99 must stay below 200 ms; how would you offload and capacity-plan the step?

10An async API must make 600 calls per second through a blocking SDK that takes 80 ms, the upstream permits 50 concurrent calls, and the endpoint p95 budget is 250 ms; how would you size and isolate its thread pool?

11Design a FastAPI service for 8,000 JSON requests per second with a 150 ms p99 target on 8-vCPU Kubernetes pods: how many ASGI workers and replicas do you start with?

12A Django endpoint receives 4,000 RPS across 8 replicas, spends 20 ms in the synchronous ORM, and makes 2 independent 120 ms HTTP calls: where do you place the sync and async boundary?

13How would you shut down an asyncio service in Kubernetes when terminationGracePeriodSeconds is 30, requests may run for 10 seconds, and each pod owns 200 background tasks?

14An async Python API handles 2,000 RPS on 20 pods with 4 workers each, while PostgreSQL allows 500 connections and an HTTP dependency allows 1,000 concurrent requests: how do you budget asyncpg and httpx pools?

15A Python endpoint has an 800 ms deadline and calls 3 dependencies sequentially: how do you assign end-to-end timeout and retry budgets without exceeding the caller's limit?

16A third-party API permits 600 requests per second with bursts to 1,200 across 40 Python pods, while interactive requests expire after 500 ms: design the fleet-wide limiter.

17Design a Python Kafka consumer for 24,000 messages per second over 96 partitions when each handler takes 20 ms, per-key order must hold, and offsets may be committed every 500 ms.

18A Python batch must process 300 million rows in 6 hours and resume after a restart with less than 2 minutes of repeated work: how do you structure it?

19Design an ASGI WebSocket service for 50,000 concurrent connections, 2 KiB messages, a 200 ms delivery p99, and 8 GiB pods.

20A Python SDK has 120 endpoints and must expose both sync and async APIs while keeping at least 95 percent of behavior in one implementation: how do you structure it?

Locked questions