460 Python Developer Interview Questions & Answers

An iterator is any object that knows how to return its next value. It uses iter() and next(), and it stops by raising StopIteration. A generator is a special kind of iterator made by a function that uses yield. The main difference is that a generator creates values lazily, one at a time, without storing the whole result. That is useful for large files, streams, database rows, or pipelines where loading everything would waste memory.

The practical answer is that an iterator is the general protocol, and a generator is an easy way to create one. A protocol means a set of methods that Python expects. For iteration, Python expects an object to work with iter() and next().

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?

An iterator must return itself from __iter__(). It must also define __next__(), which returns the next value. When there are no more values, __next__() raises StopIteration. A for loop uses this behavior for you. It calls iter() once, then keeps calling next() until StopIteration happens.

A generator function is a function that contains yield. When you call it, Python does not run the full function immediately. It returns a generator object. That object is also an iterator. Each call to next() runs the function until the next yield. Then Python pauses the function and remembers its local state.

The key idea is lazy evaluation. Lazy evaluation means values are produced only when they are requested. This is different from building a full list first. A list stores every value in memory. A generator can produce one value, hand it to the caller, then continue later.

This matters when data is large or continuous. For example, reading a huge log file line by line is a good generator use case. The program does not need the whole file in memory. It only needs the current line and a little state.

The tradeoff is that generators are usually single pass. Once a value is consumed, it is gone unless you save it somewhere. If you need random access, repeated passes, or the total length, a list may be clearer. So I would use generators when I want memory efficiency and streaming behavior. I would use a list when the data is small or I need to reuse it many times.

First, explain the iterator protocol. An object becomes an iterator when iter() returns an object that has next() behavior through __next__(). Second, explain how the loop stops. When __next__() raises StopIteration, Python knows there are no more values. Third, explain a generator function. A function with yield creates a generator object instead of returning all values at once. Fourth, explain lazy evaluation. The generator produces one value only when next() asks for it. Fifth, choose between them. Use a custom iterator when you need full class control. Use a generator when yield gives the same behavior with less code.

The code shows both forms. Countdown is a manual iterator because it implements __iter__() and __next__(). It raises StopIteration when the count reaches zero. countdown_generator does the same job with yield. Python saves the function state after each yield and resumes it on the next call. Both examples produce the same values, but the generator needs less manual code.

A common mistake is thinking every iterable is an iterator. A list is iterable because iter(list) returns an iterator, but the list itself is not consumed by next() directly. Another mistake is forgetting StopIteration in a manual iterator. That can make code fail or loop forever. Some candidates think a generator runs when the function is called. It actually starts when next() asks for a value. Another mistake is trying to reuse a consumed generator like a list. If repeated passes are needed, store the values or create a new generator.

Start by saying that an iterator is the protocol and a generator is a convenient iterator made with yield. Then explain iter(), next(), StopIteration, and lazy evaluation. End with the practical use case. Generators are best when the data is large, streaming, or should be processed one item at a time.

A class in Python is a runtime object that represents a new type, and an object is an instance of a type. I use a class when related state and behavior belong together. Each instance can have its own attributes, while class attributes live on the class and can be found through instances. Methods provide behavior for instances. Python classes are dynamic objects, so code can inspect them, pass them around, and change attributes at runtime.

A class describes a kind of thing that a program needs to work with. An object is one real value made from that description. For example, one description can represent an account, while separate values can represent Asha's account and Ben's account. Each account can keep its own owner and balance, while both follow the same rules for actions such as adding money. This is useful when related information and actions belong together. For a very small task, a simple function, dictionary, list, or tuple may be easier to understand.

1. Would you like me to explain the difference between values stored on each object and values stored on the class?
2. Should I also show a small Python example?

In Python, running a class statement executes the class body and creates a class object. That class object represents a new type. Calling it normally creates an instance of that type.

Names assigned in the class body become class attributes. Values assigned through self, such as self.balance, are instance attributes, so each instance can keep different state.

A method is a function stored on the class. When it is accessed through an instance, Python normally binds that instance to the method as self.

Every object also has an identity. Two objects can hold equal values and still be different objects. is checks identity, while == normally checks equality.

