Python Backend Developer Top 100 Interview Questions

On a termination signal, stop taking new work, finish or hand back the work already in progress within a deadline, release resources, and then exit. A hard kill drops requests mid-way and can leave jobs half-done.

flowchart TD
  A["Termination signal received"] --> B["Stop accepting new connections"]
  B --> C["Fail readiness check so traffic stops"]
  C --> D["Finish in-flight requests within a deadline"]
  D --> E{"Work left at deadline?"}
  E -->|yes| F["Cancel it and requeue jobs"]
  E -->|no| G["Close pools and flush logs"]
  F --> G
  G --> H["Exit with success code"]

Details that matter:

• Install a handler for the termination signal; in asyncio, loop.add_signal_handler on POSIX systems, or let the server framework handle it.
• Keep the drain deadline shorter than the platform's grace period, which is often 30 seconds, so cleanup finishes before a forced kill.
• Background workers should stop pulling jobs, finish the current one, and leave unfinished jobs on the queue to be retried.
• Close database pools and flush buffered logs and metrics last, so shutdown problems are still recorded.

Measure first where the time goes, between Python code, the database and other services, then profile the part that dominates. Guessing usually optimizes the wrong thing.

1. Time the stages: add timing or tracing around the handler, each query and each external call, and compare them for slow requests.
2. Check the database: count queries per request and review slow query logs; repeated or unindexed queries are the most common cause.
3. Profile Python code: run the handler under the standard cProfile module and sort by cumulative time to find the expensive functions.
4. Sample in production: sampling profilers attach to a running process with low overhead, which shows real behavior under real data.
5. Check memory and garbage collection: many short-lived objects increase collection pauses.

Reading a profile:

• Cumulative time shows which call chains are expensive overall.
• Own time shows where the CPU is actually spent.
• High call counts often reveal work done inside a loop that could happen once.

Re-measure after each change with the same input. Endpoint latency should be compared at the 95th or 99th percentile, not only the average.

Confirm that memory really grows without bound, then compare allocation snapshots over time to see which code is allocating the objects that never get freed. Restarting the worker hides the problem but does not fix it.

1. Confirm the trend: plot memory over hours under steady traffic. A rise that levels off may be normal caching; steady growth is a leak.
2. Snapshot allocations: start tracemalloc, take a snapshot, process traffic, take another, and compare them grouped by line. The top lines show where growing memory was allocated.
3. Count objects: count live objects by type with the gc module and watch which types keep increasing.
4. Check usual suspects: unbounded caches, module-level lists or dictionaries, callbacks never unregistered, and stored exceptions keeping large frames alive.
5. Fix and verify: bound the cache, release references or clear the collection, then rerun the same test and confirm memory now stays flat.

As a safety net, worker supervisors can restart a worker after a set number of requests, but keep that as protection, not as the fix.

Both are first-in, first-out queues with optional size limits, but queue.Queue is built for threads, while asyncio.Queue is built for tasks on one event loop. Using the wrong one either blocks the loop or causes race conditions.

Crossing between threads and the event loop:

• From a worker thread, hand items to the loop with loop.call_soon_threadsafe(queue.put_nowait, item).
• From async code, read a thread queue with await asyncio.to_thread(thread_queue.get), which waits without blocking the loop.

Shared good practices:

• Set a maximum size so a slow consumer creates backpressure instead of unbounded memory growth.
• Use task_done and join to know when all queued work has finished.
• For work that must survive restarts or be shared between processes, use a durable external queue instead.

Use the bridge that matches the direction and never start a second event loop inside a running one. Mixing the two models carelessly causes errors such as "event loop is already running", or silently blocks the loop.

Design advice:

• Keep one direction of dependency: an async core that calls sync helpers through threads, or a sync app that calls async code only at clear edges.
• Avoid libraries that hide a call to asyncio.run inside functions, since they break when called from async code.
• Test both paths, because a bridge that works in a script can fail once the same code runs inside an async server.

Every request waiting on the slow dependency occupies a worker, thread or connection for the whole wait. When that dependency slows down, all of the service's capacity fills with waiting requests, and even endpoints that never call it stop responding.

