Scenario-Based Python Interview Questions

“No error and zero rows saved makes me think the data was there once and then gone. My first guess is that records is a generator, maybe from a file reader or a map call, and the validation loop walked it to the end. A generator can only be iterated once, so the second loop gets nothing and finishes silently. I'd confirm by logging the type of records and counting items in each loop. If the batch fits in memory, I'd turn it into a list once at the top. If it's huge, I'd validate and save in one pass, row by row. What would change my mind is if the first loop also saw zero items, because then the problem is upstream, in whatever produces the records.”

“The outer * 3 doesn't make three rows. It makes a list that holds the same inner list three times. So when I set board[0][1] = 1, I'm changing that one shared row, and because every row is that row, the value shows up in the same column everywhere. I can prove it in a second: board[0] is board[1] returns True. The fix is to create a new inner list for each row, with a comprehension. The inner [0] * 3 is fine, because integers are immutable, so repeating them is harmless. The same trap shows up with dict.fromkeys(keys, []), where every key ends up sharing one list.”

“Sets have no defined order, and for strings it's worse than it sounds. Python salts string hashes with a random value each time the process starts, as a defence against inputs crafted to cause lots of collisions. So the same set of names iterates in a different order on every run. With small integers you might never notice, because they hash to themselves and the order looks stable. It matters the moment anyone relies on it: tests comparing output, report diffs where every line looks changed, or cached output that never matches. The fix is to decide which order we actually want. Alphabetical means sorted(names). First-seen means deduping with dict.fromkeys(names), since dicts keep insertion order. Fixing PYTHONHASHSEED would hide it, but that's papering over the real issue.”

“The for loop walks the list by position. Say position one is bad and I remove it. Everything after it shifts left, so the item that was at position two is now at one, and the loop moves on to position two and never looks at it. That's why two bad emails in a row is the case that slips through. There's no error, which makes it nasty. The clean fix is to build a new list with a comprehension that keeps only the good ones. If other code holds a reference to the same list and needs to see the change, I'd assign to emails[:] to replace the contents in place. And remove searches from the start every time, so the original is slow on big lists anyway.”

“That message means a circular import. When Python imports a module, it registers it in sys.modules and runs it top to bottom. If models imports services near the top, and services does from models import User, Python hands back the half-finished models module, User isn't defined yet, and it fails. I'd read the traceback bottom up to see the exact loop. The cleanest fix is usually to pull whatever both modules need into a third module, so dependencies only point one way. Switching to import models and using models.User inside functions also works, because the name is looked up later, at call time. Importing inside a function is my last resort. If the import is only there for type hints, I'd put it under if TYPE_CHECKING:.”

“When a standard module seems to be missing a function it definitely has, I assume I'm not importing the module I think I am. The script's own folder comes first on Python's search path, so if there's a file called random.py sitting next to it, maybe an old practice file, Python imports that instead. I'd confirm with print(random.__file__), which shows the exact file that was loaded. The fix is to rename my file to something that doesn't clash. The same thing happens with files called email.py, json.py or test.py, and with variables too: naming a variable list or str breaks calls to those built-ins later in the same scope, with an equally confusing error.”

“First I'd find out whether the data really is that deep or whether it loops. If it came straight from json.loads, it can't contain a cycle, so it's genuinely deep. If our code built it or linked nodes to their parents, a cycle recurses forever and the limit just catches it, so I'd track what I've visited, by id. For genuinely deep data, the issue is that Python caps recursion, around a thousand frames by default, and it doesn't do tail call optimisation. So I'd rewrite the walk with an explicit stack: push the root, pop an item, process it, push its children. That handles any depth that fits in memory. I wouldn't just crank up sys.setrecursionlimit, because the real C stack can overflow and kill the process with no Python traceback at all.”

“That line is almost certainly a KeyError where someone logged str(e), which for a KeyError is only the missing key in quotes. The type and the traceback are gone. First I'd change the handler to use logger.exception with the record's id in the message. That logs the message plus the full traceback, so I get the file, the line and the record. Then I'd decide how the job should behave. If one bad record shouldn't kill the whole run, I'd catch errors per record, log each with its id, count them, and fail the job at the end if too many went wrong. For this bug itself, I'd look at that record, see why user_id was missing, and validate input where it enters, so the next failure is a clear message instead of a bare key name.”

