Python Interview Questions for Freshers

“Interpreted means I don't run a separate compile step. When I run a file, the standard interpreter turns it into bytecode and executes that on its own virtual machine right away. The catch is that some mistakes, like a typo in a branch that rarely runs, only show up when that line actually executes. Dynamically typed means a variable is just a name pointing at an object, and the type lives on the object. So x can point to an int and later to a string, and nothing complains until I use it wrongly. But Python is also strongly typed: adding the string three to the number four raises a TypeError instead of guessing. That's why I lean on tests and type hints to catch mistakes early.”

“break stops the loop immediately and jumps past it. continue skips the rest of the current pass and goes to the next item. pass does nothing at all; I use it when Python needs a statement, like an empty function or class I'll fill in later. The loop else is the one people forget. It runs only if the loop ended normally, without a break. That makes it handy for searching: I loop over items, break when I find a match, and put the not-found handling in the else. It saves me from keeping a separate found flag. The same else works on a while loop too.”

“Every Python module gets a variable called __name__. When I run a file directly, Python sets it to the string __main__. When another file imports it, __name__ is the module's own name instead. So the code inside that if-block only runs when I launch the file as a script, not when someone imports it. That lets me keep reusable functions at the top and a small entry point at the bottom, like parsing arguments and calling main(). Without the guard, importing my file in a test would run the whole script. It also matters for multiprocessing on systems that start new processes by re-importing the main file, where a missing guard can make the program start processes over and over.”

“The falsy values are None, False, zero in any number type, and empty containers: an empty string, list, tuple, dict or set. Everything else is truthy, including the string with a zero in it, which catches people out. My own classes can decide too, through __bool__ or __len__. if not x: is fine when I just mean 'is this empty'. It's wrong when zero or an empty string is a real answer. Say a function returns a discount that could be zero, or None when there's no discount. If I write if not discount, a real zero discount gets treated as missing. There I write if discount is None so only the missing case is caught.”

“In Python 3, a single slash is true division and always gives a float, so six divided by three is 2.0. Double slash is floor division: it rounds down, toward negative infinity, not toward zero. So seven floor-divided by two is 3, but minus seven floor-divided by two is minus 4. The modulo operator gives the remainder, and its sign follows the divisor, so minus seven modulo two is 1. That keeps floor division and the remainder consistent with each other. On floats, 0.1 can't be stored exactly in binary, so 0.1 plus 0.2 ends up a tiny bit off from 0.3 and the equality check fails. For comparisons I use math.isclose, and for money-like values where every digit matters I'd use the Decimal type.”

“A virtual environment is a folder that gives one project its own set of installed packages. Without it, every project on my machine shares one global set, so two projects that need different versions of the same library end up fighting. I create one with python -m venv .venv in the project folder, then activate it: source .venv/bin/activate on macOS or Linux, or the activate script in the Scripts folder on Windows. After that, pip install puts packages inside that folder only. To share the setup, I list the packages in requirements.txt and teammates run pip install -r requirements.txt. I don't commit the .venv folder itself; it goes in .gitignore.”

“Indexes start at zero, and negative indexes count from the end, so nums[-1] is the last item. A slice is start, stop and step. The start is included and the stop isn't, so nums[1:4] gives me the items at positions one, two and three. If I leave out start or stop, it means from the beginning or to the end. The step is how far to jump each time, and a step of minus one walks backwards, so text[::-1] reverses a string. Two things I keep in mind: slicing a list gives me a new list, and a slice that runs past the end just stops quietly, while a single index past the end raises an IndexError.”

“append adds one object to the end. If that object is a list, I get a list inside my list, which surprises people the first time. extend takes any iterable and adds each of its items one by one, so extending with two numbers makes the list two longer. One gotcha is that extending with a string adds each character separately. insert takes an index and an item and puts it at that position, shifting everything after it along, so inserting at the front of a large list is slow compared with appending at the end. If I need to add at the front a lot, I'd use a deque from collections instead.”