Classes group state and behavior and can use composition by storing other objects. Because classes are runtime objects, Python can inspect them, pass them to functions, and change attributes dynamically. Use a class when this structure makes a real concept clearer. Use a function or simple data structure when the problem does not need that extra structure.

The example defines an Account class. The class attribute currency belongs to the class and can be found through each instance. The __init__ method stores owner and balance as instance attributes, so each Account object keeps its own values. The deposit method changes the balance of the specific instance passed as self. Two Account instances show that they use the same class but keep separate instance state. The final checks show that account_one has type Account and that the two variables refer to different objects.

A common mistake is treating a class as something outside normal Python runtime behavior. In Python, the class itself is an object. Another mistake is confusing class attributes with instance attributes. A mutable class attribute, such as a list, can be shared by instances and cause unexpected changes. Candidates also sometimes confuse is with ==. The first checks object identity, while the second normally checks equality. Another mistake is creating a class for a tiny task where a function or simple data structure would be clearer.

Start with the main definition: a class is a runtime object representing a type, and an object is an instance of a type. Then use one small example to explain instance attributes, class attributes, and methods. Mention identity and composition briefly. Finish by explaining that a class is useful when related state and behavior belong together, but simpler tools are often better for small problems.

self is the conventional name for the current instance passed to an instance method. When I call obj.method(), Python binds that method to obj and supplies obj as the first argument, so I do not pass self myself. Inside the method, self lets me read or change that object's state and call its other methods. self is a convention, not a reserved Python word.

In Python, an instance method usually works with one particular object. The first parameter in the method definition represents that object, and Python programmers normally call it self. For example, when you call obj.show(), Python supplies obj to the method as its first argument. This lets the method read or change information stored on that object and call other actions that belong to the same object. The name self is not a special reserved word. Another name can work, but self is the normal convention because it makes Python code easier to understand.

1. Would you like me to explain how method binding supplies self?
2. Should I also compare instance methods with class methods and static methods?

The practical rule is simple. Use an instance method when the behavior needs a specific object's state or other instance methods.

When Python evaluates obj.show, it creates access to show that is bound to obj. Calling obj.show() therefore passes obj as the first argument to the underlying function. That is why the definition includes self even though the normal call does not.

Inside the method, self.value accesses state on that exact instance. self.save() calls another method using the same instance.

You can also call an instance method through the class, such as MyClass.show(obj). In that form, you supply the instance yourself. This shows that self is an ordinary parameter name, not a keyword.

A class method receives the class as its first argument, usually named cls. A static method receives no automatic instance or class argument. These choices do not add a special performance or memory benefit by themselves. Choose the method type based on what context the behavior actually needs.

A common mistake is thinking self is a reserved Python keyword. It is only a naming convention. Another mistake is passing self manually in a normal call such as obj.method(self). Python already supplies the instance for a bound method call. Candidates may also forget the first instance parameter in the method definition. Another mistake is assuming every method receives self. A class method receives the class, usually as cls, while a static method receives no automatic instance or class argument.

Start by saying that self is the current instance passed to an instance method. Then explain that obj.method() binds the method to obj and Python supplies obj as the first argument. Mention that self is a convention rather than a reserved word. Finish by briefly comparing self with cls in a class method and with a static method that receives no automatic instance or class argument.

__init__ initializes a new instance after Python has created it. It receives the instance through self and usually saves constructor arguments as instance attributes. With inheritance, a class often calls super().__init__ so required initialization earlier in the method resolution order can run. __init__ must return None. The actual creation of the instance is handled by __new__.

__init__ is the place where an object gets its starting information. For example, when we create an employee with a name, age, and role, this method can save those values inside the new employee. Python gives the method the new object automatically, so the method can change that object. This is useful because every new object can begin with valid values. A class can also reuse initialization from another class that it inherits from. This method does not make the object itself. It prepares an object that has already been created.

1. Would you like me to explain the difference between __init__ and __new__?
2. Should I also show how __init__ works with inheritance?

When Python evaluates Employee("Maya", 30, "Developer"), object creation happens first. __new__ is responsible for creating and returning the new instance. Python then normally calls __init__ on that instance.

