Hire Django developers

Django is the batteries-included Python web framework, and hiring for it means testing whether someone can control its ORM rather than merely use it.

What Django actually is

Django is a Python web framework maintained by the Django Software Foundation, with long-term support releases on a predictable schedule. It supplies an object-relational mapper, a migration system, an authentication framework, a templating language and an automatically generated administrative interface, all designed to work together. It is the framework of choice for a large share of Python web applications, particularly content-heavy and data-heavy ones.

Its central design belief is that most web applications need the same things, and that supplying them coherently is more valuable than supplying them flexibly. That is why a Django project written by two different teams looks broadly similar, and why a competent Django developer can be productive in an unfamiliar Django codebase within days. Few frameworks in any language offer that.

The administrative interface deserves particular mention because it changes project economics. A great many internal tools that would otherwise be built from scratch are instead a Django admin with some customisation, delivered in a fraction of the time. Knowing when that is sufficient and when it is a trap is a genuine senior skill, because the admin is excellent for staff and consistently wrong as a customer-facing interface.

The part that separates seniors from mid-levels

The ORM is where Django projects succeed or fail. It is expressive enough that developers can write code that looks clean and issues a query per row. The querysets are lazy, so where a query executes is not always where it was written, and evaluation can be triggered by something as innocuous as a template loop. Developers who understand this reach for select_related and prefetch_related deliberately and read the query log. Those who do not ship applications that work in development and fall over in production.

Migrations are the second area, and the one that causes the most operational pain. Django generates them automatically from model changes, which is convenient and hides the fact that some migrations lock tables. On a large table in production, adding a column with a default, or adding an index without the concurrent option, can take a site down. Senior developers review generated migrations before applying them and know which operations are safe on a live database.

The third is the request and response cycle and where middleware sits in it. Django's middleware is ordered and each layer can short-circuit the rest, which makes it powerful for cross-cutting concerns and a good source of confusing bugs when the order is wrong. Understanding this is what lets someone debug a problem where authentication appears to work everywhere except one path.

Where Django is used

The label “Django developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Content-heavy applications

Publishing, education and media platforms, where the admin and the ORM cover most of the editorial workflow.

Internal business tools

Operations systems built largely on the admin interface, often replacing spreadsheets in a matter of weeks.

Data-adjacent products

Applications where the same team also does analysis or modelling, and sharing Python across both is the point.

Marketplaces and SaaS

Subscription and multi-party products using Django REST Framework behind a separate front end.

Scientific and research platforms

University and research applications, where Python is already the working language.

Government and non-profit

A strong Django presence, helped by its accessibility, security record and lack of licensing cost.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Django versions are still supported

Django publishes long-term support releases with clear support windows and a well-documented deprecation path, which makes upgrade planning unusually predictable.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 3 are still maintained and 5 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Django alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Django REST Framework

The standard way to build APIs on Django, with serialisers, permissions and browsable documentation.

PostgreSQL

The usual data store, and the one whose features Django supports most thoroughly.

Celery with Redis

Background work and scheduling, which Django itself deliberately leaves out.

pytest with pytest-django

Testing, generally preferred over the built-in runner for fixtures and parameterisation.

django-debug-toolbar

Local query inspection, which is how N plus one problems become visible.

Gunicorn or uvicorn

The application server, with uvicorn where async views are in use.

Whitenoise or a CDN

Static file serving, a routine source of deployment confusion.

django-allauth

Authentication flows beyond the built-in defaults, including social sign-in.

Related skills that frequently appear on the same specification: Python, SQL, Data Engineering, React, AWS.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Querysets and lazy evaluation

The core of the framework and the source of most performance problems.

• Strong answer: Explains when a queryset executes, uses select_related and prefetch_related deliberately, and reads the query log as a habit.
• Warning sign: Cannot say when a query runs, or has never inspected the SQL a view produces.

Migrations on a live database

Where Django causes production incidents rather than merely slow pages.

• Strong answer: Reviews generated migrations, knows which operations lock, and separates schema changes from data backfills.
• Warning sign: Applies generated migrations without reading them and has not considered table locking.

Where the admin is and is not appropriate

