460 Python Developer Interview Questions & Answers

Docstrings are string literals used to document a Python module, class, function, or method. The string must be the first statement in the object being documented. Python makes the text available through the object’s __doc__ attribute, so help and documentation tools can read it. I use docstrings to explain purpose, parameters, return values, raised exceptions, side effects, and behavior that is not obvious from the code.

Use a docstring when documentation should stay close to a Python object and remain available to tools. A docstring is a string literal used as the first statement in a module, class, function, or method. A module docstring is the first statement in the file. Comments, an encoding declaration, or an interpreter line may appear before it because they are not Python statements. Class, function, and method docstrings appear immediately inside their bodies.

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 exposes the text through the object’s __doc__ attribute. The built in help function and documentation generators can inspect this value. A string placed after another statement is only an unused string expression and does not become the docstring.

Docstrings should describe public purpose and behavior. They may explain parameters, return values, raised exceptions, side effects, and limits. They should not repeat obvious code or replace clear names and type hints.

A docstring does not run each time a function is called, so it normally has no meaningful call performance cost. Its text uses memory while available. Python can remove docstrings when started with the double O optimization option, causing __doc__ to be None.

The example uses one module docstring, one class docstring, one method docstring, and one function docstring. Each string is the first statement in the object it documents. The program reads each value through __doc__ and calls help on the function. The example also shows that the documented class, method, and function continue to run normally because docstrings describe behavior without changing the program logic.

A common mistake is placing the string after another statement. That string does not become the object’s docstring. Another mistake is assuming comments are available through __doc__. Comments are ignored for this purpose. Developers may also repeat obvious code, forget to document important exceptions or side effects, or leave the text unchanged after behavior changes. Another mistake is assuming __doc__ always contains text. It is None when an object has no docstring, and it may also be None when Python removes docstrings under the double O optimization option.

Start by saying that a docstring is the first string statement inside a module, class, function, or method. Then explain that Python exposes it through __doc__. Mention help and documentation generators, and finish with one limitation such as __doc__ being None when no docstring exists or when docstrings are removed by optimization.

Comments are notes in the source code that Python does not keep as runtime values. They normally begin with the number sign. Docstrings are string literals placed as the first statement in a module, function, class, or method. Python normally stores a valid docstring in the __doc__ attribute, so help and documentation tools can read it. I use comments to explain implementation decisions and docstrings to describe how reusable code should be used.

Use comments for implementation notes and docstrings for documentation that tools and developers should be able to access. A comment normally begins with the number sign. Python ignores it while creating the executable program, so it does not become a normal runtime value or add runtime memory for the running code.

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 docstring is a string literal placed as the first statement in a module, function, class, or method. Python recognizes that position and normally stores the text in the object through its __doc__ attribute. The help function, editors, inspection tools, and documentation generators can read it.

Placement is important. A string written later inside a function is only a string expression. It is not that function's docstring. Triple quoted strings are common because they support several lines, but a single quoted string can also be a valid docstring.

Docstrings have a small memory and loading cost because their strings are normally stored at runtime. Running Python with the OO optimization option can remove docstrings, so production code should not depend on them for required program behavior. Comments should explain reasons or unusual choices. Docstrings should explain purpose, inputs, results, errors, and expected use.

A common mistake is calling every triple quoted string a docstring. It is a docstring only when it appears as the first statement in a supported object. Another mistake is expecting comments to be available through __doc__ or runtime inspection. Developers may also place important program data in a docstring even though the OO optimization option can remove docstrings. Other mistakes include writing comments that only repeat obvious code, using docstrings for temporary notes, and allowing documentation to become outdated when the implementation changes.

Start with the practical difference. Say that comments explain the implementation in source code, while docstrings document an object and are normally available at runtime. Then mention the required first statement placement and the OO optimization limitation.

Python first checks sys.modules for the fully qualified module name. If the module is already there, Python normally reuses the cached module object. Otherwise, finders try to locate it, usually through sys.meta_path. The standard path finder searches sys.path for a top level module or the parent package path for a child module. A loader then creates the module when needed and executes its code. Python places the module in sys.modules before execution finishes, which prevents repeated loading but can expose a partly initialized module during a circular import.

Python first checks sys.modules, a dictionary that maps fully qualified module names to module objects. If the requested name is present, Python normally reuses that object instead of finding and executing the module again.

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 a new import, Python asks the finders in sys.meta_path for a module specification. The standard path finder searches sys.path for a top level module. For a child module, it searches the parent package path, usually stored in __path__. The specification identifies details such as the loader and module origin.

The loader creates the module when needed and executes its code. Before execution, Python places the module in sys.modules. This early insertion prevents endless repeated loading and lets recursive imports refer to the same object. If execution fails, Python removes the failing module entry, although modules imported successfully as side effects can remain cached.

