Django interview questions

What a strong answer covers

• Define Model (data layer, ORM), View (business logic, request processing), and Template (presentation layer).
• Explain that Django's 'View' acts more like a 'Controller' in MVC, handling logic and selecting templates.
• Clarify that Django's 'Template' is the 'View' in MVC, responsible for rendering output.
• Highlight the benefits: clear separation of concerns, reusability, and maintainability.

Where people lose the point

• ×Confusing Django's 'View' with the 'View' in MVC, leading to an incorrect mapping.
• ×Failing to explain the role of the ORM within the Model component.
• ×Not mentioning the request-response cycle in the context of MVT.

What a strong answer covers

• Explain that models are Python classes inheriting from `django.db.models.Model`.
• Demonstrate defining fields using `models.CharField`, `models.IntegerField`, etc.
• Show how to define a `ForeignKey` relationship to another model.
• Mention the importance of `__str__` method for human-readable representation.

Where people lose the point

• ×Forgetting to import `models` from `django.db`.
• ×Incorrectly defining field types or relationship arguments (e.g., `on_delete`).
• ×Not explaining the purpose of `__str__` or omitting it entirely.

What a strong answer covers

• Explain the role of the project-level `urls.py` as the main dispatcher.
• Describe how `include()` is used to delegate URL patterns to app-specific `urls.py` files.
• Detail the use of `path()` or `re_path()` to define URL patterns and map them to views.
• Mention how path converters (e.g., `<int:pk>`) capture parts of the URL as arguments for the view.

Where people lose the point

• ×Confusing the order of URL pattern matching (first match wins).
• ×Not explaining the purpose of `include()` for modularity.
• ×Failing to mention how arguments are passed from the URL to the view.

What a strong answer covers

• Explain `{{ variable }}` for displaying data from the context.
• Describe `{% tag %}` for control flow (e.g., `for` loops, `if` statements, `extends`, `block`).
• Provide examples of `for` loop iteration and `if`/`else` conditions.
• Mention template filters (e.g., `|date`, `|length`) for modifying variable output.

Where people lose the point

• ×Confusing the syntax for variables and tags.
• ×Not providing concrete examples for both variable display and control flow.
• ×Overlooking the concept of template filters.

What a strong answer covers

• Explain `STATIC_URL`, `STATICFILES_DIRS`, and `STATIC_ROOT` settings in `settings.py`.
• Describe using `{% load static %}` and `{% static 'path/to/file.css' %}` in templates.
• For development, mention `django.contrib.staticfiles` and `DEBUG=True` automatically serving files.
• For production, explain the need to run `python manage.py collectstatic` and configure a web server (e.g., Nginx, Apache) to serve `STATIC_ROOT`.

Where people lose the point

• ×Confusing `STATIC_URL` with `STATIC_ROOT`.
• ×Not differentiating between development and production serving mechanisms.
• ×Forgetting to mention `collectstatic` for production deployments.

What a strong answer covers

• Define a simple Django model (e.g., `Book` with `title`, `author`).
• Show how to create a new object using `Book.objects.create()` or `save()` on a new instance.
• Demonstrate reading objects using `all()`, `filter()`, `get()`, and `exclude()`.
• Explain how to update an object by modifying its attributes and calling `save()`.
• Illustrate deleting an object using the `delete()` method on an instance or queryset.

Where people lose the point

• ×Forgetting to call `.save()` after modifying an existing object.
• ×Confusing `get()` (returns single object, raises error if not found/multiple) with `filter()` (returns queryset).
• ×Not explaining the difference between deleting a single instance vs. a queryset.

What a strong answer covers

• Define FBVs as Python functions that take `HttpRequest` and return `HttpResponse`.
• Define CBVs as Python classes that inherit from `View` or generic views, with methods like `get()`, `post()`.
• Discuss advantages of FBVs: simpler for basic logic, easier to read for beginners, explicit flow.
• Discuss advantages of CBVs: reusability (mixins), inheritance, better organization for complex logic, built-in generic views.
• Provide scenarios for choosing each: FBV for simple, unique logic; CBV for common patterns (CRUD), complex logic, or when using mixins.

Where people lose the point

• ×Failing to mention the `HttpRequest` and `HttpResponse` objects for FBVs.
• ×Not explaining how CBVs handle different HTTP methods (e.g., `get`, `post`).
• ×Giving a blanket recommendation for one over the other without context.

What a strong answer covers

• Explain that `forms.Form` is for general data input and validation not directly tied to a database model (e.g., contact form, search form).
• Explain that `forms.ModelForm` is specifically designed to interact with a Django model, automatically generating fields and handling saving/updating model instances.
• Highlight the benefits of `ModelForm`: automatic field generation, automatic validation based on model fields, and easy saving to the database.
• Provide clear use cases for each: `Form` for non-database interactions, `ModelForm` for CRUD operations on models.

Where people lose the point

• ×Incorrectly stating that `forms.Form` cannot save data (it can, but manually).
• ×Not emphasizing the automatic nature of `ModelForm` for field generation and saving.
• ×Failing to mention the `Meta` class in `ModelForm` for specifying the model and fields.

What a strong answer covers