A commercially significant judgement that is often made by accident.

• Strong answer: Uses it for internal staff, builds properly for customers, and can articulate where the line is.
• Warning sign: Proposes exposing the admin to customers, or dismisses it entirely for internal use.

Django REST Framework serialisers

Where API performance and correctness problems concentrate.

• Strong answer: Understands nested serialiser cost, validates properly, and separates read and write representations.
• Warning sign: Nests serialisers deeply without considering the queries that result.

Settings and environments

Django projects accumulate settings, and secrets end up in source control.

• Strong answer: Environment-based configuration, secrets from the environment or a vault, and explicit failure when something required is absent.
• Warning sign: A settings file with credentials in it and a committed local override.

Async views and when they help

Newer capability, frequently misunderstood.

• Strong answer: Knows async helps input-and-output-bound work and that a blocking call inside an async view defeats the purpose.
• Warning sign: Assumes async views make an application faster generally.

Testing approach

Django makes testing straightforward, so weak testing is a choice.

• Strong answer: Tests through the view layer against a real database, with factories rather than fixtures, and is clear about what is not tested.
• Warning sign: Mocks the ORM, or relies on the admin to verify behaviour manually.

Warning signs in a Django codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

The N plus one query

• What you see: A template or serialiser touching a related object per row.
• What it costs: Hundreds of queries per page, with latency that grows as data grows.
• The fix: select_related for forward relations, prefetch_related for reverse and many-to-many. Run the debug toolbar locally so the count is always visible.

Fat models and fat views

• What you see: Business logic spread across model methods and view functions with no clear home.
• What it costs: Logic cannot be reused or tested without constructing a request or a database row.
• The fix: Extract into service functions that take plain arguments. Keep models for data and views for the HTTP layer.

Blocking migrations in production

• What you see: A generated migration applied directly to a large live table.
• What it costs: Table locks and an outage during what was planned as a routine deploy.
• The fix: Read every generated migration. Add indexes concurrently, add columns without a default then backfill, and split schema from data changes.

Secrets in settings

• What you see: Database passwords and API keys committed in a settings module.
• What it costs: Credentials in version control history forever, including for anyone who ever had read access.
• The fix: Read from the environment or a secret store, and fail loudly at startup when a required value is missing.

Signals for core business logic

• What you see: Important behaviour triggered by post_save handlers.
• What it costs: Effects fire from tests, fixtures, the admin and data imports, producing surprising results far from the cause.
• The fix: Call the behaviour explicitly from an application service. Keep signals for narrow, genuinely incidental concerns.

The admin as a customer interface

• What you see: External users given admin accounts with restricted permissions.
• What it costs: An interface designed for trusted staff exposed to untrusted users, with a permission model that was never meant to carry that weight.
• The fix: Build the customer-facing views. The admin is a staff tool and its security assumptions reflect that.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Django developer.

Junior

Builds views, models and admin configuration in an existing project. Needs review on query patterns and on migrations.

Mid-level

Owns a feature area including its API, tests and background jobs. Can diagnose an N plus one problem unprompted.

Senior

Owns the data model, the migration strategy on live data, the API design and the background-work architecture. Knows where the framework's conventions stop serving the product.

Staff

Owns the upgrade path across long-term support versions, the boundary between Django and the rest of the estate, and the decision about what should not be in Django at all.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New Django application

• Usual team: One to two developers.
• What governs it: Very fast to a working product. The data model is the thing to get right, because changing it later under real data is the expensive part.

Internal tool on the admin

• Usual team: One developer.
• What governs it: Often days rather than weeks. Scoped by how much customisation pulls it away from the defaults.

API for a separate front end

• Usual team: One developer with REST Framework experience.
• What governs it: Serialiser design drives both performance and the front-end experience, so it deserves review.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Begins with the query log. Usually a handful of views account for most of the problem.

Long-term support upgrade

• Usual team: One developer.
• What governs it: Routine between adjacent long-term support versions. Third-party packages are the usual blocker rather than Django itself.

Migration work you may actually be hiring for

A large share of Django work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

An older Django version to the current long-term support release

