460 Python Developer Interview Questions & Answers

A decorator receives a callable and returns the object that will replace it. Python applies the decorator when it executes the function definition. The at syntax is equivalent to assigning the result of the decorator back to the function name. A wrapper can run logic before or after the original call. In production code, I normally use functools.wraps so tools can still find the original name, documentation, and wrapped function.

A decorator changes what a function name refers to. Python can do this because functions are first class objects. They can be passed to another function and returned as values.

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

When Python executes a decorated function definition, it creates the original function first. It then evaluates the decorator expression, passes the function to the decorator, and assigns the returned object to the original name. Therefore, applying @logger to process is equivalent to process = logger(process). Decoration happens when that definition is executed, which is often during module import, not on every later call.

A common decorator returns a wrapper function. The wrapper runs extra logic, calls the original function, and returns its result. It often accepts *args and **kwargs so it can forward different arguments.

A decorator with arguments needs three levels. The outer function receives configuration, the next function receives the target callable, and the wrapper handles each call.

functools.wraps copies useful metadata and sets __wrapped__. It does not remove the extra call cost. A closure can also keep captured objects alive while the decorated function remains reachable.

The example uses a decorator factory named log_calls. The outer function receives the label argument. It returns the real decorator, which receives the target function. The decorator returns a wrapper that accepts any positional and keyword arguments. functools.wraps preserves important metadata and adds a __wrapped__ reference to the original function. Each call prints the configured label and function name, calls the original function once, and returns its result unchanged.

Common mistakes include calling the target function while creating the decorator instead of inside the wrapper, forgetting to return the wrapper, and forgetting to return the original result. A wrapper with fixed parameters may fail for functions with different call signatures, so forwarding *args and **kwargs is common. Omitting functools.wraps causes misleading names and documentation. Another mistake is assuming wraps gives the wrapper the exact runtime signature of the original function. It preserves metadata and sets __wrapped__, but the wrapper itself still uses its declared parameters. Decorators can also be applied in the wrong order because stacked decorators are applied from the bottom upward.

Begin with the replacement rule. Say that @decorator above a function is equivalent to assigning decorator(function) back to the same name. Then explain the wrapper, when decoration occurs, why functools.wraps matters, and why decorator arguments require one extra function level.

A closure is an inner function that keeps access to names from an enclosing function even after the enclosing function has returned. Python keeps references to those captured names rather than copying their current values. This causes late binding, so functions created in a loop may all read the final loop value. I can save each current value with a default argument, and I use nonlocal only when the inner function must rebind a captured name.

A closure is created when an inner function refers to a name from an enclosing function scope and the inner function is returned or stored for later use. Python keeps the captured name in a closure cell, so the inner function can still access it after the outer call has finished.

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

The captured object is not copied. The closure keeps a reference to it. Python also uses late binding for captured names. The value is normally read when the inner function runs, not when its function object is created. This matters in loops because several functions may share the same loop variable and later return its final value. A common fix is a default argument because its value is evaluated each time the def statement runs.

Reading a captured name needs no keyword. Mutating a captured mutable object also needs no nonlocal statement. However, assigning a different object to a captured name is rebinding, so nonlocal is required. It targets the nearest enclosing function scope and cannot target a global name.

Closures are useful for decorators, callbacks, factories, and small private state. Creating or calling one is normally constant time, apart from the work inside it. Captured references use memory and may keep large objects alive. For complex state, a class is often clearer.

The code demonstrates the three behaviors required by the question. make_multiplier captures factor and reads it after make_multiplier has returned. build_functions stores the current loop value in a default argument, so each returned function has its own saved value instead of reading one shared loop variable later. make_counter uses nonlocal because increment assigns a new integer object to count. The examples print 12, then the list 0, 1, 2, and then the counter values 1 and 2.

A common mistake is assuming that a closure stores an independent frozen copy of every captured value. It normally stores access to a closure cell, so late binding can make loop functions share the final loop value. Another mistake is assigning to a captured name without nonlocal. Python then treats that name as local to the inner function, which can cause UnboundLocalError if it is read before assignment. Developers also sometimes use nonlocal when only mutating a captured list or dictionary, even though rebinding is not occurring. A closure can also keep captured objects alive longer than expected, which matters when those objects use significant memory or hold external resources.

Begin with the main rule that a closure keeps access to an enclosing scope. Then explain that Python captures names through closure cells and uses late binding. Use a loop example to show the problem, explain the default argument fix, and finish by stating that nonlocal is needed for rebinding but not for reading or mutating a captured object.

