Python interview questions

An immutable object can't be changed after it's created; "changing" it makes a new object. A mutable object can be changed in place.

Why it matters:

• Aliasing: two names can point to the same mutable object, so a change through one is visible through the other.
• Dictionary keys and set items must be hashable, which in practice means immutable: a tuple can be a key, a list can't.
• Default arguments that are mutable are a classic bug (see that question).
• Immutable objects are safe to share between threads and functions.

• == compares values: do the two objects have equal contents? (It calls __eq__.)
• is compares identity: are they the same object in memory? (Same id().)

Use is only for singletons: None, True, False.

Trap: small integers and some strings are cached by CPython, so is can seem to work by accident:

Never rely on that: compare numbers and strings with ==.

Default values are evaluated once, when the function is defined, not each time it's called. A mutable default (like [] or {}) is therefore shared between calls:

The fix: use None as the default and create a new object inside the function:

The same applies to dict, set and any mutable object, and to defaults like datetime.now(), which is fixed at definition time.

Linters such as Ruff and Pylint flag this pattern automatically.

They let a function accept a variable number of arguments:

• *args collects extra positional arguments into a tuple.
• **kwargs collects extra keyword arguments into a dict.

The same symbols unpack when calling a function:

Full parameter order: def f(pos_only, /, normal, *args, kw_only, **kwargs).

• Parameters before / are positional-only.
• Parameters after * or *args are keyword-only.

A common use is a wrapper or decorator that passes everything through: return func(*args, **kwargs).

• A shallow copy creates a new outer object, but the items inside are shared with the original.
• A deep copy recursively copies everything, so nothing is shared.

Ways to make a shallow copy: lst[:], list(lst), lst.copy(), dict(d), d.copy(), {**d}, copy.copy(x).

When it matters: copying nested structures such as a list of lists, a dict of lists, or JSON-like data.

A classic bug with the same cause:

deepcopy is slower and handles cycles. Classes can customise it with __copy__ and __deepcopy__.

Neither, exactly. Python passes object references by value, often called pass by assignment or "pass by object reference". The parameter becomes a new name for the same object.

• If the function changes a mutable object in place, the caller sees the change.
• If the function rebinds the parameter to a new object, the caller doesn't see it.

So a function can't change a caller's variable to point to something else; it can only change mutable objects, or return new values (x = increment(x)).

Good practice: avoid surprising callers by mutating their arguments. Either document it clearly or work on a copy and return the result.

In an if or while, any object can be tested. These are falsy:

• None and False
• zero of any number type: 0, 0.0, 0j, Decimal(0)
• empty collections: "", [], (), {}, set(), range(0)

Everything else is truthy, including "0", "False", [0] and -1.

Custom classes decide with __bool__, or __len__ if there's no __bool__.

Pythonic checks:

Trap: if value: treats 0 and "" the same as None. When 0 or an empty string is a valid value, use if value is not None:.

and and or return one of their operands, not just True/False: name = user_input or "Guest".

Python looks up names using the LEGB rule, in this order:

1. Local: inside the current function.
2. Enclosing: in any outer function (for nested functions).
3. Global: at the top level of the module.
4. Built-in: names like len and print.

Assigning to a name inside a function makes it local to that function, unless you declare otherwise:

Without global or nonlocal, count += 1 raises UnboundLocalError, because the assignment makes count local, and it's read before it's set.

In real code, avoid global: pass values in and return results, or use a class.

Good practices:

• Catch specific exceptions, not bare except: (which also catches KeyboardInterrupt).
• Keep the try block small, so you don't accidentally catch errors from other lines. Put follow-up code in else.
• Use with (context managers) instead of finally for closing files and locks.
• Re-raise with plain raise to keep the original traceback; chain with raise NewError(...) from e to add context.
• Define your own exceptions by subclassing Exception.

EAFP vs LBYL: Python style often prefers "easier to ask forgiveness than permission" (try it and handle the exception) over "look before you leap" (check first), especially where the check could become out of date (a file deleted between the check and the open).

Follow-ups:

• Single-item tuple: (5,). The comma makes the tuple, not the parentheses: (5) is just 5.
• "Is a tuple always immutable?" The tuple is, but it can hold mutable items: in t = ([1], 2), t[0].append(3) works.
• Named tuples (collections.namedtuple, typing.NamedTuple) give tuple items names: p.x instead of p[0].

A dict is a hash table:

1. Python calls hash(key) to get an integer.
2. That number picks a slot in an internal array.
3. If the slot is taken by a different key (a collision), it probes other slots.
4. To find a key later, it hashes again, goes to the slot, and checks equality with ==.