“A restart that fixes it for a few days is a classic leak, so first I'd measure it. On Linux I'd count the entries in the process's fd folder under /proc every few minutes, or run lsof -p on it, and look at what's piling up: regular files, sockets to one host, or pipes. That tells me where to look. If it's files, I search for open() calls that aren't in a with block, especially on error paths where an exception skips the close. If it's sockets, a common cause is creating a new HTTP client for every request and never closing it. I'd fix it with with blocks and one shared client. Raising the open file limit only buys time. To catch it early, running the tests with python -X dev shows a ResourceWarning whenever a file is cleaned up without being closed.”

“Two separate fixes. First, readers should never see a half-written file, whatever kills the worker. So I'd write output to a temporary file in the same directory, flush and fsync it, then call os.replace onto the real name. On the same file system that swap is atomic on Linux and macOS, so the next step sees either the old file or the complete new one. Second, the worker should stop politely. Deploy tools usually send SIGTERM and wait a while before a hard kill. I'd install a handler that just sets a flag, have the main loop check it between items, finish the current item and exit cleanly. And since a hard kill can still happen, I'd make every job safe to rerun, so a restart simply redoes the unfinished item.”

“Two hundred times the rows but thousands of times the run time tells me it's roughly quadratic, not just more work. Before guessing, I'd profile it on about twenty thousand rows with cProfile and sort by cumulative time. Very often in a matching script it's a membership check like if customer_id in seen_ids, where seen_ids is a list. Each check scans the whole list, so the loop is n times n. Turning that list into a set makes each lookup constant time on average, and the script goes back to seconds. If the profile pointed somewhere else, like a database call for every row, I'd batch those calls instead. Either way, I'd add a timing check on a bigger sample so it can't creep back unnoticed.”

“A list is fast at the end and slow at the front. Every pop(0) shifts all the remaining items left by one, so with ten thousand items each new event does ten thousand moves, and that cost grows with traffic. I'd switch to collections.deque with a maxlen of ten thousand. Appending then drops the oldest item automatically, and both ends are constant time. Before swapping, I'd check how the dashboard reads the window. If it only loops over it or reads the newest items, deque is a drop-in. If it indexes into the middle, deque is slower there, so I'd keep running totals as events arrive instead of rescanning. If several threads touch it, single appends are safe, but reading several items together still needs a lock.”

“I wouldn't load fifty million rows into a list and sort them. That's a lot of memory and n log n work just to keep twenty. I'd read the file lazily, one row at a time, and keep a min-heap of the twenty largest seen so far. For each row, if the heap has fewer than twenty items I push it, otherwise if its amount beats the smallest in the heap, I replace that one. That's n log 20, basically linear, with only twenty rows held. In Python, heapq.nlargest does exactly that and accepts a generator, so the code is two lines. I'd settle what happens with ties and missing amounts first. And if the data already sat in a database, I'd let the database sort and limit it.”

“A few hundred megabytes on disk can easily become several gigabytes in Python, because each record becomes an object with a header and its own __dict__, and each field is a separate int or string object. First I'd ask whether we need all ten million in memory at once. Often we're summing or grouping, and a generator that aggregates while it reads solves it outright. If we do need them all, adding __slots__, or slots=True on a dataclass, removes the per-instance dict and saves a lot. Plain tuples are smaller again. For numeric columns, the array module or a numeric library stores raw values instead of objects. I'd measure with tracemalloc on a sample of a hundred thousand records before and after, rather than guess.”

“Threads share one memory space, so any function works. Processes don't. The pool has to pickle the function and every argument and send them to the worker, and pickle can only handle a function by its importable name. A lambda or a function defined inside another function has no such name, hence the error. So I'd move the worker to the top level of a module. Then I'd check the arguments: a database connection, an open file or a lock won't pickle either, so each worker should open its own connection. I'd also create the pool under if __name__ == "__main__":, because where workers are spawned fresh, each one re-imports the main module. And I'd pass small inputs like ids, since pickling big objects can eat the whole speed-up.”