Type hints are optional annotations that describe the types a function, variable, or collection is expected to use. They help readers, editors, linters, and static type checkers understand the code. Python normally does not enforce most type hints when the program runs, so a value with a different type can still reach the function. If runtime validation is required, the program needs separate validation logic or a library that performs it.

Type hints are notes that describe what kind of value a part of a Python program is expected to receive, store, or return. They make code easier for people to understand and help development tools find some mistakes before the program runs. These notes can describe one value, a group of values, a value that may be missing, or several allowed kinds of values. The key point is that these notes usually guide people and tools. They do not normally stop a running Python program from receiving a different kind of value.

1. Should I focus only on normal Python behavior, or also discuss runtime validation tools?
2. Would you like examples of modern annotation syntax?

Type hints are optional annotations. A parameter can be written as name: str, a return value as -> int, and a variable as count: int.

Collections can describe their contents, such as list[str] or dict[str, int]. A union such as str | int means either type is expected. str | None means a string or None is expected. A protocol describes required behavior rather than requiring one specific class. Generics let one annotation work with several related types while keeping useful type information.

Editors, linters, and static type checkers can inspect these annotations. Normal Python execution usually does not reject a value just because it conflicts with a hint. Python remains dynamically typed.

Use type hints for clearer interfaces, safer refactoring, better editor help, and static checking. Do not treat them as input validation. Values from users, files, networks, or external services should be validated at runtime when correctness or safety depends on the actual value.

A common mistake is saying that Python automatically rejects values that do not match type hints. Normal execution usually does not do that. Another mistake is confusing static type checking with runtime validation. Static checking examines annotations without relying on normal program execution, while runtime validation examines actual values while the program runs. Candidates also sometimes think str | None means a required string. It means either a string or None is expected. Another mistake is adding complicated annotations that make simple code harder to understand without providing useful checking value.

Start by saying that type hints describe expected types but normally do not enforce them at runtime. Then give one parameter and return example, mention collections and unions, and finish by clearly separating static checking from runtime validation.

A Python dataclass is a normal class decorated with @dataclass. Python can generate common methods such as init, repr, and eq from the annotated fields. I use it when a class mainly stores related data and I still want clear named fields and normal class behavior. For mutable defaults such as lists, I use default_factory so each object gets its own value.

A dataclass is useful when you want to group related information into one clear object without writing the same setup code again and again. You describe the pieces of information that the object should hold, and Python can create much of the routine setup for you. This makes the class shorter and easier to read. It works well for records such as a user, order, configuration, or message. It is still a normal class, so you can add your own methods and rules when needed.

1. Would you like me to cover options such as frozen and slots?
2. Should I compare dataclasses with dictionaries and validation libraries?

A dataclass is a normal Python class decorated with @dataclass. Python reads its annotated fields and can generate methods such as init, repr, and eq. By default, equality compares the class and the values of fields marked for comparison.

Fields can have default values. For mutable values such as lists, use field with default_factory so each instance receives a new object. This avoids sharing one mutable value between instances.

The frozen option blocks normal assignment to dataclass fields after creation. It does not make contained mutable objects deeply immutable, and it is not a security boundary. The slots option asks the dataclass to create a class with slots. This can reduce per instance memory use because instances normally do not need their own dict, although inheritance and base class behavior can affect the final layout.

__post_init__ runs after the generated init finishes and is useful for derived values or extra checks. Dataclasses support inheritance, but required fields cannot follow fields with defaults across the final inherited field order.

Use a dataclass for structured application data with normal class behavior. A dictionary is more flexible but gives less declared structure. A dataclass also does not automatically perform runtime type validation or provide a complete external data validation and serialization system.

A common mistake is thinking a dataclass is a special container that is separate from normal Python classes. It is still a normal class. Another mistake is expecting field annotations to validate values at runtime automatically. They do not. Developers may also expect a dataclass to provide complete JSON serialization automatically, which it does not. Mutable defaults such as lists should use default_factory so each instance gets its own object. frozen does not make contained mutable objects deeply immutable. With inheritance, required and default field ordering must remain valid across the combined inherited fields.

Start by saying that a dataclass is a normal class where @dataclass can generate common methods from annotated fields. Then mention init, repr, eq, defaults, and default_factory. Finish with frozen, slots, post_init, inheritance, and the key distinction that a dataclass gives structure and convenience but does not automatically provide runtime validation or a complete serialization system.

Structural pattern matching lets Python inspect both the value and the structure of an object with match and case. Python evaluates the subject once, checks cases from top to bottom, and runs the first case whose pattern matches and whose guard is true. Patterns can test literals, sequences, mappings, classes, alternatives, and nested data while capturing useful parts. This makes it more powerful than a simple switch statement.

