Django is a batteries-included Python web framework used by many startups and enterprises. These Django interview questions cover MVT, models, views, templates and the admin for freshers, then the ORM, migrations, middleware, Django REST Framework, query optimisation, security and deployment for experienced Django developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Django is a high-level Python web framework that includes an ORM, admin panel, authentication, forms, templating and security features out of the box.
It follows Model-View-Template: models define data and database tables, views contain the logic that handles requests and returns responses, and templates render HTML.
Django itself acts as the controller, routing URLs to views.
A project is the whole website with its settings, root URL configuration and WSGI or ASGI entry point.
An app is a self-contained module for one feature, such as blog, accounts or payments, with its own models, views, URLs and templates.
A project contains several apps, and apps can be reused across projects.
Migrations are files that record changes to models so the database schema can be updated to match. makemigrations creates migration files from model changes, and migrate applies them to the database. They are version-controlled, so every environment can be brought to the same schema, and can include data migrations.
The ORM lets you work with the database using Python classes and methods instead of SQL, for example Book.objects.filter(published=True).order_by("-created").
A QuerySet is lazy: building and chaining filters does not touch the database until you iterate over it, slice it, call len(), list() or similar.
This lets Django build one efficient query from all the chained conditions.
ForeignKey creates a many-to-one relationship, such as many books to one author, with on_delete deciding what happens when the author is deleted (CASCADE, PROTECT, SET_NULL).
ManyToManyField links many to many, such as books and tags, using a join table, optionally a custom one with through.
OneToOneField links exactly one to one, such as a user and a profile. related_name sets the reverse accessor.
The admin is an automatically generated interface for managing data in registered models.
With a ModelAdmin class you configure list_display, list_filter, search_fields, inlines for related objects, read-only fields and custom actions.
It is ideal for internal staff and content management, but is not meant as a customer-facing interface.
urls.py files map URL patterns to views with path(), using converters such as <int:id> or <slug:slug> to capture values, and include() to delegate to each app's URL configuration. Naming routes, as in path("books/<int:pk>/", views.detail, name="book-detail"), lets you build URLs with reverse() or the url template tag instead of hard-coding them.
A base template defines the common layout with {% block content %}{% endblock %} placeholders.
Child templates start with {% extends "base.html" %} and override only the blocks they need. {% include %} inserts reusable fragments, and custom template tags and filters add logic.
The template language deliberately limits logic so that it stays in views.
A Form defines fields and validation for any input, such as a contact form.
A ModelForm builds its fields automatically from a model, validates them against the model's rules and can save directly to the database with form.save().
Both clean and validate data, show errors, and protect against CSRF when rendered with {% csrf_token %}.
DEBUG (must be False in production), SECRET_KEY (from the environment), ALLOWED_HOSTS, DATABASES, INSTALLED_APPS, MIDDLEWARE, TEMPLATES, STATIC_URL and STATIC_ROOT, MEDIA settings, AUTH_USER_MODEL, TIME_ZONE and USE_TZ, and security settings such as CSRF_TRUSTED_ORIGINS and SECURE_SSL_REDIRECT. Many projects split settings by environment or read them from environment variables.
Static files are part of the code, such as CSS, JavaScript and images, collected into STATIC_ROOT with collectstatic and served by WhiteNoise, Nginx or a CDN.
Media files are uploaded by users, such as profile photos, stored in MEDIA_ROOT or cloud storage such as S3 through django-storages.
Django should not serve either directly in production.
Applied problems, trade-offs and questions about your own projects.
Both solve the N+1 query problem. select_related follows foreign key and one-to-one relationships using an SQL JOIN, fetching related objects in the same query. prefetch_related runs a separate query for each relationship and joins the results in Python, which works for many-to-many and reverse foreign key relationships.
Middleware is a layer of hooks that process every request and response globally.
Each middleware can act before the view runs, after it returns, or on exceptions.
Built-in middleware handles sessions, authentication, CSRF protection, security headers and messages.
Order in the MIDDLEWARE setting matters because requests pass through top to bottom and responses bottom to top.
Function-based views are simple functions that take a request and return a response, which is explicit and easy for simple logic. Class-based views organise handling by HTTP method and allow reuse through inheritance and mixins, and generic views such as ListView, DetailView and CreateView handle common patterns with very little code.
Signals let code react to events, such as post_save after a model is saved or user_logged_in, without the sender knowing about the receiver.
They are useful for decoupled apps, such as creating a profile when a user is created.
I avoid overusing them because the flow becomes hidden and hard to debug; explicit service functions are usually clearer.
F() refers to a field's value in the database, so you can compare fields or update a value without loading it, such as Product.objects.update(stock=F("stock") - 1), which avoids race conditions. Q() builds complex conditions with OR (|), AND (&) and NOT (~), such as filter(Q(city="Pune") | Q(city="Mumbai")).
aggregate() calculates values over the whole QuerySet and returns a dictionary, such as Order.objects.aggregate(total=Sum("amount")). annotate() adds a calculated value to each object, such as Author.objects.annotate(book_count=Count("books")), which you can then filter or sort on. Both run the calculation in the database, which is far faster than looping in Python.
Changing the user model after the first migration is very difficult, so Django recommends starting every project with a custom user model, usually subclassing AbstractUser, and setting AUTH_USER_MODEL.
It lets you add fields such as phone number or log in with email instead of username later.
Code should refer to the user with get_user_model() or settings.AUTH_USER_MODEL.
django.contrib.auth provides users, password hashing, login and logout views, sessions, groups and permissions.
Views are protected with @login_required or LoginRequiredMixin, and @permission_required or PermissionRequiredMixin check model permissions such as "blog.change_post".
Groups assign permissions to many users.
Object-level permissions need custom checks or a library such as django-guardian.
A manager is the interface to database queries for a model, objects by default.
A custom QuerySet class holds reusable, chainable query methods, such as Post.objects.published().recent(), and is attached with as_manager() or a custom manager.
This keeps query logic in one place instead of repeating filters across views.
By default each query is committed immediately. transaction.atomic, as a decorator or context manager, wraps several operations so they all succeed or all roll back, for example creating an order and reducing stock. select_for_update locks rows to prevent concurrent changes, and transaction.on_commit runs code such as sending emails only after the transaction has committed.
Django supports cache backends such as Redis, Memcached, the database and local memory.
You can cache whole pages with the cache_page decorator, fragments of templates with {% cache %}, or any value with the low-level API (cache.get, cache.set).
Cache keys must include anything the result depends on, such as the user or language, and entries need sensible timeouts or invalidation.
System design, deep internals, leadership and tough follow-ups.
I define serializers to convert models to JSON and validate input, use ViewSets or generic API views for endpoints, and register them with routers for URLs.
I configure authentication (session, token or JWT), permission classes, pagination, filtering and throttling.
Query optimisation in get_queryset with select_related and prefetch_related keeps endpoints fast.
I use Django Debug Toolbar or django-silk to find slow views and duplicate queries, fix N+1 problems with select_related and prefetch_related, fetch only needed columns with only() or values(), add database indexes, and use aggregate and annotate to calculate in the database. I cache expensive results with Redis, paginate large lists, and move slow tasks to Celery.
Django protects against SQL injection through the ORM, cross-site scripting through automatic template escaping, cross-site request forgery with CSRF tokens, and clickjacking with the X-Frame-Options header.
It hashes passwords with PBKDF2 by default and supports argon2.
In production I set DEBUG = False, use a secret key from the environment, set ALLOWED_HOSTS, enable HTTPS settings such as SECURE_SSL_REDIRECT and secure cookies, and run manage.py check --deploy.
Celery with Redis or RabbitMQ as the broker runs tasks such as sending emails, generating reports and processing images in worker processes, with retries, scheduling through celery beat, and monitoring with Flower.
Simpler alternatives include RQ and Dramatiq, and Django 6.0 adds a built-in tasks framework.
Tasks should be idempotent and receive IDs rather than whole objects.
ASGI is the asynchronous successor to WSGI.
Django supports async def views, async ORM methods and async middleware, which help with views that wait on external APIs.
Django Channels adds WebSockets and other long-lived connections, for chat or live updates, using a channel layer such as Redis to communicate between processes.
Servers such as Uvicorn or Daphne run ASGI apps.
Run it with Gunicorn (or Uvicorn for ASGI) behind Nginx or a cloud load balancer with HTTPS, set DEBUG = False and read secrets from the environment, run migrations and collectstatic during deployment, serve static files with WhiteNoise or a CDN and media from cloud storage, use PostgreSQL, add Redis for caching and Celery, and set up logging, error tracking with Sentry and backups. Containers make this repeatable.
Django's TestCase wraps each test in a transaction and provides a test client for requests; pytest-django gives the same with pytest fixtures. factory_boy builds test data, APIClient tests Django REST Framework endpoints, and assertNumQueries catches N+1 problems. External calls are mocked, and tests run in CI with a real PostgreSQL database.
Add indexes for common filters and orderings (Meta.indexes), avoid N+1 queries, use only(), defer(), values() and iterator() for large datasets, and move heavy reports to raw SQL or database views. Add connection pooling with PgBouncer or Django 5.1's built-in pooling for PostgreSQL, send reads to replicas with database routers, cache aggressively, and partition very large tables.
See all Backend Developer interview questions, covering Node.js, Express.js, NestJS, Python, Django and more.