460 Python Developer Interview Questions & Answers

pip is the common tool for installing Python distributions, while PyPI is the main public package index that pip searches by default. I usually run python -m pip so pip runs with the Python interpreter I intend to use. In real projects, I also control dependency versions because an installation can change over time if versions are not constrained or locked.

pip is a tool that helps you add reusable software to a Python environment. PyPI is the main public place where many Python projects publish that software. A project can request one exact release or allow a range of acceptable releases. The installer may also need to install other software required by that project. Teams record dependency choices so development, testing, and production environments can stay consistent. Some companies use a private package source for internal software. The name used to install a project can also be different from the name used inside Python code.

1. Should I also explain dependency reproducibility and private package sources?
2. Do you want an example of how a distribution name can differ from an import package name?

pip is Python's common package installer. PyPI is the default public package index that pip commonly searches for project metadata and distribution files. pip can also install from other configured indexes, local files, or supported source locations.

I prefer python -m pip because it runs pip with the selected Python interpreter. This reduces the chance of accidentally using pip from another Python environment.

When installing a project, pip resolves version requirements for that project and its dependencies. It selects versions that satisfy the available constraints. If a compatible wheel is available, pip normally uses it. A wheel is a built distribution that usually installs without building the project locally. Otherwise pip may use a source distribution, which can require a local build and build tools.

A requirements file records dependency requirements, but broad version ranges do not guarantee an identical environment later. Production teams often pin versions or use a lock based workflow with isolated environments. pip can also use private indexes for internal distributions. Finally, a distribution name used with pip does not have to match the package or module name used with import.

Common mistakes include treating pip and PyPI as the same thing, running a pip command that belongs to a different Python environment, assuming a requirements file automatically guarantees an identical environment, and ignoring transitive dependency versions. Another mistake is assuming the distribution name passed to pip must exactly match the package or module name used with import. Developers may also forget that pip can use private or alternative indexes instead of only PyPI.

Start by saying that pip installs Python distributions and PyPI is the public index that pip searches by default. Then briefly explain python -m pip, dependency resolution, wheels, source distributions, reproducibility, private indexes, and the difference between distribution names and import package names.

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.

An exception is an object that tells Python that an abnormal condition happened. When an exception is raised, normal control flow stops and Python looks for a matching except block. I catch the narrowest exception type that I can handle correctly, and I use finally when cleanup should run whether the operation succeeds or fails.

An exception is Python's way of reporting that something abnormal happened while a program was running. For example, a program may try to open a missing file or turn invalid text into a number. Instead of continuing normally, Python changes the path of execution and looks for code that knows how to respond. This lets a program recover from expected problems, show a useful message, or stop safely. It also helps developers understand where a failure happened and make sure important cleanup work still occurs.

1. Would you like a simple example using built in exceptions?
2. Should I also explain custom exceptions and exception chaining?

An exception in Python is an object. Python can raise one automatically when an operation fails, or code can raise one explicitly with raise.

Code that may fail goes inside try. An except block handles a compatible exception type. Python searches for a matching handler, so production code should catch the narrowest type it can handle correctly.

The else block runs when the try block completes without raising an exception. The finally block normally runs whether the operation succeeds or fails, so it is useful for cleanup.

An exception object can contain a message. If an exception remains unhandled, Python reports it with a traceback that shows the calls leading to the failure. Custom exceptions normally inherit from Exception directly or indirectly. Exception chaining, such as raise NewError from original_error, keeps the original cause visible. Broad exception handling can hide unexpected bugs, so it should be used only when the code has a clear recovery, logging, or shutdown responsibility.

Common mistakes include catching Exception when only one specific error is expected, using a bare except that hides problems that should remain visible, ignoring an exception without a clear reason, and putting too much unrelated code inside one try block. Another mistake is assuming that finally means the exception was handled. A finally block performs cleanup but does not automatically suppress the exception. Developers can also lose useful debugging context by raising a new exception without preserving the original cause when exception chaining would be clearer.

Start by saying that an exception is an object that signals an abnormal condition and changes normal control flow. Then explain raise, try, except, else, and finally in that order. Finish by saying that production code should catch the narrowest exception type it can handle correctly and preserve useful error context.

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.

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.

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.

Indentation is significant in Python because it defines code blocks. Statements at the same indentation level belong to the same suite, while deeper indentation creates a nested suite. Incorrect indentation can raise IndentationError or TabError. Valid indentation at the wrong level can also change program behavior without raising an error. In production code, I use four spaces consistently so the control flow is clear and predictable.

Indentation is significant because Python uses it to define blocks of code. A block is also called a suite. It is the group of statements controlled by an if statement, loop, function, class, try statement, or with statement. Statements at the same indentation level belong to the same suite. Moving farther to the right starts a nested suite. Returning to an earlier level ends the current suite.

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 uses visible indentation instead of braces to show program structure. The parser reads indentation before the program runs and uses it to determine block boundaries. Indentation therefore adds no separate runtime operation and no meaningful memory cost.

Invalid indentation can raise IndentationError. Mixing tabs and spaces in a way that makes indentation levels unclear can raise TabError. A more dangerous problem is valid indentation at the wrong level. The program may run, but a statement may execute inside a condition or loop when it should execute outside it.

Blank lines and comment only lines do not create or end suites. Indentation used to align a continued expression inside parentheses does not create a new block. In production code, teams normally use four spaces, editor checks, formatters, code review, and tests to keep control flow clear.

Common mistakes include treating indentation as optional formatting, mixing tabs and spaces, using different indentation widths at the same logical level, and placing a statement inside the wrong condition or loop. Another mistake is assuming that code is correct because it runs. Valid indentation can still produce incorrect behavior when a statement belongs to the wrong suite. Developers may also wrongly assume that alignment inside parentheses creates a new block.

Start by saying that indentation defines Python code blocks. Then explain suites, nesting, IndentationError, TabError, and the risk of valid but misplaced indentation. Finish by mentioning four spaces and consistent editor settings.