Top 65 Python Interview Questions and Answers (2026)

Python is a high-level, interpreted programming language known for readable syntax and a huge standard library. It's dynamically typed, supports procedural, object-oriented, and functional styles, and runs on every major platform.

Its popularity comes from low friction: code reads close to English, the ecosystem covers everything from web development (Django, Flask) to data science (pandas, NumPy) and machine learning (PyTorch, scikit-learn), and beginners become productive in days rather than months.

A list is mutable: you can add, remove, and change elements after creation. A tuple is immutable: once created, its contents can't change. Lists use square brackets, tuples use parentheses.

Because tuples are immutable they're hashable (usable as dictionary keys), slightly faster, and signal intent: this collection is fixed. Lists are for sequences that grow and change.

Mutable: list, dict, set, bytearray, and most user-defined objects. Immutable: int, float, bool, str, tuple, frozenset, and bytes.

This distinction drives real behavior: immutable objects can be dict keys, are safe to share between functions, and explain why string concatenation in a loop creates a new object every iteration. Mutability is also the root of Python's most famous gotcha, the mutable default argument.

Default argument values are evaluated once, at function definition, not on each call. A mutable default like a list is shared across every call that doesn't pass the argument, so mutations accumulate.

The fix is the None-sentinel pattern: default to None and create the list inside the function.

A dict maps hashable keys to values with average O(1) lookup, insertion, and deletion. Internally it's a hash table: the key's hash picks a slot, and collisions are resolved by open addressing.

Since Python 3.7, dicts preserve insertion order as a language guarantee. Keys must be hashable, which is why lists can't be keys but tuples can.

A shallow copy creates a new outer object but shares the inner objects: copying a list of lists gives you a new list whose elements are the same inner lists. A deep copy recursively copies everything, producing fully independent objects.

Use copy.copy() for shallow and copy.deepcopy() for deep. The classic bug is mutating a nested structure through what you thought was an independent copy.

== compares values; is compares identity, whether two names point to the same object in memory. Two equal lists satisfy == but not is.

The practical rule: use == for comparisons, and reserve is for None (if x is None), because None is a singleton.

Functions can be assigned to variables, passed as arguments, returned from other functions, and stored in data structures, exactly like any other object.

This is the foundation for decorators, callbacks, and functional tools like map and sorted's key argument. If you understand first-class functions, decorators stop being magic.

*args collects extra positional arguments into a tuple; **kwargs collects extra keyword arguments into a dict. They let a function accept a flexible number of arguments.

The names args and kwargs are convention; the stars are the syntax. The same stars also unpack in the other direction when calling a function.

A list comprehension builds a list from an iterable in one readable expression: [expr for item in iterable if condition]. It replaces a three-line append loop with one line and is usually faster.

Use them for simple transform-and-filter operations. When the logic needs multiple conditions or nested loops beyond one level, a regular loop reads better, and reviewers notice when a comprehension has been stretched past readability.

range() returns a lazy sequence object that generates numbers on demand instead of storing them. range(1_000_000_000) uses a few dozen bytes, not gigabytes.

It supports indexing, slicing, len(), and membership tests without materializing values. Wrap it in list() only when you genuinely need the whole list.

String immutability makes strings hashable (usable as dict keys), safe to share without copying, and allows interning optimizations. Any operation that seems to modify a string actually creates a new one.

The practical implication: building a large string with += in a loop is O(n squared) because every step copies. Collect parts in a list and join once.

PEP 8 is Python's official style guide: naming conventions, indentation (4 spaces), line length, import ordering, and spacing rules. It matters because Python code is read far more often than written, and a shared style makes every codebase navigable.

In practice teams enforce it with tools like flake8, black, or ruff rather than by memory. Saying that shows you've worked on real codebases.

Python is dynamically typed: variables get their type from the object they reference at runtime, and the same name can rebind to different types. It's also strongly typed: '1' + 1 raises rather than silently coercing.

Type hints (def total(prices: list[float]) -> float:) add optional annotations that tools like mypy check statically. The runtime ignores them; teams use them for correctness and editor support on larger codebases.

It runs a block only when the file is executed directly, not when it's imported. Python sets __name__ to "__main__" for the entry-point script and to the module's name on import.

This lets one file be both an importable module and a runnable script, which is why nearly every Python script ends with this guard.

