Most Python interview questions in a phone screen come from the same list of roughly forty fundamentals, reworded slightly from company to company. This post is that list: five groups covering the data model, functions, OOP, concurrency, and tooling, each with a spoken answer, code tested on Python 3.14.6, and a link to its deep-dive lesson. Score yourself at the end and build a revisit list from your misses.

“Programs must be written for people to read, and only incidentally for machines to execute.”

Harold Abelson, Structure and Interpretation of Computer Programs

Last Updated: July 2026 | Tested on: Python 3.14.6 | Difficulty: Intermediate | Reading Time: 22 minutes

A Python phone screen is mostly a listening exercise for the interviewer. They ask about is versus ==, and they are not grading the definition; they are listening for whether you mention identity, the small-int cache, the trap that follows. Live coding is the same game at a keyboard: they watch how you narrate, not just what you type. The forty questions below are the ones screens keep reaching for, so practice saying each answer out loud, in plain words, the way you would over a call. Recognition is cheap; recall under a timer is what the screen actually measures.

The diagram above is the whole plan: five question groups roll up into one self-score, and anything under 25 sends you to a revisit list where every miss names its lesson. Work that loop, rescore in a week, and the phone screen stops being scary. The rest of the post walks the map one group at a time.

How This Checkpoint Works

Each of the five groups below has eight questions, forty in total, chosen because the same Python interview questions show up again and again in real screens across companies of every size. For each group you get a table with a one-line answer you could say out loud and a link to the post that explains it properly, then one runnable code block that proves the part people usually get wrong. Read the answer, cover it, and say it back in your own words. If you cannot, that question goes on your revisit list.

Give yourself one point for every question you can answer cleanly without peeking, so the group tables add up to 40. Keep a running tally on paper. A spoken answer counts only if you could explain it to a colleague in three sentences, not just recognize the words. We total it up in the scoring section, and the honest truth is that this checkpoint measures recall, while the warmups at the end measure whether you can still write code under mild pressure.

Data Model: is vs ==, Mutability, Copy

Think of a library book. Two copies of the same title have equal contents but they are different physical objects. That is the whole is versus == story: == compares contents, is compares whether two names point at the exact same object. Most data-model Python interview questions are variations on that one distinction plus what happens when you change a shared object.

📄 data_model.py: identity, the small-int cache, the default-arg trap, and copy depth

a = [1, 2, 3]
b = [1, 2, 3]
print("a == b:", a == b)          # same contents
print("a is b:", a is b)          # different objects

small = 256
big = 257
print("256 cached, same object:", small is int("256"))   # True
print("257 uncached, new object:", big is int("257"))    # False

# Mutable default argument: the list is built ONCE and reused
def add(item, bucket=[]):
    bucket.append(item)
    return bucket
print("first call: ", add("tomato"))
print("second call:", add("potato"))   # surprise: still has tomato

import copy
grid = [[1, 2], [3, 4]]
shallow = copy.copy(grid)
deep = copy.deepcopy(grid)
grid[0][0] = 99
print("shallow sees change:", shallow)
print("deep stays isolated:", deep)

▶ Output

a == b: True
a is b: False
256 cached, same object: True
257 uncached, new object: False
first call:  ['tomato']
second call: ['tomato', 'potato']
shallow sees change: [[99, 2], [3, 4]]
deep stays isolated: [[1, 2], [3, 4]]

What happened here: Two lists with the same contents are equal but not identical, which is why a == b is True while a is b is False. The small-int cache means 256 already exists as a shared object so is returns True, but 257 is built fresh each time and fails the identity check, which is the concrete reason you never use is to compare numbers.

The default-argument trap is the one that bites people in real code: the empty list is created a single time when the function is defined, so the second call still carries the tomato from the first. Shallow copy duplicates only the outer list and keeps sharing the inner lists, so editing grid leaks into shallow, while deepcopy rebuilds every level and stays clean.

Functions: Closures, Decorators, args

