Hire Python Developers: Costs, Vetting and Engagement Models

Python is not one job, and that is where hiring breaks

Python spans four largely separate careers, and most bad hires come from confusing them.

The person who builds a Django admin with a Postgres schema, Celery workers and a Stripe webhook is not the person who writes Airflow DAGs and dbt models on top of Snowflake. Neither is the person who fine tunes a model in PyTorch, and none of the three is the person who keeps an asyncio service answering 3,000 requests per second without leaking file descriptors. They all write Python. They read each other's code with roughly the fluency of a novelist reading a legal contract.

The mismatch usually looks like this. A founder hires a senior Python developer whose CV lists pandas, scikit learn and a Kaggle placement. The job is a FastAPI backend for a scheduling product. Six weeks in, the endpoints work on the developer's laptop and fall apart under any concurrency. The reason: they wrote async def route handlers and then called the synchronous requests library and a blocking database driver inside them. Every request parked the event loop. The developer had never needed to know this, because notebooks do not have event loops. They were not a fraud. They were a data person doing a backend job, and nobody in the room knew enough to catch the mismatch in the interview.

The second failure mode is subtler and more expensive: the developer who treats Python's flexibility as permission. No type hints, no pyproject.toml, dependencies pinned nowhere, a utils.py that grew to 2,000 lines, business logic in Django views, mutable default arguments, and tests that hit the live database. It runs. It ships. Then month five arrives, someone needs to change how pricing works, and every change breaks something two modules away. Python punishes undisciplined teams later than most languages do, which is exactly why it punishes them harder.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house hire. Right when Python is the core of your product, the domain logic is genuinely yours, and you will keep shipping to it for years. A staff engineer who owns your Django or FastAPI codebase, your migration hygiene, and your Celery queue behaviour under load will pay for themselves. Wrong when you have nobody technical to interview them, because a mediocre Python developer interviews extremely well. The language is friendly and the demos are easy.

Freelancer. Good for bounded, self contained work: a scraper, a Stripe integration, a one off data migration, a Streamlit internal tool. Cheap and fast. The failure is structural, not personal. One freelancer has nobody reviewing their pull requests, so whatever habits they have go straight into your repo. When they disappear, so does the only mental model of why settings.py looks like that.

Agency. You buy a team: an engineer, someone senior reviewing their code, a QA pass, and a project manager who chases things you forgot. Highest rate per hour, usually the lowest cost per shipped feature on anything above a few weeks. What you give up is control of defaults. If they build everything in Django and your problem wants a thin FastAPI service and a queue, you may still get Django. Ask what stack they would choose and why before you sign.

Staff augmentation. A vetted engineer embedded in your team, your sprints, your standup, your repo. Fits when you have a technical lead who can direct work but not enough hands. Cheaper than an agency, safer than a freelancer. It only works if that lead actually reviews code. Drop an augmented Python engineer into a team with no code review and you have bought an expensive freelancer.

What it costs

These are Digital Heroes numbers, drawn from what we pay, what we quote, and what clients tell us they were quoted before calling us.

• Offshore (India, Eastern Europe, Latin America): roughly $25 to $55 per hour. The low end is junior or CRUD Django work. The upper end buys someone who has run Celery in production and knows why your task is executing twice.
• Onshore contractor (US, UK, Western Europe): roughly $60 to $110 per hour, mid to senior.
• Agency, US or Western Europe: roughly $110 to $180 per hour blended, which includes review, QA and delivery management.
• Specialist premium: we quote applied ML, LLM systems, real time data engineering and high concurrency async work above the equivalent generalist, because the pool is smaller and the mistakes cost more.

The in-house number people quote is base salary, and base salary is the smaller half of the story. Employer taxes, health coverage, retirement contributions and insurance put total compensation meaningfully above base. Then add recruiting: an agency fee tied to first year salary, or your own senior people spending weeks screening, which is not free. Then equipment, tooling and cloud seats. Then ramp. A new Python engineer joining an existing Django or FastAPI codebase is typically net negative for the first month, at partial output through month two or three, and fully productive somewhere in month three or four. Budget a real fully loaded first year cost, not a salary line.

One item nobody prices: if the hire is wrong, you pay for the hire, the severance, the re-recruit, and then somebody has to untangle what they built. That last part is often the biggest number on the page.

How to vet a Python developer

Name the actual job first: web backend, data engineering, or ML. Then vet for that, not for "Python."