try runs code that may fail; except catches named exception types; else runs when nothing was raised; finally always runs, for cleanup. Raise exceptions with raise, and prefer catching specific types over a bare except.

A bare except swallows everything, including KeyboardInterrupt and genuine bugs, which turns crashes into silent corruption. Specific exception types keep real failures visible.

with runs a block inside a context manager that guarantees setup and cleanup: the classic case is opening a file that closes itself even if the block raises.

Anything with __enter__ and __exit__ works: locks, database transactions, temporary directories. It replaces fragile try/finally cleanup with one line.

A lambda is an anonymous single-expression function: lambda x: x * 2. It's appropriate as a short throwaway passed to sorted, max, min, or filter, where naming a function would add noise.

The moment logic needs a second expression, a name, or a docstring, use def. PEP 8 explicitly prefers def when you're assigning a lambda to a name.

An iterable is anything you can loop over (lists, strings, dicts): it produces an iterator via iter(). An iterator is the object that actually yields items one at a time via next() and remembers its position.

Every iterator is an iterable, but not vice versa. A list can be looped repeatedly; an iterator is exhausted after one pass, a distinction that explains many 'my loop ran empty' bugs.

break exits the nearest loop entirely; continue skips to the loop's next iteration; pass does nothing and exists as a syntactic placeholder where a statement is required.

Bonus depth: loops can have an else clause that runs only when the loop completed without break, a genuinely obscure feature that interviewers occasionally probe.

in tests membership: 3 in [1, 2, 3] is True, "ell" in "hello" checks substrings, and key in dict checks keys, not values.

Performance matters here: membership in a list is O(n), in a set or dict it's O(1) average. Converting a lookup list to a set is one of the cheapest optimizations in Python.

Slicing extracts a portion of a sequence with [start:stop:step]; start is inclusive, stop is exclusive, and all three parts are optional. Negative indices count from the end.

Slices never raise IndexError for out-of-range bounds, and [::-1] is the idiomatic reversal. Slicing a list returns a new (shallow) copy, which is also the classic quick-copy idiom.

None is Python's null: a singleton object representing absence of a value. Functions without an explicit return produce None.

Check with is None, not == None: identity is the intended semantic, is can't be overridden by a class's __eq__, and it's the PEP 8 rule. Also don't confuse None with falsy values like 0 or an empty list when both are possible inputs.

The lookup proceeds Local, Enclosing, Global, Built-in: the function's own scope first, then any enclosing function, then the module, then built-ins.

Assignment creates a local name by default, which is why reading a global works but assigning to it needs the global keyword, and modifying an enclosing function's variable needs nonlocal. This question is the gateway to closures.

f-strings (formatted string literals, f"Hello {name}") embed expressions directly in strings. They're the preferred formatting style since Python 3.6: more readable than %-formatting or .format(), and faster because they're evaluated at compile time to bytecode.

They support any expression, format specifiers (f"{price:.2f}"), and since 3.8 the debugging form f"{value=}" that prints both the expression and its value.

A decorator is a function that takes a function and returns a modified or wrapped version of it. The @decorator syntax is shorthand for func = decorator(func) at definition time.

Decorators handle cross-cutting concerns (timing, caching, auth checks, logging) without touching the wrapped function's body. Use functools.wraps so the wrapper preserves the original's name and docstring.

A generator is a function that yields values one at a time instead of returning once; each next() resumes execution right after the last yield, with all local state intact. It produces values lazily, so memory stays flat regardless of sequence length.

Use generators for large or infinite streams: reading huge files line by line, paginated APIs, pipelines. Generator expressions ((x*x for x in data)) are the comprehension-shaped version.

The GIL is a mutex in CPython that lets only one thread execute Python bytecode at a time. Threads still help for I/O-bound work (the GIL is released while waiting on network or disk), but CPU-bound threads can't run in parallel.

For CPU parallelism, use multiprocessing (separate processes, separate GILs) or push the work into C-backed libraries like NumPy that release the GIL internally. Recent CPython versions ship an experimental free-threaded build, worth as awareness, but the standard answer above is what production Python matters.

Threading: I/O-bound work with a moderate number of tasks, or when you must call blocking libraries. Multiprocessing: CPU-bound work that needs real parallelism. Asyncio: I/O-bound work at high concurrency (thousands of connections) where cooperative single-threaded scheduling beats thread overhead, provided your libraries are async-aware.

