Django and FastAPI Interview Questions and Answers

Django uses Model, View, Template (MVT).

• Model: Python classes that define data and map to database tables through the ORM.
• View: a function or class that receives an HTTP request, talks to models, and returns a response. This is the logic, similar to a controller in MVC.
• Template: the HTML presentation layer with Django template language.

The "controller" role in MVC is played by the framework itself: the URL dispatcher (urls.py) routes a request to the right view.

# urls.py
path("posts/", views.post_list)

# views.py
def post_list(request):
    posts = Post.objects.order_by("-created")[:10]
    return render(request, "posts.html", {"posts": posts})

So MVT is MVC with different names: Django's view is MVC's controller and Django's template is MVC's view. In a REST API setup, templates are replaced by serializers returning JSON.

What they are checking: Whether you can map Django's terms to MVC without confusion

The ORM (Object Relational Mapper) lets you use database rows as Python objects. It writes the SQL for you. Each model class maps to a table and each field to a column.

class Book(models.Model):
    title = models.CharField(max_length=200)
    price = models.DecimalField(max_digits=8, decimal_places=2)
    author = models.ForeignKey("Author", on_delete=models.CASCADE)

b = Book.objects.create(title="Dune", price=9.99, author=a)    # create
Book.objects.filter(price__lt=10).order_by("title")            # read
Book.objects.filter(id=b.id).update(price=12)                  # update
b.delete()                                                     # delete

Benefits: it works with many databases, it escapes values to stop SQL injection, and it has migrations. Limits: complex report queries may need .raw() or raw SQL. Careless use makes slow queries (see N+1).

What they are checking: Comfort with the ORM and awareness of its limits

Both avoid extra queries when you access related objects, but they work differently.

# one query with JOIN
books = Book.objects.select_related("author")

# two queries: books, then authors' tags
authors = Author.objects.prefetch_related("books")

# fine-tune the prefetch
from django.db.models import Prefetch
Author.objects.prefetch_related(
    Prefetch("books", queryset=Book.objects.filter(published=True))
)

Use select_related for "one" side joins and prefetch_related for "many" side. Check with django-debug-toolbar or len(connection.queries).

What they are checking: The join versus second-query distinction

Migrations are Python files, kept in version control, that describe changes to your database schema (create model, add field, change field). Django creates them from your model changes.

python manage.py makemigrations     # detect model changes, write migration files
python manage.py migrate            # apply unapplied migrations
python manage.py showmigrations     # list applied state
python manage.py sqlmigrate app 0003  # preview SQL

• Applied migrations are recorded in the django_migrations table.
• Each migration lists its dependencies, so they form a graph.
• Migrations can also change data with RunPython and run raw SQL with RunSQL.
• Commit migration files to git. Never edit an applied one; create a new migration.
• If two branches create the same migration number, fix it with makemigrations --merge.

What they are checking: Practical workflow and not editing applied migrations

Choose Django when you want a complete, convention-driven stack and an admin panel quickly. Choose Flask for small, flexible apps where you pick every library. Choose FastAPI for API-only services where automatic docs, type-driven validation and async I/O matter. They can coexist: a Django monolith plus FastAPI microservices is common.

What they are checking: Reasons for each choice, not just a favourite

A serializer turns complex objects (model instances, querysets) into plain Python types for JSON output. It also checks incoming data and turns it back into objects.

• Serializer: you declare every field and implement create/update yourself.
• ModelSerializer: makes the fields and default create and update from a model.

class BookSerializer(serializers.ModelSerializer):
    author_name = serializers.CharField(source="author.name", read_only=True)

    class Meta:
        model = Book
        fields = ["id", "title", "price", "author", "author_name"]

    def validate_price(self, value):
        if value <= 0:
            raise serializers.ValidationError("must be positive")
        return value

Use validate_<field> for single-field rules and validate() for cross-field rules. Call serializer.is_valid(raise_exception=True) then serializer.save(). Avoid fields = "__all__" in public APIs, because new model fields would be shown automatically.

What they are checking: Validation hooks and controlling what is shown

Pydantic is a data validation library that uses Python type hints. You define a model. It reads and checks the input, changes types where it makes sense, and gives clear errors. FastAPI uses Pydantic models for request bodies and responses, and to build the OpenAPI schema.

from fastapi import FastAPI
from pydantic import BaseModel, Field, EmailStr

class UserIn(BaseModel):
    name: str = Field(min_length=2)
    age: int = Field(ge=0, le=120)
    email: EmailStr          # requires email-validator package

class UserOut(BaseModel):
    id: int
    name: str

app = FastAPI()

@app.post("/users", response_model=UserOut, status_code=201)
def create(user: UserIn):
    return {"id": 1, "name": user.name}

Invalid input returns an automatic 422 with details. response_model removes fields like passwords. Pydantic v2 (written in Rust) is much faster than v1 and uses model_validate, model_dump, and field_validator.

What they are checking: Validation and response filtering in FastAPI

Yes. Building or chaining a QuerySet does not run SQL. The query runs only when the results are needed.

• ForeignKey: many-to-one. Many books belong to one author.
• OneToOneField: one-to-one, e.g. a Profile extending a user.
• ManyToManyField: many-to-many, e.g. students and courses. Django creates a hidden join table, or you define a through model to store extra fields.

FastAPI decides by where the parameter appears and by its type.

• In the path string: path parameter.
• Simple types not in the path: query parameter.
• A Pydantic model: JSON request body.

1. The web server (through WSGI or ASGI) gives the request to Django, which builds an HttpRequest.
2. Request middleware runs in the order listed in MIDDLEWARE (security, sessions, CSRF, authentication).
3. The URL resolver matches the path against urlpatterns and picks a view.
4. The view runs. It may query the...

