Python Interview Questions Real Candidates Got Asked

The best way to prepare for Python interview questions is to study the ones people actually get asked, not a generic list of 200 trivia items. We pulled the questions candidates faced in real, live interviews, looked at where their answers fell apart, and wrote model answers that fix each gap. The two that come up most often (list versus tuple, and decorators) are deceptively simple, which is exactly why they trip people up.

How these Python interview questions were collected

Two sources feed this piece. The first is our own data: anonymized aggregates from real interviews recorded with MeetAssist, where technical questions dominate the Python screens we see. The second is public discussion from job seekers and engineers working through the same concepts, including an r/learnpython thread on when to reach for a tuple instead of a list and a long-running Stack Overflow debate on list versus tuple and when to use each.

Two questions in our corpus have enough repeat appearances to report exact counts. "What is the difference between a list and a tuple?" was asked 7 times across 6 distinct candidates. "What is a decorator in Python?" was asked 9 times across 7 candidates. We analyzed the answers to both and logged the specific mistakes people made. The rest of the questions below are the standard follow-ups that round out a Python screen, with model answers but no stat claims attached.

One thing worth knowing before you prep: a 2025 study of software engineering candidates found that most people do not prepare in authentic conditions, practicing code in private but rarely explaining it out loud with someone watching. That gap between knowing a definition and saying it cleanly under pressure is where interviews are won and lost.

"What's the difference between a list and a tuple?"

This is the flagship Python interview question, and the answer has a proven shape: lead with mutability, confirm the shared traits, then show code.

Model answer:

Both lists and tuples are ordered sequences that can hold any mix of Python objects, and both support indexing and slicing. The core difference is mutability. A list is mutable, so you can add, remove, or change elements after creation. A tuple is immutable, so once it exists its contents are fixed. That immutability has real consequences: a tuple with hashable elements can be used as a dictionary key or a set member, and I reach for a tuple when I want to signal that a group of values should not change, like a fixed coordinate pair.

Then the snippet:

items = [1, 2]

items.append(3) # valid, list is mutable

point = (10, 20)

mapping = {point: "origin-like"} # valid, tuple is hashable

# point[0] = 99 # TypeError

# mapping = {[1, 2]: "x"} # TypeError: unhashable type: 'list'

Our analysis of real answers found three recurring gaps. People often opened with a slip or an inverted definition (calling lists immutable, or hesitating on which is which), which plants doubt in the first five seconds. Many never mentioned that both are ordered collections, so the answer felt half-finished. And the most common miss: stating the mutability difference without connecting it to anything, no safety, no performance, no use case. The definition is correct but it goes nowhere.

The strong answers did the opposite. They stated mutability plainly, noted both are ordered, and closed with a practical reason to pick one over the other. If SQL comes up in the same screen, the same structure applies, and our breakdown of WHERE vs HAVING in SQL shows the same "define, contrast, example" rhythm working for a different concept.

"What is a decorator in Python?"

The second flagship, and the one people most often fumble. A decorator sounds abstract, so vague answers are common.

Model answer:

A decorator is a callable that takes a function and returns a new function, usually to add behavior like logging, timing, caching, or authorization without touching the original function's body. The @decorator syntax above a definition is just shorthand: writing @logged above add is equivalent to add = logged(add).

Follow it with the wrapper:

from functools import wraps

def logged(func):

@wraps(func)

def wrapper(*args, **kwargs):

print(f"calling {func.__name__}")

result = func(*args, **kwargs)

return result

return wrapper

@logged

def add(a, b):

return a + b

In our recorded answers, the decorator question exposed three gaps. The definition was frequently too vague, skipping the key fact that a decorator is a callable that receives a function and returns another function. Many answers never mentioned the @ syntax or how the decorator actually attaches to a function. And most never showed the inner wrapper function that holds the added behavior, which is the part that proves you understand it rather than having memorized a sentence.

One extra detail separates good from great: wrapping the inner function with functools.wraps preserves the original function's name and docstring. Mentioning it signals you have written decorators in real code, not just read about them.

More Python questions candidates get asked (with model answers)

Once list-versus-tuple and decorators are out of the way, interviewers usually probe a predictable set of follow-ups. Keep each answer to a definition, a consequence, and a line of code.

Mutable vs immutable types

Mutable objects can change after creation (list, dict, set). Immutable objects cannot (int, str, tuple, frozenset). The practical catch is rebinding versus mutating: x.append(4) changes the existing list in place, while x = x + [4] builds a new list and points x at it.

*args and **kwargs

*args collects extra positional arguments into a tuple; **kwargs collects extra keyword arguments into a dict. They let a function accept a variable number of inputs, and you forward them with func(*args, **kwargs).

List comprehensions

A concise way to build a list from an iterable: squares = [n * n for n in range(5)]. It is usually faster and more readable than an equivalent for loop that calls append.

