Python Developer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Tell me about a time you had to speed up a slow Python script.

   What they're really asking: Do you profile before optimizing, and know Python's common slow paths?

   Answer outline (STAR)

   • SituationA nightly data job that had grown to take several hours.
   • TaskBring the runtime down without destabilizing the output.
   • ActionProfiled with cProfile, found a quadratic pattern from repeated list lookups, switched to a set and vectorized a loop with pandas.
   • ResultRuntime dropped from four hours to twenty-five minutes, verified against the old output first.

   Full sample answer (fictional example)

   A nightly job that enriched customer records had grown from under an hour to almost four hours as the dataset grew. I profiled it with cProfile instead of guessing, and found two issues: a lookup against a plain list inside a loop, which was effectively quadratic, and a row-by-row pandas operation that could be vectorized. I switched the lookup to a set for constant-time membership checks and replaced the row-by-row apply with a vectorized pandas operation. Before deploying, I ran both versions against the same input and diffed the output to make sure results hadn't changed. The job dropped from about four hours to twenty-five minutes.

2. 2.Describe a time you had to debug a tricky issue caused by mutable default arguments or shared state.

   What they're really asking: Have you been bitten by a Python-specific pitfall, and did you learn from it?

   Answer outline (STAR)

   • SituationA function using a mutable default argument that accumulated state across calls.
   • TaskFind why results from unrelated calls were bleeding into each other.
   • ActionReproduced it in isolation, read the function signature closely, recognized the classic mutable-default trap.
   • ResultFixed it with None as the default and a fresh object inside the function; added a linter rule to catch it going forward.

   Full sample answer (fictional example)

   We had a function that logged events, with a default argument like def log_event(event, tags=[]). It worked fine in testing but in production, tags from one call were showing up in unrelated calls. I reproduced it in a quick isolated script and realized the default list was being created once, at function definition time, and every call without an explicit tags argument was mutating that same shared list. I fixed it by changing the default to None and creating a fresh list inside the function body when needed. I also enabled a flake8 rule that flags mutable default arguments, so review catches it next time.

3. 3.Tell me about a time you introduced type hints or static analysis to an existing codebase.

   What they're really asking: Can you improve code quality incrementally without a disruptive rewrite?

   Answer outline (STAR)

   • SituationA mid-sized codebase with no type hints and occasional type-related bugs reaching production.
   • TaskReduce that class of bug without blocking ongoing feature work.
   • ActionAdded mypy in non-strict mode, typed the most-touched modules first, fixed issues it surfaced gradually.
   • ResultType-related production bugs dropped noticeably over the next quarter, and new code was typed by convention.

4. 4.Tell me about a time you had to choose between two libraries for the same job.

   What they're really asking: Do you evaluate dependencies deliberately instead of picking whatever's familiar?

   Answer outline (STAR)

   • SituationA need for background task processing with two viable library choices.
   • TaskPick the one that fit the team's actual constraints.
   • ActionCompared maintenance activity, documentation, and how each handled retries and failures, prototyped both briefly.
   • ResultChose the simpler option for the team's scale, which paid off when a teammate picked it up with no ramp-up time.

5. 5.Tell me about a deadline where you had to cut scope on a Python project.

   What they're really asking: Can you make an honest tradeoff instead of quietly skipping tests or error handling?

   Answer outline (STAR)

   • SituationA client-facing script due before a demo, with more edge cases than time allowed.
   • TaskDeliver something reliable for the demo's actual scope.
   • ActionAgreed the demo's exact inputs with the stakeholder, handled those robustly, logged a clear error for anything else.
   • ResultDemo went smoothly, and the edge cases were handled in the following week's work.

6. 6.Tell me about a time you wrote a script to automate a repetitive manual task.

   What they're really asking: Do you look for opportunities to remove toil, not just do what's asked?

   Answer outline (STAR)

   • SituationA weekly report that someone manually assembled from three spreadsheets.
   • TaskAutomate it reliably without losing accuracy.
   • ActionWrote a script to pull and merge the sources, added validation checks, scheduled it to run automatically.
   • ResultSaved several hours a week, and the report became more consistent since manual steps were removed.

   Full sample answer (fictional example)

   Our finance team spent every Friday copying figures from three CSV exports into one report. I asked if I could automate it, and they agreed to let me try with one report first. I wrote a Python script using pandas that read the files, normalized the date formats, flagged missing rows, and wrote the summary to a formatted spreadsheet. I ran it alongside their manual process for two weeks and found a rounding difference we fixed together. After that, the Friday job took five minutes, and I added a short README and a scheduled run on a shared server.