“d[key] gives me the value but raises a KeyError if the key isn't there. d.get(key) returns None instead, or a default I pass as the second argument. I use brackets when a missing key would be a real bug and I want it to fail loudly, and get when missing is normal. For counting, the simple version loops over the items and does counts[item] = counts.get(item, 0) + 1. In real code I'd just use Counter from collections, which does the counting in one line and gives me most_common for free. defaultdict(int) is another option when I'm building counts inside a bigger loop.”

“list.sort() sorts the list itself and returns None. sorted() takes any iterable, like a list, a tuple, a string or a dict's keys, and gives me back a brand new list, leaving the original untouched. The classic bug is writing nums = nums.sort(). The sort happens, but then I overwrite nums with the None that sort returned, so my list is gone. I use sort() when I own the list and don't need the old order, and sorted() when I need to keep the original or I'm sorting something that isn't a list. Both take a key function and reverse=True. Both are also stable, meaning items that compare equal keep their original order, which is handy when I sort by one field and then another.”

“Python decides at compile time which names in a function are local. If a function assigns to a name anywhere, even with +=, that name is local for the whole function. So count += 1 tries to read the local count before it has been given a value, and I get an UnboundLocalError. When a name isn't assigned in the function, Python looks it up in order: local, then any enclosing function, then the module's globals, then built-ins. To fix it, I'd usually pass the count in and return the new value, which keeps the function easy to test. If I really need to change the module-level variable, I declare global count. Inside a nested function, nonlocal does the same for the outer function's variable.”

“A lambda is a small function with no name, written in one expression, like lambda x: x * 2. It can't hold statements or multiple lines. map applies a function to every item, and filter keeps only the items where the function returns something truthy. In Python 3 both give back lazy iterators, so I wrap them in list() if I need the whole result. Honestly, for simple cases I find a list comprehension easier to read, because the logic sits right there, with no lambda. Where lambdas really earn their place is as a key argument, like sorting a list of students by marks. If a lambda gets long or I need it twice, I give it a proper name with def.”

“First I clean the input, because the spec says spaces and punctuation don't count. I keep only characters where isalnum() is true and lowercase them. Then a palindrome is just text that equals its own reverse, so I compare the cleaned version with a reversed slice. That's linear time and uses extra memory for the cleaned copy. If the interviewer wants less memory, I'd use two pointers, one at each end, skip anything that isn't a letter or digit, and compare as they move inward, stopping at the first mismatch. I'd test it with an empty string, a single character, a sentence like 'A man, a plan, a canal: Panama', and a near-miss.”

“I'd split the sentence into words, reverse the list and join it back with spaces. The detail that matters is calling split() with no argument. That splits on any run of spaces, tabs or newlines and ignores whitespace at the ends, so extra spaces don't turn into empty words. If I wrote split(" ") instead, two spaces in a row would give me an empty string in the list. For reversing I use a slice with a step of minus one, then " ".join to glue the words back with single spaces. Strings can't be changed in place, so building a list and joining once is the normal way, rather than adding strings together in a loop. The whole thing is linear in the length of the sentence.”

“The simple approach calls s.count(ch) for every character, but that scans the whole string each time, so it's quadratic. Better is two passes. First I count every character with a Counter. Then I walk the string again in its original order and return the first character whose count is one. If none qualifies, I return None. Both passes are linear, so it's O(n) time, and the extra memory is the number of distinct characters, which is small for normal text. I'd check an empty string, a string where everything repeats, and one where the answer is the last character, and I'd ask whether upper and lower case should count as the same.”

“Turning a list into a set does remove duplicates, but a set makes no promise about order, so the result can come back shuffled. To keep the order, I loop through the list with a seen set. For each item, if it's not in seen, I add it to the set and append it to the result. Checking a set is fast on average, so the whole thing is linear. There's also a neat one-liner, list(dict.fromkeys(items)), which works because dicts keep insertion order in modern Python. Both need the items to be hashable, so for a list of lists I'd convert each inner list to a tuple first.”

“First I'd ask two things: do we mean the second largest distinct value, and what should come back if there isn't one. I'll assume distinct and return None. Then one pass is enough. I keep first and second, both starting as None. For each number, if it's bigger than first, the old first becomes second and the new number becomes first. Otherwise, if it's not equal to first and bigger than second, it becomes the new second. That's O(n) time and constant memory, better than sorting's O(n log n). I'd test with duplicates of the max, a single item, a list that's all the same number, and negative numbers.”