Use structural pattern matching when a program must handle several clear shapes of data. It is available from Python 3.10.

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

A match statement evaluates its subject once. Python checks each case in order. It runs the first case whose pattern succeeds and whose optional guard is true.

A literal pattern checks a fixed value. A sequence pattern checks and extracts items from supported sequence objects, but it does not treat strings, bytes, byte arrays, or iterators as sequence patterns. A mapping pattern checks required keys and ignores extra keys unless the pattern captures them. A class pattern uses an instance check and can inspect attributes. An OR pattern accepts any listed alternative. A capture pattern binds a value to a name. The underscore wildcard accepts any value without binding it. A guard adds an extra if condition after the pattern succeeds.

This is more than a simple switch. It can inspect nested structure and extract data instead of only comparing one value with fixed choices.

Use it for structured commands, events, parsed data, and domain objects. Avoid it when a small if and elif chain is clearer. Put specific patterns before broad capture or wildcard patterns.

The example matches one value named event. It demonstrates literal, OR, sequence, mapping, class, capture, wildcard, and guard patterns. Python evaluates event once and checks the cases from top to bottom. The first case whose pattern succeeds and whose guard is true returns a result. The specific payment cases appear before the general mapping case so they are not hidden by a broader pattern. The final wildcard handles every value that earlier cases do not handle.

A common mistake is placing a broad capture or wildcard pattern before specific cases. An unguarded capture or wildcard pattern always succeeds, so Python requires an irrefutable case to be last. Another mistake is treating a plain name in a pattern as a constant. A plain name is normally a capture pattern, while a named constant must normally use a qualified name such as Color.RED. Developers may also expect sequence patterns to match strings or iterators, but they do not. Other mistakes include assuming mapping patterns reject extra keys, forgetting that guards run only after a pattern succeeds, and relying on variable bindings produced during a failed pattern because that behavior is not guaranteed.

Start with the runtime rule: Python evaluates the subject once, checks cases in order, and selects the first pattern with a true guard. Then explain that patterns can inspect structure and capture values. Give one mapping or sequence example. Finish by saying that match is more powerful than a simple switch but should be used only when it makes structured decisions clearer.

Type hints normally do not enforce types at runtime. Python keeps annotations as metadata, usually available through __annotations__, while static type checkers use them before execution. Runtime tools can inspect and act on the metadata, but they must perform their own validation. Generic types, unions, and forward references are represented as annotation values whose exact runtime form can depend on the Python version and annotation settings.

Type hints normally do not reject a value at runtime. Python still follows dynamic typing, so a function can receive a value that does not match its annotation unless some other code checks it.

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

Annotations are metadata associated with functions, classes, and modules. They are commonly available through __annotations__. In Python 3.14, annotations are evaluated lazily by default, so reading __annotations__ may evaluate annotation expressions and can raise an exception. In earlier versions, annotations were usually evaluated when the definition ran unless postponed annotation behavior was enabled.

Static type checkers read type hints without changing normal program execution. Editors also use them for completion and warnings. Runtime tools can use typing.get_type_hints to resolve annotations, including many forward references. Resolution may execute annotation code, allocate a result dictionary, and fail when a required name is missing.

A generic such as list[str] is represented as a generic alias. A union such as int | str is represented as a union type. A forward reference may remain a string or another delayed form until resolved.

Type hints improve clarity and tooling, but they do not replace validation of API requests, files, database values, or other external input.

The example defines a User class and a function with three annotation forms. list[User] is a generic alias. int | None is a union. The return annotation is str. The first call shows normal use. The second call proves that Python does not automatically enforce the limit annotation. The function completes because its own runtime logic accepts the supplied string value. The example then reads __annotations__ and uses get_type_hints to obtain resolved type information. The exact printed representation can vary between supported Python versions, but the runtime behavior and conclusion remain the same.

A common mistake is assuming that Python automatically rejects arguments that do not match annotations. Another mistake is treating __annotations__ as validated data rather than metadata. Developers may also assume annotations always have the same runtime representation in every Python version. Lazy evaluation, postponed annotation behavior, and forward references can change what is stored or when it is evaluated. Another mistake is calling get_type_hints on untrusted annotations without considering that annotation evaluation can execute code. Repeatedly resolving the same annotations in a busy request path can also add avoidable processing and allocation.

