460 Python Developer Interview Questions & Answers

Positional only parameters must be passed by position, while keyword only parameters must be passed by name. Parameters before / are positional only. Parameters after * are keyword only. Parameters between the two markers can usually be passed either way. API authors use these rules to make calls clearer, prevent incorrect argument order, and avoid making some parameter names part of the public API.

Use / and * when a function should control how callers provide arguments. Parameters before / are positional only. Their values must be supplied in order. Parameters after a bare * are keyword only, so callers must write their names. Parameters between / and * can normally be passed by position or by name.

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

For example, def resize(width, height, /, *, keep_ratio=True) requires width and height by position and keep_ratio by name. Therefore, resize(800, 600, keep_ratio=False) is valid. Passing width=800 or passing False as a third positional value raises TypeError during argument binding.

An API author may hide positional only parameter names so those names can change later without breaking callers. Keyword only options make calls easier to read and reduce mistakes when several values have similar types. However, unnecessary restrictions can make a simple function less convenient. These markers do not change the function result and do not create separate application data. Their direct performance and memory effects are normally insignificant. The main benefits are readability, safer calls, and better control of API compatibility.

The function places width and height before /, so callers must pass them by position. It places keep_ratio after *, so callers must pass it by name. The valid call prints the supplied values. Each invalid call is placed inside a try block so the program can show the TypeError raised during argument binding and then continue.

A common mistake is thinking callers include / or * in a function call. These markers appear only in the function definition. Another mistake is assuming every parameter before * is positional only. A parameter is positional only only when it appears before /. Developers may also forget that parameters between / and * can usually be passed either by position or by name. Another mistake is changing an existing public signature without checking callers, because adding either restriction can break previously valid calls. Finally, the name of a positional only parameter can still appear as a separate key inside **kwargs when the function accepts extra keyword arguments.

State the rule for / first, then the rule for *. Show one short function signature and one valid call. Finish by explaining that the main purpose is clearer calls and better API compatibility, not faster execution.

A module is a Python unit that groups related names such as functions, classes, and variables. A module is often a .py file, but it can also be provided by Python itself or by an extension. On the first normal import, Python creates a module object, stores it in sys.modules, and executes the module code to fill its namespace. Later imports normally reuse that same object. The module name provides a separate namespace, so code can use names such as math.sqrt without mixing them with unrelated names.

A module is a unit that organizes related Python definitions and executable statements. A normal module is often stored in a .py file, although modules can also come from built in or extension loaders.

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

When Python processes an import, it first checks sys.modules. This mapping stores module names and their loaded module objects. If the module is already there, Python normally reuses that object. If it is not there, the import system finds the module, creates a module object, places it in sys.modules, and executes the module code. Functions, classes, variables, and imported names created during execution become entries in the module namespace.

A namespace maps names to objects. Accessing tools.parse means finding parse inside the tools module namespace. This keeps names from different modules separate.

The first import can include file lookup, loading, possible compilation, and code execution. Later imports are usually much cheaper because they reuse the cached object. A loaded module normally remains reachable through sys.modules, so the module object and objects referenced by its namespace continue using memory. Production modules should therefore keep import work small, avoid unexpected side effects, and handle circular imports carefully.

A common mistake is thinking that import copies the module source into the importing file. Python normally creates or reuses a module object and binds a name to that object. Another mistake is expecting the module code to run every time an import statement is reached. Normal imports usually reuse the object in sys.modules. Developers may also confuse a module namespace with the local namespace of a function. Using from module import name binds that object directly in the current namespace, which can hide its origin and cause name conflicts. Circular imports can expose a module before all of its names exist. Large side effects during import can also slow startup, complicate tests, and make failures depend on import order.

Begin with the practical definition: a module groups related Python code and provides its own namespace. Then describe the import sequence in order: check sys.modules, create the module object when needed, execute its code, and reuse the object on later imports. Finish with one production concern such as circular imports or expensive import side effects.

The main guard makes a block run only when that module is executed as the program entry point. In that case, Python sets __name__ to '__main__'. When another module imports it normally, __name__ contains the module's import name, so the guarded block is skipped. This lets the file provide reusable functions and classes without starting the program during import.

Use the main guard to separate reusable definitions from code that starts a program. Python gives every module a special variable named __name__. When a module is executed as the program entry point, Python sets __name__ to '__main__'. This includes running a file directly and running a module with python m. The condition is then true, so the guarded block runs.

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

When the module is imported normally, __name__ contains its import name, which can be a fully qualified package name. The condition is false, so the guarded block is skipped. Functions, classes, constants, and other statements outside the block are still executed or created during import.

This matters because Python executes top level module code when it loads a module. Without the guard, command line parsing, file access, network calls, or application startup could happen just because another module imported the file.

