Python Backend Developer Top 100 Interview Questions

A Python backend developer owns the whole path from a request to stored data and back, including how that path behaves under load and failure. Endpoints are only the visible part of the job.

• Domain logic: turning business rules into clear, tested code that does not depend on the web layer.
• Data access: schemas, queries, transactions and migrations that keep data correct as the system changes.
• Integration: calling other services and queues with timeouts, retries and clear error handling.
• Performance: knowing where the interpreter is slow, when to use concurrency, and how to measure before optimizing.
• Security: validating input, protecting secrets, binding query parameters and keeping dependencies patched.
• Operations: logging, metrics, health checks, graceful shutdown and packaging the service so it runs the same everywhere.

Good Python backend engineers also make the codebase easy for the next person: consistent structure, type hints that tools can check, and tests that run quickly. The language makes it easy to write code fast, so discipline about structure matters more, not less.

The interpreter compiles the source into bytecode, then a virtual machine executes that bytecode one instruction at a time. Python code is never run directly as text.

flowchart LR
  A["Source file"] --> B["Parse into syntax tree"]
  B --> C["Compile to bytecode"]
  C --> D["Cache bytecode for imported modules"]
  C --> E["Virtual machine executes bytecode"]
  E --> F["Objects and results in memory"]

1. Parsing: the source becomes an abstract syntax tree, and syntax errors are reported at this stage.
2. Compilation: the tree becomes bytecode for each function and the module body.
3. Caching: for imported modules, the reference interpreter writes the bytecode to a cache folder, so later imports skip compilation when the source has not changed.
4. Execution: the evaluation loop runs the bytecode, creating objects, calling functions and handling exceptions.

Why it matters in practice:

• Importing a module runs its top-level code, so slow work at import time slows every process start.
• Recent versions specialize frequently executed bytecode for speed, but heavy numeric loops still belong in native code or optimized libraries.

Python passes references to objects, sometimes called pass-by-object-reference or call by sharing. The function gets a new name bound to the same object the caller passed.

• Mutating the object inside the function, such as appending to a list, is visible to the caller, because both names point to one object.
• Rebinding the parameter to a new object, such as tags = [], only changes the local name; the caller's variable is untouched.
• Immutable objects such as integers, strings and tuples cannot be changed in place, so a function can never alter the caller's value through them.

Practical rules for backend code:

• Do not mutate input arguments unless the function's name and documentation say so; return a new value instead.
• Copy input collections before changing them when the caller may reuse them.
• Be careful with objects shared across requests, such as module-level lists or dictionaries, since any request can change them for all others.

Default argument values are evaluated once, when the function is defined, not on every call. A mutable default such as a list or dictionary is therefore shared by every call that does not pass that argument.

• Each call that relies on the default mutates the same object, so data leaks from one call into the next.
• In a web service, this can mix data between requests from different users, which is both a bug and a privacy risk.
• The fix is to use None as the default and create a fresh object inside the function.

Related traps:

• Defaults computed from the current time, such as a timestamp, are also fixed at definition time.
• Class attributes that are mutable are shared by all instances in the same way.
• Static analysis tools and linters flag mutable defaults, so turn that rule on in the project.

They are the four core built-in collections, and they differ in ordering, mutability and lookup speed. Choosing the right one is often the simplest performance and correctness win in Python code.

When to use which:

• Use a list for ordered data you append to or sort, such as rows returned from a query.
• Use a tuple for a fixed group of values, such as a composite key, because it is hashable when its items are.
• Use a set to remove duplicates or to test membership many times.
• Use a dictionary to index records by an identifier instead of searching a list repeatedly.

A dictionary is a hash table: it computes the key's hash, uses it to find a slot, then confirms the match with equality. That is why lookups take constant time on average.

1. Hash: Python calls the key's __hash__ method to get an integer.
2. Probe: the hash picks a slot; if the slot holds a different key, the table probes further slots.
3. Compare: keys with the same hash are compared with __eq__ to find the exact match.

What makes an object hashable:

• It has a hash that never changes while it is used as a key.
• Objects that compare equal must have equal hashes.
• Built-in immutable types such as strings, numbers and tuples of hashable items qualify; lists, sets and dictionaries do not.

Practical consequences:

• If you define __eq__ on a class, also define __hash__, or Python makes instances unhashable.
• Changing an object's fields after using it as a key can make it impossible to find again.
• Many keys with colliding hashes degrade lookups toward linear time, which is why hash randomization protects against attackers who choose keys.

== checks equality, meaning whether two objects have the same value as defined by their __eq__ method. is checks identity, meaning whether two names refer to the very same object in memory.

Why is sometimes appears to work for values:

