460 Python Developer Interview Questions & Answers

I use inheritance when one class is truly a more specific kind of another class. In Python, a derived class can use attributes and methods from one or more base classes, and it can override methods when its behavior needs to differ. super() can continue method lookup through the method resolution order. I do not treat inheritance as the default way to reuse code because composition often creates a simpler and more flexible relationship.

Use inheritance when one kind of object is clearly a more specific kind of another. It lets the new kind receive shared data and actions from the older kind, while still changing an action when needed. For example, a dog can use the general behavior of an animal and add its own sound. This can reduce repeated work and keep related behavior together. However, it should not be used only to share code. If one object simply needs help from another object, keeping them separate is often easier to change.

1. Would you like me to explain multiple inheritance as well?
2. Should I compare inheritance with composition?

In Python, class Dog(Animal) makes Animal a base class of Dog. A Dog object can use attributes and methods found on Animal.

If Dog defines speak() again, it overrides the inherited method. super().speak() continues method lookup after Dog according to Python's method resolution order, called MRO. Here, it reaches Animal.speak().

isinstance(dog, Animal) checks the object relationship. issubclass(Dog, Animal) checks the class relationship.

Python also supports multiple inheritance. A class can have several base classes, and the MRO decides the lookup order.

Use inheritance for a real type relationship with shared behavior. Prefer composition when one object only needs another object's service. Composition often reduces coupling and makes parts easier to replace.

Inherited methods are not copied into every instance. They stay on classes and are found during attribute lookup. Each instance still stores its own instance state.

The example defines Animal as the base class and Dog as the derived class. Dog.speak() overrides Animal.speak(). Inside the override, super().speak() continues lookup through the MRO and reaches Animal.speak() in this class structure. The example also shows that isinstance() recognizes the object as an Animal, that issubclass() recognizes the class relationship, and that Dog.mro() exposes the method lookup order.

A common mistake is using inheritance only because two classes share some code. Shared code alone does not create a good type relationship. Another mistake is assuming that super() always means the immediate parent class. It actually continues lookup according to the MRO. Developers can also misunderstand multiple inheritance and ignore how the full MRO affects method lookup. Another mistake is forgetting that isinstance() can return true when an object belongs to a class derived from the class being checked.

Start with the practical rule: use inheritance for a real type relationship, not just for code reuse. Then explain overriding and super(). Mention isinstance(), issubclass(), and the MRO. Finish by explaining that multiple inheritance follows the MRO and that composition is often better when the goal is only to use another object's behavior.

Cooperative multiple inheritance works when each participating class performs its own task and then calls super() with compatible arguments. Zero argument super() does not simply call one direct parent. It continues with the next class in the method resolution order. This allows every class in the chain to run once. The design fails if a class stops the chain too early or passes arguments that the next method cannot accept.

Use cooperative multiple inheritance only when every participating class follows one shared calling contract. Inside an instance method, zero argument super() uses the class where the method was defined and the current instance. Python then searches after that class in the method resolution order, called the MRO. It does not simply choose one direct parent.

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?

For example, ReportProcessor can inherit from LoggingMixin, ValidationMixin, and BaseProcessor. ReportProcessor calls super(). LoggingMixin logs the request and delegates. ValidationMixin checks the data and delegates. BaseProcessor intentionally ends the chain. Each method runs once in MRO order.

Signatures must be compatible. A useful pattern is for each class to accept the named arguments it owns and pass remaining arguments through **kwargs. If a class does not call super(), later methods are skipped. If it forwards an unsupported argument, Python can raise TypeError.

The runtime cost is one method call and MRO lookup for each participating class. Zero argument super() creates a small proxy object, but it does not copy the instance or its data. The memory cost is normally small. In production, keep the hierarchy shallow, document the argument contract, inspect the MRO, and test the complete call chain.

The example defines ReportProcessor, LoggingMixin, ValidationMixin, and BaseProcessor. Calling process on ReportProcessor starts the cooperative chain. Each zero argument super() call continues with the next class in ReportProcessor's MRO. LoggingMixin consumes request_id. ValidationMixin consumes is_valid. Both pass the remaining named arguments forward. BaseProcessor is the intentional endpoint and rejects any argument that no earlier class consumed. The printed MRO and messages show the exact lookup and execution order.

