Python Interview Questions for AI Training Work

Lists are mutable and tuples aren't, but the practical difference shows up in two places: tuples can be dictionary keys or set members because they're hashable, and using a tuple signals to anyone reading the code that the collection's shape is fixed, like coordinates or a database row, rather than a growing sequence.

The Global Interpreter Lock means only one thread executes Python bytecode at a time, so threading gives no speedup on CPU-bound work, only on I/O-bound work where threads spend time waiting. For CPU-bound parallelism you switch to the multiprocessing module, which sidesteps the GIL by running separate interpreter processes, or drop into a C extension that releases the GIL during the heavy computation.

A generator produces values lazily with yield, computing each item only when it's requested instead of building the whole sequence in memory upfront. That matters for large or unbounded data, like reading a multi-gigabyte file line by line or streaming API results, where materializing a full list would blow up memory for no benefit.

`__new__` creates and returns the instance, while `__init__` receives that already-created instance and sets it up. You override `__new__` in rare cases like implementing a singleton, subclassing an immutable type such as `tuple` or `str`, or controlling which subclass gets instantiated, since by the time `__init__` runs the object already exists and can't be swapped out.

The default list is created once when the function is defined, not on every call, so every call that doesn't pass `items` shares and mutates the same list across invocations. The fix is to default to `None` and create a fresh list inside the function body if `items is None`, which guarantees each call starts clean.

First I'd stop loading the whole file with something like `list(reader)` or `pandas.read_csv` without chunking, and switch to iterating row by row or using `pandas`' `chunksize` parameter so only a slice of the data is in memory at once. If the processing needs aggregation across the full file, I'd accumulate results incrementally, like running sums in a dict, rather than holding every row simultaneously.

I wouldn't do a blanket find-and-replace, because a bare except is often silently swallowing a real bug alongside the expected failure. I'd go clause by clause, add logging first to see what's actually being caught in production, then narrow each one to the specific exception type once I know what's really being handled, fixing any newly-exposed bugs as they surface.

I'd push back gently and ask what makes explicit passing awkward here, since globals make it hard to trace where state changes and create hidden coupling that breaks under multithreading or testing. If the shared state is genuinely cross-cutting, like configuration, I'd suggest a dedicated config object or dependency injection instead, which keeps the dependency visible in function signatures.

I once traced a slow API endpoint to string concatenation inside a loop using `+=`, which reallocates a new string on every iteration and turned an O(n) operation into O(n²). Switching to building a list and joining it once at the end fixed it. The lesson was to profile before guessing, since the obvious suspects, like the database query, weren't actually the bottleneck.

I favor readability unless the one-liner is genuinely clearer to a future reader, not just shorter. On a data transformation step I once had a nested comprehension that was technically correct but took real effort to parse, so I rewrote it as an explicit loop with a comment. Being clever in Python is easy; the harder skill is knowing when cleverness isn't worth the cost to whoever reads the code next.