Middleware is a chain of hooks. They process every request before the view and every response after it. Built-ins handle security headers, sessions, CSRF protection and authentication.

Authentication finds out who the caller is. Authorization decides what they may do. In DRF they are separate parts.

• authentication_classes set request.user and request.auth. Failure gives 401.
• permission_classes check access. Failure gives 403.

CSRF (Cross-Site Request Forgery) tricks a logged-in user's browser into sending a request the user did not want. Django stops this with a secret token that a bad site cannot read.

get() returns exactly one object, and raises an error if there are none or many. filter() returns a QuerySet (it may be empty) and never raises an error for no results.

Keep configuration out of the code and read it from environment variables. Use one settings module per environment, or one module that reads env vars.

FastAPI builds an OpenAPI schema from your routes, type hints and Pydantic models. It serves interactive docs with no extra work.

• Swagger UI at /docs, where you can try requests.
• ReDoc at /redoc.
• Raw schema at /openapi.json.

Django protects against several common attacks by default:

Static files are assets that come with the code (CSS, JS, images). Media files are uploads from users.

The Django admin is a back-office website that Django makes for you. It manages model data and comes from django.contrib.admin. You register models and change the screen with a ModelAdmin.

N+1 happens when you run one query to get N objects. Then you run one more query for each object to get a related row. That gives N+1 queries.

# 1 query for books + 1 query per book for author
for book in Book.objects.all():
    print(book.author.name)

Fixes:

• select_related("author") for ForeignKey or OneToOne (JOIN).
• prefetch_related("tags") for many-valued relations.
• .only() / .values() to fetch only the columns you need.
• Count in SQL (annotate(n=Count("comments"))) instead of counting in a loop.

Find it with django-debug-toolbar, assertNumQueries in tests, or the django.db.backends logger. In DRF, the serializer is the usual cause: put the select_related/prefetch_related in the viewset's get_queryset.

What they are checking: Recognising the pattern and tools to detect it

Django's own auth uses sessions. Login stores a session id in a cookie, and the server looks up the user on each request. DRF adds authentication classes you can swap in, and they set request.user.

JWT practice: use a short-lived access token (a few minutes) and a refresh token to renew it. Sign with a strong secret or key pair. Always use HTTPS. If XSS is a worry, keep tokens out of localStorage (HttpOnly cookies are safer). Authentication says who you are. Permissions decide what you may do.

What they are checking: Pros and cons of stateful and stateless auth

FastAPI's Depends lets you write reusable pieces (database session, current user, settings, pagination) as functions. FastAPI calls them and passes the results into your endpoint.

FastAPI supports both. async def endpoints run directly on the event loop. Plain def endpoints run in a pool of worker threads, so they do not block it.

Run the app server behind a reverse proxy (Nginx or a cloud load balancer). Manage it with systemd or containers.

• Django (WSGI): gunicorn project.wsgi:application --workers 4 --bind 0.0.0.0:8000.
• Django or FastAPI (ASGI): gunicorn as process manager with uvicorn workers:

Signals tell one part of the app when something happens in another part (the observer pattern). Common ones: pre_save, post_save, post_delete, m2m_changed, request_finished.

Each one does more for you than the last.

FastAPI's BackgroundTasks runs a function after the response is sent, in the same process.

By default, Django uses autocommit mode, so each query is its own transaction. transaction.atomic groups operations so they all save or all roll back.

Celery is a task queue that runs on many machines. The web process puts a message on a broker (Redis or RabbitMQ). Separate worker processes run it. So long or unreliable work runs outside the request.

Django has a cache framework with several backends: local memory, file, database, Memcached and Redis (the usual choice in production).

All three can be set in settings or per view.

Create the engine and session factory once. Give each request its own session through a dependency that closes it afterwards.

Both are rules for how a Python web server talks to a web application.

Use pytest with the framework's test client, a test database and fixtures.

Django:

Django's default User is hard to change later. Other tables point to it with foreign keys, and migrations depend on it. Setting AUTH_USER_MODEL before the first migration lets you add fields (phone, role) or log in with email.

A custom through model is a join table you define yourself for a ManyToManyField. It lets you store extra data about the link, such as when a student joined a course.

Measure first. Then remove the repeated queries.

1. Count queries with django-debug-toolbar or django-silk locally, or enable the django.db.backends logger. Tests can pin the number with self.assertNumQueries(3).
2. If the query count grows with the number of rows, it is N+1. Find the field that the serializer or template reads, which causes one query per object.
3. Fix in get_queryset: select_related for FKs, prefetch_related (with Prefetch objects for filtered relations) for reverse and M2M, and annotations for counts and sums.
4. Send less data: only()/defer(), paginate (PageNumberPagination or cursor pagination), avoid big nested objects.
5. Look at slow SQL with EXPLAIN ANALYZE and add indexes (db_index=True, Meta.indexes) on filtered and ordered columns.
6. If it is still slow, cache the result in Redis and measure again.

Goal: a small, fixed number of queries, no matter how many rows. Add a test to keep it that way.

What they are checking: Methodical diagnosis with ORM-level tooling

A slowdown that only appears with many users usually means requests are fighting for a limited resource.

Scale in steps. Start with the cheapest wins.

This is a race condition: the code reads first and writes later. Make the check and the update happen as one step in the database.

Option 1: lock the row.

Start with facts, not guesses.

Decide by needs, team and tools, not by hype.

Pick Django + DRF when:

• You need an admin panel, auth, ORM and migrations ready to use.
• The product is one big app built around a database, or has pages made on the server.
• The team knows Django, and you want proven conventions and many ready packages.

Keep only the essential work in the request. Move the slow parts out of it.

Avoid long locks. Make sure old code and new code both work during the rollout (add first, remove later).

Use many layers of defence.