A common mistake is assuming super() always calls one direct parent. It actually continues after the current defining class in the MRO. Another mistake is calling a parent class by name, which can skip another class or cause one implementation to run more than once. The chain also breaks when an intermediate class forgets to call super(), uses an incompatible signature, removes an argument owned by another class, or forwards an unsupported argument. A terminal base may end the chain intentionally, but that endpoint should be clear and documented.

Begin by saying that super() follows the MRO rather than one direct parent. Then explain the two main rules: every intermediate class must delegate, and all participating methods must use compatible signatures. Finish with one small mixin example and mention that composition is often clearer for unrelated behaviors.

A package is a special kind of Python module that can contain related modules and smaller packages. In a typical project, it is represented by a directory. A regular package normally has an __init__.py file, which Python executes when it first imports the package. Python also supports namespace packages without that file. A module usually represents one unit of code, while a package provides a naming hierarchy for organizing several units.

A package groups related Python modules under one import path. For example, a shop package may contain orders.py, payments.py, and products.py. Each file is normally an individual module. The shop package gives them names such as shop.orders and shop.payments.

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?

Technically, a package is a special kind of module with a __path__ attribute. This path tells Python where it can search for the package's submodules.

A regular package is typically a directory containing __init__.py. Python executes this file when the package is first imported. It may be empty, perform small initialization tasks, or expose selected names from other modules. Heavy work should be avoided there because it increases import time, keeps more objects in memory, and may create unwanted side effects.

Python also supports namespace packages without __init__.py. One namespace package can combine portions found in different import locations. This is useful for some large libraries, but it adds complexity.

Importing a package does not automatically import every module inside it. Loading all modules would increase startup work and memory use. Packages should therefore expose only the modules and names that users need.

A common mistake is saying that a package is only a directory. A package is a module that Python recognizes as able to contain submodules, and it has a __path__ attribute. Another mistake is saying that every package must have __init__.py. Regular packages normally have this file, but namespace packages do not. Developers may also assume that importing a package automatically imports every module inside it. Python normally loads only the package and the modules requested by the import statements. Other mistakes include placing slow database or network work in __init__.py, exposing too many internal names, and creating circular imports between package modules.

Begin with the main difference. Explain that a package organizes related modules and is itself a special module that can contain submodules. Then describe regular packages, __init__.py, and namespace packages. Finish by noting that importing a package does not automatically import every module inside it.

enumerate() lets me loop over an iterable while receiving both a counter and the current value. It yields pairs containing the counter and the item. The counter starts at zero by default, but the start argument can change its first value. It is usually clearer and safer than maintaining a separate counter.

Use enumerate() when a loop needs both a counter and the current item. It accepts an iterable, such as a list, tuple, string, or generator, and returns an enumerate iterator. As the loop requests values, the iterator yields tuples containing the current counter and the next item.

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?

For example, enumerate(["red", "blue"]) yields (0, "red") and then (1, "blue"). A loop can unpack each tuple into two names, such as position and color.

The counter starts at zero unless start is provided. enumerate(values, start=1) pairs the first item with one. The start argument does not skip items and does not change the original iterable.

enumerate() is usually better than a manual counter because it removes extra state. A manual counter can become incorrect when the loop changes, especially when continue causes an update statement to be skipped.

enumerate() works lazily. It does not create every pair in advance. Creating the iterator uses constant extra memory, and processing all items takes linear time. The iterator is consumed as it is read, so reuse requires creating a new enumerate object.

A common mistake is assuming that the counter is always the real index of a sequence. When start is not zero, the counter and the actual index differ. Another mistake is expecting start to skip items. It changes only the counter. Developers may also convert enumerate() to a list without needing every pair in memory, reuse an already consumed enumerate iterator, or maintain a separate counter when enumerate() would be clearer.

Explain three points clearly: enumerate() yields counter and value pairs, the default counter starts at zero, and start changes the counter without skipping items. Then mention that it avoids the extra state of a manual counter.

In CPython, Python objects live in a private heap managed by the Python memory manager. Each object normally has a reference count. When that count reaches zero, CPython can usually destroy the object immediately. Reference counting alone cannot remove a group of objects that only reference each other. The cyclic garbage collector finds those unreachable cycles and clears them. Memory can still grow when objects remain reachable through globals, caches, containers, closures, tasks, or callbacks. Also, freed object memory may stay inside Python for reuse instead of returning to the operating system.