• Why teams do it: Security support and compatibility with maintained packages.
• What to watch: Move between long-term support versions rather than chasing every release. Check third-party package compatibility first, because that is what blocks the upgrade rather than Django's own deprecations.

Server-rendered templates to a REST API with a separate front end

• Why teams do it: A genuinely application-like interface, or more than one client consuming the same data.
• What to watch: Authentication changes shape entirely, from sessions to tokens. Run both in parallel and move page by page; a simultaneous cutover of the interface and the auth model is where these projects fail.

Synchronous views to async views

• Why teams do it: Throughput where the application spends its time waiting on external services.
• What to watch: A single blocking call inside an async view undoes the benefit, and much of the ORM and many libraries are still synchronous. Only worth doing for genuinely input-and-output-bound paths, not across the board.

Logic in signals and model methods to explicit service functions

• Why teams do it: Behaviour that fires invisibly from tests, imports and the admin is the hardest kind of bug to trace.
• What to watch: Move one signal at a time and search for every trigger path first. Data imports and admin actions are the ones people forget.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Django developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which Django version the project is on and whether an upgrade is in scope.
• Whether the interface is server-rendered templates, the admin, or a separate front end over an API.
• How large the main tables are, since that determines whether migrations are routine or dangerous.
• Whether Celery or another background worker is in use and who is responsible when jobs fail.
• Whether the person will be working alongside data scientists, which is common in Python and changes the review dynamic.
• What the deployment looks like, because static files and application servers are where Django deployments usually go wrong.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Django work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Django developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Django developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Django frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

ORM use without SQL understanding. Ask what SQL a given view produces. Django hides the database well enough that this gap can persist for years.

No experience of migrations under load. Ask about a migration that caused a problem. This is where Django hurts production rather than merely performance.

Admin-only depth. Someone whose Django experience is largely admin customisation has not necessarily built an application. Ask what they have built outside it.

Data-science background without web engineering. Common in the Python world. Test error handling, authentication and deployment rather than assuming.

Hiring Django developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Django developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Is Django a good choice for a new product?

For most data-backed web applications, yes. It gets you to a working product faster than almost anything else because authentication, the admin, migrations and the ORM are already there and designed together. It is less compelling where the application is mostly a thin API in front of something else, or where the workload is dominated by concurrency rather than by data modelling.

Django or FastAPI?

Django when you want a complete application with an admin, sessions, templates and a data model that will evolve. FastAPI when you are building typed APIs, want async throughout, and do not need the rest. A useful test is whether you would use the admin: if yes, that alone is often worth choosing Django for.

Can we use the Django admin as our internal tool?

For staff, very often yes, and it is one of the highest-return decisions available in Python web development. Weeks of interface work can be replaced by configuration. The line to hold is that it is for trusted internal users. Exposing it to customers puts an interface built on staff-level assumptions in front of people who do not share them.

Why is our Django site slow?

Almost always the query count. A page that looks simple can be issuing several hundred queries because a template or serialiser touches a related object per row. Installing the debug toolbar and looking at one slow page usually identifies it in minutes, and the fix is typically a few lines of eager loading.

How risky are Django migrations in production?

Riskier than most teams assume, because the framework generates them automatically and they look routine. On a large table, adding an indexed column or altering a type can hold a lock long enough to be an outage. The practice that prevents this is reading every generated migration before it is applied and separating schema changes from data backfills.

How do Django upgrades work?

Between long-term support versions they are usually straightforward, helped by clear deprecation warnings and good release notes. The blocker is almost always third-party packages rather than Django itself, so the first step in any upgrade is checking which dependencies support the target version. Applications that upgrade on the cycle rarely find it difficult.

Should we use Django's templates or a separate front end?

Templates when the application is mostly server-rendered and the team is Python-first; it is simpler and faster and there is no second codebase. A separate front end when the interface is genuinely application-like or when there is more than one client. Choosing a separate front end for a mostly server-rendered product is a common way to double the work for no benefit.

Is Django suitable for high-traffic sites?

Yes, with the usual caveats about caching and database design that would apply to any framework. Large sites run on it. Where Django-based applications struggle at scale, the cause is nearly always the database access pattern rather than the framework, and that is fixable without changing technology.