That's why lookups, inserts and deletes are O(1) on average, regardless of size.

Keys must be hashable: their hash must never change, and equal keys must have equal hashes. Mutable objects like lists aren't hashable, because changing them would change their hash and the dict would look in the wrong slot.

Other facts interviewers like:

• Since Python 3.7, dicts keep insertion order (guaranteed by the language).
• Custom classes are hashable by identity by default. If you define __eq__, also define __hash__ (or use a frozen dataclass).
• 1, 1.0 and True are equal and have the same hash, so they're the same key:

Sets use the same hash-table idea, storing keys without values.

A comprehension builds a collection from an iterable in one readable expression: [expression for item in iterable if condition].

A generator expression uses parentheses and produces values lazily, without building a list in memory:

When not to use them:

• When the logic needs several lines, multiple conditions or side effects: a normal for loop is clearer.
• Deeply nested comprehensions are hard to read; two levels is usually the limit.
• Don't use a list comprehension only for side effects ([print(x) for x in items]).

Comprehensions are usually a bit faster than an equivalent for loop with append, because the loop runs in optimised bytecode.

Both accept key= (a function giving the value to sort by) and reverse=True.

Key facts:

• The algorithm is Timsort: O(n log n) worst case, and very fast on data that's already partly sorted.
• It's stable: items with equal keys keep their original order. That lets you sort by several keys in passes (secondary key first, then primary).
• operator.itemgetter(1) and operator.attrgetter("age") are fast alternatives to lambdas.
• For the top few items of a big list, heapq.nlargest(k, items, key=...) is faster than sorting everything.

The most common performance bug is a membership test on a list inside a loop:

Other things to know:

• deque gives O(1) appends and pops at both ends.
• heapq gives O(log n) push and pop of the smallest item, for priority queues.
• String concatenation in a loop can be O(n²); collect pieces in a list and "".join(parts).
• "Amortised O(1)" for append: lists over-allocate, so occasional resizes are spread across many appends.

sequence[start:stop:step] returns a new sequence from start up to, but not including, stop. Any part can be left out.

Slicing works on lists, tuples, strings, range, bytes and many libraries' types (NumPy, pandas).

On lists, you can also assign to a slice:

Slices create copies for lists and strings (O(k) for k items). For huge data, itertools.islice or memoryview avoids copying.

A decorator is a function that takes a function and returns a new function that adds behaviour around it, without changing the original code. @decorator above a function is shorthand for func = decorator(func).

A decorator with arguments needs one more level: a function that returns the decorator.

Common uses: logging, timing, caching (functools.lru_cache), retries, access checks, and frameworks registering routes (@app.get("/") in Flask and FastAPI).

Built-in decorators: @property, @staticmethod, @classmethod, @dataclass, @functools.cache.

A generator is a function that uses yield to produce values one at a time, pausing between them. Calling it returns a generator object; nothing runs until you ask for the first value.

Why use them:

• Memory: values are produced on demand, so you can process huge files or infinite streams without loading everything.
• Pipelines: chain small generators, each doing one step.

Things to know:

• A generator can be iterated only once.
• yield from other() delegates to another generator.
• Generator expressions: (x * x for x in data).
• itertools (islice, chain, groupby, count) is full of generator-based tools.

• An iterable is anything you can loop over: it has __iter__(), which returns an iterator. Lists, strings, dicts, files and ranges are iterables.
• An iterator is the object that does the looping: it has __next__(), which returns the next item or raises StopIteration. It remembers its position, and is used up after one pass.

A for loop calls iter() once, then next() until StopIteration:

Writing your own iterable class:

Gotcha: zip, map, filter, file objects and generators are iterators, so they're exhausted after one use. Convert to a list if you need to loop again.

A lambda is a small, anonymous function written in one expression: lambda arguments: expression.

map applies a function to every item; filter keeps items where the function returns true. Both return lazy iterators:

Guidelines:

• Use lambdas for short throwaway functions, mostly as key= arguments or callbacks.
• If you'd assign a lambda to a name, write a def: it gets a real name in tracebacks.
• Prefer comprehensions over map/filter with a lambda.
• functools.reduce exists, but sum, max, any, all or a loop are usually clearer.

A closure is an inner function that remembers variables from the enclosing function, even after the outer function has returned.

Uses: function factories, callbacks that carry configuration, decorators (the wrapper is a closure over func), and simple private state.

The classic late-binding trap: closures capture variables, not values. In a loop, all functions see the variable's final value:

To change a captured variable inside the inner function, declare it nonlocal.