7. 7.Describe a time you had to review someone else's Python code that didn't follow the team's conventions.

   What they're really asking: Can you give useful feedback without being pedantic?

   Answer outline (STAR)

   • SituationA pull request with inconsistent naming and no type hints, from a developer new to the team.
   • TaskGet the code to a mergeable standard without discouraging them.
   • ActionFocused comments on the few things that mattered for correctness and maintainability, linked to the style guide for the rest.
   • ResultThe PR was updated and merged the same day, and their next PR needed far fewer comments.

8. 8.Tell me about a time you had to work with a dataset or API that had inconsistent or missing data.

   What they're really asking: Do you handle messy real-world input defensively?

   Answer outline (STAR)

   • SituationA third-party API that sometimes omitted fields or returned them in unexpected types.
   • TaskKeep the pipeline running without silent data corruption.
   • ActionValidated and normalized the response with a schema, logged and skipped malformed records instead of crashing.
   • ResultThe pipeline ran reliably afterward, and the logs made it easy to follow up with the API provider.

   Full sample answer (fictional example)

   A partner's API returned prices as strings, sometimes with commas, sometimes with a currency symbol, and occasionally nothing at all. My first version crashed on the third batch. I rewrote the ingestion step to parse prices defensively, log every row it couldn't read, and store the raw response next to the cleaned value. Then I wrote tests from the actual bad examples I'd collected. I also emailed the partner's support team with a few sample records, and they fixed two of the issues on their side. My code handled the rest safely.

9. 9.Tell me about a time you had to explain a technical decision to a non-technical stakeholder.

   What they're really asking: Can you translate technical tradeoffs into terms that matter to the business?

   Answer outline (STAR)

   • SituationA choice between a faster-to-build script and a more robust service for a recurring task.
   • TaskGet buy-in for the right tradeoff, not just the faster-sounding one.
   • ActionExplained the cost of the quick option breaking silently, framed it in terms of time lost later, not jargon.
   • ResultThey chose the more robust option, and the task has run without issue since.

10. 10.Tell me about a time you contributed to or set up a CI pipeline for a Python project.

    What they're really asking: Do you invest in catching problems automatically rather than relying on manual checks?

    Answer outline (STAR)

    • SituationA project where tests passed locally but broke in different environments.
    • TaskMake sure what passes locally also passes for everyone, reliably.
    • ActionSet up CI to run tests, linting and type checks on every pull request, pinned dependency versions.
    • ResultEnvironment-specific failures dropped to near zero, and reviewers stopped needing to manually re-run tests.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.What's the difference between a list, a tuple and a set in Python, and when would you use each?

   What they're really asking: Basic data structure fluency used in almost every script.

   Answer outline

   • Lists are mutable and ordered; tuples are immutable and ordered, useful as fixed records or dict keys.
   • Sets are unordered and unique, giving fast membership tests, but cost you order and duplicates.

   Full sample answer (fictional example)

   A list is ordered and mutable, so I use it for a sequence of items I expect to change, like results I'm building up in a loop. A tuple is ordered but immutable, which I use for fixed records, like a coordinate pair, or whenever I need something hashable, such as a composite dictionary key. A set is unordered and only stores unique elements, which makes membership checks very fast, close to constant time, so I reach for it when I need to deduplicate or repeatedly check whether something is in a collection.

2. 12.Explain Python's GIL, and what it means for multithreaded versus multiprocess code.

   What they're really asking: A question that reveals whether you understand Python's actual concurrency model.

   Answer outline

   • The Global Interpreter Lock lets only one thread execute Python bytecode at a time in CPython.
   • Threads still help for I/O-bound work, since the GIL is released during I/O waits, but not for CPU-bound work.

   Full sample answer (fictional example)

   The Global Interpreter Lock means that in CPython, only one thread can execute Python bytecode at any given moment, even on a multi-core machine. That doesn't mean threading is useless, though: for I/O-bound work, like making network requests or reading files, the GIL is released while waiting, so threads still give real concurrency benefits there. For CPU-bound work, like heavy numeric computation in pure Python, threads won't actually run in parallel because of the GIL, so I'd reach for the multiprocessing module instead, which runs separate processes with their own interpreter and memory space.

3. 13.What are Python generators, and why would you use one instead of returning a list?

   What they're really asking: Memory and performance awareness for data-heavy code.

   Answer outline

   • A generator yields values lazily, one at a time, instead of building the whole result in memory.
   • This matters for large or unbounded datasets, like reading a huge file line by line.

   Full sample answer (fictional example)

   A generator uses yield to produce values one at a time, lazily, instead of computing and holding the entire result in memory at once. I'd use one when processing something large or effectively unbounded, like reading a multi-gigabyte log file line by line, where building a full list would use far more memory than necessary. The tradeoff is that a generator can only be iterated once; you can't index into it or ask for its length without consuming it. For a function where the caller might need to loop over the result multiple times or access it by index, I'd return a list instead, even at the memory cost.