The self parameter refers to the instance being initialized. Statements such as self.name = name save constructor arguments as attributes on that instance. Simple validation can also happen here so the object begins in a valid state.

Employee calls super().__init__(name, age). In this example, that runs the User initializer, which stores the shared name and age values. Employee then stores role.

__init__ must return None. Returning another value causes a TypeError because __init__ initializes an existing instance rather than replacing it.

One runtime edge case is that if __new__ returns an object that is not an instance of the class, Python does not call that class's __init__.

In production code, keep __init__ focused on creating valid initial state. Expensive network calls or unrelated work can make instance creation slower and harder to test.

The example defines a User class whose __init__ stores name and age on each instance. Employee inherits from User. Its __init__ calls super().__init__(name, age), which runs the User initializer in this inheritance structure. Employee then stores role. Creating Employee("Maya", 30, "Developer") produces an instance whose name is Maya, age is 30, and role is Developer. Neither __init__ method explicitly returns a value, so each returns None as required.

A common mistake is saying that __init__ creates the object. Object creation is handled by __new__, while __init__ initializes an instance after creation. Another mistake is returning a value other than None from __init__, which causes a TypeError. Developers may also forget self when assigning instance attributes, skip super().__init__ when required initialization from another class must run, or place expensive external work inside __init__, making instance creation slow and harder to test.

Start by saying that __init__ initializes an instance after it is created. Then explain self, constructor arguments, and assigning initial attributes. Mention that __init__ must return None. Finish by distinguishing it from __new__ and briefly show how super().__init__ supports inheritance.

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.

__new__ creates and returns an object, while __init__ initializes an object that has already been created. Python calls __new__ first. It then calls initialization only when the returned object is an instance of the requested class or one of its subclasses. I normally use __init__ for regular setup and override __new__ only when creation itself must be controlled, such as for an immutable subclass or a singleton like design.

__new__ handles object creation. It receives the class as its first argument and must return an object. In a normal custom class, it usually calls super().__new__(cls) and returns the new instance.

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 then performs initialization when the returned object is an instance of the requested class or one of its subclasses. __init__ receives that existing object. It can validate input, assign attributes, and prepare state. It must return None. Returning another value raises TypeError.

The order is therefore creation first and initialization second. If __new__ returns an unrelated object, Python skips initialization for the requested construction call.

Most classes should only define __init__. Immutable subclasses may define __new__ because values such as an int, str, or tuple value must be chosen while the object is being created. A singleton like design may also define __new__ to return a cached instance. However, __init__ can still run after each successful class call, so repeated initialization must be safe or guarded.

Overriding __new__ has no fixed performance or memory cost by itself. The cost depends on extra allocation, caching, locking, validation, or lookup logic added by the implementation.

A common mistake is saying that __init__ creates the object. The object already exists when __init__ starts. Another mistake is forgetting that __new__ must return an object. If it returns None or an unrelated object, normal initialization does not occur. Developers may also return a value from __init__, but Python requires an implicit or explicit None return. In singleton like designs, it is incorrect to assume that __init__ runs only once. It can run after every class call that returns a valid instance. Another mistake is overriding __new__ for normal attribute assignment when __init__ is simpler and clearer.

Begin with the direct rule: __new__ creates and returns the object, while __init__ prepares the returned object. Then explain the call order, the return requirements, and the case where initialization is skipped. Finish with one practical example involving an immutable subclass.

A Python decorator is a callable that receives a function, method, or class and returns a replacement or modified object. The @ syntax is convenient syntax for assigning the decorated result back to the same name. A common decorator creates a wrapper that runs extra logic around the original function. In production code, I normally use functools.wraps so the wrapper keeps useful information such as the original function name and documentation.

A decorator lets us add the same extra behavior around existing work without rewriting that work. Imagine a greeting action that already works correctly. We may also want to record when it runs or check permission first. Instead of mixing those extra steps into the greeting itself, we can place them around it. This keeps the main job focused and makes the extra rule reusable. Python connects this extra behavior when it creates the decorated item, so the setup is normally done once when that definition is executed.

1. Would you like a simple function decorator example?
2. Should I also explain decorators that accept their own arguments?

A decorator is a callable that receives a function, method, or class and returns a replacement or modified object. For a function, it often returns a wrapper.

