Python interview questions: the ones a backend round actually asks

The questions below have one thing in common: each has an easy answer that's correct and a second layer that decides the round. The easy answer is the doorway, and interviewers use these particular questions precisely because the doorway is so well known that it tells them nothing on its own.

If you'd rather work through the topic than read about it, the Python track covers the same ground one idea at a time.

Question 1: what does the GIL actually stop you doing?

Everyone has heard that Python has a global interpreter lock and that threads are therefore useless. Half of that is right, and the half that's wrong is the half that matters when you're deciding how to make a slow endpoint faster.

Worth knowing rather than claiming: recent CPython versions ship a build with the lock removed, and it's a genuinely large change to the runtime. Saying it exists is a good signal. Saying your service would get faster by switching to it is a claim you'd have to defend, and single-threaded code on that build isn't automatically quicker.

Question 2: why does this function remember the last call?

The most-asked Python gotcha, and still worth asking, because the mechanism behind it explains a whole category of surprises.

def add_item(item, basket=[]):
    basket.append(item)
    return basket

add_item("apple")   # ['apple']
add_item("pear")    # ['apple', 'pear']  <- the same list

A def statement runs once. Its defaults are evaluated at that moment and stored on the function object, so every call that doesn't pass the argument shares one list. The fix is basket=None and if basket is None: basket = [] inside the body.

Question 3: async, threads or processes?

The question a backend round almost always reaches, because it's the one where a wrong mental model shows up directly in production behaviour.

@app.get("/report")
async def report():
    data = requests.get("https://slow-api.example.com").json()  # blocking
    return summarize(data)

An event loop runs on one thread. A coroutine that blocks doesn't yield, so nothing else on that loop runs until it returns, including requests that have nothing to do with it. It's the same failure as blocking the event loop in Node.js, and the fix is the same shape: use an async client so the wait is awaited, or push the blocking call off the loop with asyncio.to_thread or a run-in-executor call.

• asyncio for lots of concurrent I/O in one process: thousands of open connections, where a thread each would be wasteful. It costs you a whole parallel ecosystem of libraries, because one blocking call in the wrong place undoes it.
• Threads for I/O when the code is already synchronous. Simpler, and fine at the scale most services actually run at.
• Processes for CPU-bound work, with real memory cost and pickling at the boundary.
• A task queue when the work doesn't need to finish inside the request at all. Frequently the right answer, and the one candidates forget to offer.

Question 4: this endpoint loads a million rows into memory

Generators are a first-year topic that turns into a senior one the moment the question is about a real dataset instead of a toy.

rows = [transform(r) for r in cursor.fetchall()]   # whole table in memory
rows = (transform(r) for r in cursor)              # one row at a time

Question 5: the ORM query that gets slower as the data grows

This one isn't really a Python question, which is exactly why it separates backend candidates from people who know the language.

for order in Order.objects.all():        # 1 query
    print(order.customer.name)           # 1 more query per order

Lazy loading is the ORM's best feature and its sharpest edge. Attribute access issues a query, so a loop over a hundred orders is a hundred and one queries, each fast in isolation, and the endpoint gets slower in production as the table grows while staying fine on your laptop's seeded data. The fix is to tell the ORM what you're going to need: a join for a single related row, a second batched query for a collection. In Django that's select_related and prefetch_related; in SQLAlchemy, joinedload and selectinload.

What makes the answer senior is saying how you'd catch it rather than how you'd fix it, because you'll write this bug again. Log query counts per request in development, assert on the count in a test for the endpoints that matter, and watch the count in production rather than only the latency. Database interview questions for backend engineers goes further into what the database itself is doing with these.

Two smaller ones that come first

• is versus ==. == asks whether two objects are equal, is asks whether they're the same object. They agree often enough by accident to be dangerous: small integers and short strings are cached by the interpreter, so a is b can be True for 256 and False for 257 with nothing else changed. Use is for None, True and False, and == for values.
• Type hints. They're not enforced at runtime. The interpreter ignores them, a type checker reads them before the code ever runs, and passing a string where the annotation says int fails nowhere until something downstream breaks. Pydantic and FastAPI are the exception people are thinking of when they disagree: those validate at runtime, deliberately, because the data came from outside.

The live task: write a retry decorator

If there's a keyboard moment in a Python backend round, it's usually a decorator, and retry is the most common one. It's short, it uses closures, and it has an opinionated second half that most candidates skip.

1. Say what you're building before typing: a wrapper that calls the function, and on a failure waits and tries again up to a limit.
2. Reach for a closure over the arguments, and functools.wraps on the inner function, so the wrapped function keeps its name and docstring instead of becoming a nameless wrapper in every traceback.
3. Forward *args and **kwargs unchanged, so the decorated function stays interchangeable with the original.
4. Back off between attempts rather than retrying immediately, because a service that just failed under load is exactly the one you shouldn't hit three more times in a row.
5. Catch the exceptions you can retry, not every exception. Retrying a timeout is sensible, retrying a 400 is a bug that hides a bug.
6. Say the limit out loud: retries are only safe if the operation is idempotent. This is the sentence that separates the answer from the implementation.

import functools, time

def retry(attempts=3, delay=0.5, exceptions=(TimeoutError,)):
    def decorator(fn):
        @functools.wraps(fn)
        def wrapper(*args, **kwargs):
            for attempt in range(attempts):
                try:
                    return fn(*args, **kwargs)
                except exceptions:
                    if attempt == attempts - 1:
                        raise
                    time.sleep(delay * 2 ** attempt)
        return wrapper
    return decorator

Expect to be asked what happens when every caller retries a struggling service at once, and whether you'd add jitter. And expect the version of this question that's really about trade-offs: would you write this, or take the dependency that already does it properly.

Question 6: what keeps an object alive?

The closing question in a lot of senior Python rounds, and the one people are least ready for, because Python's memory management is usually invisible until a long-running worker starts growing.

CPython counts references. When the count of things pointing at an object drops to zero, it's freed immediately, which is why the memory behaviour is mostly predictable. Cycles are the exception: two objects referring to each other keep each other's counts above zero forever, so a separate cycle collector runs periodically to find groups that only reference each other. That's why a parent holding children that hold the parent is a real leak shape, and why a cache that never evicts is a leak with no cycle in it at all.