Python developer screening questions: Python 3 versions, Django and FastAPI, packaging, async and tests

Python developer screening questions should find out what kind of Python the candidate writes (web back ends in Django, FastAPI or Flask; automation and internal tools; data pipelines; or machine learning), which Python 3 version and libraries they ran in production, and whether they own the things that keep Python code reliable: dependencies and packaging, type checking, tests and async code. As of November 2026, Python 3.14 and 3.15 receive bug fixes, 3.11 to 3.13 receive security fixes only, and 3.10 reached end of life in October 2026, so "which version did your last project run, and how did you upgrade it?" is a quick test of real ownership. No license applies, and the Python Institute's exams show study rather than production work.

The general engineering screen is in software engineer phone screen questions. If the role is mostly pipelines and SQL, use the data engineer phone screen questions; if it is models in production, use the machine learning engineer screening questions. This page is for developers who write and ship Python applications, services and tools; to source them, see the Boolean search strings for Python developers.

Which Python developer job is it?

Ask the hiring manager for the Python version, the framework and its version, how code is packaged and deployed, whether the codebase is type-checked, and whether the role carries on-call. "Python developer" ads often list a web framework, a data stack and a cloud at once; find out which one the first six months actually need.

Which versions and certifications should you check?

• Python versions. The Python developer guide shows 3.14 (first released October 2025) and 3.15 (October 2026) in bugfix status, 3.11, 3.12 and 3.13 in security status, and 3.10 at end of life since October 2026, with 3.9 having ended in October 2025. Python.org says Python 2 was sunset on January 1, 2020.
• Removed modules. PEP 632 says code that imports distutils no longer works from Python 3.12, and the What's New in Python 3.13 page lists 19 legacy standard library modules removed in 3.13, including cgi, crypt and telnetlib. These are the kinds of breakage a developer who really upgraded will mention.
• Django. The Django project's download page shows 4.2 LTS out of support since April 7, 2026, 5.2 LTS supported until April 2028, 6.0 and 6.1 as current feature releases, and 6.2 LTS planned for April 2027.
• Free-threaded Python. PEP 779 set the criteria under which the free-threaded build, without the global interpreter lock, became officially supported but still optional in Python 3.14. The standard build still has the GIL, so a candidate who says they "removed the GIL" in production should be able to say which build they ran and which libraries supported it.
• Python Institute exams. The Python Institute's certification roadmap lists PCEP (Certified Entry-Level Python Programmer), PCAP (Certified Associate Python Programmer) and PCPP1 (Certified Professional Python Programmer 1) as active, plus entry-level tracks for data analysis, testing and security. They are optional; if a client asks for one, ask the candidate for the credential record and check the name and date.

Knockout questions

Python depth questions

1. "Tell me about the last Python or framework upgrade you did. What broke?"
   • Strong answer: a from-and-to version and a specific problem: a removed module, a dependency without a wheel for the new version, a Django deprecation, a test that started failing, and how they rolled it out.
   • Red flags: still on an end-of-life version with no plan, or "we just changed the version number."
2. "How were dependencies managed and installed on your last project?"
   • Strong answer: a pyproject.toml, a lock file or pinned requirements (pip-tools, Poetry or uv), isolated environments, a container build, and a story about a library release that broke something.
   • Red flags: installs whatever is latest on the server, or has never seen a lock file.
3. "Where did you use async code, and what went wrong?"
   • Strong answer: asyncio or FastAPI for I/O-bound work, a blocking call that froze the event loop, and when they chose threads, processes or a task queue instead.
   • Red flags: "async makes everything faster."
4. "Do you use type hints, and how are they checked?"
   • Strong answer: a type checker such as mypy or pyright running in CI, typed models with Pydantic or dataclasses, and a bug the checker caught.
   • Red flags: hints in some files that nothing ever checks.
5. "Tell me about slow Python code you made faster."
   • Strong answer: profiled first (cProfile, py-spy or a tracing tool), found the cause (a loop over rows that should have been one query, repeated work that could be cached, CPU-bound work in threads), and gives a before and after.
   • Red flags: "Python is just slow," with no measurement.
6. "How did you keep the code and its dependencies secure?"
   • Strong answer: dependency scanning (pip-audit or the platform's own), parameterized queries or the ORM instead of string-built SQL, secrets outside the repository, and care with package names copied from the web.
   • Red flags: credentials committed to the repository, described without concern.

Testing, deployment and code quality questions

If the next stage is a coding exercise, keep it short, relevant and scored the same way for every candidate; see how to evaluate a take-home assignment.

How does Python experience get overstated?

• Notebooks as production. Analysis in notebooks described as building applications. Ask where the code ran and who used it.
• Scripts as systems. A few automation scripts listed as "built a Python platform." Ask how it was installed, tested and supported.
• Framework by tutorial. Django or FastAPI from a course project. Ask about a migration, an authentication bug or a slow query in their own app.
• The data science list. pandas, NumPy and scikit-learn on a resume for a web role. Ask which the last job used every week.
• Python 2 maintenance as current work. Ask what was migrated and when.
• "Built an AI app." Often a script that calls a model provider's API. Ask what they built around the call: data, evaluation, error handling, cost limits.
• Team results as personal. Ask for the baseline, the change and who else worked on it.

A 15-minute phone-screen flow

1. Minutes 0 to 2: the product, the Python and framework versions, how it is deployed, the working pattern.
2. Minutes 2 to 5: knockouts 1 to 4.
3. Minutes 5 to 10: the upgrade question, then dependencies or async depending on the role. Write down versions and tools in their words.
4. Minutes 10 to 13: one testing question and one deployment question.
5. Minutes 13 to 15: pay expectations (see salary expectation questions), notice period and next steps.

Scoring

What to put in the submittal

Python developer: [name]
Kind of Python: [web / tools and automation / data / ML], main area last 2 years
Versions in production: [e.g. 3.11 to 3.13], framework [Django 5.2 / FastAPI / Flask]
Upgrade story: [from-to, what broke, how tested]
Dependencies: [pyproject and lock file / pinned requirements / other]
Typing and quality: [type checker in CI yes or no], [formatter and linter]
Testing: [pytest, what was covered]
Deployment: [container, server, pipeline, rollback]
Performance story: [problem, tool, cause, before and after]
Candidate's own gap: [e.g. "no async in production; Django only, not FastAPI"]

Lawful phrasing

Keep the questions on the work: versions, systems, results and how recent they are. Do not ask for graduation years or describe the team as "young"; the age discrimination guide explains why those comments cause trouble. Ask the sponsorship question the same way of every candidate and never ask about citizenship or national origin. If the role is fully remote and the client verifies identity (the FBI's January 2025 public service announcement on North Korean IT workers recommends it during interviewing and onboarding), use the same steps for everyone, as in how to verify candidate identity on a phone screen. Offer accommodations for any coding exercise on request, and see illegal interview questions for the full list to avoid. This page is not legal advice.