The @ syntax is convenient assignment syntax. Writing @log_call above greet is effectively greet = log_call(greet). Decoration happens when Python executes that definition.

A wrapper often accepts *args and **kwargs to pass arguments through. It is a closure because it remembers the original function. functools.wraps preserves useful metadata.

A decorator can accept arguments through another outer callable. With stacked decorators, Python evaluates expressions from top to bottom, then applies decorators from the closest one outward.

Decorators suit logging, authorization, caching, registration, and retries. They add call overhead and another control flow layer, so direct code can be clearer for simple cases.

The example uses a decorator factory named log_call. The outer function receives a prefix, so the decorator itself accepts an argument. The decorator function receives greet and returns wrapper. The wrapper remembers both prefix and greet through closures. It accepts *args and **kwargs and forwards them unchanged to greet. functools.wraps preserves useful metadata from greet. Python evaluates log_call("CALL") when it executes the decorated definition, then applies the returned decorator to greet. Calling greet later runs wrapper, prints the prefix, and then calls the original greet function.

A common mistake is saying that a decorator only adds code before a function call. A decorator can return a replacement object and may change behavior in many ways. Another mistake is forgetting to return the original result from a wrapper. Developers also forget *args and **kwargs, which can make a wrapper reject arguments accepted by the original function. Forgetting functools.wraps can hide useful metadata. Another mistake is thinking decoration happens on every function call. Decorator expressions are evaluated when Python executes the decorated definition. With stacked decorators, candidates also sometimes confuse expression evaluation order with application order.

Start with the simple rule: a decorator receives an object and returns a replacement or modified object. Then explain @ syntax as assignment, show one wrapper, and mention closures, *args and **kwargs, and functools.wraps. Finish with one production use and explain that stacked decorator expressions are evaluated from top to bottom but applied from the closest decorator outward.

Duck typing means Python code usually cares about what an object can do, not which class it belongs to. If an object supports the operation my code needs, I can use it. For example, a function can call write on any object that provides a compatible write method. This makes code flexible, but the expected behavior should still be documented and tested because missing or incompatible operations fail when they are used.

Duck typing means code accepts an object because it supports the behavior the code needs. The object does not have to inherit from one required class. For example, a function that calls writer.write can work with a file object, an in memory stream, or a custom writer. They are compatible because each provides a suitable write method.

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 normally checks this when the operation runs. It looks up write on the object. If the method exists, accepts the supplied arguments, and behaves as expected, the call works. If write is missing, Python raises AttributeError. If its call signature is incompatible, Python can raise TypeError.

Duck typing is useful for reusable functions, testing, adapters, iterables, context managers, and file like objects. Its main limitation is that the required behavior can be unclear. A Protocol can document the expected methods for static type checkers without forcing inheritance. An abstract base class is useful when explicit inheritance, shared code, or runtime membership rules are needed.

Duck typing itself does not copy the object or create a replacement object. Its cost is the normal attribute lookup and method call. In production, use small interfaces, clear names, type hints, focused tests, and useful boundary validation.

The example defines save_message without checking the concrete class of its argument. The function only calls write because that is the behavior it requires. FileWriter and MemoryWriter are unrelated classes, but both work because each provides a compatible write method. BrokenWriter does not provide write, so Python raises AttributeError when the call is attempted. The Writer Protocol documents the expected method for static type checking. It does not change the runtime method call or force the classes to inherit from Protocol.

A common mistake is saying duck typing means Python has no types. Python objects still have types. The point is that code can accept different types when they support the required behavior. Another mistake is checking every object with type or isinstance even when the needed operation is enough. A matching method name is also not a complete guarantee. The method must accept compatible arguments and follow the expected meaning. Another mistake is believing Protocol changes runtime behavior. It mainly helps static type checkers unless separate runtime checking is added. Broad exception handling can also hide defects, so catch errors only where the program can respond usefully.

Start with the practical rule that Python uses supported behavior rather than requiring one parent class. Give one small write example. Then explain that missing methods fail at runtime and that Protocol or an abstract base class can make the expected interface clearer.