Begin with the conclusion that type hints do not normally enforce types. Then explain static checking, __annotations__, and runtime inspection with get_type_hints. Mention that Python 3.14 evaluates annotations lazily by default. Finish by explaining how a generic, a union, and a forward reference appear at runtime.

A dataclass inspects the annotated fields in a class and can generate methods such as __init__, __repr__, and __eq__. This removes repeated class code while keeping the fields clear. I use default_factory for mutable defaults, __post_init__ for validation or derived values, frozen to block normal field assignment, order for field based comparisons, and slots when many small objects need lower memory use.

The practical benefit of @dataclass is that it generates common class behavior from annotated fields. By default, it creates __init__, __repr__, and __eq__. The generated __init__ accepts field values and stores them on the object. The generated __repr__ shows the class name and fields. The generated __eq__ compares objects of the same class using fields marked for comparison.

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

A normal default is reused as the declared default value. Mutable defaults such as lists must use default_factory. The factory runs for each new object, so objects do not accidentally share one list.

The frozen option blocks normal assignment and deletion of fields after initialization. It does not make mutable values inside the object immutable. The order option generates comparison methods from fields in declaration order and requires equality support. The slots option creates slotted instances without the usual instance dictionary, which can reduce memory use and prevents undeclared attributes.

After the generated __init__ finishes, __post_init__ runs. It is useful for validation and derived fields. In a frozen dataclass, object.__setattr__ is needed to set a derived field during this step. Dataclasses work best for clear data models. A regular class is often better when construction rules or behavior are highly complex.

The example defines an ordered, frozen, and slotted Product dataclass. The name and price fields become parameters in the generated __init__. The tags field uses default_factory, so each Product receives a separate list. It is excluded from equality, ordering, and hashing because compare is false and hash follows that setting by default. The display_name field has init set to false, so callers cannot pass it to the constructor. After initialization, __post_init__ validates the price and calculates display_name. Because the object is frozen, object.__setattr__ is used during post initialization. The generated __repr__ displays the fields, __eq__ compares the selected fields, and the generated ordering methods compare name first and price second.

A common mistake is using a list or dictionary as a direct default instead of using default_factory. Another mistake is assuming frozen makes every nested value immutable. A frozen dataclass can still contain a list whose contents can change. Developers may enable order without checking whether field declaration order matches the required comparison rule. Other mistakes include placing a required field after a field with a default, expecting __post_init__ to replace all complex construction logic, forgetting that equality requires the same class, and assuming slots supports undeclared instance attributes.

Start by saying that @dataclass generates standard methods from annotated fields. Then explain default_factory for safe mutable defaults. Finish by stating how frozen, order, slots, and __post_init__ change the generated behavior.

A shallow copy creates a new outer object, but it keeps references to the same nested objects. A deep copy creates a new outer object and recursively copies nested objects when needed. I use a shallow copy when sharing nested values is safe. I use a deep copy when nested mutable data must be independent.

The practical difference is what happens to nested objects. A shallow copy creates a new outer container, but its items still refer to the same objects used by the original. If a list contains another list, changing that inner list through the shallow copy is visible through the original.

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

The copy.copy function performs a shallow copy. It is useful when only the outer container must be separate or when nested objects are intentionally shared.

The copy.deepcopy function recursively processes the contained objects. It creates independent copies of nested mutable objects when their copying behavior allows it. Immutable objects may still be shared because they cannot be changed. Deepcopy also keeps a record of objects it has already processed. This helps it preserve shared relationships and handle recursive structures.

A deep copy can require more processing time and memory because Python may visit much of the reachable object graph. Classes can customize copying through special methods, and some resource based objects, such as open files, should not be treated as ordinary data copies.

In production, I choose the smallest level of copying that gives the required isolation. This avoids accidental shared changes without copying more data than necessary.

The example creates a nested list and then makes a shallow copy and a deep copy. The shallow copy has a new outer list, but it shares both inner lists with the original. Appending 5 through the shallow copy therefore changes the inner list seen by the original. The deep copy has separate inner lists. Appending 6 through the deep copy therefore does not change the original.

A common mistake is assuming that a shallow copy makes every nested object independent. Another mistake is using list.copy or slicing on a nested list and expecting deep copy behavior. Developers may also use deepcopy for every object without considering its processing and memory cost. It is also incorrect to assume that deepcopy always creates a new instance for every value. Immutable objects may be shared, and classes can define custom copy behavior.

Start with the practical rule. A shallow copy separates only the outer object, while a deep copy also separates nested mutable objects when needed. Then show one nested list example and mention the processing and memory tradeoff.