Read their code before you talk to them. Ask for a repo or a published package. You are looking at plumbing, not cleverness. Is there a pyproject.toml with pinned dependencies, or a requirements.txt that says django with no version? Are there type hints on public functions, and does mypy or pyright actually pass? Do the tests use fixtures and factories, or does test_user.py depend on test_admin.py having run first? Is there a ruff or flake8 config, and black? Is business logic in Django views and serializers, or in a service layer? A developer who has felt maintenance pain has these by reflex. A developer who has only ever shipped features once does not.

Questions that separate people.

• "Walk me through what happens when I put requests.get() inside a FastAPI async def handler." The right answer names the blocked event loop and reaches for httpx or run_in_executor. A blank look tells you they have never run async under load.
• "How do you stop a Celery task from running twice?" They should go straight to at least once delivery, idempotency keys, and the visibility timeout. Anyone who says "Celery handles that" has not been paged at 2am.
• "Show me an N+1 you found in Django." You want a war story with select_related versus prefetch_related, and ideally django-debug-toolbar or a query log. The distinction between those two calls, a join versus a second query, is a clean seniority test.
• "Describe a migration that went wrong." Good answers mention adding a non-nullable column to a large table, locking, or a data migration that timed out. Great answers mention splitting schema and data migrations to avoid it.
• "What is a mutable default argument and why does it bite?" Basic, and worth asking anyway. It filters people who learned Python from tutorials rather than from bugs.
• For data roles: "How do you test a dbt model or an Airflow DAG?" and "What did you do when a backfill silently produced wrong numbers?"

The take home. Keep it under four hours and make it look like your work. A good shape: here is a CSV or a small third party API, build an endpoint that ingests it, persists to Postgres, handles duplicate submissions safely, and exposes a filtered read. Ship with tests and a README. Then judge it on what a demo hides. Did they use a transaction? Did they handle the API returning a 500 halfway? Did they write one test that proves the duplicate case, or three that all prove the happy path? Do the type hints exist and pass? Is there a docker-compose.yml so you can run it? Pay for their time. Then spend thirty minutes making them defend a choice you disagree with. How they argue tells you more than the code does.

Red flags

• Everything is a notebook. A portfolio of Jupyter notebooks and Kaggle entries proves analysis skill, not engineering skill. Notebooks hide state, order dependence and untested code. Ask instead: "Show me something you shipped that other people had to run in production."
• "Python is slow, so I wrote it in..." A developer who blames the language before profiling has never opened cProfile or py-spy. Ask instead: "Tell me about the last time you profiled something. What was actually slow?" The real answer is nearly always a query, an N+1, or a network call in a loop, not the interpreter.
• Async everywhere. Someone who marks every function async def including CPU bound ones is copying a pattern they do not understand. Ask instead: "When would you not use async, and would you reach for threads or processes for CPU bound work?" They should know the GIL and why multiprocessing exists.
• Dependency chaos. Unpinned requirements, no lockfile, no virtualenv discipline, or "it works on my machine, just pip install." This predicts your deploys breaking on a Tuesday because a transitive dependency shipped a minor version. Ask instead: "How do you pin dependencies and how do you upgrade them?" Poetry, uv, pip-tools, any real answer is fine. No answer is not.
• Tests that touch the real database and the real API. Ask to see their test suite run offline. If it needs network, they have never had a CI pipeline they trusted, and they do not know pytest fixtures, factory_boy or responses. Ask instead: "How do you test code that calls a third party API?"

When to hire a Python developer at all, and how we staff it

Do not hire one because Python is popular. Hire one when the problem is genuinely Python shaped: heavy data work, an ML or LLM component, integrations and automation across messy systems, a backend where the ecosystem does the hard part for you. If you are building a browser heavy product with a thin API, a strong TypeScript full stack developer will move faster than a Python backend developer plus a separate frontend developer. If your only need is scripts and glue, an automation or DevOps engineer may cover it. If the real problem is that your data lives in six places, you want a data engineer who happens to write Python, not a Django developer.

How Digital Heroes staffs it: we name the discipline first, then pick the person. Web backend work goes to engineers with Django or FastAPI in production and scars from migrations and queues. Data work goes to people who have run pipelines that broke at 3am. ML work goes to people who have deployed a model, not just trained one. Every engagement has a senior reviewing pull requests, because you avoid the maintenance cliff by refusing the first shortcut, not by fixing it in month five. Type checking, linting and CI are set up in week one, because they cost an afternoon then and a rewrite later. You own the code and the repo from the first commit. When a client wants to bring the work in-house eventually, we plan for that and hand over a codebase a new hire can read, which is the only real test of whether it was written well.