Django Interview Questions

"The model is my data layer: a Python class per table, and the ORM handles the SQL. The view is a function or class that receives the request, talks to the models, and returns a response. The template is the HTML with placeholders that the view fills in. The naming confuses people because Django's view does what MVC calls the controller, and Django's template does what MVC calls the view. The remaining controller work, deciding which code handles which URL, is done by the framework itself through the URL configuration. In practice I keep templates free of logic, keep views thin, and put business rules on the models or in a small service module, so they can be tested without a request."

"The request first reaches an application server like Gunicorn or Uvicorn, which calls Django through WSGI or ASGI. Django wraps it in an HttpRequest object. It then runs through the middleware stack top to bottom, so things like security headers, sessions, authentication and CSRF checks happen before my code. Next the URL resolver walks the urlpatterns in ROOT_URLCONF and picks the first pattern that matches, capturing any path parameters. The view runs with the request and those parameters, usually queries the database through the ORM, maybe renders a template, and returns an HttpResponse. That response travels back up through the middleware in reverse order, where things like compression or extra headers get applied, and the server sends it to the browser. If the view raises an exception, middleware can handle it, otherwise Django turns it into an error page."

"Middleware is code that wraps every request. Django builds a chain at startup: each middleware gets a get_response callable, which is the next layer down, and eventually the view. In my timing example, the code before calling get_response runs on the way in, and the code after runs on the way out, so I measure the gap and add it as a header and a log line. Order matters because each layer sees what the layers above it did. The authentication middleware reads the user from the session, so the session middleware has to come before it, otherwise request.user can't be set. Security middleware usually goes near the top so its redirects and headers apply to everything. I keep middleware light, because it runs on every single request, including static and health check hits if they go through Django."

"Signals let one piece of code react when something happens elsewhere. For example, a post_save receiver runs every time a model is saved. I connect receivers in the app's AppConfig ready method so they're registered once. They're useful when I need to react to a model I don't own, like a third-party app's model, where I can't just edit the save method. But I'm careful with them for our own business logic. A receiver runs synchronously, in the same request and the same database transaction, so a slow receiver slows the save and an exception in it bubbles up to whoever called save. Someone reading the view has no idea extra code runs. And QuerySet.update() and bulk_create() don't send save signals at all, so logic in a receiver can silently be skipped. For our own models, I'd rather call a clear service function that does the save and the follow-up steps in one visible place."

"The clue is that the email exists but the account doesn't. post_save runs straight after the INSERT, but still inside the transaction. If the sign-up view wraps several steps in atomic, or ATOMIC_REQUESTS is on, and a later step fails, the user row rolls back. The email, though, has already gone out, and you can't roll back an email. It also means the request waits on the mail server. I'd suggest two changes. First, wrap the send in transaction.on_commit, so it only happens once the data really commits, and have it queue a background task that takes the user's id and loads the user fresh, so the request stays fast and retries are possible. Second, I'd move it out of the signal into the function that registers users. Then anyone reading the sign-up code sees that it sends an email, and a bulk import or a test won't trigger emails by surprise. I'd pair with the teammate on it rather than just rewriting it."

"Lazy means that building a QuerySet costs nothing. When I write Book.objects.filter(published=True).order_by('title'), Django just builds up a description of the SQL. The query only runs when I actually need the rows: when I loop over it, call list() or len() on it, test it in an if, print it in the shell, or slice it with a step. A plain slice like [:10] stays lazy and becomes a LIMIT. Once a QuerySet has been evaluated, it caches its results, so looping over the same object twice only queries once. But if I call .filter() or .all() again I get a new QuerySet and a new query. That's why I store the QuerySet in a variable when I'll reuse it, use exists() when I only need a yes or no, and use count() when I only need the number and won't load the rows anyway."

