There are four kinds of Python developer. Three of them are wrong for you.
Python spans web services, data engineering, machine learning and automation, and seniority in one of those does not transfer to the others. A language screen will not tell you which one you are talking to.
Same language, four different engineers.
A Django engineer who has spent six years on request handling, ORM behaviour and deployment is senior. Put them on an Airflow estate and they will be learning for a month, because the problems are about idempotency, backfills and scheduling rather than about requests.
A data engineer moved onto a web API will write something that works and will not have opinions about authentication, session handling or how the thing behaves when the database is slow, because those have never been their problems.
The ML engineer is further away again, and the automation specialist (the person who is excellent at making systems talk to each other) is the most under-valued of the four and frequently the one a brief needs.
None of this shows up in a CV that says “Senior Python Developer, 8 years”, and none of it is caught by a language screen. It is the first thing we establish and it changes who we put forward.
What we ask, once we know which Python you need.
The screen changes by column. These are the questions that hold across all four, and the answers still separate people sharply.
How do you manage dependencies?
Python's packaging story has improved and remains a place where teams create problems for themselves. We want a specific, current answer, not a shrug.
Where do you use type hints, and where do you not?
A considered answer indicates someone who has maintained a large Python codebase. Absolutism in either direction usually indicates the opposite.
What happens when this runs on ten times the data?
The most useful general question in Python. Memory, generators, chunking, and knowing when to stop using pandas.
How is it tested, and what is not tested?
The second half matters more. Candidates who can name what they deliberately left untested have thought about it.
Describe something you made twice as fast.
Profiling before optimising, and an actual measurement. Guessing at performance is the default behaviour in this ecosystem.
What did you have to leave running unattended?
Logging, retries, alerting and idempotency. Anything scheduled shows whether someone has operated software or only written it.
What the work looks like decides the hire.
Plot the work instead of the job title. Most briefs we receive sit somewhere other than where their job description implies.
Pipelines and warehouses
Airflow, dbt, warehouse modelling, backfills, idempotency. Nobody sees the output directly and everybody depends on it.
Models with an interface
Training, serving and evaluation with a product surface on top. Often two people instead of one.
Glue and integrations
Scripts, scheduled jobs, systems talking to each other. Undervalued, and frequently the highest return per day of the four.
Django or FastAPI
Requests, auth, ORM, deployment. The largest pool and the most straightforward brief to fill.
Four kinds of work, on this site.
Every one of these is a page you can read instead of a claim you have to take on trust.
- Applied AI and agents. Grounded retrieval, orchestration and evaluation — see AI agent development and the ATS agent.
- Forecasting and modelling. Feature pipelines, backtesting and serving — see demand forecasting.
- Data platform work. Ingestion, warehouse modelling and the reporting layer above it — see data, analytics and BI.
- Automation and integration. Systems that were never designed to talk to each other, made to — see workflow automation.
- Back-end services. Django and FastAPI behind products and internal platforms — see the Python stack.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring Python engineers.
Starting with the question that decides everything else.
How do we work out which of the four we need?
Describe what the code has to do rather than what you would call the role. “Take these files every night, reconcile them and load them somewhere reportable” is data engineering. “Let customers do this thing on a screen” is web. “Work out which of these is likely to churn” is ML, and possibly data science before that. “Stop three people copying between systems every morning” is automation, and it is usually the cheapest and highest-return of the four. If you send us that description we will tell you which column it lands in, and if it lands in two we will say that, not proposing a unicorn.
Is Python fast enough?
For the overwhelming majority of business systems, yes, because the time goes to the database, the network and the other services, not to the interpreter. Where it matters is tight numeric loops, and the answer there is not a different language but the libraries the ecosystem exists for, NumPy, Polars and the like push that work into optimised native code. The realistic performance risk on a Python project is not the language, it is loading a dataset into memory that will not fit there in eighteen months. We screen for that specifically.
Can one Python engineer cover the web app and the data work?
For a while, and it is a reasonable way to start a small team. The point at which it stops working is usually visible in advance: it is when the data work acquires a schedule and other people start depending on its output, because that turns it from a task into a system with its own reliability requirements. At that point one person is carrying two on-call responsibilities with different failure modes, and something gets neglected. If you are near that line, we would rather flag it now than staff one person and watch it arrive.