A context manager sets something up and guarantees cleanup, even if an error happens. It's what the with statement uses:

Write one as a class with __enter__ and __exit__:

Or, more simply, with contextlib.contextmanager and a generator: code before yield is setup, code after is cleanup.

Common uses: files, locks, database transactions, network connections, temporary directories, and timers. contextlib also offers suppress(SomeError) and ExitStack for handling several resources.

functools.lru_cache (or functools.cache, unlimited) memoises a function: it stores results by arguments, so repeated calls with the same arguments return instantly.

Rules for caching:

• Arguments must be hashable (no lists or dicts).
• Only cache pure functions: same input, same output, no side effects.
• maxsize limits memory; least-recently-used entries are dropped first.
• On methods, the cache keeps self alive. Be careful with many short-lived objects.

functools.partial creates a new function with some arguments pre-filled:

partial is handy for callbacks and key= functions that need extra arguments.

Why cls matters: a classmethod called on a subclass creates an instance of that subclass.

Examples from the standard library: dict.fromkeys(), datetime.fromisoformat() and int.from_bytes() are classmethods.

Dunder ("double underscore") methods like __init__ and __len__ let your classes work with Python's built-in syntax and functions. Python calls them for you: len(x) calls x.__len__(), a + b calls a.__add__(b).

Always define a helpful __repr__. Or let @dataclass generate __init__, __repr__ and __eq__ for you.

A class can inherit from one or more parent classes. When you call a method, Python searches the classes in the Method Resolution Order (MRO), which it computes with the C3 linearization algorithm: each class appears before its parents, and parents keep the order you listed them in.

Notice that super() in A called B, not Base. super() means "the next class in the MRO of the object", not "my parent". That's what makes cooperative multiple inheritance work: in the diamond above, Base.greet runs exactly once.

super() in __init__:

Practical advice:

• Prefer composition (having an object) over deep inheritance trees.
• Use multiple inheritance mainly for small mixins that add one behaviour (JsonMixin, LoggingMixin).
• Always call super().__init__(...) when overriding __init__, and accept **kwargs in cooperative hierarchies.

@dataclass generates the boilerplate for classes that mainly hold data: __init__, __repr__ and __eq__, plus optional ordering, immutability and more.

Useful options:

Alternatives: typing.NamedTuple (immutable, tuple-like); Pydantic models when you need validation and parsing of external data (APIs, config); attrs for more features.

@property turns a method into an attribute-like accessor. Callers write obj.value, but your code runs, so you can compute values or validate assignments without changing the public interface.

Why it's useful: start with a plain public attribute. If you later need validation, switch to a property and no calling code changes. That's why Python doesn't need Java-style get_x() / set_x() methods.

Use functools.cached_property for an expensive value computed once on first access.

Duck typing: "if it walks like a duck and quacks like a duck, it's a duck". Python cares whether an object has the methods you call, not what class it is.

Abstract base classes (abc.ABC) define a required interface and refuse to instantiate subclasses that don't implement it:

Protocols (typing.Protocol) give duck typing static type checking: any class with matching methods satisfies the protocol, with no inheritance needed. Tools like mypy and Pyright check it.

By default, each instance stores its attributes in a per-object dictionary, __dict__. Declaring __slots__ replaces that dict with a fixed set of attribute slots:

• less memory per instance, which matters with millions of objects;
• slightly faster attribute access;
• no new attributes can be added by accident (typos raise an error).

Trade-offs:

• No dynamic attributes, and no __weakref__ unless you add it to the slots.
• Every class in an inheritance chain needs its own __slots__, or instances get a __dict__ anyway.
• Some libraries that rely on __dict__ (certain pickling or copying tricks) need extra care.

Easy way to use it: @dataclass(slots=True) (Python 3.10+).

Use it for small, numerous objects (points, records, graph nodes). For ordinary classes, the default is fine.

Both, in a way. CPython (the standard implementation):

1. Compiles your source code to bytecode, a simpler, lower-level instruction set. It's cached in __pycache__/*.pyc files for imported modules.
2. Interprets that bytecode in a loop in the Python virtual machine.

You can see the bytecode with dis:

Other implementations:

Why Python is slower than C or Java for tight loops: dynamic typing (every operation checks types at run time), objects for every value, and interpretation overhead. The usual fixes are to push work into C-backed libraries (NumPy, pandas), use built-ins, or use PyPy, Cython or Numba for hot code.

CPython uses two mechanisms:

1. Reference counting (the main one). Every object counts how many references point to it. When the count drops to zero, the object is freed immediately.