“The first idea is two nested loops that try every pair. It works but it's quadratic, so it gets slow on big lists. The better way uses a dict from number to index. I walk the list once. For each number, I work out what I still need, which is the target minus the number. If that value is already in the dict, I've found my pair and return both indexes. If not, I store the current number with its index and move on. Checking before storing means I never pair a number with itself, and it still works when the same value appears twice. That's O(n) time, and I pay for it with O(n) extra memory for the dict.”

“self is the object the method was called on. When I write cart.add(item), Python passes cart in as self for me. __init__ runs right after a new object is created and sets its starting data, like self.owner = owner. The trap is putting a mutable value on the class itself. If I write items = [] in the class body, there's only one list, owned by the class, and every instance that calls self.items.append adds to that same list. So adding a pen to one cart makes it show up in every cart. The fix is to create the list inside __init__, so each object gets its own. Class attributes are fine for constants that everyone should share.”

“Python relies on convention rather than enforcement. A single leading underscore, like _balance, tells other developers it's internal and might change, but anyone can still read it. It also keeps the name out of from module import * when the module doesn't define __all__. A double leading underscore, like __balance, makes Python rename it inside the class to _Account__balance. That's called name mangling. Its real purpose is to stop a subclass from accidentally overwriting the parent's attribute, not to hide data, because you can still reach the mangled name. Names with double underscores on both sides, like __init__, are special methods and aren't mangled. When I need rules around a value, I use a @property.”

“I open the file in a with block so it gets closed even if something goes wrong, and I pass encoding="utf-8" because the default depends on the machine. Then I loop over the file object directly. That reads one line at a time, so it's fine even for a big file, unlike read() or readlines(), which pull everything into memory. Each line keeps its newline, so I usually strip it. For modes: r is read, the default, and it raises FileNotFoundError if the file isn't there. w is write, which creates the file or empties an existing one, so it's easy to wipe data by mistake. a is append, which creates the file if needed and adds to the end.”

“I'd define a small class, say InvalidAgeError, that inherits from ValueError, because bad input is a value problem. The body can just be pass. In my function, when the input is wrong, I raise InvalidAgeError with a message that says what was expected and what I got. The reason not to raise a plain Exception is that the caller can only catch it with except Exception, which also catches every other bug, like a typo that causes a NameError. With a specific class, the caller catches exactly that case and lets real bugs surface. Inheriting from ValueError also means code that already handles ValueError keeps working. If I'm turning one error into another, I use raise ... from err to keep the original cause.”

“In my final year, three of us built a tool that took exam marks from spreadsheets exported as CSV files, cleaned them and produced a report card for each student. My part was the reading and checking code. I wrote functions that parsed each row, flagged missing marks and caught names typed in different ways. Halfway through, one department's file used a different date format and the whole run crashed. I fixed it by validating each row and collecting the bad rows into an error file instead of stopping. I also added a few pytest tests after that scare. If I did it again, I'd use Git from day one, since we lost an afternoon merging copies by hand, and I'd write the tests before the code, not after.”

“In a data structures lab, my recursive function to search a binary tree kept returning None, even for values I could see were in the tree. I spent an hour changing things at random, which didn't help. Then I slowed down. I made the smallest tree that failed, just three nodes, and used breakpoint() to step through each call. I saw the function found the value deep down, but the result vanished on the way back up. I'd written the recursive call without return in front of it, so the found value was thrown away. After that, I always start with the smallest input that fails and step through it before changing code, and I set myself a time limit before asking a classmate or the lab assistant.”

“First I'd get the project running on my machine: create a virtual environment, install the requirements and run the existing tests, so I know what normal looks like. Then I'd reproduce the bug myself. If there's a traceback, I read it from the bottom up to find the exact line. I'd search the codebase for that function or the error message instead of trying to understand everything at once. Before changing anything, I'd write a small test that fails because of the bug. Then I make the smallest fix that makes it pass and run the full test suite. If I'm still stuck after an hour or so, I ask a teammate with what I've tried, not just 'it doesn't work'.”