"Both solve the same problem: touching a related object inside a loop, which otherwise fires one query per row, the classic N+1. select_related follows ForeignKey and OneToOne fields using a JOIN, so I get the books and their authors in a single query. It only works where each row has at most one related object. For the many side, like an author's books or a many-to-many of tags, a JOIN would multiply rows, so prefetch_related runs a second query with an IN clause for all the related rows and matches them up in Python. So the rule of thumb is: a single related object, select_related; a collection, prefetch_related. I can combine them, and when I need to filter or order the prefetched rows I use a Prefetch object with its own QuerySet."

"If I load a post, add one to views in Python and save it, two requests that overlap can both read the same number and both write the same result, so one view is lost. With an F expression the update becomes a single SQL statement, views equals views plus one, and the database applies each one in turn, so nothing is lost. I use update() on a filtered QuerySet for this, which also skips loading the object. One catch: if I set an F expression on an instance and call save, the attribute holds the expression until I call refresh_from_db. Q objects are for conditions that keyword arguments can't express. Keyword arguments to filter are always joined with AND, so for OR or NOT I wrap the conditions in Q and combine them with the pipe, the ampersand, or the tilde."

"I'd annotate each author with a Count over their books, using the filter argument so only published books are counted, then order by that count descending and slice the first five. That's one SQL query with a GROUP BY, a LIMIT and the count computed by the database, instead of loading every book into Python. The difference between the two methods is what comes back. annotate returns a QuerySet where every object gets an extra attribute, here published, so I can keep filtering and ordering on it. aggregate returns a plain dictionary with totals for the whole QuerySet, for example the total number of books, and ends the chain. One thing I watch for is combining two annotations over different multi-valued relations, because the joins multiply rows and the counts come out inflated."

"By default Django runs in autocommit, so every query commits immediately. When several writes must succeed or fail together, I wrap them in transaction.atomic. If an exception escapes the block, everything inside rolls back. Nested atomic blocks become savepoints. For stock, atomic alone isn't enough, because two requests could both read five items left and both sell the last one. So inside the atomic block I load the product with select_for_update, which locks that row. The second request waits until the first commits, then reads the updated stock. select_for_update has to be inside a transaction, or Django raises an error. Two more rules: I don't catch a database error inside the atomic block and carry on, because the transaction is broken at that point; I catch it outside. And anything that talks to the outside world, like sending an email, goes in transaction.on_commit so it only happens if the data really committed."

"A manager is how a model talks to its table. Post.objects is the default one Django adds. When the same filter appears in many views, like 'published and not in the future', I don't copy it around. I write a custom QuerySet class with methods like published() and by_author(), and attach it with as_manager(). Because they're QuerySet methods, they chain: Post.objects.published().by_author(user). That keeps the rule in one place, so if the definition of published changes, I change one method. The risk is overriding get_queryset on the default manager to hide rows, like soft-deleted ones. The admin and other tools use the default manager, so those rows vanish and nobody can see or restore them. If I want that, I keep objects unfiltered and add a second manager, say active, for the filtered view."

"First I'd measure, because the fix depends on where the time goes. Usually it's a few things together. There are often per-row queries from related fields, which select_related fixes. The code loads full model objects when it needs five columns, so values_list with just those fields cuts memory a lot. Any totals computed in Python can become an annotate in the database. And the QuerySet caches every row, so I'd use iterator() to process them in chunks, and send the file with a StreamingHttpResponse so the first bytes go out right away. That alone often gets it under the timeout this week. But a request that grows with the data will time out again, so I'd also propose the proper fix: a background job that builds the file and sends the user a download link when it's ready. I'd tell the product team which part ships now and which follows."

"Migrations are version control for the database schema. When I change a model, makemigrations compares my models with the state described by the migration files already in the app and writes a new file describing the difference, like adding a field. It doesn't touch the database at all. migrate is what changes the database: it applies each migration that hasn't run yet, following the dependencies between files, and records each one in the django_migrations table. That table is how Django knows what's done. Because of that, migration files are code: I commit them, review them in pull requests, and never edit one that has already run somewhere else. If I want to see the actual SQL before running it, sqlmigrate prints it, and showmigrations lists what's applied."