2. A cyclic garbage collector. Reference counting can't free cycles (A refers to B, B refers to A, nothing else refers to either). The gc module periodically finds and frees unreachable cycles. It's generational: new objects are checked often, long-lived ones rarely.

Other points:

• Memory freed by Python is often kept by Python's allocator (pymalloc) for reuse, so a process's memory use may not shrink much.
• Leaks in Python usually mean objects are still referenced: growing global caches, lists that are never cleared, closures or callbacks holding big objects.
• Tools: tracemalloc (which lines allocate memory), gc.get_objects(), objgraph, memory profilers.
• weakref lets you refer to an object without keeping it alive, which is useful for caches.

The Global Interpreter Lock (GIL) is a lock in CPython that allows only one thread to run Python bytecode at a time. It keeps CPython's internals (like reference counts) simple and safe.

The effect:

# CPU-bound work: use processes to use several cores
from concurrent.futures import ProcessPoolExecutor
 
def count_primes(limit):
    return sum(1 for n in range(2, limit) if all(n % d for d in range(2, int(n ** 0.5) + 1)))
 
if __name__ == "__main__":
    with ProcessPoolExecutor() as pool:
        results = list(pool.map(count_primes, [200_000] * 4))   # 4 processes, 4 cores
    print(results)

Points that impress interviewers:

• The GIL doesn't make your code thread-safe: operations like counter += 1 are several bytecode steps, and a thread switch can happen between them. You still need locks.
• Python 3.13 introduced an optional free-threaded build (PEP 703) without the GIL; it's becoming more mature in newer releases.
• Other implementations differ: Jython and IronPython have no GIL; PyPy has one.

import asyncio
import httpx   # an async HTTP client
 
async def fetch(client, url):
    response = await client.get(url)     # other tasks run while this waits
    return url, response.status_code
 
async def main():
    urls = ["https://example.com"] * 20
    async with httpx.AsyncClient() as client:
        results = await asyncio.gather(*(fetch(client, u) for u in urls))
    print(results)
 
asyncio.run(main())

How to choose:

1. CPU-bound? multiprocessing / ProcessPoolExecutor (or vectorise with NumPy).
2. I/O-bound with async libraries available (web servers like FastAPI, httpx, asyncpg)? asyncio.
3. I/O-bound with blocking libraries (requests, most database drivers)? ThreadPoolExecutor.

concurrent.futures gives threads and processes the same simple interface (submit, map). In async code, run unavoidable blocking calls with await asyncio.to_thread(func).

• async def defines a coroutine function. Calling it returns a coroutine object; it doesn't run yet.
• await runs another coroutine and pauses the current one until the result is ready. While paused, the event loop runs other tasks.
• Everything runs in one thread. Tasks switch only at await, so there are no surprise thread switches.

import asyncio
import time
 
async def brew(name, seconds):
    print(f"start {name}")
    await asyncio.sleep(seconds)       # non-blocking wait: other tasks run
    print(f"done {name}")
    return name
 
async def main():
    start = time.perf_counter()
    results = await asyncio.gather(     # run concurrently
        brew("tea", 2),
        brew("coffee", 3),
        brew("toast", 1),
    )
    print(results, f"{time.perf_counter() - start:.1f}s")   # about 3s, not 6s
 
asyncio.run(main())

Key points:

• await asyncio.sleep(1) lets other tasks run; time.sleep(1) blocks the whole loop. The same goes for blocking libraries like requests. Use async libraries (httpx, aiohttp, asyncpg) or asyncio.to_thread.
• asyncio.gather and asyncio.TaskGroup (3.11+) run coroutines concurrently. asyncio.create_task starts one in the background.
• asyncio.timeout(5) (3.11+) or asyncio.wait_for add timeouts.
• asyncio.Semaphore limits concurrency, e.g. at most 10 requests at once.
• Async helps with waiting (I/O), not with CPU work.

Type hints annotate the expected types of variables, parameters and return values. Python doesn't enforce them at run time; they're used by tools: type checkers (mypy, Pyright), editors (autocomplete, error highlighting) and libraries like Pydantic and FastAPI, which read them to validate data.

A type checker would flag greet(123) before the code ever runs.

Modern syntax (3.9 / 3.10+): list[int], dict[str, int], int | None instead of List, Dict, Optional.

Useful extras: TypedDict (dicts with known keys), Literal["red", "green"], Protocol (structural typing), TypeVar and generics, Callable[[int], str].

Why use them: catch bugs early, better editor help, and self-documenting code, especially in larger codebases and teams. Many teams run mypy or Pyright in CI.

match (Python 3.10+) compares a value against patterns that can check structure and extract values at the same time. It's more than a switch statement.