The guard usually calls a main function or runs a small demonstration. It does not stop code outside the block from running, create a separate scope, or prevent later execution through reload tools. Its runtime cost is one small comparison, and its extra memory cost is constant and negligible.

A common mistake is believing that the guard prevents the entire module from running during import. Python still executes top level statements outside the guard when it loads the module. Another mistake is placing reusable functions or classes inside the guard, which makes them unavailable after a normal import. Developers may also misspell __name__ or '__main__'. The guard does not create a new scope, and it should protect entry point behavior rather than ordinary reusable definitions.

Start by comparing the two values of __name__. Then explain that the guard keeps entry point behavior from running during a normal import. Also mention that top level code outside the guard still executes.

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.

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.

Python is a high level, general purpose programming language designed for readable code and developer productivity. In CPython, source code is compiled to bytecode, and the interpreter executes that bytecode. Python uses dynamic and strong typing, and every value is an object. CPython manages object lifetime automatically, mainly through reference counting with additional cycle detection. Python is widely used for web services, automation, testing, data work, scientific computing, and machine learning. Its main strength is fast development, while some workloads can use more execution time and memory than lower level native code.

Python is a programming language designed to make programs clear and practical to write. It is used for websites, automation, data work, testing, scientific tasks, and many applications. A developer writes readable instructions while Python handles many low level details, including memory cleanup for objects that are no longer needed. Python includes many built in tools, and developers can install more packages from the wider community. This makes development flexible. Some workloads can still run more slowly and use more memory than similar programs written in lower level compiled languages.

1. Should I focus on Python or CPython?
2. Should I compare Python with compiled languages?

Python is a high level, general purpose language that emphasizes readable code. In CPython, source code is compiled to bytecode, and the interpreter executes that bytecode.

Python uses dynamic typing, so names do not have permanently declared types. It is strongly typed, so incompatible operations usually raise errors. Adding an integer to a string raises TypeError.

Python values are objects, and names refer to objects. CPython mainly uses reference counting, with a cyclic garbage collector for unreachable reference cycles. Freed memory may be kept for reuse rather than immediately returned to the operating system.

Python includes a large standard library and package ecosystem. It is common in web services, automation, testing, data work, and machine learning. Interpreter work and object overhead can make Python slower and more memory intensive than lower level native code for some workloads. Critical sections often use optimized libraries or native extensions.

A common mistake is saying that CPython directly interprets source text without mentioning bytecode. CPython normally compiles source code to bytecode before executing it. Another mistake is calling Python weakly typed because type declarations are usually not required. Python is dynamically typed but strongly typed. Candidates also sometimes say that variables contain fixed typed storage. Python names instead refer to objects. Another mistake is saying that garbage collection immediately returns all unused memory to the operating system. CPython can keep released memory available for later reuse.

Start with the definition, then explain the common CPython execution model, dynamic and strong typing, the object model, automatic memory management, the standard library and package ecosystem, common application areas, readability, and the main performance tradeoff. Keep the distinction between Python as a language and CPython as one implementation clear.

CPython is the reference and most widely used implementation of Python. It normally compiles Python source code into bytecode and executes that bytecode with the CPython virtual machine. Imported modules can also use cached bytecode from .pyc files when the cache is valid. A key practical point is that details such as CPython bytecode and reference counting are implementation behavior, so I would not assume that every Python implementation works the same way.

CPython is the main program most people use to run Python code. Python itself is a set of language rules. CPython is one program that follows those rules and makes Python programs work on a computer. When you run a Python file, CPython reads it, prepares instructions that it can execute, and then runs those instructions. For imported files, it may also save some prepared work so it can reuse it later. Understanding this difference helps you avoid assuming that every program that runs Python must behave exactly like CPython.

1. Would you like me to focus on the normal CPython execution path or also compare it with other Python implementations?
2. Should I also explain CPython memory management and extension modules?

CPython is the reference and most widely used implementation of Python. A .py file contains Python source code. CPython normally compiles that source into bytecode in memory. Its virtual machine then executes the bytecode instructions.

When CPython imports a module, it can store valid cached bytecode in a .pyc file, usually under pycache. On a later import, CPython can reuse that cache when its validation rules say the cache is still valid. A .pyc file is therefore an optimization, not a different Python language.

CPython also supports native extension modules, commonly written in C, through interfaces provided by CPython. These modules are widely used by libraries that need native code.

For memory management, CPython primarily uses reference counting. It also has cyclic garbage collection for certain reference cycles. These are CPython implementation details.

The main production rule is simple. Depend on documented Python language behavior when portability matters. Depend on CPython specific behavior only when the application intentionally requires CPython.