The main difference is what Python binds automatically. An instance method receives the current object as self when accessed through an instance. A class method receives the class as cls, including a subclass used for the call. A static method receives nothing automatically. I use an instance method for object state, a class method for class aware behavior or alternative constructors, and a static method for a related helper that needs neither object nor class state.

Choose the method type by deciding what the operation needs. A normal function defined in a class acts as an instance method. When it is accessed through an instance, Python creates a bound method that supplies that instance as self. When it is accessed through the class, no instance is supplied, so one must be passed explicitly if the function is called.

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 class method uses the classmethod decorator. Python supplies the class as cls whether the method is accessed through the class or an instance. If a subclass performs the access, cls is that subclass. This makes class methods useful for alternative constructors and behavior that must respect inheritance.

A static method uses the staticmethod decorator. Python returns the stored function without supplying self or cls. It is useful for a helper that belongs conceptually with the class but needs no object or class state.

Binding does not copy the object or class data. Instance and class method access can create a small temporary bound method object. This cost is normally minor. Use module functions instead of static methods when the helper is not closely related to the class.

The example uses a base class and a subclass. The instance method reads data from one object through self. The class method creates an object by calling cls, so calling it through AdminUser creates an AdminUser object and preserves inherited behavior. The static method validates a value without receiving self or cls. The final class level call also shows that an instance method is not given an object automatically when it is accessed through the class.

A common mistake is forgetting self in an instance method or cls in a class method. Another mistake is believing that self and cls are Python keywords. They are strong naming conventions, but the binding behavior depends on the method form, not the parameter name. Developers may also use a static method for an alternative constructor, which prevents Python from supplying the subclass automatically. Another mistake is assuming that accessing an instance method through the class supplies an instance. It does not. A caller must provide the instance explicitly. It is also unnecessary to place every helper inside a class. A general helper may be clearer as a module function.

Start with what Python supplies automatically: an instance, a class, or nothing. Then explain that inherited class methods receive the subclass used for access. Finish with one practical use case for each method type.

Python uses the method resolution order, or MRO, to decide which class supplies an attribute or method when inheritance is involved. It calculates one consistent order with C3 linearization and exposes it through ClassName.__mro__ or ClassName.mro(). The super function continues with the next class in that order, not always the direct parent. This is why cooperative multiple inheritance requires compatible method signatures and careful super calls.

Python uses the method resolution order, or MRO, to decide which class supplies an attribute or method when inheritance is involved. For class lookup, Python checks classes in the MRO and uses the first matching definition. Normal instance lookup rules still apply, so an instance attribute or descriptor can affect the result before a class attribute is returned.

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 calculates the MRO when the class is created by using C3 linearization. In practical terms, the result preserves the parent order written in the class definition, keeps every parent before its own parents, and produces one consistent order without repeating a class. Python raises TypeError if no valid order exists.

You can inspect the order with ClassName.__mro__, which is a tuple, or ClassName.mro(), which returns a list. The super function continues after the current class in that MRO. It does not simply call a fixed parent.

Cooperative inheritance works when each nonterminal override calls super once and compatible methods accept compatible arguments. A final method may intentionally end the chain. The MRO is stored on the class, so Python does not recalculate it for every call. Lookup may inspect several classes, while the stored order uses memory proportional to the number of classes.

The example uses a diamond inheritance structure. Class D inherits from B and C, while both B and C inherit from A. Python calculates the order D, B, C, A, object. Calling D().process() starts in D. The super call in D continues to B. The super call in B continues to C, not directly to A, because C is next in the MRO. The super call in C then continues to A. Class A intentionally ends this custom method chain because object does not define process. Each custom implementation therefore runs exactly once.

A common mistake is assuming that super always calls the direct parent. It continues with the next class after the current class in the MRO. Another mistake is calling a parent method directly, such as A.process(self), because this can skip another class or run a shared ancestor more than once. A class can also break the cooperative chain by omitting super too early, calling it more than once, or using arguments that the next method cannot accept. Developers may also forget that changing the order of parent classes can change the MRO and therefore change runtime behavior.

Begin with the practical rule that Python searches classes in MRO order and uses the first matching definition. Then explain that C3 linearization creates the order, show how __mro__ exposes it, and state that super moves to the next class in that order. Use a small diamond example to prove that super does not always mean direct parent.