It works on dicts and classes too, which suits JSON-like data:

Gotcha: a bare name in a pattern captures a value; it doesn't compare against a variable. case RED: matches anything and assigns it to RED. Use dotted names (case Color.RED:) or literals to compare.

A virtual environment is an isolated folder with its own Python interpreter and installed packages. Each project gets its own versions of libraries, so projects don't conflict and you don't touch the system Python.

python -m venv .venv                 # create
source .venv/bin/activate            # activate (Windows: .venv\Scripts\activate)
pip install requests pandas          # installs only into this environment
pip freeze > requirements.txt        # record exact versions
pip install -r requirements.txt      # recreate elsewhere

Modern tools:

Good practices:

• Keep dependencies in pyproject.toml (the modern standard), with a lock file for exact, reproducible versions.
• Never commit the .venv folder; add it to .gitignore.
• Pin versions for applications; use version ranges for libraries you publish.
• In Docker, you often skip a venv, or use one in a multi-stage build.

pytest is the most popular framework: tests are plain functions with plain assert statements.

# shop.py
def total(prices, discount=0.0):
    if not 0 <= discount < 1:
        raise ValueError("discount must be between 0 and 1")
    return round(sum(prices) * (1 - discount), 2)
 
# test_shop.py
import pytest
from shop import total
 
def test_total_without_discount():
    assert total([10, 20]) == 30
 
@pytest.mark.parametrize("prices, discount, expected", [
    ([100], 0.1, 90.0),
    ([], 0.5, 0.0),
    ([19.99, 0.01], 0, 20.0),
])
def test_total_with_discounts(prices, discount, expected):
    assert total(prices, discount) == expected
 
def test_invalid_discount():
    with pytest.raises(ValueError):
        total([10], discount=1.5)

Run with pytest in the project folder; it finds test_*.py files automatically.

Key features to mention:

Good testing habits: test behaviour, not implementation details; keep tests fast and independent; mock at the boundaries (network, clock), not your own logic; and run tests in CI on every pull request.

The standard library's unittest (class-based, self.assertEqual) also works, and pytest can run those tests too.

Pythonic code uses Python's features and idioms the way they're meant to be used: clear, concise and readable (see import this, "The Zen of Python", and the PEP 8 style guide).

More idioms:

• with for resources (files, locks).
• Unpacking: first, *rest = items.
• is None, not == None.
• EAFP: try/except KeyError where appropriate.
• Small functions, descriptive names, snake_case for functions and variables.

Tools that enforce style: Ruff (fast linter and formatter), Black (formatter), plus a type checker.

Brute force checks every pair: O(n²) time.

Better: one pass with a dictionary of numbers already seen. For each number, check whether its complement (target - n) was seen before: O(n) time, O(n) memory.

What interviewers look for:

1. Clarify: can numbers repeat? Is there always exactly one answer? Can you use the same element twice? (No: that's why we check before adding n to seen.)
2. Start with the brute force, state its complexity, then improve it.
3. Test edge cases out loud: duplicates ([3, 3]), no solution, negative numbers.

Variation: if the list is sorted, use two pointers from both ends: O(n) time and O(1) memory.

Normalise the text, count with Counter, then take the top k:

Complexity: counting is O(n) for n words. most_common(k) uses a heap, so it's O(m log k) for m distinct words, which is better than sorting all of them when k is small.

Without Counter, to show you know the mechanics:

Follow-ups to discuss:

• Ties: sort by (-count, word) for a stable, alphabetical tie-break.
• Stop words: filter out "the", "a" and so on.
• Huge files: read line by line (a generator), so the whole file never sits in memory.
• Too big for one machine: split the counting across workers and merge the counters (the classic MapReduce word count).

Clean the string, then compare it with its reverse:

That's O(n) time and O(n) extra memory. With two pointers, you can use O(1) extra memory by skipping non-alphanumeric characters from both ends:

Things to say: clarify the rules first (case? spaces? Unicode?), mention both approaches and their complexity, and test the edge cases: an empty string, one character, only punctuation.

Recursive generator: yield items, and recurse into anything that's a list.

Iterative version with a stack, which avoids Python's recursion limit (about 1,000 levels) for very deep nesting:

Discussion points:

• Why not flatten strings: a string is iterable, and each character is also a string, so checking for "any iterable" would recurse forever. Checking isinstance(item, list) (or excluding str and bytes) avoids that.
• For exactly one level of nesting, itertools.chain.from_iterable(lists) or [x for sub in lists for x in sub] is simplest.
• Generators keep memory low for large inputs.