• The reference interpreter caches some small integers and may reuse some short strings, so a is b can be true for them by accident.
• That behavior is an implementation detail and changes between versions and situations, so code that relies on it is a bug waiting to happen.

Interview tip: explain why x is None is preferred over x == None; a class can override __eq__ to return anything, but identity with the single None object cannot be faked.

A shallow copy creates a new outer container but keeps references to the same inner objects. A deep copy recursively copies every nested object, so the copy shares nothing mutable with the original.

Pitfalls:

• Changing a nested list through a shallow copy also changes it in the original, which surprises many developers.
• A per-request copy of a configuration template needs a deep copy if handlers change nested values.
• Deep copies are slower and use more memory, so for large structures consider building a new object from only the fields you need.

A generator is a function that uses yield to produce values one at a time. Calling it returns an iterator, and each next call runs the function until the next yield, then pauses with its local state saved.

• Memory: only the current item exists in memory, so you can process files, query results or streams far larger than available RAM.
• Pipelines: small generators can be chained, each doing one step such as parsing, filtering or batching.
• Laziness: work happens only when a consumer asks for the next item, and stops early if the consumer stops.

Things to watch:

• A generator can be consumed only once; iterating it again yields nothing.
• Exceptions inside a generator surface when the consumer asks for the item that failed.
• Resources opened inside a generator, such as a file, should be managed with with, so they close even if the consumer stops early.

They share almost the same syntax, square brackets for a list comprehension and parentheses for a generator expression, but they evaluate differently. One builds the whole result immediately; the other produces items on demand.

When to use which:

• Use a generator expression when passing the result straight to a function that consumes it once, such as sum(order.total for order in orders).
• Use a list comprehension when you need the length, indexing, sorting or several passes over the data.
• Keep both short and readable; when the logic needs several conditions or nested loops, a normal loop or a named generator function is clearer.

A decorator is a function that takes a function and returns a replacement, usually a wrapper that adds behavior before or after calling the original. The @name syntax is shorthand for func = name(func).

• Wrapping: the wrapper accepts *args and **kwargs so it works for any signature.
• Metadata: functools.wraps copies the original name and docstring onto the wrapper, which keeps logs, debugging and documentation correct.
• Parameters: a decorator that takes its own arguments, such as @retry(times=3), is a function that returns the actual decorator.

Common backend uses: retries, timing, caching, access checks and registering route handlers.

Rules for a retry decorator:

• Retry only errors that are likely to be temporary, such as connection failures, never validation errors.
• Wait longer after each attempt and cap the number of attempts.
• Re-raise the last error so callers still see the failure.
• Retry only operations that are safe to repeat.

A context manager defines setup and cleanup around a block of code used with with. Python calls __enter__ at the start and __exit__ at the end, even when the block raises an exception.

sequenceDiagram
  participant C as Calling code
  participant M as Context manager
  participant B as With block
  C->>M: __enter__
  M-->>C: Resource
  C->>B: Run the block
  B-->>C: Returns or raises
  C->>M: __exit__ with the exception details, or None
  M-->>C: Cleanup done, true only to suppress the error

• Guaranteed cleanup: files, locks, database transactions and network connections are released however the block exits.
• Exception handling: __exit__ receives the exception and can log it, roll back a transaction or, rarely, suppress it by returning true.
• Simple version: the contextlib.contextmanager decorator turns a generator with one yield into a context manager, with cleanup in a finally block.

When to write your own:

• Pairing operations that must always happen together, such as acquire and release or begin and commit.
• Temporarily changing state, such as a setting in a test, and restoring it afterwards.
• Timing a block of code for metrics.

For several resources at once, contextlib.ExitStack manages a variable number of them and closes each one in reverse order.

Python resolves a name by searching four scopes in order: local, enclosing function, global module and built-in. A name assigned anywhere inside a function is local to that function unless declared otherwise.

• global lets a function assign to a module-level name. In backend code it usually signals shared mutable state, which is risky across requests and threads.
• nonlocal lets an inner function assign to a variable of its enclosing function, which is how closures keep counters or caches.
• Closures capture variables, not values, so an inner function sees the variable's value at the time it runs.

A classic trap: functions created in a loop all see the loop variable's final value, because they share one variable. Binding the current value as a default argument, or using a factory function, captures it at creation time.

Assigning to a name before reading it in the same function makes it local everywhere in that function. Reading it first then raises an UnboundLocalError.

Raise specific, meaningful exceptions where an error is detected, and handle them only where you can do something useful, usually at the boundary that turns them into a response. Swallowing errors silently is worse than crashing.