A circular import fails when one module reads a name from another before that name has been created. This may cause an ImportError or AttributeError involving a partly initialized module. In production, keep package boundaries clear, avoid unnecessary import time work, and move shared definitions into a separate module when two modules depend on each other.

A common mistake is saying that Python simply searches every directory on the computer. Python uses registered finders, and the standard path based finder searches configured locations. Another mistake is saying that every import executes the module again. Successful imports are normally reused from sys.modules. Developers may also assume that importing a package automatically imports every child module, which is not generally true. A local file can shadow a standard library or installed module when it has the same name. Editing sys.path inside application code can hide packaging problems. Moving an import into a function may delay a circular dependency, but it does not always remove the underlying design problem. Deleting a module from sys.modules also does not guarantee that old references to the previous module object disappear.

Explain the process in runtime order. Start with sys.modules. Then describe sys.meta_path, the module specification, the loader, sys.path for top level modules, and the package path for child modules. Finish by explaining that early insertion into sys.modules can expose a partly initialized module during a circular import.

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.

Use try for code that may fail, except for expected errors, else for work that should run only when try succeeds, and finally for cleanup. Python checks except clauses from top to bottom and runs the first compatible handler. The finally block normally runs whether the operation succeeds, fails, or returns, so it is useful for releasing resources.

Use try for code that may fail, except for expected errors, else for work that should happen only after success, and finally for cleanup. Python runs the try block first. If try finishes without an exception, Python skips every except block, runs else, and then runs finally. If an exception is raised inside try, Python stops the remaining statements in that block and checks the except clauses from top to bottom. The first clause with a compatible exception type runs. A handler for a parent class also matches its child exception classes, so specific handlers should come before broad handlers.

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?

If no handler matches, the exception continues to the caller after finally runs. An exception raised inside else is not handled by the earlier except clauses, but finally still runs. Finally also normally runs before return, break, or continue completes. It is therefore useful for closing files, releasing locks, and freeing other resources.

Finally is not an absolute guarantee if the process is forcibly stopped or exits immediately. Avoid return inside finally because it can hide an active exception or replace an earlier return value. In production, catch only errors you can handle and keep the try block small.

The example creates an in memory text stream and tries to read an integer from it. Valid text lets the try block finish, so else prints the converted value. Invalid text raises ValueError, so the matching except block prints an error message. The finally block closes the stream in both cases. An unexpected exception would continue to the caller after the stream is closed.

A common mistake is catching Exception when only one known error is expected. This can hide unrelated problems. Another mistake is placing too much code inside try, which makes it difficult to know which operation failed. Developers may expect else to run after except, but else runs only when try finishes without an exception. An error raised inside else is not caught by the earlier except clauses. A broad handler placed before a specific handler also prevents the specific handler from running. Avoid a bare except because it also catches signals such as KeyboardInterrupt and SystemExit. Returning from finally can suppress an active exception or replace an earlier return value.

Explain the blocks in execution order. Say that try performs the risky work, except handles the first matching error, else means the try block succeeded, and finally performs cleanup. Also mention that specific exception types should come before broad ones.

Use the raise statement when an operation cannot continue normally. I usually raise a specific built in or custom exception instance, such as raise ValueError("Age cannot be negative"). Inside an except block, raise by itself re raises the active exception and preserves its original traceback. When one error causes a new error, raise NewError(...) from original_error creates an explicit exception chain and preserves the original cause.

Use raise when an operation cannot return a valid result. The usual form is raise followed by an exception instance, such as raise ValueError("Age cannot be negative"). Python stops normal execution and searches outward for a matching except block. If no handler matches, Python ends the current program flow and prints a traceback.

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?

Use a built in exception when its meaning fits the problem. Use a custom exception that inherits from Exception when the failure belongs to your application domain.

Inside an except block, raise with no value re raises the active exception. This keeps the original exception type and traceback. Writing raise error instead raises that exception object again from the current location and can add another traceback frame.

When converting one exception into another, use raise NewError(...) from original_error. Python stores the original exception in the new exception's __cause__ attribute and shows both errors in the traceback. Python also keeps an implicit __context__ when a new exception is raised during exception handling. Use from None only when you intentionally want to hide that context from the displayed traceback.

Raising an exception creates traceback data and unwinds stack frames, so it is slower and uses more memory than normal branching. Exceptions should represent failures, not common control flow.

The example validates an age value. A value that cannot be converted to an integer first causes TypeError or ValueError. The code converts that failure into a custom AgeInputError and uses explicit exception chaining to preserve the original cause. A negative integer raises a built in ValueError. The process_age function catches AgeInputError, adds simple logging, and uses bare raise to re raise the same active exception with its original traceback.

