Python Developer interview questions and how to answer them

Python interviews are rarely about trick syntax. They check whether you understand how the language behaves under the hood, whether you can write code another person can maintain, and whether you stay calm when something breaks in production. Here's what each round looks for and how to handle the questions that come up again and again.

The process

What happens in each round

  1. 1

    Recruiter screen

    What happens

    That your experience matches the stack in the posting, that you can describe a recent project in plain words, and that your expectations on location and pay fit the role.

  2. 2

    Technical phone screen or take-home

    What happens

    Whether you can write working, readable Python without an IDE doing the thinking. Take-homes are judged on tests, structure and the README as much as on whether the code runs.

  3. 3

    Live coding

    What happens

    How you break a problem down, talk through trade-offs and recover from a bug while someone watches. Idiomatic use of dictionaries, comprehensions and the standard library gets noticed.

  4. 4

    System design or code review round

    What happens

    Whether you can reason about an API, a database schema, background jobs and caching together. Some teams hand you a messy pull request and ask what you'd flag instead.

  5. 5

    Team and hiring manager conversation

    What happens

    How you handle review feedback, disagreements about approach and on-call incidents, and whether you'd make the team's week easier or harder.

Questions you're likely to get

1.What's the difference between a list, a tuple and a set, and when would you pick each?

Why they ask

It sounds basic, but the answer shows whether you think about mutability, hashing and lookup speed or just reach for a list every time.

How to answer

  • Lists are ordered and mutable, good for sequences you'll append to or reorder
  • Tuples are immutable, so they're hashable and can be dictionary keys or represent a fixed record
  • Sets give fast membership checks and remove duplicates, but don't keep order
  • Give a real case, like switching a list to a set to fix a slow 'is this ID already processed' check
2.Explain generators. Why would you use one instead of returning a list?

Why they ask

Generators separate people who've processed real data volumes from people who've only worked with small samples.

How to answer

  • A generator yields values one at a time and keeps its state between calls
  • Memory stays flat because the whole result never sits in memory at once
  • Useful for streaming a large CSV, paginating an API or reading log files line by line
  • Mention the catch: you can only iterate it once, and debugging lazy code takes care
3.What is the GIL, and how does it affect how you write concurrent code?

Why they ask

They want to know if you'll pick threads, processes or asyncio for the right reasons instead of guessing.

How to answer

  • The global interpreter lock lets only one thread run Python bytecode at a time in CPython
  • Threads still help for I/O-bound work like network calls, because the lock is released while waiting
  • CPU-heavy work goes to multiprocessing, a task queue like Celery, or a library that drops into C
  • asyncio suits many concurrent network calls in a single thread
  • Tie it to something you built, such as moving image resizing out of a web request into a worker
4.What's wrong with using a mutable default argument, like def add(item, items=[])?

Why they ask

It's a classic bug that shows up in real codebases, and spotting it proves you understand when defaults are evaluated.

How to answer

  • The default list is created once when the function is defined, not on each call
  • Every call that relies on the default shares and mutates the same list
  • The fix is items=None, then create a new list inside the function
  • Mention that linters like Ruff or pylint flag this, and you keep them in CI
5.A Django view that used to be quick now takes several seconds. How do you track it down?

Why they ask

This is the everyday job. They want a method, not a lucky guess.

How to answer

  • Reproduce it locally or on staging with realistic data before changing anything
  • Use Django Debug Toolbar, query logging or an APM tool to count and time the queries
  • Look for one query firing per row in a loop and fix it with select_related or prefetch_related
  • Check for missing indexes with EXPLAIN in PostgreSQL
  • Add a test or a query-count assertion so it doesn't creep back
6.How do you structure tests for a service that calls an external API?

Why they ask

Flaky tests and tests that hit real services are a daily headache. They want someone who writes tests the team can trust.

How to answer

  • Keep the API client behind a small interface so the rest of the code doesn't know about HTTP
  • Use pytest fixtures and mock the client, or record responses with a tool like responses or VCR.py
  • Test the failure paths too: timeouts, rate limits, malformed payloads
  • Keep a small number of contract or integration tests that run against a sandbox separately
7.How do you manage dependencies and environments in a Python project?

Why they ask

Environment drift causes 'works on my machine' bugs. They want to know you've lived with a real project over time.

How to answer

  • Use a virtual environment per project, through venv, Poetry, pip-tools or uv
  • Pin exact versions in a lock file so every machine and CI build installs the same thing
  • Keep production and development dependencies separate
  • Describe how you handle upgrades: a bot opens the pull request, the suite runs, a person reviews the changelog
8.Walk me through how you'd design an endpoint that kicks off a long-running report.

Why they ask

It tests whether you know not to block a web request on slow work, and how you'd let the user know when it's done.

How to answer

  • Return quickly with a job ID and a status URL instead of holding the request open
  • Hand the work to a queue such as Celery or RQ backed by Redis
  • Store status and results so the client can poll, or push a notification when finished
  • Cover retries, idempotency and what happens if the worker dies halfway
9.What do decorators do, and where have you written one?

Why they ask

Decorators show up all over Flask, FastAPI and Django. Writing one proves you understand functions as objects.

How to answer

  • A decorator is a function that takes a function and returns a wrapped version of it
  • Use functools.wraps so the name and docstring survive
  • Give a real use: timing a function, retrying a flaky call, checking permissions
  • Mention that too many stacked decorators make code hard to follow
10.Tell me about a time a code review changed your mind.

Why they ask

Reviews happen daily. They're checking whether you can take criticism in writing without getting defensive.

How to answer

  • Pick a real review where the reviewer was right and you were initially sure you weren't
  • Say what the comment was and why it was better
  • Show what you do differently now because of it
  • Keep it short and give the reviewer the credit
11.Describe a production incident you helped fix.

Why they ask

They want to see how you behave when things are on fire and whether you learn from it afterwards.

How to answer

  • Set the scene briefly: what broke and who noticed
  • Explain how you found the cause, using logs, Sentry traces or metrics
  • Say what the immediate fix was and what the lasting fix was
  • Mention the follow-up: a test, an alert or a runbook change
12.How do you use type hints, and do you run a type checker?

Why they ask

Many teams now lean on typing to catch bugs early. They want to know if you'll fit their habits.

How to answer

  • Type hints document intent and let tools like mypy or Pyright catch mistakes before runtime
  • Add them to public functions and data models first, where they help most
  • Use dataclasses or Pydantic models for structured data instead of loose dictionaries
  • Be honest that strict typing on an old codebase is a gradual process

Mistakes that sink good candidates

Writing clever one-liners in live coding that you can't explain when asked to walk through them

Talking only about tools you've read about instead of problems you've actually solved

Going silent while stuck, when saying what you're thinking would let the interviewer help

Criticising your current team's codebase in a way that sounds like you'd do the same here

Need more Python Developer interviews to prep for?

HeroApply applies to Python Developer jobs that match you, every day. 258 jobs are open today.

Find Python Developer jobs