async def creates a coroutine function, and await lets its coroutine pause while an awaitable is not ready to complete. Control can then return to the event loop so other ready tasks can run. This is useful for input and output work such as network requests. Awaiting independent operations one after another is still sequential, while scheduling them as tasks can let their waiting periods overlap. asyncio does not automatically make CPU intensive Python code faster.

The practical idea is to avoid wasting time while a program waits. Imagine a program starts a network request and must wait for a reply. Instead of doing nothing during that wait, Python can pause that piece of work and let other ready work continue. When the requested operation becomes ready, Python can continue the paused work. This is useful when a program spends much of its time waiting for networks, databases, files, or other services. It does not mean that every type of Python work becomes faster.

1. Would you like a small asyncio example?
2. Should I also explain sequential and concurrent waits?

In Python, async def creates a coroutine function. Calling it creates a coroutine object. Its body starts running only when the coroutine is awaited or scheduled.

Inside a coroutine, await works with an awaitable object. If that operation is not ready, the coroutine can suspend and give control back to the event loop. The event loop then runs other ready tasks. This is cooperative scheduling because running code must reach a point that allows other work to run.

A Task schedules a coroutine with the event loop. Awaiting two independent operations one after another keeps them sequential. Creating both tasks first can let their waiting periods overlap.

Cancellation is normal in asyncio. A cancelled task usually receives asyncio.CancelledError when cancellation is delivered, so cleanup should use constructs such as try and finally when needed.

Blocking calls and CPU intensive Python work can stop the event loop from serving other tasks. asyncio is mainly useful for input and output concurrency. It does not automatically speed up CPU intensive Python code.

The example creates two coroutine tasks before waiting for their results. Each coroutine reaches asyncio.sleep, which suspends that coroutine without blocking the event loop. While one task is waiting, the event loop can run the other ready task. asyncio.gather waits for both scheduled tasks and returns their results. This demonstrates concurrent waiting for independent input and output style operations without claiming that Python executes the coroutine bodies in parallel.

A common mistake is thinking that async makes every function run in parallel. It does not. Another mistake is awaiting independent operations one by one and expecting concurrency. That keeps their waits sequential. Developers may also call blocking functions inside a coroutine. A blocking call can stop the event loop and delay other tasks. Another mistake is ignoring cancellation and cleanup. Finally, asyncio should not be treated as an automatic speed improvement for CPU intensive Python work.

Start with the practical idea that async and await let Python use waiting time for other work. Then explain that async def creates a coroutine function, await can suspend its coroutine, and the event loop runs other ready tasks. Clearly separate sequential awaits from concurrently scheduled tasks, and mention that blocking or CPU intensive work can still stop the event loop.

Asyncio uses an event loop and cooperative scheduling. Calling an async function creates a coroutine object, but does not run it. Awaiting that coroutine runs it as part of the current task. Creating a task schedules it to run independently when the event loop gets control. Each task runs until it reaches an await that must wait. It then suspends so the event loop can run other ready work. Because the loop does not interrupt normal Python code, one blocking call or long calculation can delay every task on that loop.

Asyncio schedules coroutine work through an event loop. Calling an async function creates a coroutine object. The object holds the future execution state, but does not start by itself.

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

Awaiting a coroutine runs it as part of the current task. Creating a task registers the coroutine with the event loop so it can make progress independently. The loop selects ready tasks and lets each task run until it finishes, raises an exception, or reaches an await that cannot complete yet.

At that suspension point, the task saves its state and gives control back to the loop. When the awaited operation becomes ready, the loop schedules the task to continue. An await may not suspend when its result is already available.

This is cooperative scheduling. Asyncio provides concurrency, but does not make ordinary Python code run in parallel on one event loop. Blocking input and output, time.sleep, or long calculation can stall every task because the loop cannot run other work until control returns.

Each coroutine and task also uses memory for frames, local values, state, and results. Task switching has overhead, but it is usually small compared with the waiting time saved in input and output heavy programs.

Common mistakes include believing that calling an async function starts it, creating coroutine objects without awaiting or scheduling them, and assuming that every await always gives control to another task. Another mistake is treating concurrency as parallel execution. Developers may also call time.sleep, use a blocking library, or perform long calculation directly on the event loop. This prevents other tasks from running. It is also incorrect to assume that cancel stops a task immediately. Cancellation is a request and cleanup may still need to run. Fire and forget tasks should be stored and their exceptions should be observed.

Explain the runtime flow in this order: coroutine object, current task or new task, event loop, await, suspension, and resumption. Then state the main limitation clearly. Asyncio is cooperative, so code must return control to the event loop and must not perform blocking work there.