Python is the most-used language on Stack Overflow’s 2024 survey for the third year running, which means the Python developer interview pool is enormous. Companies interviewing for Python roles know this. The questions have gotten harder.
Here’s a working set of questions organized by level, plus notes on where I see candidates mess up even when they know the material.
The fundamentals questions (don’t get caught on these)
These seem basic. They’re not always easy to answer well under pressure.
What’s the difference between a list and a tuple? The expected answer is mutability: lists are mutable, tuples are not. The better answer adds that tuples are often used as dictionary keys precisely because they’re hashable, which lists are not. That extra sentence is what separates someone who’s read the docs from someone who’s actually written Python.
Explain the Global Interpreter Lock. The GIL prevents more than one Python thread from executing Python bytecode at once. This matters a lot for CPU-bound tasks (parallelism doesn’t help you here unless you use multiprocessing) and matters less for I/O-bound tasks (because threads release the GIL during I/O). Most candidates can say what the GIL is. Fewer can clearly say when it actually affects their code and when it doesn’t.
What are decorators and how do they work? A decorator is a function that takes another function as input and returns a modified version. The @functools.wraps detail is worth mentioning because it preserves the original function’s metadata, which matters for things like documentation and introspection. If you’ve never thought about why functools.wraps exists, this is worth looking up before your interview.
- What does
*argsand**kwargsdo? - What’s the difference between
isand==? - What’s a generator and when would you use one instead of a list?
- What are Python’s built-in data structures and their approximate time complexities?
- Explain
__init__vs__new__.
One thing I don’t know: how much the fundamentals depth varies between companies. Some organizations spend 45 minutes on fundamentals. Others skip straight to coding or system design. Ask the recruiter what the interview format looks like so you’re not surprised.
Intermediate topics that show up constantly
These come up in most Python-specific interviews for backend, data engineering, and ML engineering roles.
Async/await and the event loop. The core idea is that async def functions are coroutines, and await suspends execution until the awaited thing completes. This is specifically good for I/O-bound concurrency (making 50 API calls without blocking), not for CPU-bound work. Common interview question: “Why wouldn’t you use asyncio to speed up a function that does a lot of numeric computation?” If you can answer that clearly and quickly, you’re in good shape.
Type hints. Python’s type hints (via mypy or Pyright) don’t enforce types at runtime, they just annotate them for static analysis. Interviewers will ask why you’d bother. Good answer: type hints make large codebases much easier to refactor safely and let IDEs give you better autocomplete and error detection. They’re a team communication tool as much as a correctness tool.
- How does Python’s memory management work? What’s reference counting?
- Explain how context managers work. When would you write a custom one?
- What’s the difference between
copyanddeepcopy? - How would you design a REST API in Python? What framework would you reach for first?
- How does
pytestwork? What’s a fixture? - What is monkey-patching and why is it risky in tests?
Advanced questions for senior roles
These come up at larger companies, at companies with serious Python infrastructure, and at any company where Python performance is a real concern (data platforms, ML pipelines, high-volume APIs).
How would you diagnose a slow Python application? Start with a profiler (cProfile, line_profiler, py-spy for production). Don’t optimize before you measure. A common interviewer follow-up: “You’ve profiled it and the bottleneck is a nested loop over a large dataset. What are your options?” You want to mention vectorization (NumPy if applicable), caching (are you recomputing the same values?), and Cython or C extensions if performance is really critical.
Design a rate limiter in Python. This is a real system design question with a Python implementation component. The interviewer wants to see whether you think about the data structure first (sliding window, token bucket, fixed window each have different trade-off profiles) before thinking about the code. The implementation in Python usually involves Redis for the backing store in production, or a thread-safe in-memory structure for simpler use cases.
- What are descriptors in Python and how do they work?
- How would you build an ETL pipeline that processes 10GB of CSV files? What would you use?
- What’s the difference between
multiprocessingandconcurrent.futures? - How does Python’s import system work? What’s a circular import and how do you fix it?
- Explain Python’s method resolution order (MRO) with an example of diamond inheritance.
The Pythonic code question
Almost every Python interview will show you a block of code and ask how you’d rewrite it. The thing they’re testing isn’t correctness, it’s whether you write idiomatic Python or just Python-shaped code.
According to Stack Overflow’s 2024 Developer Survey, Python was used professionally by 51% of respondents who identified as developers. With that kind of market penetration, interviewers have seen every variation of “loop over a list and build a new list” imaginable. If you’re writing a for-loop with an empty list and append, you’re going to get a follow-up about list comprehensions.
The BLS Occupational Outlook for Software Developers projects 26% job growth through 2033, which is much faster than average. Python developers are a big chunk of that growth, especially in ML engineering and data infrastructure. The interview bar reflects the demand.
How to practice the technical explanation piece
The gap between knowing something and explaining it clearly in an interview is real. Most developers find that describing the GIL out loud to a non-expert is harder than they expected, even if they understand it perfectly in code.
Recording yourself explaining concepts aloud is underrated. So is using tools that ask follow-up questions when your explanation has gaps. Craqly‘s technical interview practice includes Python-specific question sets where the follow-up questions push you to explain the “why” behind your answers, not just the “what.” Whether you use that or find a practice partner who’ll push back, the practice has to be verbal to actually help.
Start with the section you least want to review. That’s almost certainly the one that will come up.