4. 14.How do decorators work in Python, and can you describe a practical use case?

   What they're really asking: Do you understand a core Python idiom beyond @staticmethod and @property?

   Answer outline

   • A decorator is a function that takes a function and returns a new function wrapping it with extra behavior.
   • Common uses include logging, timing, caching with functools.lru_cache, and access control checks.

5. 15.What's the difference between a shallow copy and a deep copy, and when does it matter?

   What they're really asking: A frequent source of subtle bugs with nested data structures.

   Answer outline

   • A shallow copy duplicates the outer container but still references the same nested objects.
   • A deep copy recursively duplicates everything, so nested objects are independent too.

6. 16.How would you handle a function that might fail for several different reasons, using exceptions?

   What they're really asking: Error-handling judgment, not just try/except syntax.

   Answer outline

   • Catch specific exception types rather than a bare except, so you don't hide unrelated bugs.
   • Use custom exception classes when callers need to distinguish failure types programmatically.

   Full sample answer (fictional example)

   I'd catch specific exception types rather than a bare except, so I only handle the failures I actually expect and let anything unexpected surface as a loud error instead of hiding it. If callers need to distinguish between failure types programmatically, like a 'not found' versus a 'validation failed' case, I'd define custom exception classes for those, often inheriting from a common base exception for the module. For resource cleanup, like closing a file or a database connection, I'd use a context manager or a finally block so cleanup happens whether or not an exception occurred.

7. 17.What does an ORM like Django's or SQLAlchemy's give you, and what's the risk of relying on it blindly?

   What they're really asking: Framework fluency and awareness of its hidden costs.

   Answer outline

   • An ORM maps rows to objects and lets you write queries in Python instead of raw SQL.
   • The main risk is the N+1 query problem, where looping over related objects triggers a query per iteration.

   Full sample answer (fictional example)

   An ORM maps database rows to Python objects and lets you express queries as method calls instead of writing raw SQL, which speeds up development and keeps most query logic in one language. The risk I watch for most is the N+1 query problem: if you loop over a list of objects and access a related object inside the loop, like order.customer.name, the ORM can silently issue one query per iteration instead of one efficient join. I fix this with eager loading, like select_related or prefetch_related in Django, or joinedload in SQLAlchemy, chosen based on whether the relationship is one-to-one or one-to-many.

8. 18.What's the difference between args and kwargs, and when would you use **kwargs in a function signature?

   What they're really asking: Common syntax that still trips people up when explaining why, not just what.

   Answer outline

   • *args collects extra positional arguments into a tuple; **kwargs collects extra keyword arguments into a dict.
   • Useful for wrapper functions or decorators that need to pass arguments through without knowing them in advance.

9. 19.Explain list comprehensions versus generator expressions, and when the difference matters.

   What they're really asking: Do you know when laziness actually helps versus when it's just syntax preference?

   Answer outline

   • A list comprehension builds the full list in memory immediately; a generator expression produces values lazily.
   • For large datasets or when you only need to iterate once, a generator expression saves memory.

10. 20.How does Python's garbage collection work, and what role does reference counting play?

    What they're really asking: Memory model fluency beyond 'Python handles it for me'.

    Answer outline

    • CPython primarily uses reference counting: an object is freed when its reference count hits zero.
    • A separate cyclic garbage collector handles reference cycles that counting alone can't clean up.

11. 21.How would you structure a FastAPI or Django project so business logic isn't tangled with the web framework?

    What they're really asking: Architecture judgment: can you keep the framework at the edges?

    Answer outline

    • Keep request/response handling in views or routes, and put business logic in separate service or domain modules.
    • Pass data in and out with plain functions or dataclasses rather than framework-specific objects where possible.

12. 22.How do you manage dependencies and reproducible environments in a Python project?

    What they're really asking: Practical judgment that affects every project's reliability.

    Answer outline

    • Pin dependency versions in a lockfile, using tools like pip-tools, Poetry, or a requirements.txt generated from a lock.
    • Use a virtual environment per project to avoid cross-project version conflicts.

Take-home or live exercise: tips

Python interviews often include live coding in a shared editor, and sometimes a take-home script or code review.

• Write idiomatic Python, not code translated from another language, using comprehensions and built-ins naturally.
• Narrate your reasoning while coding, including why you chose a particular data structure.
• In a take-home, include a short README with how to run it and your assumptions.

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.You find that a script works fine on your machine but fails in production. How do you investigate?

   What they're really asking: Can you reason about environment differences rather than just re-running it?

   Answer outline

   • Compare Python versions, installed package versions, and environment variables between environments.
   • Check for differences in file paths, time zones, locale settings, and available permissions.

   Full sample answer (fictional example)

   I'd start by comparing environments rather than re-running the script and hoping: Python version, installed package versions, and environment variables are the first three things I check, since a surprising number of these bugs come from a version mismatch. Next I'd look at anything environment-specific in the code itself, like hardcoded file paths, time zone assumptions, or locale-dependent formatting, since those often work locally by coincidence. If I still can't spot it, I'd reproduce the production environment in a container or a matching virtual environment locally, which usually surfaces the difference quickly.