"I wouldn't do it in one migration. Adding a non-null column means every existing row needs a value, and on a big table that can rewrite or lock it while live traffic waits. And during a deploy, old and new code run side by side, so the schema has to work for both; old code that inserts rows without the new value would start failing. So I split it. First, a migration adds the column as nullable, which is quick, and the code starts writing the value for new rows. Second, I backfill old rows in small batches with a script or a data migration, so no single transaction holds locks for long. Third, once every row has a value, a final migration adds the not-null constraint. I run sqlmigrate on each step to see the real SQL. If I also need an index on PostgreSQL, I'd use AddIndexConcurrently in a non-atomic migration so writes aren't blocked. Renames follow the same idea: add, copy, switch, then drop."

"null is about the database: null=True lets the column store NULL. blank is about validation: blank=True lets forms, the admin and full_clean accept an empty value. They're independent, so I often need both, for example an optional date field needs null=True so the database can hold nothing and blank=True so the form allows it. For CharField and TextField, the Django convention is to leave null off and store an empty string, because otherwise 'no value' can be either NULL or an empty string and every query has to check both. The exception is a text field that's unique but optional: then I do use null=True, because several empty strings would clash with the unique constraint, while several NULLs don't."

"An abstract base class, with abstract set to True in Meta, has no table. I use it to share common fields like created_at and updated_at, and each child gets those columns in its own table. It's the one I reach for most. Multi-table inheritance is when the parent is a normal model: both get tables, the child's table has a one-to-one link to the parent, and loading a child means a join. Querying the parent returns parent objects, not the specific child types. It's useful when I genuinely need to query all the kinds together, but the joins can get costly, so I use it sparingly. A proxy model shares the parent's table exactly and can't add fields. I use it to give the same data different behaviour, for example a separate admin page for a subset of users, with its own manager and ordering."

"A function view is just a function that takes a request and returns a response. Everything is visible top to bottom, so I use it when the logic is unusual or when it handles a form in a way the generic views don't fit. Class-based views shine for standard patterns. ListView, DetailView, CreateView and the rest already handle pagination, templates and form processing, and I only override the parts that differ. For 'my orders', I'd subclass ListView, add LoginRequiredMixin so anonymous users are sent to the login page, and override get_queryset to filter by request.user. The mixin has to come first in the class list so it runs before the view. The trade-off with class views is that the behaviour is spread across parent classes, so a newcomer has to know which method to override."

"When I call form.is_valid(), Django cleans each field in turn. First the field's own checks, like whether an EmailField holds a real email, then any method named clean_ plus the field name. That's where a single-field rule goes, like checking the email isn't already registered, and the method must return the cleaned value. After all the fields, Django calls the form's clean() method, which is where I compare fields, like password and confirm. There I use add_error so the message shows next to the right field rather than at the top. Valid values end up in cleaned_data and errors in form.errors. A ModelForm also runs the model's validation, including unique checks. One thing people miss: calling save() on a model directly doesn't run full_clean, so the validation only happens if something calls it."

"The user model sits under almost everything: foreign keys from orders, comments, permissions, the admin, and many migrations point at it. If I start with the built-in User and later need, say, email as the login, swapping AUTH_USER_MODEL means rewriting those relations and migrations by hand. So on a new project I create a custom user straight away, usually subclassing AbstractUser, even if it has no extra fields yet. If I need email login, I'd use AbstractBaseUser with PermissionsMixin, set USERNAME_FIELD, and write a manager with create_user and create_superuser. Everywhere else I refer to settings.AUTH_USER_MODEL in models and get_user_model() in code, never the User class directly. If the project already has live users, I'd usually add a profile model with a one-to-one link for the extra data. A full swap is possible but it's a planned, tested, manual migration, not a quick change."