A common mistake is raising Exception for every failure instead of choosing a specific exception type. Another mistake is using bare raise when no exception is active, which causes RuntimeError. Developers may also write raise error when they mean to preserve the current traceback exactly, or replace a low level error without using the from clause, which makes the cause less clear. Other mistakes include catching exceptions too early, hiding unexpected errors with a broad except block, using unclear messages, and using exceptions for common branches that can be handled with normal conditions.

Explain three cases in order. First, show how to raise a specific built in or custom exception instance. Second, explain that bare raise re raises the active exception inside an except block. Third, show that raise new_error from original_error preserves the original cause. Mention that specific exception types and useful messages improve handling and debugging.

Exception chaining connects a new exception to an earlier exception. If I raise a new exception while handling another one, Python automatically stores the earlier exception in __context__. If the earlier exception is the direct cause, I use raise NewError from original_error, which stores it in __cause__. If I use from None, Python hides the automatic context from the normal traceback but does not remove the stored __context__. Explicit chaining is usually best when translating a low level failure into a clearer application error because the traceback keeps the real cause.

The practical rule is to preserve the earlier exception when it explains why the new exception occurred. If a new exception is raised while another exception is being handled, Python automatically assigns the active exception to the new exception's __context__. The traceback normally says that another exception occurred while handling the earlier one.

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?

Use raise NewError from original_error when the earlier exception is the direct cause. Python stores that exception in __cause__, sets context suppression, and presents the cause before the new exception. The traceback says that the new exception was the direct result of the earlier one. This makes error translation clear across abstraction layers.

Use raise NewError from None when the automatic context is not useful to the person reading the traceback. Python sets __cause__ to None and __suppress_context__ to true. The original exception can still remain in __context__, but the standard traceback does not display it.

Chaining adds little work beyond exception creation and traceback handling. It can keep references to earlier exceptions, traceback frames, and local values while the exception chain remains reachable. Production code should preserve useful causes, avoid retaining exception objects unnecessarily, and suppress context only when the hidden details do not help debugging.

A common mistake is raising a replacement exception without from when the original exception is the known direct cause. The automatic context may still exist, but the intended causal relationship is less precise. Another mistake is believing that from None deletes the original exception. It only suppresses implicit context in the standard traceback. Developers may also suppress useful context only to shorten logs, catch Exception too broadly before translating it, or log only the final error message instead of the complete traceback. Another mistake is using chaining when a bare raise is better. A bare raise should be used when the same exception should continue with its existing traceback.

Explain the three cases in order. Start with automatic __context__, then explicit __cause__ through raise from, and finally suppression through from None. State that explicit chaining is useful when translating an error while preserving its real cause. Also mention that from None hides traceback context but does not erase __context__.

The with statement manages setup and cleanup around a block of code. Python enters a context manager before the block and exits it after the block, even when an exception occurs. It is commonly used to close files and release locks safely, so cleanup is not missed because of an early return or an error.

Use the with statement when some work needs reliable setup and cleanup. The object after with must be a context manager. Python calls its __enter__ method before the block. The returned value can be assigned with as. When the block ends, Python calls __exit__ with information about any exception.

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 a file, entering returns the open file object and exiting closes it. For a lock, entering acquires the lock and exiting releases it. Cleanup normally runs after successful work, an early return, or an exception. The __exit__ method may suppress an exception by returning a true value, although most context managers let the exception continue.

This is safer than manually calling close or release because manual cleanup can be skipped. A try and finally statement can provide the same guarantee, but with is usually shorter and makes the resource lifetime clear.

Only objects that implement the context manager protocol can be used directly. If __enter__ fails, that context manager is not entered, so its __exit__ method is not called. The statement adds a small method call cost. It does not copy the managed value, and it normally uses only a small amount of extra memory.

Common mistakes include opening a file without with and forgetting to close it, acquiring a lock without guaranteed release, using a file after the with block has closed it, and assuming every object supports the context manager protocol. Another mistake is believing that with always hides exceptions. Exceptions normally continue after cleanup unless __exit__ explicitly returns a true value. It is also incorrect to assume that __exit__ runs when __enter__ itself fails.

Begin by saying that with guarantees setup and cleanup around a block. Use files and locks as examples. Then explain that cleanup still occurs after an early return or an exception, which makes with safer and clearer than manual cleanup.

A context manager implements the with statement through __enter__ and __exit__. Python calls __enter__ before the block and assigns its return value to the name after as. If __enter__ succeeds, Python calls __exit__ when control leaves the block. When an exception occurs, __exit__ receives its type, value, and traceback. Returning True suppresses that exception. Returning False or None lets it continue. The contextlib.contextmanager decorator provides the same protocol through a generator that performs setup before yield and cleanup after yield.

