Python Developer interview questions

Python interviews are full of questions with a textbook answer and a real answer. Interviewers are listening for the second one.

The good ones test whether you have maintained Python that other people wrote, and whether you know where the language will surprise you.

Every question below is one that gets asked. What we have added is the part that usually goes unsaid: what a strong answer actually demonstrates. Career1 scores interviews for a living, so this is the difference we see between an answer that lands and one that was rehearsed.

How this interview usually runs

Most companies run some version of these stages. Smaller teams often fold two of them into one conversation.

  1. 01

    Screening call

    What kind of Python you write: web services, data work, automation or tooling. The rest of the process often depends on the answer.

  2. 02

    Coding exercise

    Live or take-home. Product teams tend to set a practical task; larger engineering organisations are more likely to use algorithm problems.

  3. 03

    Code review or debugging

    Read unfamiliar code, find the bug and suggest improvements. This is where the language's surprises come up naturally.

  4. 04

    Design and experience

    A system you built or maintained, how it was structured and tested, and what you would change.

Language behaviour that bites

  1. What happens if you use a list as a default argument?

    What a strong answer shows: Textbook knowledge is table stakes. The useful signal is whether you have been bitten by it in a real codebase.

  2. Explain the difference between a shallow and a deep copy, with a case where it mattered.

    What a strong answer shows: Whether the knowledge is attached to an experience or was read the night before.

  3. When does the GIL actually matter to you?

    What a strong answer shows: Precision. Strong answers separate CPU-bound from I/O-bound work, name what they did about it, and know free-threaded builds exist without assuming production runs one.

  4. How do generators help with memory, and when do they hurt?

    What a strong answer shows: That you know they are single pass, and have hit the bug where something is consumed twice.

  5. How does a context manager work, and when would you write one?

    What a strong answer shows: The __enter__ and __exit__ protocol or contextlib.contextmanager, and a real use: guaranteed cleanup of a connection, a lock or a temporary file even when an exception is raised.

  6. What does a decorator do, and what does functools.wraps fix?

    What a strong answer shows: That a decorator takes a function and returns a replacement, and that without wraps the result loses its name and docstring, which confuses logs, debuggers and some frameworks.

Everyday Python

  1. What is the difference between is and ==?

    What a strong answer shows: Identity versus equality, and why comparisons with None use is. Knowing that CPython caches small integers, so some is comparisons work by accident, shows real depth.

  2. Why can a tuple be a dictionary key when a list cannot?

    What a strong answer shows: Hashability and mutability, and what would break if a key changed after insertion. The follow-up: a tuple is only hashable if everything inside it is.

  3. When would you use a dataclass, a NamedTuple or a plain dictionary?

    What a strong answer shows: Choosing by purpose: dictionaries for loose data at the edges, dataclasses for structured objects with defaults or behaviour, NamedTuples for small immutable records, and validation where data enters the system.

  4. How fast is checking membership in a list compared with a set?

    What a strong answer shows: Linear versus average constant time, and ideally a story about a loop that slowed to a crawl because it checked a growing list. It is the classic accidental quadratic.

  5. How do you handle exceptions without hiding bugs?

    What a strong answer shows: Catching specific exceptions where you can do something useful, never a bare except that swallows everything, and raise ... from ... to keep the original cause.

Structure and testing

  1. How do you organise a Python project that has outgrown one file?

    What a strong answer shows: Opinions formed by maintenance: packages, dependency direction, and keeping the import graph acyclic.

  2. What do you mock in tests, and what do you refuse to mock?

    What a strong answer shows: Judgement. Over-mocked suites pass while the system is broken, and candidates who have lived through that say so.

  3. How do you use pytest fixtures without making tests depend on each other?

    What a strong answer shows: Fixture scope chosen deliberately, and knowing that shared state in a session-scoped fixture is how a suite starts passing or failing depending on the order tests run in.

  4. How do you add type hints to a codebase that has none?

    What a strong answer shows: Pragmatism about incremental adoption rather than an all or nothing rewrite.

  5. How do you manage dependencies and virtual environments?

    What a strong answer shows: Pinned, locked dependencies for applications, looser ranges for libraries, and one reproducible tool across the team, whether pip-tools, Poetry or uv. The reasoning matters more than the brand.

Concurrency and performance

  1. A Python service is slow. How do you find out why?

    What a strong answer shows: That you profile before optimising, and know the answer is usually I/O or an accidental quadratic, not the language.

  2. When would you reach for asyncio, and when would you not?

    What a strong answer shows: Whether you can name the cost: one blocking call in an async path stalls everything.

  3. How do you call blocking code from async code?

    What a strong answer shows: asyncio.to_thread or an executor for blocking calls, async-native clients where they exist, and knowing that time.sleep inside a coroutine stalls the whole event loop.

  4. How do you process a file too large to fit in memory?

    What a strong answer shows: Iterating line by line or in chunks, generators to keep the pipeline lazy, and chunked reading for tabular data rather than loading it all into one DataFrame.

Web services and data

  1. How would you design a small REST API in Python?

    What a strong answer shows: A framework chosen for the job, such as FastAPI, Django or Flask, then input validation, consistent error responses, a database session per request and tests against the HTTP layer.

  2. How do you avoid SQL injection in Python?

    What a strong answer shows: Parameterised queries or an ORM, never string formatting into SQL, and knowing where an ORM still lets raw SQL in.

Now practise it out loud

Reading questions is the easy half. Career1's AI interviewer asks questions like these by voice and follows up when an answer is thin. It takes about eight minutes and costs nothing.

Practise first, in private: once a week, no video and no score, with written feedback that is never shared with companies. When you are ready, the vetting interview is a separate single attempt, no retakes: it is recorded, scored and becomes a profile companies can find. You can hide that profile at any time.

Practise this interview free

Questions people ask

What level of Python do interviews usually test?

Most interviews stay in day to day territory: data structures, error handling, testing and debugging. Questions about metaclasses and descriptors are more common in blog posts than in interviews, and often signal a team that is testing trivia rather than the job.

Should I prepare LeetCode style problems for a Python role?

It depends entirely on the company. Product teams tend to ask about code you have written; larger engineering organisations are more likely to run algorithm rounds. Read the job description and ask the recruiter what the process is, which is a reasonable question.

How do I show Python depth without a public portfolio?

Talk about a bug that took you a long time to find. Depth shows up in debugging stories far more reliably than in a list of libraries.

Do Python interviews cover type hints?

Often. Many Python codebases use type hints now, so expect to read typed code and to be asked how you would introduce type checking to a codebase without it. Knowing what a checker such as mypy catches, and what it cannot, is usually enough.

Are Python interviews for data roles different?

The core language questions are shared. Data roles lean towards pandas, SQL, missing values and memory on large datasets; backend roles lean towards web frameworks, databases and concurrency.

Other roles

Preparing for the general questions too? Common interview questions and what they test.

Hiring instead of interviewing? See how Career1 vets applicants for you.

Career1 help

Answers in seconds, any time

Ask anything about Career1. Leave your email so we can reply if the answer needs a person.

Thinking…

Passed to a person. We will reply to .