The honest interview answer includes the cost side: multiprocessing pays serialization and memory overhead, and asyncio requires an async ecosystem top to bottom, since one blocking call stalls the whole event loop.

CPython uses reference counting as its primary mechanism: every object tracks how many references point to it, and when the count hits zero the object is freed immediately. A supplementary cyclic garbage collector handles reference cycles that counting alone can't free.

Objects live on a private heap managed by the interpreter; small objects go through the pymalloc allocator. You rarely manage memory manually, but the model explains __del__ timing, why cycles need the gc module, and why del only removes a name.

A closure is a function that captures variables from its enclosing scope and keeps them alive after the outer function returns. The inner function 'closes over' those names.

Closures power decorators, factory functions, and callbacks with baked-in state. The classic gotcha: closures capture variables, not values, so loop variables captured in lambdas all see the final value unless you bind them as default arguments.

Classes define attributes and methods; instances get their own __dict__ of attributes; methods receive the instance as self explicitly. Python supports inheritance (including multiple), polymorphism through duck typing, and encapsulation by convention (a leading underscore means internal, double underscore triggers name mangling).

The Pythonic emphasis is duck typing: code cares whether an object supports the needed behavior, not what class it is. That's why interfaces are informal and isinstance checks are used sparingly.

Instance methods receive self and act on one object. Class methods receive cls and act on the class, most commonly as alternative constructors. Static methods receive neither; they're plain functions namespaced inside the class for organization.

Dunder methods (double underscore: __init__, __repr__, __eq__) let your objects plug into Python's syntax: operators, len(), iteration, string display, context managers. Implementing them is how a custom class behaves like a built-in.

The everyday set: __init__ (construction), __repr__ (debugging display, aim for unambiguous), __eq__ and __hash__ (equality and dict/set membership, always together), __len__ and __iter__ (container behavior), __enter__/__exit__ (with-statement support).

Python linearizes the class hierarchy with the C3 algorithm: each class's MRO is a single ordered list that respects every parent's order, child before parent, and each class appearing once. Method lookup walks that list; ClassName.__mro__ shows it.

super() follows the MRO, not simply 'the parent', which is what makes cooperative multiple inheritance work: every class in the chain calls super() and the MRO guarantees each __init__ runs exactly once.

An abstract base class (via the abc module) defines methods subclasses must implement; instantiating a class with unimplemented abstract methods raises immediately. Use ABCs when you're designing a plugin-style interface and want loud, early failure instead of a missing-method crash at runtime.

The counterweight to mention: idiomatic Python often prefers duck typing and Protocols (structural typing from the typing module) over nominal ABCs. Knowing both options and the trade-off is the senior-sounding answer.

@property turns a method into an attribute-style accessor: callers write obj.total instead of obj.total(), while your code computes, validates, or caches behind the scenes. Paired @total.setter intercepts assignment.

Its real value is evolution: a plain attribute, and if validation is needed later, add a property without breaking a single caller comes first. That's the answer to 'why not just getters and setters like Java?'.

Subclass Exception (never BaseException), name it with an Error suffix, and raise it where the failure happens. A small exception hierarchy per package (a base error plus specific subclasses) lets callers catch at whatever granularity they need.

Also worth saying: chain causes with raise NewError(...) from original so tracebacks keep the root cause.

A module is a single .py file; a package is a directory of modules, traditionally marked by __init__.py, that creates a namespace hierarchy (package.module.function).

__init__.py runs on first import and commonly curates the package's public surface by re-exporting key names. Imports resolve via sys.path, which explains most 'ModuleNotFoundError' debugging.

A virtual environment is an isolated Python installation per project: its own interpreter link and site-packages, so project A's dependency versions can't collide with project B's. python -m venv .venv creates one; activation just adjusts PATH.

Production answers pin dependencies (requirements.txt or a lock file from a tool like poetry or uv) so environments are reproducible on every machine and in CI.

enumerate(iterable) yields (index, item) pairs, replacing manual counters. zip(a, b) pairs elements from multiple iterables, stopping at the shortest; zip(*pairs) inverts it, the idiomatic 'unzip'.