“Fire and forget with create_task has two traps. First, the event loop only keeps a weak reference to a task, so if my code doesn't hold on to it, it can be garbage collected before it finishes, and the work just stops. Second, if send_email raises, nobody awaits the task, so the exception only shows up as a 'Task exception was never retrieved' warning when the task is cleaned up, which is easy to miss. I'd also check whether deploys stop the process while tasks are still pending. The fix is to keep each task in a set and add a done callback that removes it and logs any exception. But if an email truly must go out, I'd put it on a proper job queue with retries instead of trusting an in-memory task.”

“The low total is real, and the teammate is mixing up two things. The GIL means only one thread runs Python bytecode at a time, which keeps the interpreter's own objects safe. But count += 1 is several steps: load the value, add one, store it back. The interpreter can switch threads between those steps, so two threads both read 41, both write 42, and one increment is lost. Whether you see it depends on the Python version and timing, which is exactly why it's dangerous: it passes tests and fails under load. I'd wrap the increment in a threading.Lock. If it's a hot path, I'd let each thread count locally and add the totals at the end, or send results through a queue.Queue so a single thread owns the counter.”

“I'd stop it being a matter of taste and look at the forty callers. If most of them treat no match as normal, like a search box, returning None is honest, and I'd type it as User | None so the type checker makes every caller handle it. If most of them assume the user exists because the id just came from our own database, None is dangerous: it blows up three lines later as a confusing AttributeError. There, raising a specific UserNotFound fails right where the problem is. Quite often the answer is both, with find_user returning None and get_user raising, so the name tells callers which contract they get. What I'd avoid is raising a bare Exception or returning False, which hides the reason.”

“I wouldn't approve it, and I'd explain why rather than just block it. Unpickling isn't just reading data. A pickle file can tell Python to call any function with any arguments while it loads, so a user could upload a file that runs a shell command on our server. There's no safe way to load an untrusted pickle. The feature itself is fine, though. I'd suggest saving settings as JSON, and on load, validating it into a dataclass or schema so unknown keys and wrong types get a clear error. That's not much extra work. Pickle is fine for things only our own code writes and reads, like a local cache file. I'd also search the codebase for other places that unpickle outside data, because this pattern tends to repeat.”

“Nobody complaining just means nobody has tried yet. eval runs whatever expression it gets, so a user could type something that imports os and deletes files or reads our secrets. I'd raise it as a security bug with a short example, not as a style comment. I wouldn't try to make eval safe by passing empty builtins or blocking certain characters, because people keep finding ways around that. What we actually need is arithmetic on a few known variables. So I'd parse the formula with the ast module and walk the tree, allowing only numbers, the variable names we provide, and the four basic operators, and rejecting everything else with a clear error. If it only needs literal values like numbers or lists, ast.literal_eval is enough.”

“Both values are strings, and Python compares strings one character at a time. The first characters are 1 and 9, and 1 comes first, so it decides 10.0 is less than 9.2 without looking any further. It worked for years because every version had a single-digit major number. The quick fix is to split on dots and compare tuples of integers, so it becomes ten, zero against nine, two, and tuples compare item by item as numbers. If versions can carry things like rc1 or post1, I'd use the Version class from the packaging library, which knows those rules. Then I'd add a test with a two-digit version and a pre-release, and look for other places comparing versions as strings, because it's rarely just one.”

“In Python 3, bytes and text are different types. sock.recv returns bytes, and "OK" is a str, so the in check refuses to compare them. The quick patch is to check for b"OK", and for a simple protocol check that's actually fine. But if the code goes on to treat the reply as text, I'd decode it once, right where it comes in, with the encoding the server really uses, usually UTF-8, and keep everything inside the program as str. Then I'd encode only when sending. One catch with sockets: a single read can stop in the middle of a multi-byte character, so I'd collect a full message, by a length prefix or a newline, before decoding. Otherwise it works in testing and fails on the first name with an accent.”

“When a key is obviously there but the lookup fails, I stop looking at values and look at types. A plain print shows 42 either way, so I'd print the repr of the incoming id next to the repr of a key from the dict. Very often the request sends the id as the string 42, while the dict was built from database rows with integer ids, and in Python a string never equals an int, so they're different keys. A stray space or newline is the other usual suspect, and repr shows that too. I'd fix it where data enters the program: parse the request into a model or dataclass that turns product_id into an int once, with a clear error if it isn't a number. Converting at each lookup just spreads the problem around.”