"When I run migrate, Django creates four permissions for every model: add, change, delete and view. I can add my own in the model's Meta, like publish_article. I don't usually give permissions to people one by one. I create a group such as Editors, give the group the permissions, and add users to it, so a role change is one click in the admin. In code I check with user.has_perm using the app label and codename, or protect a view with PermissionRequiredMixin, and templates get a perms variable for hiding buttons. Superusers pass every check. The catch is that these permissions are per model, not per row. The default backend can say whether someone may change articles, not whether they may change this article. So publishing is a custom permission for the Editors group, and for authors editing their own drafts I filter the query by author and status, so another person's draft simply returns 404."

"CSRF is when a malicious page makes your browser send a POST to a site you're logged into. The browser attaches your session cookie, so without protection the request looks like you. Django's CSRF middleware blocks that. It sets a secret in a cookie, and every form includes a matching token through the csrf_token template tag, or JavaScript sends it in an X-CSRFToken header. On POST, PUT, PATCH and DELETE, the middleware checks the token matches the secret. Another site can make the browser send the cookie, but it can't read the token, so it can't forge the request. Django also checks the Origin header when the browser sends one, and on HTTPS it checks the Referer. I only exempt a view when it isn't used by a logged-in browser at all, like a payment webhook, and then it must verify the sender another way, such as checking a signature. And GET views must never change data, because CSRF protection doesn't cover them."

"For XSS, Django templates escape every variable by default, so a name containing a script tag is shown as text rather than run. The protection goes away when someone marks content safe: the safe filter, mark_safe in Python, or turning autoescape off. I only do that for HTML I built myself, and I use format_html to build it so the inserted values still get escaped. Escaping for HTML also isn't enough inside a script block, so to pass data to JavaScript I use the json_script filter. For SQL injection, the ORM always sends values as query parameters, never pasted into the SQL text. The danger is raw SQL: calling raw() or cursor.execute with an f-string that includes user input. The fix is to pass the values as a separate params list, which the database driver handles safely. In code review, any f-string near SQL gets a second look from me."

"First, DEBUG must be off. With it on, any error page shows a full traceback with settings and local variables to anyone. Second, SECRET_KEY comes from an environment variable or secret store, never the repository, since it signs sessions and tokens. Third, ALLOWED_HOSTS lists the real domains, so requests with a forged Host header are rejected. Then HTTPS: SECURE_SSL_REDIRECT, and SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE so cookies never travel over plain HTTP. I'd add HSTS with a short duration first and raise it once I'm sure HTTPS works everywhere, because browsers remember it. Then I run manage.py check --deploy, which flags most of these. Finally, I make sure errors reach us through logging or an error tracker now that the debug page is gone, and I protect the admin with strong passwords and ideally two-factor sign-in."

"A serializer works in both directions. Going out, it turns model instances or QuerySets into plain Python dictionaries, which DRF renders as JSON. Coming in, it takes the request data, validates it, and gives me validated_data. Calling save() then calls create() or update() depending on whether I passed an instance. A ModelSerializer saves typing by building the fields from the model, including its validators, and I list the fields explicitly rather than using all, so I don't leak a new column by accident. For a single field I add a method named validate_ plus the field name, and for rules across fields I override validate(). Read-only data, like the id or an author name pulled through a relation with source, I mark read_only so clients can see it but not set it."

"A ModelViewSet gives me list, create, retrieve, update, partial update and delete in one class, and a router turns it into URLs. The important part is how access is enforced. First, I override get_queryset to return only the current user's notes, so another user's note isn't in the list and a request for it by id returns 404. Second, I add a custom permission with has_object_permission checking the owner. That's a second line of defence if someone later widens the queryset. But it's important to know that object permissions are only checked when the view calls get_object, which list views don't do, so the queryset filter is what actually protects the list. Finally, I set the owner in perform_create from request.user, so a client can't create notes on someone else's behalf. Because there's no queryset attribute on the class, the router needs a basename."