list.sort() sorts in place and returns None; sorted() works on any iterable and returns a new list. Both take key (a function computing each element's sort value) and reverse, and both are stable: equal elements keep their relative order.

Stability is the underrated half of this answer: sorting by secondary key then primary key produces a correct multi-level sort precisely because Timsort is stable.

Counter (frequency counting with most_common), defaultdict (auto-initializing values, ends the key-check dance), deque (O(1) appends and pops at both ends, the right queue), and namedtuple or dataclasses for lightweight records.

Reaching for these instead of reimplementing them is a strong signal of real-world fluency; Counter alone collapses a dozen-line loop to one line.

Python passes references to objects (call it pass-by-object-reference): the parameter and the caller's variable The same list, so in-place mutation is visible to both. Rebinding the parameter (param = [...]) only changes the local name.

The distinction to articulate is mutation versus rebinding. Functions that mutate arguments says so loudly; otherwise return a new object and leave inputs alone.

The json module: json.dumps(obj) to a string, json.loads(s) back to Python objects, with dump/load for file handles. Dicts, lists, strings, numbers, booleans, and None map directly; anything else (datetimes, custom classes) needs a default function or explicit conversion.

Mention pickle only with its warning label: it executes arbitrary code on load, so it's for trusted internal data only, never user input.

pytest is the practical standard: test files named test_*.py, plain functions with assert statements, fixtures for setup, parametrize for input matrices, and one command to run everything. The standard library's unittest works everywhere but needs more ceremony.

The technical detail is testing behavior rather than implementation, and mocking external boundaries (network, clock, database) with unittest.mock or pytest fixtures.

The walrus operator assigns and returns a value inside an expression, letting you capture a result where a plain statement can't go: while chunk := f.read(8192): processes a stream without priming reads or repeated calls.

Use it where it removes duplication (loop conditions, comprehension filters that reuse a computed value); skip it where it just compresses two clear lines into one clever one.

CPython compiles source to bytecode (the .pyc files cached in __pycache__), then a stack-based virtual machine interprets that bytecode. So Python is both compiled and interpreted; the compilation just targets the VM rather than the CPU.

Senior-level extras: the bytecode cache invalidates on source change, import runs a module's top level exactly once per process, and alternative runtimes (PyPy's JIT) change the execution story without changing the language.

A descriptor is any class implementing __get__, __set__, or __delete__; when an instance of it sits on a class, attribute access on instances routes through those methods. This is the machinery beneath properties, methods, classmethod, and staticmethod.

@property is a data descriptor built for you. Writing a custom descriptor earns its keep when the same attribute behavior (validation, units, lazy loading) must repeat across many attributes or classes.

A metaclass is the class of a class: type by default. It intercepts class creation itself, letting you validate, register, or rewrite classes as they're defined. ORMs and serialization frameworks use metaclasses to turn declarative class bodies into machinery.

The honest production-ready answer: almost never write one. __init_subclass__ and decorators cover most registration and validation cases with far less magic. Knowing the mechanism but reaching for simpler tools first is the signal the question needs.

An event loop runs coroutines cooperatively: await yields control back to the loop, which multiplexes thousands of paused coroutines over OS-level I/O readiness (epoll/kqueue). Nothing runs in parallel; everything interleaves at await points on one thread.

The two production rules that follow: any blocking call (requests, time.sleep, heavy CPU) freezes every coroutine, so blocking work goes to run_in_executor or async-native libraries; and structured concurrency (gather, TaskGroup) beats fire-and-forget tasks that swallow exceptions.

Measure first: cProfile or py-spy for CPU hot spots, tracemalloc for memory, and a realistic workload, because intuition about bottlenecks is usually wrong. Then fix in order of impact: better algorithms and data structures, batching I/O, caching (functools.lru_cache), vectorizing with NumPy or pandas, and only then parallelism.