2. 24.A teammate's pull request uses a bare except: pass around a database call. How do you respond?

   What they're really asking: Will you flag a real risk constructively in review?

   Answer outline

   • Explain what a bare except hides: it can swallow real bugs, including ones unrelated to the intended case.
   • Suggest catching the specific exception type the database driver raises, and logging it at minimum.

3. 25.Your Python service's memory usage grows steadily over days until it's restarted. How do you approach it?

   What they're really asking: Can you diagnose a slow leak methodically in a dynamic language?

   Answer outline

   • Check for unbounded caches, circular references involving objects with __del__, or a library holding onto connections.
   • Use a memory profiler or tracemalloc to snapshot allocations over time and find what's accumulating.

4. 26.You're asked to add a feature to a script that has no tests and was written by someone who's left the company. How do you proceed?

   What they're really asking: Do you balance caution and speed in unfamiliar, untested code?

   Answer outline

   • Read through it carefully and run it against known inputs to understand current behavior first.
   • Add a few tests around the behavior you're about to touch before changing anything.

5. 27.You're asked to add type hints to a large untyped codebase. How do you approach it without blocking other work?

   What they're really asking: Can you drive a quality improvement incrementally and sustainably?

   Answer outline

   • Start with mypy in a lenient mode, and type the most frequently touched or highest-risk modules first.
   • Add a CI check that prevents new untyped code without requiring the whole codebase to pass immediately.

6. 28.A dependency your project relies on hasn't been updated in two years and has an open security advisory. What do you do?

   What they're really asking: Do you manage dependency risk proactively?

   Answer outline

   • Assess whether the advisory actually affects how you use the library.
   • Look for an actively maintained alternative or a patched fork, and estimate the migration effort.

7. 29.Your test suite takes 25 minutes to run and is slowing down the team. How do you address it?

   What they're really asking: Can you improve developer experience without sacrificing confidence in the suite?

   Answer outline

   • Profile the suite to find the slowest tests, often ones hitting a real database or network.
   • Replace slow integration-style tests with faster unit tests plus a smaller, separate integration suite.

8. 30.You're debugging a script that works correctly with small inputs but produces wrong results on large ones. How do you investigate?

   What they're really asking: Do you suspect scale-dependent bugs like overflow, ordering or memory limits?

   Answer outline

   • Check for issues that only appear at scale: floating-point accumulation, dictionary ordering assumptions, or truncation.
   • Narrow the input size until the bug disappears, to isolate roughly where it starts.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Writing working code that ignores Python idioms, like manual index loops.

   Practice rewriting a few snippets idiomatically and explaining why the idiom is clearer.

2. No real answer about how dependencies or environments are managed on past projects.

   Be ready to describe your actual setup: lockfiles, virtual environments, and how you pin versions.

3. Jumping straight to multiprocessing or async without explaining the actual bottleneck.

   Describe how you'd profile first, and only reach for concurrency once you know where time is going.

4. Treating exceptions as something to suppress rather than handle.

   Explain the specific exception types you catch and why, not just that you wrapped something in try/except.

How to prepare for a Python developer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: Language fundamentals

   Review mutability, the GIL, decorators, generators and comprehensions, and write one example of each from memory.

2. 2

   Day 2: Coding practice

   Solve two medium coding problems in a shared-editor style tool, writing idiomatic Python and narrating your reasoning.

3. 3

   Day 3: Framework refresh

   Rebuild a small endpoint in the relevant framework (Django, FastAPI or Flask), including one test.

4. 4

   Day 4: Debugging story

   Write out a past debugging story: symptom, investigation, root cause, fix, and what you'd check earlier.

5. 5

   Day 5: Dependency and tooling review

   Review how you'd explain dependency management, virtual environments and linting setup on a real project.

6. 6

   Day 6: Design and tradeoffs

   Prepare one example where you chose between two libraries, with the comparison you made.

7. 7

   Day 7: Coding dry run

   Run a mock covering one coding problem, one language-internals question and two behavioral questions, then rest.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. What does the Python version and main framework look like, and are there plans to upgrade either?
2. How is testing structured, and is there a required coverage or review standard?
3. How does the team manage dependencies and virtual environments?
4. What's a recent performance or scaling issue the team worked through?
5. What does the balance look like between new feature work and maintaining existing scripts or services?

Preparation tips

• Review Python pitfalls: mutable defaults, the GIL, shallow versus deep copy and decorators.
• Practice explaining a past debugging story in two minutes: symptom, investigation, cause, fix.
• Check the job post for the framework and be ready to compare it with what you've used.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.