Python interview questions

What a strong answer covers

• Default argument values are evaluated once at function definition time, not on each call, so the same list object is shared across every call that relies on the default
• Mutating that shared default (e.g. appending) causes state to leak between calls, a classic source of surprising bugs
• The idiomatic fix is to default to None and create a fresh list inside the body: def f(x, acc=None): if acc is None: acc = []
• Ties back to Python binding default values to the function object at def time, stored in func.__defaults__

Where people lose the point

• ×Claiming defaults are re-evaluated on every call, which is the opposite of the real behavior
• ×Suggesting you should just avoid lists entirely rather than using the None sentinel pattern
• ×Confusing this with variable scope rather than the timing of default-value evaluation

What a strong answer covers

• == compares values by calling __eq__, while is compares object identity (whether both names point to the same object, effectively id() equality)
• They diverge when two distinct objects are equal by value: e.g. two separate lists [1,2] == [1,2] is True but is is False
• Small-int caching (-5 to 256) and string interning can make is appear True for equal values, which is a CPython implementation detail and should not be relied on
• The correct idiom is x is None for singletons like None, True, False; use == for value comparison

Where people lose the point

• ×Using is to compare integers or strings and assuming it always works because of caching
• ×Saying is compares values or that == compares identity, reversing the two
• ×Not recognizing None/True/False are singletons where is is the correct check

What a strong answer covers

• A list materializes all elements in memory at once; a generator produces values lazily one at a time via the iterator protocol (__next__), holding only current state
• Generators give O(1)-ish memory for large or infinite sequences and enable pipelines and streaming, using yield or generator expressions (x for x in ...)
• Tradeoffs: generators are single-pass and exhaustible, have no len() or indexing, and cannot be reused once consumed
• Good fit for large files, data pipelines, or when you only iterate once; a list is better when you need random access, multiple passes, or the length

Where people lose the point

• ×Saying generators are always faster, when for small reused collections a list can be faster and simpler
• ×Forgetting a generator is exhausted after one full iteration and trying to loop over it twice
• ×Confusing generator functions (with yield) and generator expressions, or conflating them with regular functions that return lists

What a strong answer covers

• A decorator is a callable that takes a function and returns a replacement (usually a wrapper), applied with @decorator syntax as syntactic sugar for f = decorator(f)
• The wrapper should accept *args and **kwargs so it works on any signature, call the original, and return its result
• Use functools.wraps on the wrapper to preserve the original function's __name__, __doc__, and metadata
• Strong answers mention decorators with arguments (an extra layer of nesting) and real uses like caching, timing, auth, and retry

Where people lose the point

• ×Writing a wrapper with a fixed signature instead of *args/**kwargs, breaking it for other functions
• ×Omitting functools.wraps, which silently loses the wrapped function's identity and docstring
• ×Forgetting to return the wrapper's result, so the decorated function returns None

What a strong answer covers

• The GIL is a CPython mutex that lets only one thread execute Python bytecode at a time, so threads cannot run CPU-bound Python code in true parallel on multiple cores
• Threads still help I/O-bound work because the GIL is released during blocking I/O and many C extensions; asyncio handles high-concurrency I/O in a single thread via an event loop and cooperative await
• For CPU-bound parallelism use multiprocessing (or a ProcessPoolExecutor), which runs separate interpreters/processes each with its own GIL, at the cost of IPC and memory overhead
• Nuance: the GIL is a CPython implementation detail (not in the language spec), and recent work on free-threaded / no-GIL CPython (PEP 703) is changing this landscape

Where people lose the point

• ×Claiming the GIL makes threads useless for everything, ignoring that I/O-bound workloads benefit
• ×Recommending threading for CPU-bound number crunching in pure Python
• ×Treating the GIL as a language-level guarantee rather than a CPython implementation detail

What a strong answer covers

• Assignment (b = a) binds a new name to the same object; mutations through either name are visible through both because there is only one object
• A shallow copy (copy.copy, list(a), a[:]) creates a new outer object but its elements are references to the same inner objects, so mutating a nested list affects both copies
• A deep copy (copy.deepcopy) recursively copies nested objects so the result is fully independent, and it handles shared references and cycles via a memo table
• Strong answers note deep copy is more expensive, that immutable inner elements make the shallow/deep distinction moot, and that custom classes can control copying via __copy__/__deepcopy__

Where people lose the point

• ×Believing list(a) or a[:] fully clones nested structures, then being surprised nested mutations leak
• ×Not distinguishing that mutating an outer element vs a nested element behaves differently under a shallow copy
• ×Reaching for deepcopy everywhere, ignoring its cost and that it is unnecessary for flat or immutable data