the check is for the discipline (profile, don't guess) and the escalation ladder ending at 'rewrite the hot loop in C/Rust or use a faster runtime' as the last resort, not the first.

Yes, practically: unbounded caches and module-level containers that only grow, reference cycles involving __del__, closures capturing large objects, and C-extension leaks all inflate long-running processes even with garbage collection.

Diagnosis: tracemalloc snapshots diffed over time to find the growing allocation sites, gc.get_objects()/objgraph for cycle hunting, and process-level RSS tracking to confirm. The fix is usually a bounded cache (lru_cache maxsize, TTL) or breaking the cycle with weakref.

dataclasses generate __init__, __repr__, and __eq__ from annotated fields: the default for structured records in modern code. namedtuple gives immutable, tuple-compatible records with lower memory. Pydantic adds runtime validation and parsing, the right tool at trust boundaries (APIs, config). attrs is the feature-richer ancestor of dataclasses, still common in libraries.

The judgment call interviewers probe: validation at boundaries (Pydantic), plain data inside the system (dataclasses), and frozen=True when immutability communicates intent.

Incrementally: run mypy (or pyright) with permissive settings, type the boundaries first (public APIs, data models), enforce no-new-untyped-code in CI, and ratchet strictness module by module. Typed dicts, Protocols, and Optional discipline pay for themselves at boundaries fastest.

The failure mode to name: a big-bang typing sprint that produces thousands of errors and gets abandoned. Gradual typing is a migration, and the tooling (per-module overrides) exists precisely for that.

pyproject.toml is the single source of truth: project metadata, dependencies, and build backend. Build produces a wheel (prebuilt) and sdist; publishing goes to PyPI via twine or the build tool. Lock files (poetry, uv, pip-tools) pin the full dependency graph for reproducibility.

For applications, the deliverable is usually a container image with a locked environment rather than a published package; saying that distinction out loud indicates production experience.

Two ways: a class with __enter__ and __exit__ (where __exit__ receives exception info and can suppress by returning True), or the lighter @contextlib.contextmanager decorator around a generator that yields exactly once, with try/finally providing the cleanup.

lru_cache memoizes a function keyed by its arguments, evicting least-recently-used entries past maxsize. It's the one-line fix for repeated pure computation.

The bites: arguments must be hashable; caching methods keeps instances alive (leak via self) unless you use cached_property or a per-instance cache; unbounded (maxsize=None) caches grow forever; and caching anything impure trades correctness for speed.

Implement __iter__ returning an iterator, and the easiest correct iterator is a generator: write __iter__ as a generator function and Python handles __next__ and StopIteration for you. Each call to __iter__ should return a fresh iterator so the object supports multiple simultaneous loops.

Objects that compare equal must have equal hashes, and an object's hash must never change while it's in a dict or set. Defining __eq__ without __hash__ makes instances unhashable (Python sets __hash__ to None), which is correct for mutable objects and a bug for value objects.

Practical guidance: hash the same immutable tuple of fields you compare in __eq__, or use frozen dataclasses which generate both consistently.

Environment variables carry deployment-specific values, parsed and validated once at startup into a typed settings object (Pydantic Settings is the common choice); secrets come from the platform's secret manager, never the repo; and the config object is passed explicitly rather than imported globally, which keeps tests trivial.

The anti-patterns worth naming: config.py files mutated at import time, scattered os.environ reads deep in the call stack, and .env files leaking into images.

Reproduce or observe first: logs and traces around the slow path, then py-spy dump/top on the live process for a no-restart flame view (is it CPU, a lock, or waiting on I/O?). Correlate with recent deploys and dependency changes; check the usual suspects: N+1 queries, missing timeouts, retry storms, GIL-bound CPU work on a threaded server.

Then fix at the right layer with a measurement to confirm. The technical sequence matters more than any single tool: observe, hypothesize, verify, fix, confirm.

A weak reference points to an object without increasing its reference count, so it doesn't keep the object alive. When the object is collected, the weakref returns None.

Use cases: caches and registries that shouldn't immortalize their entries (WeakValueDictionary), observer patterns where listeners may die, and breaking reference cycles between parent and child structures.

Options in ascending effort: ctypes/cffi to call existing shared libraries, Cython to compile annotated Python to C, and hand-written CPython extension modules (or Rust via PyO3, the modern favorite). NumPy-style vectorization often removes the need entirely.

Drop down when a profiled hot loop is pure computation that resists vectorization, and remember extensions can release the GIL around pure-C sections, which is how libraries achieve real threaded parallelism.

Clarify the requirements first (per-user or global, burst tolerance, distributed or single process), then pick the algorithm: a token bucket gives smooth rates with burst capacity and is a few lines with a timestamp and a counter. Single process: store buckets in a dict keyed by user with a lock. Distributed: the state moves to Redis with atomic Lua or INCR+EXPIRE, because per-process memory can't see global traffic.

The closing step is the operational edges: clock behavior, what to return on rejection (429 plus Retry-After), and metrics on rejects. Structuring the answer clarify, algorithm, storage, edges is what the question is really scoring.