"Django has four levels. The site-wide cache middleware caches whole pages, cache_page does the same for one view, the cache template tag caches a fragment, and the low-level API lets me cache any value with get and set. For a dashboard, whole-page caching is dangerous because the page is personal, so I'd use the low-level API on the expensive part, the computed stats, with the team id in the key. I'd set a timeout so it can't be stale forever, and delete the key when the underlying data changes, from the service function that writes it. In production the backend has to be shared, like Redis or Memcached, because the default local memory cache lives inside each worker process, so workers would disagree and invalidation wouldn't reach them all. I'd also think about a burst of requests all missing at once after expiry, and measure the hit rate to confirm it helps."

"Static files are part of the code: stylesheets, scripts, logos. Each app can have a static folder, and running collectstatic copies everything into STATIC_ROOT, one place a web server or CDN can serve from. With a hashed file storage, filenames include a content hash so browsers can cache them for a long time. Media files are what users upload, like profile pictures, stored through FileField or ImageField into MEDIA_ROOT or, more often in production, an object storage bucket through a storage backend. The development server serves static files for convenience when DEBUG is on, which hides the real setup. In production Django shouldn't be serving either type itself; Nginx, a CDN, a library like WhiteNoise for static, or the storage service does it. For media I also treat every upload as untrusted: check type and size, and never trust the uploaded filename."

"In production I never use runserver. The app runs under an application server, usually Gunicorn with a few worker processes through WSGI, or an ASGI server like Uvicorn if we use async views or websockets. In front sits Nginx or a cloud load balancer that terminates HTTPS and serves static files, and if it terminates TLS I set SECURE_PROXY_SSL_HEADER so Django knows the request was secure. The release pipeline builds the image once, runs collectstatic, then runs migrate as a single step before the new workers take traffic, not on every worker start, where they'd race each other. Settings come from environment variables, so the same code runs in staging and production with different databases, keys and hosts, and secrets never live in the repository. I add a health check URL, send errors to a tracker, and write logs to standard output so the platform collects them."

"At my last company the order history page in our customer portal took several seconds for our bigger customers. Before changing anything, I opened it locally with the debug toolbar against a copy of realistic data, and saw over four hundred queries. The template was showing each order's customer and its line items, and each of those was a separate query per order, the classic N+1. I added select_related for the customer and prefetch_related for the line items, which brought it down to three queries. The page was still a bit slow, and EXPLAIN showed the main query sorting a big table without an index, so I added a composite index on customer and created date. The page went from seconds to well under half a second. To stop it coming back, I added a test using assertNumQueries on that view, so a new template field that sneaks in a query fails the build."

"In my last role I added an index to support a new search filter. It was a normal AddIndex migration on our events table, which had tens of millions of rows. It passed review and ran fine on staging, which had much less data. In production, building the index blocked writes to that table for several minutes during the deploy, and some requests timed out. Cancelling would only have rolled it back and left the release half done, so we let it finish, posted an update to the team, and watched the error rate fall back. Afterwards I rewrote our approach: on PostgreSQL we use AddIndexConcurrently in a non-atomic migration for big tables, and I added a pull request checklist item to paste the sqlmigrate output for any migration touching a large table. We also started refreshing staging with production-sized, anonymised data so a slow migration shows up before release."

"At my last company we were two major versions behind, and security fixes for our version were about to stop. I started by running the test suite with deprecation warnings turned on, because most breaking changes are announced as warnings in earlier versions. We fixed those while still on the old version, which made the actual upgrade much smaller. Then I listed our third-party packages and checked each one's supported Django versions; two needed upgrades and one was abandoned, so we replaced it. Rather than jumping straight to the latest, we moved one version at a time, each on its own branch, running the tests and reading the release notes for anything our tests didn't cover, like changed defaults. We deployed each step to staging and did a manual pass on login, payments and the admin. The final production release was uneventful, which was the goal."