Generators vs lists

A list holds every element in memory at once. A generator yields items one at a time and remembers its state, so it uses far less memory for large or infinite sequences. Use (n * n for n in range(1000000)) instead of a list when you only iterate once.

is vs ==

== compares values; is compares identity (whether two names point to the same object). a == b can be True while a is b is False. Use is only for singletons like None.

Shallow vs deep copy

copy.copy makes a shallow copy, so nested objects are still shared. copy.deepcopy recursively copies everything, so the new object shares nothing with the original. It matters when your structure contains mutable objects inside it.

The mutable default argument trap

def add_item(item, bucket=[]) shares one list across every call, because defaults are evaluated once when the function is defined. The fix is bucket=None, then create the list inside the function when bucket is None.

List vs tuple vs set vs dictionary at a glance

Interviewers often widen the list-versus-tuple question into the full set of built-in collections. Here is the comparison worth keeping in your head.

• List: mutable, ordered, allows duplicates, not hashable. Use for an ordered collection you will modify.
• Tuple: immutable, ordered, allows duplicates, hashable when all elements are hashable. Use for fixed groups of values and as dictionary keys.
• Set: mutable, unordered, no duplicates, elements must be hashable. Use for membership tests and deduplication.
• Dictionary: mutable, insertion-ordered since Python 3.7, no duplicate keys, keys must be hashable. Use for key-value lookups.

The detail that impresses: because a tuple is hashable (when its contents are), it can serve as a dictionary key or a set member, while a list cannot. On speed, tuples are slightly faster to create and iterate than lists, which is a nice aside but rarely the real reason to choose one.

The slip-ups that make strong candidates sound shaky

Across both of our first-party questions, the same three failure patterns showed up again and again, and they are all avoidable.

Inverting or fumbling the definition. Opening with the wrong direction (tuples are mutable, lists are... wait) costs you instantly. The interviewer stops listening to the content and starts wondering how shaky your basics are. Say the core distinction first, cleanly, before you add anything.

Skipping the shared traits. Jumping straight to the difference without noting that both lists and tuples are ordered sequences makes the answer feel incomplete. The contrast only lands when the baseline is stated.

Defining without grounding. A correct definition that never touches a use case or a line of code reads as memorized. This is the single most common gap in our data, and interview guidance agrees that stronger answers connect the feature to a consequence, for example that immutability is what lets a tuple be hashed and used as a dictionary key. Every concept deserves either a short example or a sentence on when you would actually use it.

These are the same habits that separate confident candidates on any technical screen. If you want the broader picture of what gets asked beyond Python, our analysis of common interview questions from 340 real interviews shows how technical and behavioral questions cluster together.

A repeatable formula for answering any Python question

Every answer above follows one pattern, and you can apply it to a question you have never seen:

1. Define precisely. One clean sentence that would survive a fact-check.
2. Contrast or add the implication. Note the shared traits, the trade-off, or the real-world consequence.
3. Show a short example or use case. A three-line snippet or a sentence about when you reach for it.

This matters more than raw knowledge because structured answers read as competence. The research backs the broader point too: structured interviews are reported to be nearly twice as effective as unstructured ones at predicting job performance, and the candidates who impose structure on their own answers tend to come across the same way. Practicing out loud, not just in your head, is what makes the formula automatic. Our guide to preparing for an interview without memorizing covers how to drill the pattern rather than scripts.

The hard part is recovering when a definition slips mid-sentence, which is exactly what our data shows derails otherwise strong candidates. During a live Zoom, Meet, or Teams call, MeetAssist shows real-time answer suggestions so you can steady an answer that started to wobble. It works during live calls only (there is no mock mode), which is also when the pressure is real.

Frequently asked questions

Which is faster, a list or a tuple?

A tuple is generally slightly faster to create and iterate than a list, because it is immutable and has a simpler internal structure. The difference is small and rarely the deciding factor in real code. Choose based on whether you need to change the contents, not on micro-benchmarks.

Can I convert a tuple to a list (and back)?

Yes. Use list(my_tuple) to turn a tuple into a list, and tuple(my_list) to go the other way. This is common when you need to modify a tuple's contents: convert to a list, change it, then convert back to a tuple.

Why would you use a tuple instead of a list?

Use a tuple when the group of values should not change, such as a coordinate pair, a database row, or a function returning multiple values. Immutability signals intent to other developers and, when all elements are hashable, lets the tuple serve as a dictionary key or set member. A list cannot do that.

What are the advantages of tuples over lists?

Tuples are immutable, which prevents accidental changes and makes them safe to share. They can be hashable and therefore usable as dictionary keys or set elements. They also use slightly less memory and are marginally faster, though those benefits are minor compared to the safety and intent they communicate.