• A small hierarchy: define a base error for the service and subclasses such as NotFoundError and ConflictError, so callers can catch by category.
• Chaining: use raise DomainError(...) from error when translating a low-level failure, so the original cause stays in the traceback.
• Catch narrowly: catch the exceptions you expect, never a bare except:, which also catches interrupts and system exits.
• Log once: log the full traceback at the boundary that handles the error, not at every level it passes through.
• Clean up: use with or finally for resources rather than relying on exception handlers.

Python favors EAFP, "easier to ask forgiveness than permission": try the operation and handle the failure, instead of checking every condition first. This also avoids race conditions between a check and the action.

When several concurrent tasks fail together, recent versions group them in an ExceptionGroup, handled with except*.

All four describe structured data, but they differ in mutability, behavior and whether the structure exists at runtime or only for type checkers.

When to use which:

• Use a dataclass as the default for internal records; mark it frozen when instances should not change.
• Use a named tuple when you need tuple behavior, such as unpacking or use as a dictionary key.
• Use a typed dictionary when the data really is a dictionary, such as a decoded request body.
• Use a plain class when the object enforces rules in its methods.

Remember that type annotations are not validation; incoming data still needs explicit checks.

At runtime, type hints do almost nothing: Python stores them as annotations but does not enforce them. Their value comes from tools that read them, such as static type checkers, editors and libraries that build validation or serialization from them.

• Static checking: a type checker in the build catches wrong argument types, missing None handling and typos before the code runs.
• Documentation: signatures show what a function expects and returns, which helps every reader.
• Structural typing: a Protocol describes the methods an object needs, so any matching class fits without inheritance.
• Generics: type variables describe relationships, such as a function that returns the same type it received.

How teams adopt them:

1. Type public functions and new code first, rather than the whole codebase at once.
2. Run the type checker in the pipeline, starting lenient and tightening over time.
3. Validate external input explicitly, because annotations alone never reject bad data at runtime.

Avoid Any as a habit; it switches off checking for everything it touches.

Special methods, often called dunder methods for their double underscores, are hooks that Python calls for built-in syntax and functions. Implementing them makes your objects behave like built-in types.

• Representation: __repr__ gives an unambiguous developer view used in logs and debuggers; __str__ gives a user-facing one.
• Comparison and hashing: __eq__ defines equality, and __hash__ must be consistent with it for use in sets and dictionary keys.
• Operators: __add__, __lt__ and friends let a + b and sorting work.
• Containers: __len__, __iter__, __contains__ and __getitem__ support len, loops, in and indexing.
• Context management: __enter__ and __exit__ support with.

Rules that avoid subtle bugs:

• Return NotImplemented from a comparison when the other object is of an unsupported type, so Python can try the reverse operation.
• Keep the fields used by __hash__ immutable.
• Always define a useful __repr__; it pays off in every log line.

The method resolution order is the sequence of classes Python searches when looking up an attribute. Python computes it with an algorithm called C3 linearization, which keeps every class before its parents and preserves the order you list the bases in.

• ClassName.__mro__ shows the order explicitly.
• super() does not mean "the parent"; it means the next class in the resolution order of the actual object.
• That is what makes cooperative multiple inheritance work: each class calls super(), and every class in the chain runs exactly once.

Practical guidance:

• Use multiple inheritance mainly for small mixins that add one behavior, such as auditing or serialization.
• Make every class in a cooperative chain accept and pass on **kwargs, so constructors with different arguments still work.
• Prefer composition, holding a collaborator as an attribute, when the classes are not genuinely variations of one type.

If Python cannot build a consistent order, it raises a TypeError when the class is defined.

Both define an interface, but an abstract base class works through inheritance and runtime enforcement, while a protocol works through structural typing: any class with the right methods qualifies.

When to use which:

• Use an abstract base class for a plugin system you control, where shared helper methods and a hard runtime check are valuable.
• Use a protocol for dependencies such as "anything with a send(message) method", so tests can pass simple fakes and existing classes fit without changes.

A runtime-checkable protocol only checks that the methods exist, not their signatures, so do not rely on it as validation.

The reference interpreter frees most objects through reference counting, and a separate cyclic garbage collector cleans up groups of objects that refer to each other. You rarely free memory yourself, but you can easily keep objects alive by accident.

• Reference counting: every object tracks how many references point to it, and it is freed as soon as the count reaches zero.
• Cycle collection: objects that reference each other, such as a parent and child pointing to one another, never reach zero on their own, so the collector finds and frees unreachable cycles periodically.
• Memory pools: small objects come from internal pools, so freed memory is often reused by Python rather than returned to the operating system immediately.

How leaks happen in backend services:

• Caches and module-level collections that grow without limits.
• References held in closures, registered callbacks or long-lived task objects.
• Large objects kept alive by a traceback stored in a log record or variable.

The standard tracemalloc module compares memory snapshots to show which lines allocate the memory that keeps growing.