The practical point is that CPython usually frees an object when nothing refers to it, but cycles need a second cleanup system. Memory can also remain allocated when objects are still reachable or when Python keeps freed blocks for reuse.

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?

Python stores its objects and internal data structures in a private heap. Application code does not directly manage this heap. The Python memory manager requests larger areas of memory from the operating system and then uses internal allocators for Python objects. Different object types may use different allocation strategies because a small integer, a list, and a dictionary have different storage needs.

In normal CPython, reference counting is the first cleanup mechanism. Every object keeps track of how many active references point to it. Assigning an object to another variable usually increases that count. Removing a reference usually decreases it. When the count reaches zero, CPython can run the object cleanup process and release its owned resources immediately.

For example, a local list may become unreachable when a function returns. If no other object refers to that list, its reference count reaches zero. CPython can destroy the list and decrease the counts of the objects stored inside it.

Reference counting cannot solve every case. Two objects can reference each other. Their reference counts stay above zero even after the application loses all outside references. This is a reference cycle. A parent object may refer to a child, while the child refers back to the parent.

CPython therefore includes a cyclic garbage collector. It supplements reference counting. The collector tracks container objects that can participate in cycles, such as lists, dictionaries, class instances, and other objects that hold references. It periodically examines groups of tracked objects. If a group cannot be reached from live application roots, the group is garbage even when its internal reference counts are not zero. The collector can then clear the cycle and allow the objects to be destroyed.

The collector uses generations because most objects die young. New tracked objects are checked more often. Objects that survive collections move to older generations and are checked less often. This reduces the cost of scanning every tracked object during every collection.

An important production point is that memory growth does not always mean the collector is broken. An object cannot be collected while it is still reachable. Common causes include unbounded dictionaries, lists, caches, global variables, closures, registered callbacks, background tasks, retained exceptions, tracebacks, and application sessions that are never removed.

Memory shown by the operating system may also stay high after objects are destroyed. Python allocators often keep freed blocks and arenas so later allocations can reuse them quickly. Some object types also use free lists. Therefore, object memory becoming reusable inside Python does not always mean the process immediately returns that memory to the operating system.

For debugging, I first confirm that memory growth is real and repeatable. I use tracemalloc to compare allocation snapshots. I inspect cache sizes, container lengths, task registries, and object ownership. The gc module can show collection statistics and tracked objects, but forcing gc.collect is not a general fix. The correct fix is usually to remove the unwanted reference, bound the cache, close the resource, or correct the object lifecycle.

First, identify where Python obtains and stores object memory. Python requests memory from the operating system and manages Python objects inside its private heap. Second, follow the reference count. Creating or storing another reference increases the count. Removing a reference decreases it. A count of zero normally allows immediate cleanup in CPython. Third, check for reference cycles. If objects only refer to each other, their counts may never reach zero. Fourth, let the cyclic garbage collector find tracked container groups that are no longer reachable. Fifth, separate unreachable garbage from reachable memory growth. Inspect globals, caches, containers, callbacks, tasks, closures, and tracebacks. Finally, remember that freed memory may remain in Python allocators for reuse, so process memory and live object memory are not always the same.

Traditional algorithm complexity does not fully describe Python memory management. Reference count updates add a small cost when references are created or removed. Destroying a container can take time related to how many references it owns. Cyclic collection costs depend on how many tracked objects the collector examines. Large object graphs can therefore cause longer collection work. Generations reduce this cost by checking young objects more often and older objects less often. Keeping many reachable objects increases memory use and can make scans more expensive. Python allocators improve speed by reusing freed memory, but the process may keep a larger memory footprint. The practical goal is to control object lifetime and measure real allocation growth.

A common mistake is saying that Python uses only garbage collection. Normal CPython mainly uses reference counting and adds cyclic collection for unreachable cycles. Another mistake is saying that del deletes an object. The del statement removes one reference. The object remains alive if another reference still exists. Candidates also assume that every increase in process memory is a leak. Python may keep freed memory for reuse. Another mistake is calling gc.collect repeatedly instead of finding the retaining reference. Disabling the cyclic collector without proving that cycles cannot occur is also risky. Finally, a weak reference does not keep its target alive, but using weak references everywhere is not a substitute for correct ownership.

