Python Interview Questions and Answers for Data and Automation Roles

Mutable objects can change in place after creation: list, dict, set, bytearray, most user-defined classes. Immutable objects cannot: int, float, str, tuple, frozenset, bytes. This matters in three places interviewers probe. (1) Function arguments: passing a mutable object lets the callee modify the caller's data. (2) Default arguments: def f(x=[]) shares ONE list across all calls. (3) 'Modifying' a string like s += 'x' actually allocates a new string each time — which is why ''.join(parts) beats += in a loop. Identity check: after s = 'ab'; s += 'c', id(s) has changed; after lst.append(3), id(lst) has not.

== compares values by calling __eq__; is compares identity — whether both names point at the same object in memory. [1,2] == [1,2] is True, but [1,2] is [1,2] is False because they are two distinct objects. The only idiomatic uses of is are for singletons: x is None, x is True, x is NotImplemented. The interview trap: small integers (-5..256) and short strings are interned by CPython, so 256 is 256 happens to be True while 257 is 257 may be False — code relying on that is broken by design, which is exactly why comparisons should use ==.

A list comprehension builds a list from an iterable in a single expression:

squares = [x*x for x in range(10) if x % 2 == 0]

It replaces a for-loop with append, is usually faster (the loop runs in C), and reads declaratively. Variants: dict comprehensions {k: v for ...}, set comprehensions {x for ...}, and generator expressions (x for ...) which produce items lazily instead of materialising a list. Interview follow-up: nested comprehensions flatten a matrix — the for-clauses read left-to-right in the same order as nested loops:

[cell for row in grid for cell in row]

Prefer a plain loop when the logic needs multiple statements; an unreadable comprehension is worse than a loop.

*args collects extra positional arguments into a tuple; **kwargs collects extra keyword arguments into a dict. def f(*args, **kwargs) accepts any call signature, which is how decorators and wrappers forward arguments unchanged: return func(*args, **kwargs). The same stars unpack in the other direction at call sites: f(*[1,2], **{'x': 3}) is f(1, 2, x=3). Two details worth volunteering: parameters after * are keyword-only (def f(a, *, b) forces f(1, b=2)), and Python 3.8's / marks positional-only parameters. Order in a signature is: positional, *args, keyword-only, **kwargs.

CPython uses reference counting as its primary mechanism — every object tracks how many references point to it, and when the count hits zero the memory is freed immediately. A cyclic garbage collector supplements this, because reference counting alone cannot free reference cycles (a.b = b; b.a = a). Small objects are allocated from pooled arenas by pymalloc rather than the OS directly. Practical implications interviewers look for: del removes a name, not necessarily the object; sys.getrefcount(x) shows the count (plus one for the call itself); circular references with __del__ used to be uncollectable; and long-running processes can hold memory because arenas are not always returned to the OS — which is why large batch jobs often fork workers instead.

A list materialises every element in memory immediately; a generator produces elements one at a time, on demand, remembering its position between next() calls.

gen = (x*x for x in range(10**9))

That is instant and uses constant memory, while the list equivalent would need gigabytes. Generators are written as functions with yield or as generator expressions. The trade-offs: generators are single-pass (once consumed, they are exhausted), have no len(), and cannot be indexed. They shine in pipelines — sum(x*x for x in nums if x > 0) — and for streaming large files. A follow-up worth pre-empting: yield from delegates to a sub-generator, and generators underpin how 'for' loops, itertools and async code work.

A decorator is a callable that takes a function and returns a replacement, applied with @name above the definition. It is the standard way to add behaviour — timing, caching, auth checks, retries — without editing the wrapped function. Minimal pattern:

def log(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        print(func.__name__)
        return func(*args, **kwargs)
    return wrapper

The @functools.wraps line is the detail that separates candidates: without it the wrapper hides the original's name and docstring. Decorators with their own arguments need one more nesting level (a factory returning a decorator). Built-ins used daily: @property, @staticmethod, @functools.lru_cache.

A shallow copy (copy.copy, list(x), dict(x), x[:]) creates a new outer container whose elements are the SAME inner objects; a deep copy (copy.deepcopy) recursively copies everything. The classic failure: b = copy.copy(a) where a = [[1,2],[3,4]], then b[0].append(9) — a[0] also shows 9, because both lists share the inner lists. Deep copy avoids that but costs time, memory, and needs care with cycles (deepcopy handles them via a memo dict). In data code the same idea appears as df.copy() vs df.copy(deep=False) in pandas, and views vs copies in NumPy — a slice of an ndarray is a VIEW, mutating it mutates the original.

A context manager guarantees setup/teardown around a block: with open(path) as f: ... closes the file even if the body raises. The protocol is two methods — __enter__ (returns the resource) and __exit__ (cleans up; returning True suppresses the exception). The lighter way to write one is @contextlib.contextmanager with a single yield: everything before it is setup, everything after runs on exit. Real uses beyond files: acquiring locks, database transactions (commit on success, rollback on exception), temporarily changing a working directory, and pytest's 'with pytest.raises(ValueError):' assertion.

def add(item, bucket=[]) evaluates the default ONCE, at function definition — so every call without a bucket shares the same list, and items mysteriously accumulate across calls. The fix is a sentinel:

def add(item, bucket=None):
    if bucket is None:
        bucket = []

The same trap applies to dict/set defaults and to any mutable object constructed in the signature, including default arguments like now=datetime.now() — that timestamp is frozen at import time, not call time. This question is a favourite precisely because the broken version works in simple tests and fails only in production-shaped call patterns.

map(f, xs) applies a function lazily; filter(pred, xs) keeps matching items lazily; both return iterators in Python 3. A list comprehension does either or both eagerly and is generally preferred as more readable: [f(x) for x in xs if pred(x)] replaces list(map(f, filter(pred, xs))). map/filter win when you already have a named function (map(str.strip, lines) is clean) or when you want laziness without a generator expression. The functional trio's third member, reduce, moved to functools and is usually better expressed with sum(), max(), or an explicit loop. Mentioning that comprehensions avoid lambda-call overhead — and are therefore usually faster than map with a lambda — lands well.

Python 3.9+: merged = a | b (b's values win on key conflicts); in-place: a |= b. Python 3.5+: {**a, **b}. Older / still common in codebases: merged = a.copy(); merged.update(b). For nested structures none of these recurse — a shallow merge replaces entire sub-dicts, so deep merges need a small recursive helper or a library. Related tools worth naming: dict.setdefault for insert-if-missing, collections.ChainMap for a LAYERED view that does not copy at all (first match wins — handy for config-over-defaults), and the fact that later sources always override earlier ones in every merge form.

An iterable is anything you can loop over — it implements __iter__ returning an iterator (lists, strings, dicts, files, generators). An iterator is the stateful cursor doing the walking — it implements __next__ (produce the next item or raise StopIteration) and __iter__ (return itself). A for-loop calls iter() on the iterable, then next() repeatedly, catching StopIteration. Key consequences: iterables like lists can be looped many times; iterators are one-shot — zip, map, filter, and generators all exhaust. The subtle bug this explains: assigning it = iter(xs), consuming part of it in one loop, then wondering why a second loop starts midway. Files are their own iterators, which is why you can only read them through once.

Stream it, never call .read() or .readlines(). For text, the file object is already a lazy line iterator:

with open(path) as f:
    for line in f:
        process(line)

That is constant memory regardless of file size. For binary, read fixed chunks: while chunk := f.read(1024*1024). For CSVs, csv.reader streams rows; in pandas, pd.read_csv(path, chunksize=100_000) yields DataFrame chunks you aggregate incrementally, and specifying dtype/usecols cuts memory further. For columnar analytics at scale, mention Parquet + predicate pushdown via pyarrow/DuckDB, which reads only the needed columns and row groups. If the follow-up is 'and sort it?' — external merge sort: sort chunks, write runs, heapq.merge the runs.

A closure is an inner function that captures variables from its enclosing scope and keeps them alive after the outer function returns:

def make_counter():
    n = 0
    def inc():
        nonlocal n
        n += 1
        return n
    return inc

Each make_counter() call gets independent state — lightweight encapsulation without a class. Closures are the mechanism behind decorators and factory functions like def multiplier(k): return lambda x: x * k. Two interview details: 'nonlocal' is required to REBIND a captured variable (reading needs nothing), and the late-binding trap — functions created in a loop all see the loop variable's FINAL value unless you pin it with a default: lambda x, k=k: x * k.

In priority order: (1) Eliminate row loops — replace iterrows/apply with vectorised column operations; df['c'] = df.a * df.b runs in C. (2) Fix dtypes — object columns are Python-object arrays; convert repeated strings to 'category', numbers out of object with pd.to_numeric, and use nullable dtypes. (3) Load less — usecols/dtype/parse_dates in read_csv, or switch to Parquet. (4) Prefer merge/groupby/transform over manual loops, and query()/boolean masks over Python-level filtering. (5) Watch copies — chained indexing (df[a][b] = x) both warns and silently misses; use .loc. (6) When one core is the limit, mention the escape hatches by name: numba for custom numerics, DuckDB/Polars for large joins and aggregations — knowing WHEN pandas is the wrong tool reads as seniority.