Python is the lingua franca of machine learning, but AI/ML interviews do not test the same Python that a web-backend interview does. They probe a specific slice of the language — the parts that matter when you are moving large amounts of data, writing correct numerical code, and reasoning about performance. Here are the concepts that actually come up, and why each one earns its place.
The mutable default argument trap
Few questions separate people who know Python from people who use Python as cleanly as this one:
def add_sample(x, batch=[]):
batch.append(x)
return batch
Call it twice and the “empty” list is shared across calls, because default arguments are evaluated once, at definition time — not on each call. In ML code that shuffles data or accumulates results, this bug silently corrupts state. The correct pattern uses None:
def add_sample(x, batch=None):
if batch is None:
batch = []
…
Interviewers love this because it tests whether you understand Python’s execution model, not just its syntax.
Generators, iterators, and memory
ML work routinely involves datasets that do not fit in memory, which makes lazy evaluation a core skill rather than a nicety. The difference between [x for x in huge_source] (builds the whole list in memory) and (x for x in huge_source) (a generator that yields one item at a time) is the difference between a crash and a working pipeline. Expect to explain how generators work, why yield matters for streaming data, and when you’d choose an iterator over a materialised list. This is the exact reasoning that underlies efficient data loaders.
Vectorisation and why loops are the enemy
A quietly disqualifying answer in an ML interview is reaching for an explicit Python loop over a large array. Because Python-level loops are slow, numerical libraries like NumPy push the work down into optimised, compiled operations that act on whole arrays at once — “vectorisation.” Being able to say why array * 2 is dramatically faster than looping element by element — and rewriting a naive loop into a vectorised expression — is a common and revealing exercise. It signals whether you can write numerical code that actually performs.
Shallow vs deep copy
When you’re manipulating datasets and nested structures, the distinction between a shallow copy (the outer container is new, but inner objects are shared) and a deep copy (everything is duplicated) becomes a real source of bugs. Modifying what you thought was an independent copy — but was actually a shared reference — is a classic way to leak data between a training and validation set. Interviewers use it to check whether you understand that Python variables are references, not boxes.
The GIL — and when it does and doesn’t matter
The Global Interpreter Lock allows only one thread to execute Python bytecode at a time, which means CPU-bound Python threads don’t run in true parallel. The nuanced answer — the one that impresses — is knowing that this is often not a problem for ML, because the heavy numerical work happens in libraries that release the GIL and run in optimised native code, and because CPU-bound parallelism uses processes (or the GPU) rather than threads. Understanding the GIL’s real boundaries, rather than repeating “Python can’t do parallelism,” marks genuine depth.
Comprehensions, *args/**kwargs, and clean numerical code
Smaller but frequent: writing clear list/dict comprehensions instead of verbose loops, and understanding *args/**kwargs well enough to read and write the flexible function signatures that ML libraries are full of. These show up constantly in framework code, and fluency with them is a marker of someone who reads the ecosystem comfortably.
How to prepare for the Python slice that matters
The efficient path is to study Python through an ML lens rather than generally. Prioritise the execution model (evaluation timing, references, mutability), memory and laziness (generators, iterators), and performance (vectorisation, the GIL) — the areas the work actually exercises. A focused Python question set is more useful than a generic tutorial when you can filter for exactly these themes, and it pairs naturally with the broader AI/ML interview material that tests how these language features support real model and data work.
The bottom line
AI/ML interviews test Python where it meets data and numbers: mutable defaults, generators, vectorisation, references, and the GIL. None of it is obscure, but all of it rewards understanding the language’s execution model rather than just its syntax. Revisit that specific slice before an interview and you’ll write code that is both correct and fast — which is exactly what these roles are hiring for.