Explain the answer in four parts. Start with the private heap. Then explain reference counting and immediate cleanup. Next, show why a cycle defeats reference counting and how the cyclic collector handles it. Finish with the production distinction between unreachable garbage, reachable objects, and memory retained by Python allocators. Mention tracemalloc as a practical debugging tool. Do not claim that del directly frees an object or that every high memory value is a leak.

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.

Python has several main groups of built in data types. Numeric types include int, float, and complex. Sequence types include str, list, tuple, and range. dict is the main mapping type. set and frozenset store unique values. bool represents True or False. bytes, bytearray, and memoryview handle binary data. NoneType contains the single value None, which represents no value. I choose a type based on ordering, uniqueness, lookup needs, mutability, and the kind of data being stored.

Python groups its main built in types by the kind of value they represent. Numeric types are int for whole numbers, float for binary floating point values, and complex for numbers with real and imaginary parts. bool represents True or False. It is a separate Boolean type, although it is also a subclass of int.

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?

Sequence types keep items in order. str stores text. list stores items that may change. tuple stores a fixed group of items. range represents an immutable sequence of integers without storing every integer as a normal list.

dict is the main mapping type. It stores values by unique, hashable keys. set stores unique mutable members, while frozenset is immutable. Dictionary and set membership checks are usually fast on average, but their exact cost can grow in unusual collision cases.

Binary types include bytes for immutable binary data, bytearray for mutable binary data, and memoryview for viewing buffer data without copying the underlying bytes. A memoryview object still uses a small amount of memory.

NoneType has one value, None. It represents the absence of a value. The correct type depends on ordering, uniqueness, lookup needs, mutability, exact numeric requirements, and whether data should be copied.

A common mistake is thinking that every collection can be changed. Lists, dictionaries, sets, and bytearrays are mutable. Strings, tuples, ranges, bytes, frozensets, numbers, booleans, and None are immutable. Another mistake is using a list, dictionary, or set as a dictionary key. Dictionary keys must be hashable, so mutable built in collections cannot normally be keys. Candidates may also confuse None with False, zero, or an empty string. These values are all falsy in conditions, but they are different values with different meanings. Another mistake is using float when an exact decimal result is required, such as some money calculations. Binary floating point cannot represent every decimal fraction exactly. It is also incorrect to assume that memoryview uses no memory. It avoids copying the underlying buffer, but the memoryview object itself still requires memory.

Group the types by purpose instead of giving one long list. Name each group, give one practical use, and explain the important differences in ordering, uniqueness, mutability, hashing, and memory behavior.

Mutable objects can change after they are created, while immutable objects cannot. Lists, dictionaries, sets, and bytearrays are mutable. Integers, floats, strings, bytes, tuples, and frozensets are immutable. Mutating a list changes the same object, so every variable that references it can see the change. An operation on an immutable value produces another value and the variable is rebound. This matters when objects are shared, passed to functions, copied, or used as dictionary keys.

The practical difference is that a mutable object can change in place, while an immutable object cannot. A list is mutable, so append changes the list. A string is immutable, so concatenation produces a new string object and rebinds the variable.

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?

Python variables hold references to objects. If two variables reference the same list, a change through one variable is visible through the other. Passing that list to a function gives the function access to the same object. Reassigning the parameter only changes the local name and does not rebind the caller's variable.

Mutable built in objects include lists, dictionaries, sets, and bytearrays. Immutable objects include integers, floats, booleans, strings, bytes, tuples, and frozensets. A tuple cannot replace its elements, but an element may reference a mutable object whose contents can still change.

Dictionary keys and set elements must be hashable. Immutability often supports stable hashing, but it does not guarantee hashability. A tuple is hashable only when every contained value is hashable.

Mutation can avoid allocating a replacement container. Operations on immutable values may allocate a new object and copy data. Repeated string concatenation can use extra time and memory. Control mutation when data is shared, cached, or reused.