Functions in Python are values you can pass around, return, and wrap, exactly like numbers or strings. That single fact, first-class functions, is what makes closures and decorators possible. Picture a stamp maker: you set it up once with a design, and every time you press it, it remembers that design. A closure is a function that remembers the variables from where it was created, and a decorator is just a function that takes another function and hands back an upgraded one.

📄 functions.py: a closure, a decorator with wraps, and *args/**kwargs

def multiplier(n):
    def times(x):
        return x * n        # remembers n from the enclosing call
    return times

double = multiplier(2)
triple = multiplier(3)
print("double(5):", double(5))
print("triple(5):", triple(5))

import functools
def logged(fn):
    @functools.wraps(fn)    # keep fn's real name and docstring
    def wrapper(*args, **kwargs):
        print(f"  -> calling {fn.__name__}{args}")
        return fn(*args, **kwargs)
    return wrapper

@logged
def area(width, height):
    return width * height

print("area result:", area(3, 4))
print("name preserved:", area.__name__)

def report(*args, **kwargs):
    return f"{len(args)} positional {args}, keywords={dict(kwargs)}"
print(report(1, 2, 3, unit="cm", scale=2))

▶ Output

double(5): 10
triple(5): 15
  -> calling area(3, 4)
area result: 12
name preserved: area
3 positional (1, 2, 3), keywords={'unit': 'cm', 'scale': 2}

What happened here: multiplier(2) returns a small function that has captured n equal to 2, which is why double(5) gives 10 while triple independently remembers 3. The decorator wraps area so a log line prints before the real work runs, and because we added functools.wraps, the wrapped function still reports its real name area instead of the meaningless wrapper, which is the detail interviewers love to check. The report function shows *args gathering the three loose numbers into a tuple and **kwargs gathering the named ones into a dict, which is how Python functions accept any number of arguments.

OOP: MRO and Magic Methods

When a class inherits from several parents, Python needs one clear rule for which parent’s method wins. That rule is the method resolution order, or MRO, and it is a single ordered line-up of classes computed by an algorithm called C3 linearization. The other half of OOP questions is about magic methods, the double-underscore methods like __add__ and __repr__ that let your own objects respond to +, ==, printing, and more, so they feel like built-in types.

📄 oop.py: reading the MRO and giving an object operator behavior

class A:
    def who(self): return "A"
class B(A):
    def who(self): return "B"
class C(A):
    def who(self): return "C"
class D(B, C):
    pass

print("MRO:", [k.__name__ for k in D.__mro__])
print("D().who():", D().who())      # follows the MRO: B wins

class Money:
    def __init__(self, paise):
        self.paise = paise
    def __repr__(self):
        return f"Money({self.paise})"
    def __add__(self, other):
        return Money(self.paise + other.paise)
    def __eq__(self, other):
        return self.paise == other.paise

wallet = Money(30) + Money(20)      # calls __add__
print("added:", wallet)             # calls __repr__
print("equal:", Money(50) == wallet)  # calls __eq__

▶ Output

MRO: ['D', 'B', 'C', 'A', 'object']
D().who(): B
added: Money(50)
equal: True

What happened here: The MRO for D is D, then B, then C, then A, then object, and because B comes before C in that line-up, D().who() returns “B” without you writing a single line to resolve the conflict. The Money class shows the payoff of magic methods: defining __add__ lets you write Money(30) + Money(20), __repr__ controls how it prints, and __eq__ makes == compare by value, so your object behaves like a number instead of an opaque blob. This is exactly the kind of answer where showing three lines of code beats a paragraph of description.

Concurrency: The GIL, Threads vs Asyncio

Here is the mental model. The Global Interpreter Lock, the GIL, is like a single microphone in a meeting room: even with many people (threads) present, only one can speak Python bytecode at a time. That is why threads do not speed up pure number-crunching, but they still help when work is waiting on the network or disk, because a thread that is waiting hands the microphone to another. For genuinely parallel Central Processing Unit (CPU) work you use multiple processes; for thousands of waiting tasks you use asyncio.

📄 gil.py: proving two threads do not speed up CPU-bound work

import threading, time

def cpu_work(n):
    total = 0
    for i in range(n):
        total += i * i
    return total

N = 4_000_000

t0 = time.perf_counter()
cpu_work(N); cpu_work(N)              # one after the other
serial = time.perf_counter() - t0

t0 = time.perf_counter()
threads = [threading.Thread(target=cpu_work, args=(N,)) for _ in range(2)]
for t in threads: t.start()          # both "at once"
for t in threads: t.join()
parallel = time.perf_counter() - t0

print(f"serial (one after another): {serial*1000:7.1f} ms")
print(f"two threads at once:        {parallel*1000:7.1f} ms")
print("threads did NOT halve the time (GIL):", parallel > serial * 0.7)

▶ Output

serial (one after another):   639.4 ms
two threads at once:          679.6 ms
threads did NOT halve the time (GIL): True

What happened here: Running two CPU-heavy loops on two threads took about the same wall-clock time as running them one after another, and actually a touch longer once you count the thread setup, because the GIL let only one thread execute Python bytecode at any instant. This is the answer that separates people who have read about the GIL from people who understand it: threads are the wrong tool for CPU-bound work, and the fix is multiprocessing, which uses separate processes each with their own interpreter and lock.

One honest note for the future: at the time of writing (Python 3.14.6) there is an official free-threaded build that removes the GIL, but it is opt-in and not what most systems run, so the mental model above still holds unless you deliberately install that build. That nuance, stated calmly, is a strong senior signal.

Tooling: venv, Typing, Packaging

The last group of Python interview questions is about working like a professional, and they are practical rather than tricky. A virtual environment is a clean toolbox per project so one project’s package versions never fight another’s. Type hints are labels that tools and humans read, and the point people miss is that Python does not enforce them at runtime at all, they are advisory. Get these and you signal that you have shipped real code, not just solved puzzles.

📄 typing.py: hints are labels, not runtime enforcement

def scale(values: list[int], factor: int = 2) -> list[int]:
    return [v * factor for v in values]

print("result:", scale([1, 2, 3]))
print("annotations:", scale.__annotations__)

# Hints are advisory: Python still runs even with the "wrong" type
print("bad call still runs:", scale(["a", "b"], 3))

▶ Output

result: [2, 4, 6]
annotations: {'values': list[int], 'factor': <class 'int'>, 'return': list[int]}
bad call still runs: ['aaa', 'bbb']

What happened here: The annotations are stored on the function and you can read them back, which is how editors and type checkers give you warnings before you run anything. But the last line is the point interviewers probe: passing a list of strings where the hint said list of ints runs happily and multiplies each string, because CPython does not check hints at runtime, it just ignores them during execution. So the correct answer to “are type hints enforced” is a firm no, they are enforced by a separate type checker in your editor or CI, not by the interpreter.

Score Yourself: The Revisit List

Add up your points across the five tables, one per question you could answer out loud without peeking, for a total out of 40. The band you land in tells you what to do next, and the honest goal is not a perfect score today, it is a shrinking revisit list over the next two weeks.

Here is the trick that makes this efficient: every question in the five tables already names its deep-dive post in the last column. So your revisit list writes itself. For each question you missed, jot the topic and open the linked lesson, for example a shaky answer on the GIL sends you to Multithreading, and a blank on closures sends you to Closures. Work only those posts, not the whole series, then come back and rescore in a week. Targeted review beats re-reading everything, and the delay is what moves a fact from “I recognize it” to “I can say it cold.”

Five Live-Coding Warmups

Answering Python interview questions from memory is half the screen; the other half is writing small code without freezing. These five warmups climb from the classic FizzBuzz up to a two-pointer problem, the same range a screen uses to check you can turn a sentence into code. Try each on your own first, then compare with the solution. They all run on Python 3.14.6 exactly as shown.

📄 warmups.py: FizzBuzz, palindrome, first unique char, Fibonacci, two-pointer pair sum

# 1. FizzBuzz: Fizz for /3, Buzz for /5, FizzBuzz for both
def fizzbuzz(n):
    out = []
    for i in range(1, n + 1):
        if i % 15 == 0: out.append("FizzBuzz")
        elif i % 3 == 0: out.append("Fizz")
        elif i % 5 == 0: out.append("Buzz")
        else: out.append(str(i))
    return out
print("1. FizzBuzz:", fizzbuzz(15))

# 2. Palindrome, ignoring case and non-letters
def is_palindrome(s):
    clean = [c.lower() for c in s if c.isalnum()]
    return clean == clean[::-1]
print("2. 'Never odd or even':", is_palindrome("Never odd or even"))
print("2. 'hello':", is_palindrome("hello"))

# 3. First non-repeating character
from collections import Counter
def first_unique(s):
    counts = Counter(s)
    for ch in s:
        if counts[ch] == 1:
            return ch
    return None
print("3. first unique in 'aabbcde':", first_unique("aabbcde"))

# 4. Fibonacci, iterative and O(n)
def fib(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a
print("4. fib(10):", fib(10), "| first 8:", [fib(i) for i in range(8)])

# 5. Two pointers: a pair summing to target in a SORTED list
def pair_sum(nums, target):
    lo, hi = 0, len(nums) - 1
    while lo < hi:
        s = nums[lo] + nums[hi]
        if s == target: return (nums[lo], nums[hi])
        if s < target: lo += 1
        else: hi -= 1
    return None
print("5. pair summing to 12:", pair_sum([1, 3, 5, 7, 9, 11], 12))

▶ Output

1. FizzBuzz: ['1', '2', 'Fizz', '4', 'Buzz', 'Fizz', '7', '8', 'Fizz', 'Buzz', '11', 'Fizz', '13', '14', 'FizzBuzz']
2. 'Never odd or even': True
2. 'hello': False
3. first unique in 'aabbcde': c
4. fib(10): 55 | first 8: [0, 1, 1, 2, 3, 5, 8, 13]
5. pair summing to 12: (1, 11)

What happened here: FizzBuzz checks the divisible-by-15 case first, which is the one detail interviewers watch for, since testing 3 or 5 before 15 quietly breaks it. The palindrome solution cleans the string down to letters and digits and compares it against its reverse, so spacing and case do not matter. First-unique counts every character once with Counter, then walks the string in order and returns the first with a count of one, which is “c” here.

Fibonacci uses two rolling variables for O(n) time and no recursion, and the two-pointer pair-sum walks inward from both ends of a sorted list, moving the low end up when the sum is too small and the high end down when it is too big, landing on 1 and 11. If you can write these five cleanly while talking through them, the warmup portion of a screen is yours.

Common Mistakes

❌ Mistake: Using is to compare values instead of identity

# Bad: works by accident for small ints, breaks for big ones and strings
x = 1000
if x is 1000:          # SyntaxWarning, and unreliable
    print("equal?")

# Good: compare values with ==, reserve is for None and singletons
if x == 1000:
    print("value match")
if x is not None:
    print("identity check is correct for None")

Why: is asks “are these the same object,” which happens to be true for cached small integers and short interned strings, so beginners think it works, then it silently fails for 1000 or a computed string. Use == for value checks, and save is for comparing against singletons like None, True, and False, where identity is exactly what you mean.

❌ Mistake: Answering “asyncio is faster than threads” with no caveat

# Wrong framing: "asyncio is just a faster replacement for threads"
# Right framing, pick by the workload:
#   CPU-bound  -> multiprocessing (real parallelism, dodges the GIL)
#   Blocking IO with sync libraries -> threads
#   Thousands of awaitable IO tasks -> asyncio (one thread, an event loop)

Why: Asyncio is not faster in general, it is efficient for a very specific shape: huge numbers of tasks that spend their time waiting on IO, all cooperating on one thread through an event loop. For CPU-bound work it does nothing for you, and there you reach for multiprocessing. Naming the workload before naming the tool is the answer that reads as experienced.

Best Practices

• Answer in three sentences, then stop. Say what it is, why it matters, and one concrete example. Rambling past a correct answer usually walks you into a follow-up you did not need.
• Reach for a tiny code example when words get slippery. “Let me show you” and three lines proving __add__ or the default-arg trap lands harder than a paragraph of theory.
• Admit the edge of your knowledge cleanly. “The default build has the GIL; at the time of writing there is an opt-in free-threaded build I have not shipped to production” beats bluffing and reads as honest and current.
• Turn every miss into a named revisit. Do not re-read the whole series; open only the deep-dive post your wrong answer points to, then rescore that question in a week.
• Practice out loud, not just in your head. Recognizing an answer and saying it under mild pressure are different skills, and only the second one shows up in the room.

Wrapping Up

Python interview questions stop being scary once you see the whole screen as a fixed checklist of forty fundamentals, grouped into data model, functions, OOP, concurrency, and tooling. You ran real code on Python 3.14.6 to settle the ones people get wrong, watched is disagree with ==, watched a mutable default argument quietly carry state between calls, read the MRO decide a method conflict, and watched two threads fail to speed up CPU work because of the GIL.

The fundamentals behind these Python interview questions are evergreen, they were true decades ago and they behave the same in Python 3.14.6, with the one forward-looking caveat that a free-threaded build now exists as an opt-in. Score yourself, build the revisit list from your misses, work the five warmups until they flow, and the screen becomes a formality instead of a fear.

This post is the checkpoint that closes the Python half of the journey and hands you off to the machine learning and AI chapters ahead. For the full roadmap, from beginner basics through the AI/ML deep dives, visit the Python + AI/ML tutorial series home.

Frequently Asked Questions

Interview Questions About the Interview

How interviewers actually probe this topic: real scenarios, with answers you can say out loud.

Q: You get asked “what happens when you write list_b = list_a and then change list_b?” Walk me through it.

Assignment in Python binds a name to an object, it does not copy anything, so list_b = list_a makes both names point at the same list. Changing list_b therefore also changes list_a, because there is only one list. If I want an independent copy I use list_a.copy() or slice with list_a[:] for a shallow copy, and copy.deepcopy if the list contains nested mutable objects I also need to isolate.

Q: A candidate says decorators are “just syntactic sugar.” Push on that, what are they really?

The @ symbol is sugar, but the mechanism underneath is real and worth naming: a decorator is a function that takes a function and returns a replacement, so @logged above def area is exactly area = logged(area). That replacement is usually a closure that remembers the original function and adds behavior around it. The practical caveat is to apply functools.wraps inside so the wrapped function keeps its real name and docstring instead of masquerading as the wrapper.

Q: How do you decide between a list, a set, and a dict for a given task?

I pick by the operation I do most. If I need ordering or duplicates, a list. If I mainly ask “have I seen this?” or need to remove duplicates, a set, because membership is an O(1) hash lookup instead of a scan. If I need to map keys to values, a dict, which is also O(1) on average for lookups and inserts. The moment I catch myself scanning a list to check membership inside a loop, that is the signal to switch to a set or dict and drop from O(n squared) to O(n).

Q: The interviewer asks a question you genuinely do not know. What do you do?

I say so plainly, then reason out loud toward a best guess instead of going silent. Something like “I have not used that directly, but based on how Python handles similar cases, I would expect it to work like this, and here is how I would confirm it.” Interviewers are testing how you handle the edge of your knowledge as much as the knowledge itself, and an honest, structured attempt scores far better than a confident wrong answer or a freeze.

Further reading: for the full reference, see the official Python documentation.

Related Posts

Previous: FastAPI Capstone: Build, Test, and Ship a Real Application Programming Interface (API)

Next: Jupyter Notebook and Google Colab: The Data Science Setup

Series Home: Python + AI/ML Tutorial Series