How to prevent it:

1. Timeouts on every call: a waiting request gives up its slot after a short, deliberate limit.
2. Bulkheads: give each dependency its own small connection pool or concurrency limit, so one cannot take every slot.
3. Circuit breakers: after repeated failures, fail fast for a while instead of waiting each time.
4. Fallbacks: serve cached data or a degraded response where the business allows it.
5. Load shedding: reject excess requests early with a clear error rather than queueing them until they time out.
6. Async I/O: waiting tasks are much cheaper than waiting threads, which raises the ceiling, though it does not remove the need for timeouts.

Decide first whether the job may run in every instance or must run exactly once across the fleet. That choice, not the timer, is the hard part.

• Per-instance work: refreshing a local cache or flushing local metrics can run in each process, with a simple async loop that sleeps between runs or a timer thread.
• Fleet-wide work: sending a daily report must run once. If every replica schedules it, it runs once per replica. Use an external scheduler that starts one job, or have instances compete for a lock or lease so only one runs it.

Make jobs robust:

1. Idempotent: running twice by accident must not send two reports or double-charge anyone.
2. Recorded: store the last successful run so a missed run can be detected and caught up.
3. Bounded: give each run a timeout, and prevent overlapping runs when one takes longer than the interval.
4. Time-zone aware: "every day at 9" needs a time zone and a decision about daylight-saving changes.
5. Observed: alert when a job fails or has not succeeded within its expected window.

The web process puts a small message describing the job onto a queue, and separate worker processes take messages off, run the job and acknowledge it. This keeps slow work, such as sending emails or generating reports, off the request path.

flowchart LR
  A["Web request"] -->|enqueue job id| B["Message queue"]
  B --> C["Worker process"]
  C --> D{"Job succeeded?"}
  D -->|yes| E["Acknowledge and remove"]
  D -->|no| F{"Retries left?"}
  F -->|yes| G["Requeue with backoff"]
  F -->|no| H["Dead-letter queue and alert"]
  G --> B

Delivery is usually at least once: if a worker crashes after doing the work but before acknowledging it, the job runs again.

What makes a task safe to retry:

• Idempotency: the task checks whether its effect already happened, using a unique key or a status column, before acting.
• Small messages: send an ID and load fresh data in the worker, instead of a stale copy of the record.
• Bounded retries with backoff for temporary errors only, and a dead-letter queue for the rest.
• Time limits so a stuck job is killed and retried rather than blocking a worker forever.

A token bucket holds up to a fixed number of tokens and refills at a steady rate. Each request spends a token, and a request that finds the bucket empty is rejected or delayed. This allows short bursts while keeping the long-run average rate under control.

Key design points:

• Lazy refill: instead of a background timer, compute how many tokens accumulated since the last check, capped at the capacity.
• Inject the clock: pass the time source in, so tests can control time precisely.
• One bucket per key: keep a dictionary of buckets per client or API key, and evict idle ones to bound memory.
• Thread or task safety: guard each bucket with a lock if multiple threads share it.

Across many processes: an in-memory bucket limits only one process. For a fleet-wide limit, store the bucket state in a shared store and update it atomically, or give each instance its share of the total rate.

Return HTTP status 429 with a header telling the client when to retry, so well-behaved clients slow down.

Produce the response in chunks with a generator or async generator, and let the server send each chunk as it is ready. Memory then stays proportional to one chunk, not to the whole export.

• Generators as bodies: most Python web frameworks accept an iterator or async iterator as the response body and send it using chunked transfer encoding.
• Database side: fetch rows in batches with fetchmany, or use a server-side cursor, so the database driver does not load every row first.
• Backpressure: with async servers, each chunk is sent before the next is produced, so a slow client slows the producer instead of filling memory.
• Client disconnects: stop producing when the client goes away, and close cursors and files in a finally block.

Things to decide up front:

• Headers are sent first, so errors found midway cannot change the status code; validate inputs before streaming begins.
• Set a content type and, for downloads, a filename header.
• For very large exports, generating a file in the background and returning a download link is often more reliable than a long-lived response.