A common mistake is thinking that passing an object to a function creates a copy. Python passes the same object reference to the parameter. Another mistake is confusing mutation with rebinding. Appending to a list changes the object, while assigning a new list changes which object a name references. Developers may also use a mutable object as a default function argument, which can share state across calls. Another mistake is assuming every immutable object is hashable. A tuple is unhashable when any contained value is unhashable. Shallow copying is also often misunderstood because nested mutable objects can still be shared.

Begin by saying that mutable objects can change in place and immutable objects cannot. Give a list and a string as examples. Then explain shared references, mutation versus rebinding, function arguments, and the hashability rule for dictionary keys. Mention the tuple containing a list as the main edge case.

Use == when you want to compare values. Use is when you want to check whether two names refer to the exact same object. I use is mainly for singleton objects such as None and for private sentinel objects. I do not use is to compare normal strings, numbers, or collections.

The practical rule is simple. Use == for value equality. Use is for object identity.

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 == operator asks whether two objects are equal according to their comparison rules. Built in types such as lists compare their contents. Two different lists can therefore be equal when they contain equal items.

The is operator asks whether both operands refer to the exact same object. It does not compare the contents of that object. Python defines x is y as true only when x and y are the same object. ([docs.python.org](https://docs.python.org/3.15/reference/expressions.html?utm_source=chatgpt.com))

For example, first = [1, 2] and second = [1, 2] create separate list objects. first == second is True because their values are equal. first is second is False because they are not the same list. If alias = first, then first is alias is True because both names refer to one list.

A type can customize == through its equality method. Because of that, == may perform content checks, call user code, return NotImplemented so Python can try another comparison path, raise an exception, or even return a non Boolean object. Built in comparisons normally return True or False. In a condition, Python converts a custom comparison result to a truth value. The is operator cannot be customized. It always checks identity.

None should normally be checked with is None or is not None. None is the sole instance of NoneType, and Python style guidance says singleton comparisons should use identity rather than equality. ([docs.python.org](https://docs.python.org/3/library/constants.html?utm_source=chatgpt.com)) This also avoids custom equality behavior. An object can define == in a way that reports equality with None, but it cannot make itself identical to None.

Identity comparison is also useful for a private sentinel object. A sentinel is one unique object used as a special marker. It is helpful when None is already a valid input and the program must distinguish None from an argument that was not provided.

Do not use is to compare normal numbers or strings. A Python implementation may reuse some objects, so an identity comparison may appear to work in one case and fail in another. That reuse is an implementation detail and is not a valid rule for value comparison.

One edge case is a not a number value. A floating point NaN is not equal to itself, so nan_value == nan_value is False. However, nan_value is nan_value is True when both names refer to the same NaN object. This shows that equality and identity answer different questions.

In production code, use == for business values, request data, database results, strings, numbers, collections, and domain objects when logical equality is intended. Use is for None, private sentinels, and rare cases where the exact object matters.

First, decide which question the program must answer.

If the program needs to know whether two values are logically equal, use ==.

If the program needs to know whether two names refer to the exact same object, use is.

For an optional value, write value is None or value is not None.

When None is a valid value and a separate missing marker is needed, create one sentinel with object() and compare it using is.

Do not choose is because two small numbers or strings happen to share an object during one test. That behavior is not a reliable value comparison rule.

Remember that custom equality code can change the behavior and cost of ==. The meaning of is does not change.

The code creates two different lists with equal contents and one alias that refers to the first list. It shows that == compares the list values while is checks whether the references identify one object. It then uses is for a None check and a private sentinel check. The final class demonstrates that custom equality can report equality with None, while identity still correctly reports that the object is not None.

A common mistake is using is to compare strings or numbers. Object reuse can make the result appear correct in one test, but the code is checking identity rather than value.

Another mistake is writing value == None. It may produce the expected result for many built in values, but a custom equality method can change the result. value is None states the intended identity check clearly.

Some developers assume that equal objects must be the same object. Two separately created lists or class instances can be equal while having different identities.

Another mistake is assuming that == always performs a simple or cheap comparison. It may scan a large collection or execute custom Python code.

A final mistake is using id values as permanent memory addresses. Identity remains stable only during an object's lifetime, and an id value may be reused after that object is destroyed.

Begin with the rule that == compares values and is checks identity. Use two equal but separate lists as the example. Then explain that None is a singleton and should normally be checked with is None. Mention object reuse only as a warning, not as behavior that application code should depend on.