Python Developer Interview Questions for AI Training Work

I use a generator when I only need to iterate once and don't need random access, since it keeps memory flat regardless of dataset size. I reach for NumPy arrays when doing numeric operations at scale, since vectorized operations are far faster than looping over a plain list.

Common causes include holding references in a growing global cache, circular references involving objects with custom __del__ methods, or accumulating data in a list that's never cleared. I use tools like tracemalloc or objgraph to snapshot memory over time and identify which object types are growing unexpectedly.

I check whether shared mutable state, like a list or dictionary passed by reference, is being modified somewhere upstream before the function receives it. I also verify the actual arguments being passed at the call site with a debugger rather than assuming they match my mental model.

I mock the external call at the boundary so tests run deterministically and don't depend on network availability, and I write a smaller set of integration tests that hit the real API to catch contract drift. Relying only on mocks risks tests passing while the real integration is broken.

I profile first rather than guessing where the bottleneck is, usually with cProfile or line_profiler, since the actual slow section is often not where I'd expect. Common fixes include replacing nested loops with vectorized operations or switching a data structure with O(n) lookup to a set or dictionary.

I'd switch from loading the entire dataset into memory to processing it in chunks or as a stream, since the issue is almost always that the code assumes the whole dataset fits in memory. I would also check for accidental duplication, like keeping both the raw and transformed data in memory at once.

I'd write characterization tests around the existing behavior of the code I'm about to touch before making changes, so I have a safety net even without full coverage. I wouldn't try to add comprehensive tests for the entire codebase at once, since that scope creep delays the actual feature work.

I'd first identify whether the bottleneck is CPU-bound or I/O-bound, since the fix differs, multiprocessing helps for CPU-bound work while async or threading helps for I/O-bound work like network calls. I'd also check whether the current architecture even needs to scale vertically, or whether horizontal scaling with more instances is simpler.

I spent a full day chasing an intermittent failure that turned out to be a mutable default argument being shared across function calls. Once I found it, the fix was a one-line change, but the lesson was to check for that specific pattern earlier when debugging state that seems to persist unexpectedly.

I rewrote a data transformation step that used nested Python loops to use pandas vectorized operations instead, which cut runtime from minutes to seconds. I kept the existing tests passing throughout by refactoring incrementally and comparing output against the old implementation on a fixed sample before replacing it fully.