• Define migrations as Django's way of propagating changes made to models into the database schema.
• Describe the `makemigrations` command: it detects changes in models and creates migration files (Python scripts).
• Describe the `migrate` command: it applies the pending migrations to the database, updating the schema.
• Explain the benefits: version control for database schema, collaborative development, database independence.

Where people lose the point

• ×Confusing `makemigrations` with `migrate`.
• ×Not explaining that migration files are Python code, not raw SQL.
• ×Failing to mention the `django_migrations` table that tracks applied migrations.

What a strong answer covers

• Define middleware as a framework of hooks into Django's request/response processing.
• Explain that middleware components process requests before they hit the view and responses before they leave the server.
• Describe common use cases: authentication, session management, CSRF protection, security headers, logging, GZip compression.
• Illustrate how middleware is configured in `settings.py` (`MIDDLEWARE` list) and its order of execution.

Where people lose the point

• ×Confusing middleware with context processors or template tags.
• ×Not explaining the 'chain' nature of middleware execution.
• ×Failing to provide concrete examples of built-in or custom middleware uses.

What a strong answer covers

• Explain that custom managers allow you to add custom database query methods to your models.
• Demonstrate creating a class that inherits from `django.db.models.Manager`.
• Show how to add custom methods (e.g., `get_published_posts()`, `active_users()`) to this manager.
• Illustrate attaching the custom manager to a model using `objects = MyCustomManager()`.

Where people lose the point

• ×Forgetting to inherit from `models.Manager`.
• ×Not explaining *why* custom managers are useful (e.g., reusability, cleaner queries).
• ×Incorrectly overriding `get_queryset()` instead of adding new methods when not intended.

What a strong answer covers

• Explain the role of `django.contrib.auth` for user management, authentication, and permissions.
• Describe the login process: user submits credentials to a login view, `authenticate()` verifies them.
• Detail the session management: `login()` stores user ID in session, `request.user` becomes available.
• Explain how `login_required` decorator or `LoginRequiredMixin` protects views.
• Mention the logout process using `logout()` to clear the session.

Where people lose the point

• ×Confusing `authenticate()` (verifies credentials) with `login()` (establishes session).
• ×Not mentioning the `User` model and its default fields.
• ×Failing to explain how `request.user` is populated after successful login.

What a strong answer covers

• Define signals as a way for decoupled applications to get notifications when actions occur elsewhere in Django.
• Explain the two main components: `senders` (who sends the signal) and `receivers` (who listens and acts).
• Describe common built-in signals (e.g., `post_save`, `pre_delete`, `request_finished`).
• Provide a practical use case: automatically creating a user profile when a new user is registered using `post_save` signal from the `User` model.
• Show how to connect a receiver function to a signal using `signal.connect(receiver, sender=...)`.

Where people lose the point

• ×Confusing signals with direct function calls or method overrides.
• ×Not explaining the `sender` argument and its importance for filtering.
• ×Failing to place signal connection code in an appropriate place (e.g., `AppConfig.ready()` method).

What a strong answer covers

• Explain the concept of ACID properties and why transactions are crucial for data integrity.
• Describe `django.db.transaction.atomic()` as the primary way to manage transactions.
• Show how to use `atomic()` as a context manager or a decorator for a block of code.
• Explain that all operations within an `atomic()` block are treated as a single unit: either all succeed (commit) or all fail (rollback).
• Mention `savepoints` for more granular control within nested transactions (though less common).

Where people lose the point

• ×Not explaining the 'all or nothing' principle of transactions.
• ×Forgetting to import `transaction` from `django.db`.
• ×Failing to mention that `atomic()` handles both success (commit) and failure (rollback) automatically.

What a strong answer covers

• State that DRF is a powerful and flexible toolkit for building Web APIs on top of Django.
• Explain its core components: `Serializers` (for converting complex data types like querysets and model instances to native Python datatypes that can then be easily rendered into JSON/XML/etc.), `ViewSets` (for combining logic for a set of related views into a single class), and `Routers` (for automatically generating URL patterns for ViewSets).
• Mention features like authentication, permissions, throttling, and pagination that DRF provides out-of-the-box.
• Highlight how DRF simplifies API development by providing abstractions over Django's core functionalities.

Where people lose the point

• ×Confusing DRF with Django's built-in capabilities (e.g., thinking Django itself handles JSON rendering for models automatically).
• ×Not explaining the role of `Serializers` as the bridge between models and API representations.
• ×Failing to mention the browsable API feature as a key DRF benefit.

What a strong answer covers

• Explain protection against CSRF (Cross-Site Request Forgery) using `CsrfViewMiddleware` and `{% csrf_token %}`.
• Describe protection against XSS (Cross-Site Scripting) through automatic HTML escaping in templates.
• Discuss SQL Injection prevention via the Django ORM, which sanitizes inputs.
• Mention secure password handling: using `django.contrib.auth` for hashing and salting passwords.
• Highlight the importance of keeping `SECRET_KEY` confidential and using `DEBUG=False` in production.

Where people lose the point

• ×Suggesting manual SQL queries, which bypasses ORM's SQL injection protection.
• ×Not emphasizing the critical importance of `SECRET_KEY` and `DEBUG` settings.
• ×Failing to mention other general web security practices like HTTPS, secure headers, and input validation.