The practical purpose of a context manager is to prepare a resource and release it reliably. Python first evaluates the expression after with and obtains a context manager. It calls __enter__, and the returned value becomes the value after as. If __enter__ raises an exception, the block never starts and __exit__ is not 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?

After __enter__ succeeds, Python runs the block. When control leaves the block normally, Python calls __exit__ with three None values. If the block raises an exception, Python passes the exception type, exception object, and traceback. Returning True tells Python that the exception was handled. Returning False or None allows it to continue.

The contextlib.contextmanager decorator offers a generator based style. Code before yield performs setup. The yielded value becomes the as value. Code after yield performs cleanup. A try and finally block is normally used so cleanup still runs when the block fails.

Context managers are useful for files, locks, transactions, temporary resources, and temporary state changes. Their time and memory cost is normally small. Python creates a manager object or generator object, but it does not automatically copy the managed resource.

The code demonstrates both supported implementation styles. ResourceManager uses __enter__ for setup and returns the resource used after as. Its __exit__ method always closes the resource after __enter__ succeeds. It prints any exception information and returns False, so the original exception continues. The managed_resource function uses contextlib.contextmanager. It creates the resource before yield, yields the value used after as, and closes it in a finally block. The example catches the propagated ValueError outside the with statement so the program can continue and show that cleanup happened.

A common mistake is to say that __exit__ always runs. It runs only after __enter__ completes successfully. Another mistake is returning True without realizing that it suppresses the active exception. Developers may also assume that the value after as must be the context manager itself, but __enter__ can return another object. With contextlib.contextmanager, the generator must yield exactly once. Cleanup should normally be placed in a finally block. Catching an exception around yield and then ending normally can suppress that exception, so the code must raise it again when suppression is not intended. A context manager also does not automatically make a resource safe for concurrent use.

Start with the __enter__ and __exit__ protocol. Explain what value is assigned after as. Then name the three exception values passed to __exit__ and state that True suppresses the exception. Mention that __exit__ is not called when __enter__ fails. Finish by explaining that contextlib.contextmanager uses setup before yield and cleanup after yield.

Use an async iterator when getting the next value may require waiting. It implements __aiter__ and __anext__. Async for calls __aiter__, awaits each __anext__ result, and stops when __anext__ raises StopAsyncIteration. Use an async context manager when resource setup or cleanup may require waiting. It implements __aenter__ and __aexit__, and async with awaits both methods. These protocols are common for network streams, database sessions, locks, and other input or output resources.

Use an async iterator for values that become available over time. The __aiter__ method must return an async iterator directly. Its __anext__ method returns an awaitable that produces one value. When no value remains, it raises StopAsyncIteration. Async for performs these calls and awaits automatically. Any other exception leaves the loop and continues through normal exception handling.

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?

Use an async context manager when entering or leaving a resource may require waiting. Async with awaits __aenter__, runs the block, and then awaits __aexit__. The __aexit__ method receives information about any exception. A truthy return value suppresses that exception. A false value lets it continue. If __aenter__ fails, the block is never entered and __aexit__ is not called.

Each iteration adds an awaited method call, so it has more overhead than a normal loop. It is useful when waiting time is much larger than that overhead. It does not speed up CPU heavy work. Async iteration can process one value at a time, so it can avoid storing the full result in memory. Cancellation still requires care because cleanup code can also be interrupted while it awaits.

The example uses AsyncNumbers as a single use async iterator. Its __aiter__ method returns the same iterator object. Its __anext__ method waits briefly, returns the next number, and raises StopAsyncIteration after three values. AsyncResource is an async context manager. Its __aenter__ method waits and opens the resource. Its __aexit__ method waits and closes the resource, then returns false so exceptions are not hidden. Main enters the resource with async with and consumes the values with async for. The output is Resource opened, the numbers 1, 2, and 3, Resource closed, and Finished.

A common mistake is defining __aiter__ with async def in modern Python. That returns a coroutine instead of returning the async iterator directly. Another mistake is returning a plain value from __anext__ instead of returning an awaitable, or raising StopIteration instead of StopAsyncIteration. Developers may also use for instead of async for, or with instead of async with. Returning true from __aexit__ by accident can hide an important exception. Breaking out of async for does not automatically call a custom cleanup method on every async iterator. Resource cleanup should therefore use an explicit async context manager when cleanup is required. Cancellation and failures inside cleanup must also be considered.

Explain the two protocols separately. First say that async for gets the iterator from __aiter__, awaits __anext__, and stops on StopAsyncIteration. Then say that async with awaits __aenter__ and __aexit__ for resource setup and cleanup. Mention that these tools help with waiting operations, not CPU heavy work. Finish with a database or network example and one cancellation warning.