A common mistake is saying that CPython is the Python language itself. Python defines the language rules, while CPython is one implementation of those rules. Another mistake is saying that CPython directly executes source text without compiling it to bytecode first. Candidates may also assume that running any .py file always creates a .pyc file. Cached .pyc files are mainly associated with imported modules and are not guaranteed to be written in every situation. Another mistake is treating reference counting, exact object cleanup timing, or CPython bytecode format as requirements for every Python implementation.

Start by saying that CPython is the reference and most widely used implementation of Python. Then explain the simple path from .py source code to bytecode to the CPython virtual machine. Mention .pyc caching, native extension modules, and reference counting briefly. Finish by clearly separating Python language guarantees from CPython specific implementation details.

The Python standard library is the collection of modules distributed with Python for common programming tasks. For example, pathlib works with file paths, json reads and writes JSON data, datetime handles dates and times, logging records application events, and unittest supports testing. These modules are different from built in functions such as len, third party packages installed from PyPI, and modules that belong to my own application. In practice, I first check whether the standard library already provides a suitable tool before adding another dependency.

The Python standard library is a large set of ready made tools distributed with Python. It helps programmers do common jobs without first installing another package. These tools can work with files, dates, stored data, tests, logs, databases, repeated values, and tasks that spend time waiting. This matters because a programmer can often solve a normal problem using tools that are already available in a Python installation. It can also keep an application simpler because fewer extra packages may be needed.

1. Would you like examples of common standard library modules?
2. Should I also explain how it differs from built in functions and packages installed from PyPI?

The standard library contains modules distributed with Python for common work. A program imports the module it needs. For example, pathlib helps manage file paths, collections provides useful container types, itertools helps work with iterators, json handles JSON data, datetime works with dates and times, logging records events, sqlite3 provides access to SQLite databases, unittest supports tests, and asyncio supports asynchronous programming.

It is important to separate this idea from three other things. Built in functions such as len and print are available without importing a normal module. Third party packages are separate projects that are commonly installed from PyPI. Application modules are files created as part of your own program.

Using the standard library can reduce external dependencies and simplify deployment. However, being in the standard library does not make a module the best choice for every problem. A third party package may provide features or an interface that better matches the requirement. In production, compare the requirements first and choose the simplest dependable option.

A common mistake is saying that every module available through import belongs to the standard library. That is not true because imported modules can also come from third party packages or the application itself. Another mistake is treating built in functions such as len or print as standard library modules. They are directly available in Python and do not require importing a normal module. Candidates may also assume that a standard library module is always better than a third party package. The correct choice depends on the required features, simplicity, maintenance needs, and production environment.

Start with one clear sentence: the standard library is the collection of modules distributed with Python for common tasks. Then name a few examples such as pathlib, json, datetime, and logging. Finish by clearly separating standard library modules from built in functions, packages installed from PyPI, and modules written inside the application.

A Python virtual environment gives one project an isolated Python context with its own package installation location. I normally create it with python -m venv .venv, activate it, and install that project's dependencies through its Python or pip command. This prevents packages for one project from interfering with another project. I keep the source code and dependency declarations, but I normally recreate the environment directory when needed.

A virtual environment gives one Python project its own place for the extra packages that project needs. This helps stop one project's packages from changing another project's setup. For example, two projects can use different versions of the same package. Each project can keep its own installed version. The environment folder is normally temporary and can be created again. The important things to keep are the source files and dependency declarations that describe what packages the project needs. This makes project setup easier to repeat on another machine or during an automated build.

1. Would you like me to explain the commands for creating and using the environment?
2. Should I also explain how dependency declarations help recreate it?

A virtual environment is an isolated Python context for one project. I can create one with python -m venv .venv. The environment has its own Python entry point and its own site packages directory. It still uses parts of the base Python installation, such as the standard library, so it is not a completely independent Python installation.

By default, packages from the base installation are not added to the environment's import path. After activation, the shell changes its command lookup so python and related commands normally use the environment. I then install dependencies through that environment so they go into its site packages directory.

Deactivation restores the shell's previous command lookup. Activation is optional because I can run the environment's Python executable directly.

I normally recreate the environment instead of committing it. Exact reproducibility also depends on package versions, Python version, operating system, architecture, package sources, and build inputs.

A common mistake is thinking a virtual environment is a completely independent Python installation. It still depends on the base Python installation that created it for parts such as the standard library. Another mistake is using the wrong pip command and installing packages into a different environment or the system installation. Developers may also commit the whole environment directory instead of keeping dependency declarations. Another mistake is assuming a simple dependency list guarantees an identical environment on every Python version, operating system, and machine architecture.

Start with isolation. Say that one project gets its own package installation location. Then explain creation, activation, package installation, deactivation, and why the environment directory is normally recreated instead of stored with the source code.