The request passes through a reverse proxy and an application server before Python code sees it, then through middleware and routing to a handler, and the response travels back the same way.

flowchart LR
  A["Client"] --> B["Reverse proxy"]
  B --> C["Application server worker"]
  C --> D["Server interface call"]
  D --> E["Middleware chain"]
  E --> F["Router"]
  F --> G["Handler and services"]
  G --> H["Database and other services"]
  G --> I["Serialized response"]

1. Proxy: terminates TLS, applies size limits and buffers slow clients.
2. Application server: parses the HTTP request in a worker and calls the app through a standard interface, synchronous or asynchronous.
3. Middleware: cross-cutting steps such as request IDs, authentication, compression and error handling run in order.
4. Routing: the URL and method select a handler, and path parameters are extracted.
5. Handler: validates input, calls business services and builds a response.
6. Response: middleware runs in reverse, and the server sends the bytes back.

Knowing this path tells you where each concern belongs and where time can be lost, such as slow clients, middleware work or database calls.

Middleware wraps every request and response with shared behavior, so individual handlers do not repeat it. Each layer receives the request, can act on it or stop it, calls the next layer, and can then act on the response.

Common middleware:

• Request IDs and structured access logging.
• Authentication and loading the current user.
• Error handling that turns exceptions into consistent responses.
• Compression, security headers, CORS headers and timing metrics.

Why order matters: layers run outermost first on the way in and outermost last on the way out, like nested function calls.

• Put logging and error handling outermost, so even rejected or failing requests are logged and formatted.
• Put authentication before anything that needs the user, such as permission checks.
• Put compression late on the way out, after the body is final.
• A layer that returns early, such as authentication rejecting a request, skips every inner layer and the handler.

Keep middleware cheap and generic. Logic that applies to only a few endpoints belongs in those handlers or in a decorator.

Treat every request field as untrusted, convert it into a typed internal object at the boundary, and reject anything that does not fit before business logic runs. After that point, the rest of the code can trust the data.

• Schema: define required fields, types, formats, ranges and lengths in one place, usually a typed model or a validation function.
• Reject unknown fields: silently ignoring them hides client bugs, and accepting them can let a client set fields it should not, such as a role.
• Limit size: cap body size, string lengths, list lengths and nesting depth, so a single request cannot exhaust memory.
• Normalize: trim whitespace and normalize case or Unicode where the business rules call for it.
• Report clearly: return a 400 or 422 status listing each invalid field, without echoing back sensitive values.

What validation is not: it does not authorize. A well-formed request for another user's order still needs an ownership check, and validated text still needs output encoding and query parameter binding.

Raise meaningful domain exceptions in the code, and translate them into HTTP responses in one central handler at the edge of the application. Handlers then stay focused on the success path, and every error has the same shape.

• Map categories to statuses: validation errors to 400 or 422, missing resources to 404, conflicts to 409, permission failures to 403.
• Use one body format, with a stable machine-readable code, a human message and field details when relevant.
• Hide internals: unexpected exceptions become a generic 500 response, while the full traceback goes to the logs with the request ID.
• Include the request ID in the response, so support can find the matching log entry.

A consistent body might look like this:

{"error": {"code": "order_not_found", "message": "Order 42 was not found.", "request_id": "req-81f3"}}

Common mistakes: returning 200 with an error flag in the body, leaking stack traces or SQL in production responses, and catching exceptions deep in the code just to return a vague message.

Separate the web layer, the business logic and the data access, so each can change and be tested on its own. The dependency direction should point inward: routes call services, and services call repositories through simple interfaces.

flowchart LR
  A["Routes and handlers"] --> B["Services with business rules"]
  B --> C["Repositories"]
  B --> D["Clients for other services"]
  C --> E["Database"]
  F["App factory and settings"] --> A
  F --> B

• Routes: parse requests, call a service, format the response; no SQL and no business rules.
• Services: hold the rules and transactions, and know nothing about HTTP.
• Repositories and clients: wrap the database and external APIs, so they can be swapped for fakes in tests.
• App factory: builds the application from settings, which makes separate test, development and production setups easy.

As the project grows further:

1. Group code by feature, such as orders or billing, rather than by type, once a single folder per layer gets crowded.
2. Keep shared utilities small, and avoid a catch-all "utils" module.
3. Enforce boundaries with import rules in the build, so layers do not slowly tangle together.

Read configuration from the environment once at startup, convert it into a typed, immutable settings object, and fail fast with a clear message if anything is missing or invalid. The rest of the code receives that object instead of reading environment variables itself.

• Environment variables keep the same build working in every environment, with only the settings changing.
• Typed conversion: environment values are always strings, so convert numbers, booleans and lists explicitly, with sensible defaults.
• Validate everything at startup: report all problems together, so a broken deploy fails immediately instead of at the first request that needs the setting.
• Secrets: inject them at runtime from a secret store or mounted files, never commit them, and never log the settings object in full.
• Immutability: a frozen object prevents code from changing settings at runtime.

Passing the settings object into an app factory also makes tests simple: each test builds its own settings without touching the real environment.

Pass collaborators in as constructor or function arguments instead of creating them inside the code that uses them. Python's dynamic nature makes this lightweight: no container is needed, just explicit parameters.

• Constructor injection: a service receives its repository, clock and HTTP client when it is built.
• Composition root: one place, often the app factory, creates the real implementations and wires them together.
• Simple interfaces: a protocol or just a documented method name, such as get and save, is enough for a fake to stand in.
• Defaults sparingly: a default real implementation is convenient, but hides the dependency from readers and tests.

Why it helps:

1. Testing: pass an in-memory repository or a list's append method as a notifier, with no patching.
2. Flexibility: swap a storage backend or add a caching wrapper without editing the service.
3. Clarity: a constructor's parameters show exactly what a class depends on.

Avoid module-level singletons such as a global database client imported everywhere. They make tests patch import paths and hide shared state between requests.

Python database drivers follow a common interface: you open a connection, create a cursor, and call execute with the SQL text and a separate sequence or mapping of parameters. The driver sends the values separately from the SQL, so they can never change the query's structure.

• Placeholders: drivers use one of a few styles, such as ?, %s or named :name parameters; check which style your driver uses.
• Never format values into SQL with f-strings, % or concatenation, even for values that seem safe.
• Dynamic structure: column names and sort directions cannot be parameters, so pick them from an allowlist in code.
• Batches: executemany runs one statement for many parameter sets efficiently.
• Fetching: fetchone, fetchmany and fetchall control how many rows come into memory at once.

Binding parameters also helps the database reuse query plans, and it handles quoting, escaping and type conversion correctly for each value.

Group statements that must succeed or fail together into one transaction, commit only when all of them succeed, and roll back on any error. A context manager makes this automatic and impossible to forget.

flowchart TD
  A["Begin transaction"] --> B["Run every statement"]
  B --> C{"All statements succeeded?"}
  C -->|Yes| D["Commit"]
  C -->|No| E["Roll back"]
  E --> F{"Deadlock or serialization error?"}
  F -->|Yes| A
  F -->|No| G["Raise the error to the caller"]

• Explicit boundaries: start the transaction in the service that owns the business operation, not inside individual repository calls.
• Context managers: many drivers let with connection: commit when the block succeeds and roll back when it raises.
• Constraints help: database constraints such as CHECK, UNIQUE and foreign keys turn invalid states into errors that trigger a rollback.
• Keep them short: do not hold a transaction open while calling slow external services, because locks and connections stay held.
• Retry whole transactions: on deadlocks or serialization errors, retry the entire block, not a single statement.

Check your driver's default: some start a transaction implicitly before the first change, and others run in autocommit mode unless told otherwise. Getting this wrong silently commits half-finished work.

All three reach the same database; they differ in how much SQL they hide. Most mature services mix them: an ORM for everyday operations and hand-written SQL where control matters.

When to use which:

• Use an ORM when most operations load and save single records, and the object model maps cleanly to tables.
• Use a query builder for search screens and reports with optional filters.
• Use raw SQL for heavy reporting, bulk operations and database-specific features, with parameters always bound.

Whatever you choose, log or inspect the actual SQL during development, because convenience layers can generate surprisingly expensive queries.