FREE!! Open Source - A Technical Recruiter's Daily Wiki
← Back to dashboard Login
Technical Recruiter Reference · Python Full-Stack · 2025–2026

Python Full-Stack
Web Development Guide

A plain-English explainer for every Python language feature, framework, and tool on a full-stack developer's résumé — written for recruiters, not engineers.

22Skills Covered
6Stack Layers
50+Interview Qs
40+Curated Links
🗺️

How a Python Full-Stack App is Built

# the big picture before diving into individual technologies

Why Python for Full-Stack Web Development?

Python is the world's most popular programming language (23.28% TIOBE share in 2025), valued for its readable, human-friendly syntax. While historically a back-end language, Python is now used across the entire web development stack — from the server that handles business logic to the database that stores data to the automation scripts that deploy the application. Python is the primary language of data science, AI/ML, and automation — making Python full-stack developers uniquely valuable when web applications need to incorporate intelligent features. Companies like Instagram, Pinterest, Spotify, Dropbox, and YouTube use Python as a core language.

# Python Full-Stack Architecture — All Layers

LAYER 1 — FRONT-END (the browser / what users see) HTML / CSS JavaScript / TS React / Vue Django Templates HTTP / REST API / JSON LAYER 2 — BACK-END (Python server — business logic & APIs) Django Flask FastAPI REST APIs / Auth ORM queries / SQL LAYER 3 — DATA & STORAGE PostgreSQL SQLite / MySQL MongoDB Redis (cache) background tasks / message queue LAYER 4 — ASYNC WORKERS & TASK QUEUES Celery RQ / Redis Queue WebSockets LAYER 5 — DEVOPS, CI/CD & CLOUD DEPLOYMENT Docker Git/GitHub Pytest AWS / Heroku CI/CD Pipelines

# every Python full-stack app flows through these 5 layers — each tab covers one area

What is a "Python Full-Stack Developer"?
# recruiter primer
🗣️ In plain EnglishA Python full-stack developer can build the entire web application — the visual interface users interact with (front-end), the server logic that processes requests (back-end), and the database that stores data — using Python as the primary language. They are a "one-person assembly line" who understands how all pieces connect, making them especially valuable at startups and smaller teams.

Python full-stack developers use Python frameworks (Django, Flask, FastAPI) for the back-end and either Python-based templating (Django Templates, Jinja2) or JavaScript frameworks (React, Vue) for the front-end. They manage databases with Python ORMs (SQLAlchemy, Django ORM), deploy via Docker and cloud platforms, and increasingly integrate AI/ML features — something Python is uniquely positioned for given its dominant role in data science. Python's #1 language status, readability, and rapid development speed make Python full-stack developers among the most in-demand roles in tech.

🐍

Core Python Skills

# the language features every Python developer must master

Core Python Language Core
# Python 3.10+ · OOP · data types · syntax
🗣️ In plain EnglishPython is a programming language famous for being readable — it's often described as "executable pseudocode" because it reads almost like English. Its clean syntax and large standard library let developers build powerful programs with far fewer lines of code than Java or C++. Python's philosophy: "there should be one — and preferably only one — obvious way to do it."

Python 3 is the current standard (Python 2 is completely deprecated). Core concepts: variables, data types (lists, dicts, tuples, sets), functions, classes (OOP — Object-Oriented Programming), file I/O, error handling (try/except), comprehensions (concise one-liner loops), generators, decorators, and context managers. Python 3.10+ introduced structural pattern matching (like a powerful switch/case). Current: Python 3.12/3.13. A résumé showing Python 2 only signals very outdated experience.

# Python's 4 key advantages over other languages
📖 Readable Clean syntax 🚀 Fast Build Less code, more done 📦 Libraries 500K+ packages (PyPI) 🤖 AI/ML #1 language for data science
pip & Virtual Environments Core
# package management · venv · pipenv · poetry
🗣️ In plain Englishpip is Python's package installer — the "app store" for Python libraries. Virtual environments are isolated project workspaces. Think of them as separate rooms in a house: each project has its own room with exactly the libraries it needs, so projects don't interfere with each other. Without virtual environments, installing one package for Project A could break Project B.

Every Python project uses pip and virtual environments — their absence is a red flag. pip installs packages from PyPI (Python Package Index — 500,000+ packages). Virtual environment tools: venv (built-in, simplest); Pipenv (combines pip + venv, adds Pipfile for reproducible installs); Poetry (modern, dependency resolution, publishing support — growing in popularity). requirements.txt files list all project dependencies for reproducible installations. Conda is used in data science environments.

Async Python (asyncio) Core
# async/await · asyncio · concurrent programming
🗣️ In plain EnglishSynchronous code is like a single waiter serving tables one at a time — while waiting for the kitchen (database), the waiter stands idle. Async Python is like that waiter managing multiple tables simultaneously — while waiting for the kitchen for Table 1, they take Table 2's order and deliver Table 3's food. This makes web applications dramatically more efficient under load without adding more servers.

Python's asyncio library and async/await syntax enable concurrent, non-blocking code — critical for modern web APIs. FastAPI is built entirely on async architecture. Django supports async views since Django 3.1. Key concepts: event loop, coroutines, awaitables, async context managers. Async Python is particularly important for I/O-bound operations (database queries, API calls, file reads) where blocking would waste CPU time. On a résumé, async/asyncio alongside FastAPI signals modern, performance-oriented back-end development.

⚙️

Back-End Frameworks & APIs

# Django · Flask · FastAPI · REST · authentication

Django Framework
# batteries-included web framework · Instagram · Pinterest
🗣️ In plain EnglishDjango is the "everything included" Python web framework — like a fully furnished apartment where everything you need is already there: user authentication, admin panel, database management, security features, URL routing, and templating. Instead of piecing together dozens of individual tools, Django gives developers a complete, opinionated system that follows "batteries included" philosophy. Instagram and Pinterest were built with Django.

Django is the most popular Python web framework for complete applications. Its "convention over configuration" approach means less decision-making for developers. Key features: Django ORM (database interaction in Python, not SQL); Django Admin (auto-generated admin interface — a massive productivity booster); Django Auth (complete user system out of the box); Django REST Framework (DRF) — the go-to extension for building APIs. Django 5+ (current) supports async views. Seeing "DRF" alongside Django on a résumé is very common for API-focused roles.

# Django request lifecycle — from browser to response
Browser Request URL Router urls.py View Logic views.py Model / DB models.py HTML back
Flask Framework
# micro-framework · lightweight · flexible · extensible
🗣️ In plain EnglishFlask is the "minimalist" Python web framework — it gives you the essentials (routing, request handling, templates) without forcing any specific structure. Like a studio apartment: bare but functional, and you furnish it exactly as you want. Flask is perfect for small-to-medium APIs, microservices, and projects where the team wants full control over every architectural decision.

Flask is often described as a "microframework" — it starts minimal and grows as you add extensions (Flask-SQLAlchemy for databases, Flask-Login for auth, Flask-Mail for email, etc.). This flexibility is both a strength (you only include what you need) and a weakness (you make all the decisions). Flask is widely used for RESTful APIs, microservices, rapid prototyping, and data science/ML model serving (wrapping a machine learning model in a Flask API). Flask and Django are complementary, not competing — Django for large full apps, Flask for small focused services.

FastAPI Framework
# modern async API framework · auto-docs · type hints
🗣️ In plain EnglishFastAPI is the fastest-growing Python API framework — it's built for high performance and modern development practices. It automatically generates interactive API documentation (Swagger UI) from your code, validates data types automatically, and is natively async. Think of it as Flask but turbo-charged for building APIs specifically — with built-in safety nets that catch data errors before they reach your database.

FastAPI is based on Python type hints (introduced in Python 3.5+). When you define a function with typed parameters, FastAPI automatically: validates incoming data, converts types, and generates documentation. This dramatically reduces bugs. FastAPI is among the fastest Python web frameworks (comparable to Node.js and Go). Key features: Pydantic models for data validation, automatic OpenAPI/Swagger docs, async support natively, OAuth2/JWT authentication built-in. Growing rapidly — seeing FastAPI on a résumé signals the candidate uses cutting-edge Python tooling.

# FastAPI: one function, three auto-features
@app.get("/users") def get_user(id: int, name: str): ✓ Validates data types 📄 Auto Docs Swagger UI ⚡ Async native support
REST APIs & Authentication Core
# HTTP · JSON · JWT · OAuth2 · DRF · Pydantic
🗣️ In plain EnglishA REST API is the "waiter" between your front-end and back-end — a structured set of rules for how the front-end requests data and how the back-end responds. Authentication answers "who are you?" before serving any data. JWT (JSON Web Token) is a digital ID badge: log in once, receive a token, send that token with every request thereafter — no need to log in again.

Every Python full-stack developer must know REST API design: HTTP verbs (GET/POST/PUT/PATCH/DELETE), status codes (200 OK, 404 Not Found, 401 Unauthorized), JSON serialization, and URL structure. Authentication: Session-based auth (Django's built-in — stores session server-side); JWT (JSON Web Tokens — stateless, used in modern SPAs); OAuth2 (third-party login — "Login with Google"). Libraries: Pydantic (data validation, used heavily with FastAPI), marshmallow (serialization for Flask), DRF Serializers (Django REST Framework's validation layer). Swagger/OpenAPI documentation is increasingly expected.

Celery & Task Queues Framework
# background jobs · scheduled tasks · Celery + Redis
🗣️ In plain EnglishSome tasks take too long to complete while a user waits — sending thousands of emails, processing large images, generating reports, or making slow API calls. Celery moves these tasks to the background. The user gets an immediate response ("your report is being generated"), and Celery runs the slow task behind the scenes without blocking the web server. It's the backstage crew while the main performance continues uninterrupted.

Celery is the most popular Python library for background task processing. It requires a message broker — Redis (most common, also serves as a cache) or RabbitMQ. Common use cases: sending emails asynchronously, processing uploads, scheduling periodic tasks (cron-style), data export generation. Celery Beat adds scheduled task support. Django + Celery + Redis is an extremely common production stack. Seeing this combination on a résumé signals experience with high-traffic, production-ready systems.

Gunicorn · WSGI / ASGI Servers Framework
# Gunicorn · Uvicorn · Nginx · production serving
🗣️ In plain EnglishDjango and Flask on their own are development servers — not production-ready. Gunicorn is the professional "head waiter" that manages multiple instances of your Python app to handle many simultaneous users. Nginx acts as the front-door receptionist — it receives all web traffic and passes it to Gunicorn. Together they form the production stack that handles thousands of concurrent users efficiently.

WSGI (Web Server Gateway Interface) is the Python standard for synchronous web apps — used with Django/Flask. ASGI (Asynchronous Server Gateway Interface) is the modern standard for async apps — used with FastAPI and async Django. Servers: Gunicorn (most common WSGI server, works with Django/Flask); Uvicorn (ASGI server for FastAPI, async applications); Daphne (ASGI, used with Django Channels). Nginx sits in front as a reverse proxy. This stack (Nginx → Gunicorn/Uvicorn → Django/Flask/FastAPI) is the standard Python production deployment pattern.

🖥️

Front-End Technologies

# what Python full-stack developers use to build the user interface

Jinja2 / Django Templates Front-End
# server-side templating · Jinja2 · DTL
🗣️ In plain EnglishTemplates are HTML files with special placeholders that Python fills in with real data before sending to the browser. Like a form letter: "Dear {name}, your order #{order_id} has shipped." The server fills in the blanks, and the browser receives complete, ready-to-display HTML. This is the "traditional" Python web approach — the server does all the work before the page reaches the user.

Jinja2 is the most widely used Python templating engine — used by Flask, FastAPI, and many other frameworks. Django Template Language (DTL) is Django's built-in template system, slightly less powerful than Jinja2 but tightly integrated with Django's security model. Both support loops, conditionals, template inheritance (base templates), and filters (formatting functions). Server-side rendering (SSR) with templates is simpler to deploy than SPAs but less dynamic. Jinja2 is also used for non-HTML templating (email templates, config file generation, etc.).

React / Vue.js + Python API Front-End
# modern SPA front-end with Python back-end API
🗣️ In plain EnglishModern Python full-stack apps often separate the front-end and back-end completely. React or Vue runs entirely in the browser and communicates with the Python back-end through API calls. This is like a restaurant where the kitchen (Python API) and the dining room (React/Vue) are completely separate but connected through a clearly defined menu (the API). This "decoupled" approach allows separate front-end and back-end teams to work independently.

React (Meta) is the most popular pairing with Python back-ends. Vue.js is lighter and increasingly popular in Python/Django shops. The Python back-end (Django REST Framework, FastAPI) exposes a JSON API; the front-end JavaScript framework consumes it. Key concepts for Python developers: CORS (configuring Python server to accept requests from the React app), JWT auth tokens (React stores the token, sends it with every request), and state management (Redux/Zustand for React, Pinia for Vue). Next.js (React-based) with a Python API is a powerful enterprise combo.

# decoupled architecture — Python API + React front-end
React / Vue runs in browser port 3000 → JSON → ← JSON ← REST API Django / FastAPI Python back-end port 8000
HTMX Front-End
# modern interactivity without JavaScript frameworks
🗣️ In plain EnglishHTMX is a library that adds modern interactive behavior (updating parts of a page without full reload) to traditional HTML templates — without requiring React or Vue.js. With HTMX, a Django developer can build a search bar that updates results as you type, or a form that submits without reloading, all while keeping Python as the only backend language. It bridges the gap between old-school server-rendered apps and modern SPAs.

HTMX has become very popular in the Django community for adding interactivity to server-rendered apps without the complexity of a JavaScript framework. Instead of React making API calls and re-rendering, HTMX asks the server for HTML fragments and swaps them into the page. The Django + HTMX combination is growing rapidly as a simpler alternative to the Django + React decoupled approach for applications that don't need full SPA complexity. Alpine.js is often paired with HTMX for small JavaScript behaviors.

CSS · Bootstrap · Tailwind CSS Front-End
# styling · UI frameworks · responsive design
🗣️ In plain EnglishCSS is the "paint and interior design" of web pages. Bootstrap and Tailwind are pre-built CSS toolkits that make styling faster — instead of designing every button from scratch, developers use pre-built components. Bootstrap gives you finished components (a dropdown menu, a card layout); Tailwind gives you precise utility classes to assemble your own design. Both are far faster than writing custom CSS from zero.

CSS knowledge is expected from Python full-stack developers. Bootstrap (older, component-based — easier for beginners, less design flexibility) vs. Tailwind CSS (utility-first — more work upfront but more flexible, increasingly preferred by modern Django/React developers). Responsive design (mobile-friendly layouts) is mandatory. Additional tools: SASS/SCSS (extended CSS with variables and nesting), Django-Tailwind (integrates Tailwind into Django projects). Knowing a CSS framework is expected; knowing both signals a well-rounded developer.

🗄️

Data & Database Technologies

# PostgreSQL · SQLite · MongoDB · Redis · SQLAlchemy · Django ORM

PostgreSQL & SQLite Database
# primary SQL databases for Python web apps
🗣️ In plain EnglishPostgreSQL (often called "Postgres") is the most popular database for Python web applications — it's a powerful, reliable, enterprise-grade database that stores data in organized tables (like spreadsheets that talk to each other). SQLite is a lightweight database that lives in a single file — perfect for development and testing. Every Django project defaults to SQLite in development and PostgreSQL in production.

PostgreSQL is the #1 production database for Python/Django applications. Key features: ACID compliance (no data loss), JSON field support (store flexible data in relational DB), full-text search, advanced indexing. PostgreSQL on Heroku, AWS RDS, or Supabase is the most common hosting choice. SQLite is used in development (zero setup — just a file) and for small embedded apps. MySQL is also supported but less common in Python shops. psycopg2 or asyncpg are the Python drivers (libraries that connect Python to PostgreSQL).

Django ORM & SQLAlchemy Database
# object-relational mapping · Alembic migrations
🗣️ In plain EnglishORMs (Object-Relational Mappers) are translators between Python objects and database tables. Instead of writing SQL ("SELECT * FROM users WHERE age > 18"), Python developers write code that reads like English: "User.objects.filter(age__gt=18)". The ORM converts this Python into SQL automatically. This means developers work in Python without needing to be SQL experts — though knowing SQL is still important.

Django ORM is built into Django — it defines database tables as Python classes (Models), and migrations track schema changes over time. SQLAlchemy is the most powerful Python ORM, used with Flask and FastAPI — offers both ORM style and raw SQL expression language. Alembic manages SQLAlchemy database migrations (like Django's migrations system). Tortoise ORM and SQLModel (by FastAPI's creator) are async ORMs gaining traction. Seeing "Django migrations" on a résumé means the candidate manages database schema changes safely.

# Django ORM vs raw SQL comparison
Raw SQL SELECT * FROM users WHERE active=true; Django ORM (Python) User.objects.filter( active=True)
MongoDB & Motor NoSQL
# document database · PyMongo · Motor (async)
🗣️ In plain EnglishMongoDB stores data as flexible "documents" (similar to JSON) instead of rigid rows/columns. Think of it as a folder of Word documents instead of a spreadsheet — each document can have different fields. This makes MongoDB ideal when your data structure changes frequently or when each record has different attributes (like a product catalog where each product has unique specifications). FastAPI + MongoDB is a popular combination.

Python libraries for MongoDB: PyMongo (synchronous, official driver — use with Django/Flask); Motor (async MongoDB driver — use with FastAPI). Beanie is an async ODM (Object Document Mapper) for FastAPI + MongoDB. MongoDB Atlas provides cloud-hosted MongoDB. The FARM stack (FastAPI + React + MongoDB) is gaining traction as a modern alternative to Django REST Framework. A Python developer listing "PyMongo" or "Motor" has NoSQL experience — valuable for roles requiring flexible data modeling.

Redis & Caching Cache
# django-redis · session cache · rate limiting · pub/sub
🗣️ In plain EnglishRedis is a super-fast "sticky note" board in memory. Instead of asking the database (slow disk) the same question repeatedly, Redis remembers the answer in RAM for instant retrieval. When a page that takes 500ms to load from the database can be served in 5ms from Redis cache, the user experience difference is dramatic. Redis also powers Celery's task queue and can handle real-time features like chat.

Redis use cases in Python web apps: Caching — storing computed results (Django's cache framework supports Redis via django-redis); Session storage — faster than database sessions; Celery broker — queuing background tasks; Rate limiting — preventing API abuse; Pub/Sub — real-time messaging; Leaderboards — sorted sets for ranking. Libraries: redis-py (official Python client), django-redis (Django integration), aioredis (async, for FastAPI). Redis on a résumé alongside Celery signals production-level performance engineering.

🚀

DevOps, Testing & Tooling

# how Python apps are tested, containerized, and deployed

Pytest & Testing Testing
# pytest · Django TestCase · unittest · mocking
🗣️ In plain EnglishPytest is the most popular Python testing framework — it automatically runs hundreds of checks on your code to make sure everything still works correctly after every change. Like a spell-checker for logic: it catches bugs before users ever see them. Professional Python teams write tests; amateur projects often skip them and pay for it in production bugs and midnight outage calls.

Pytest is the Python testing standard — simpler and more powerful than the built-in unittest. Django's TestCase provides database testing with automatic test database setup/teardown. Factory Boy creates test data. Faker generates realistic fake data for tests. pytest-django integrates pytest with Django. Coverage.py measures what percentage of code is tested. Selenium/Playwright for end-to-end browser testing. TDD (Test-Driven Development) on a résumé signals code quality discipline. A developer who says "we don't write tests" is a production risk for any serious company.

Docker & Docker Compose DevOps
# containerization · reproducible environments
🗣️ In plain EnglishDocker packages a Python application and everything it needs — Python version, all libraries, configuration — into a portable "container" that runs identically on any computer. Docker Compose lets you define an entire application stack (Django + PostgreSQL + Redis + Celery) in one file and start everything with one command. No more "it works on my machine" — Docker makes every environment identical.

Docker is increasingly standard at mid-to-senior Python developer levels. A Dockerfile defines how to build the container image. docker-compose.yml orchestrates multi-container apps (the Python app, database, Redis, Celery worker all together). Common Python docker-compose stack: web (Django/FastAPI) + db (PostgreSQL) + redis + worker (Celery). Container registries: Docker Hub, AWS ECR, GitHub Container Registry. For production at scale, Docker containers are orchestrated with Kubernetes (K8s) — an advanced skill signaling very senior experience.

Git & GitHub Core
# version control · branching · pull requests · CI/CD
🗣️ In plain EnglishGit is the "track changes" feature for code — it saves a complete history of every change ever made, who made it, and why. GitHub is where this history lives online and where teams collaborate. When something breaks, developers can see exactly what changed and roll back. Without Git, team development would be chaotic; without GitHub, collaboration would be impossible. Git fluency is an absolute baseline expectation for every developer at every level.

Git skills required at every level: branching, merging, rebasing, pull requests, resolving conflicts. GitHub Actions (or GitLab CI/CD) is used to automatically test and deploy Python applications on every code push. A typical Python CI/CD pipeline: push code → GitHub Actions runs pytest → if tests pass, build Docker image → deploy to cloud. Pre-commit hooks (using Black for code formatting, isort for import sorting, Flake8/Ruff for linting) ensure code quality standards before code even reaches the repository.

Cloud Deployment DevOps
# AWS · Heroku · Railway · DigitalOcean · Render
🗣️ In plain EnglishCloud deployment means hosting your Python web application on a third-party company's servers instead of your own. Heroku and Railway are "platform as a service" — incredibly simple (git push to deploy, done), but limited and more expensive at scale. AWS is the full-power option — endless services but a steep learning curve. DigitalOcean and Render are popular middle grounds: reasonable price, developer-friendly, powerful enough for most applications.

Python deployment options by experience level: Beginner: Heroku, PythonAnywhere, Railway (simple, git-push deploy); Intermediate: DigitalOcean (Droplets or App Platform), Render, Fly.io; Advanced: AWS (Elastic Beanstalk, ECS, EC2), Google Cloud (Cloud Run), Azure (App Service). Key AWS services for Python developers: EC2 (virtual servers), S3 (file storage for user uploads), RDS (managed PostgreSQL), Lambda (serverless Python functions), ElastiCache (managed Redis). AWS certifications (AWS SAA, AWS Developer) on a Python résumé are strong positive signals for DevOps-inclined roles.

Code Quality Tools Testing
# Black · Ruff · isort · mypy · type hints
🗣️ In plain EnglishCode quality tools are the automated "editors" and "proofreaders" for Python code. Black automatically formats code to look consistent (no debates about style). Ruff catches common errors and enforces best practices. mypy checks that data types are used correctly (like a type-checker for Python). Together they make codebases more readable, catch bugs early, and ensure every team member writes in a consistent style — critical for team collaboration.

Essential Python code quality tools: Black (auto-formatter — "opinionated," no configuration, the most widely adopted Python formatter); Ruff (extremely fast linter/formatter written in Rust, replacing Flake8+isort+Black in many projects in 2024); isort (sorts import statements); mypy (static type checker for Python type hints); pylint (comprehensive linting). Professional Python teams enforce these via pre-commit hooks and CI/CD pipelines. A candidate who mentions "Black" or "Ruff" signals adherence to professional Python development standards.

📖

Python Stack Quick-Reference Glossary

# 35+ Python terms decoded for non-technical recruiters

Term / LibraryPlain-English MeaningWhere You'll See It
Python 3The current, actively developed version of Python — Python 2 is obsolete. Ask which version a candidate usesEvery Python résumé
OOPObject-Oriented Programming — organizing code into reusable "objects" (classes). Core Python conceptCore Python experience
pipPython's package installer — downloads libraries from PyPI (the Python package index)All Python projects
venv / virtualenvIsolated project workspace — ensures each project has its own library versions without conflictsAll Python development
PoetryModern Python dependency management tool — more powerful than pip/venv, handles versioning and packagingModern Python projects
Django"Batteries included" web framework — provides everything needed for full web apps out of the boxFull-stack web, enterprise Python
FlaskMinimal "microframework" — gives you the basics; you add what you need via extensionsAPIs, microservices, small-to-medium apps
FastAPIModern, high-performance async API framework with automatic documentation — the fastest-growing Python web frameworkModern APIs, data science services
DRFDjango REST Framework — extension for building REST APIs with Django. Almost universal in Django API projectsDjango API development
ORMObject-Relational Mapper — lets developers write Python instead of SQL to query databasesDjango ORM, SQLAlchemy, Tortoise ORM
SQLAlchemyThe most powerful Python ORM — used with Flask and FastAPI. More flexible than Django ORMFlask/FastAPI database work
MigrationsVersioned database schema changes — safe, trackable way to update database structure in productionDjango (makemigrations/migrate)
CeleryBackground task queue — runs slow operations (emails, reports) asynchronously without blocking the userProduction Django/Flask apps
PydanticData validation library using Python type hints — automatic error checking for API inputs. Core to FastAPIFastAPI projects, data validation
JWTJSON Web Token — a secure digital "badge" for API authentication. User logs in once, receives a tokenAPI authentication, React + Python apps
CORSCross-Origin Resource Sharing — security rule browsers enforce; Python back-end must be configured to allow React/Vue front-end requestsDecoupled front-end + Python API
GunicornWSGI server — production-grade process manager for Django/Flask apps (replaces the dev server)Production deployment
UvicornASGI server — async equivalent of Gunicorn, used for FastAPI and async DjangoFastAPI, async Django production
Jinja2Python templating engine — HTML files with Python-filled placeholders, used in Flask and FastAPIFlask, FastAPI, email templates
WSGI / ASGIStandards for how Python web apps communicate with web servers (WSGI=sync, ASGI=async)Production architecture discussions
PytestThe standard Python testing framework — runs automated checks on code to catch bugsAny professional Python project
BlackAutomatic code formatter — enforces consistent style across the entire codebase, no style debatesProfessional Python team codebases
RuffExtremely fast Python linter — checks code for errors and style issues, replacing multiple older toolsModern Python projects (2023+)
Type HintsOptional annotations in Python code (e.g., def greet(name: str) → str) — enables better tooling and fewer bugsFastAPI (required), modern Python
async / awaitPython's concurrency model — allows one Python process to handle many requests simultaneously without blockingFastAPI, async Django, modern Python
Django AdminAuto-generated admin web interface for managing database records — a major Django productivity featureDjango web projects
HTMXJavaScript library that adds interactivity to Django templates without needing React/VueDjango + HTMX full-stack projects
AlembicDatabase migration tool for SQLAlchemy — the equivalent of Django's migrations for Flask/FastAPI appsFlask/FastAPI with SQLAlchemy
💬

Recruiter's Python Full-Stack Interview Cheat Sheet

# 50+ qualifying questions with strong / average / weak answer guidance

📌 How to Use This Section

You don't need to understand the technology to evaluate quality. Listen for specificity (real framework names, real version numbers), tradeoff awareness (when to use Django vs. Flask vs. FastAPI), and depth under follow-up. Every question shows Strong ✓, Average ≈, and answer patterns.

🔎

General Screening

ALL PYTHON FULL-STACK CANDIDATES
Opener
"Walk me through the last full-stack Python application you built. What problem did it solve, and which technologies did you use?"
Strong: Describes a complete stack ("Django REST Framework + React front-end, PostgreSQL, Redis for caching, deployed on AWS with Docker, CI/CD via GitHub Actions"). Explains the business problem and how choices were made.

Average: Can describe the app but vague on architecture ("I used Django and some database").

Only describes front-end features, no awareness of back-end architecture, or only has tutorial projects.
Framework Choice
"If we need to build a new web application, when would you choose Django vs Flask vs FastAPI? Walk me through how you'd decide."
Strong: Django for complete, feature-rich apps (auth, admin, ORM all built-in); Flask for lightweight APIs or microservices where full control is needed; FastAPI for high-performance async APIs, especially ML model serving or high-concurrency scenarios. Mentions team experience and project timeline as factors.

Average: "I'd use Django because it's what I know" — no decision framework.

Only knows one framework, can't discuss tradeoffs — inflexible for real-world requirements.
Python Version
"What version of Python are you currently working with? What features from recent Python versions have you found most useful?"
Strong: Python 3.11, 3.12, or 3.13. Mentions specific features they use: f-strings, walrus operator (:=), structural pattern matching (3.10+), improved error messages (3.11+), type hints. Shows active interest in the language evolution.

Average: "Python 3" without specific version knowledge.

"Python 2.7" — completely obsolete. Python 2 support ended in 2020; this signals very outdated experience or lack of currency.
Workflow
"Describe your development workflow from writing code to deploying a new feature."
Strong: Local dev with virtual environment → write feature + tests → black/ruff formatting → pytest → git commit with descriptive message → pull request + code review → GitHub Actions CI runs (tests, linting) → merge to main → automatic deployment to staging → production. Systematic, automated, testable.

Average: "I write code, test it manually, then push to GitHub" — no automation or testing discipline.

"I email my code to the server" or no version control usage — unacceptable for any team environment.
⚙️

Back-End Questions

DJANGO · FLASK · FASTAPI · APIs · SECURITY
Django Deep
"What is Django's ORM, and what are the tradeoffs of using it versus raw SQL?"
Strong: ORM (Object-Relational Mapper) lets you query the database using Python instead of SQL: User.objects.filter(age__gte=18). Pros: readable, database-agnostic, injection-safe. Cons: can generate inefficient queries for complex cases, N+1 query problem if select_related/prefetch_related aren't used. Knows when to use raw SQL (.raw()) for complex reports.

Average: "It lets you use Python instead of SQL" — correct but no awareness of limitations.

Can't explain what an ORM is — fundamental Django knowledge gap.
Middleware
"What is Django middleware? Give an example of when you've written custom middleware."
Strong: Middleware is code that runs on every request/response — like a pipeline. Django has built-in middleware for authentication, CSRF protection, sessions. Custom middleware examples: request logging with timing, IP-based rate limiting, adding custom headers to responses, checking API key on every request. Knows the process_request/process_response pattern.

Average: "Middleware processes requests" but never written custom middleware.

"I've heard of it" — concerning for any Django developer above junior level.
FastAPI
"What makes FastAPI faster than Django for API development? What are the tradeoffs?"
Strong: FastAPI is async-native (handles many requests concurrently without blocking), uses Pydantic for blazing-fast data validation, and has less overhead than Django's full framework. Tradeoffs: Django has more built-in batteries (admin, auth, ORM), larger ecosystem, more mature — FastAPI is leaner but you assemble more pieces yourself. Chooses based on project needs, not hype.

Average: "FastAPI is just faster" without being able to explain why.

Claims FastAPI expertise but doesn't know what async/await means.
Auth Security
"How do you implement authentication for a REST API that will be consumed by a React front-end?"
Strong: JWT (JSON Web Tokens) — user logs in with credentials, server returns access token (short-lived) + refresh token (longer-lived). React stores access token (httpOnly cookie for security, or memory — NOT localStorage due to XSS risk). Every API request includes "Authorization: Bearer {token}" header. DRF + djangorestframework-simplejwt, or FastAPI's OAuth2PasswordBearer. Mentions refresh token rotation for security.

Average: "Use JWT" but stores in localStorage and doesn't know refresh token flow.

"Session auth should work fine" — session auth doesn't work well for React SPAs consuming REST APIs.
Performance
"A Django API endpoint takes 3 seconds to respond. Walk me through how you diagnose and fix it."
Strong: Install Django Debug Toolbar to inspect SQL queries (look for N+1 — 100 queries when 2 would do). Identify slow queries, add select_related/prefetch_related to reduce queries. Add database indexes for frequently filtered columns. Implement Redis caching for computed results (cache_page or per-object caching). Profile with django-silk or cProfile. If still slow, move heavy work to Celery background task.

Average: "Add caching" — correct general direction but no diagnostic methodology.

"Upgrade the server" — hardware is rarely the first solution; usually it's query inefficiency.
Background Tasks
"A user submits a form that triggers sending 10,000 emails. How do you handle this without making them wait?"
Strong: Immediately return "Your emails are queued!" to the user. The view adds a Celery task to the queue (backed by Redis). Celery workers pick up and process tasks asynchronously in the background. User can check status via a polling endpoint or WebSocket. This pattern prevents request timeout and terrible UX. Mentions Celery Beat for scheduled tasks.

Average: "Use a background thread" — threading in Python has the GIL limitation and is not the recommended approach for web apps.

"The user just has to wait" — unacceptable for any production application sending more than a few emails.
🖥️

Front-End Questions

TEMPLATES · REACT · JAVASCRIPT · CSS
Architecture
"Would you use Django Templates with HTMX or a decoupled React + Django REST API for a new project? How would you decide?"
Strong: Django Templates + HTMX for: content-heavy sites, simpler CRUD apps, small teams, faster initial delivery, no need for a separate front-end team. React + DRF for: complex interactive UIs, mobile app sharing the same API, separate front-end/back-end teams, apps that need offline capability or PWA features. Decision based on team skills, timeline, and actual UX requirements — not hype.

Average: "I'd always use React" — shows preference without thinking through the tradeoffs.

Only knows one approach, no awareness of the architectural tradeoff — limits problem-solving flexibility.
CORS
"Your React front-end runs on localhost:3000 and your Django API on localhost:8000. What issue will you encounter, and how do you fix it?"
Strong: CORS (Cross-Origin Resource Sharing) — browsers block JavaScript from making requests to a different origin (different port counts). Fix: install django-cors-headers, add 'http://localhost:3000' to CORS_ALLOWED_ORIGINS in Django settings. In production, add the actual domain. Knows not to use CORS_ALLOW_ALL_ORIGINS=True in production (security risk).

Average: "CORS error" but not sure how to fix it precisely.

Unaware of CORS — will be blocked immediately setting up any React + Python project.
JavaScript
"How comfortable are you with JavaScript? Rate yourself and describe what you can build without help."
Strong: Gives honest self-assessment ("7/10 — I can build React components with hooks, manage state with Context API, handle async fetch calls, but I'd need to look up some TypeScript nuances"). Specific and accurate — not claiming expertise they don't have.

Average: "I know JavaScript basics" without being able to describe what "basics" means.

"I'm a Python developer, I don't do JavaScript" — a true full-stack developer needs at least functional JavaScript knowledge. This signals back-end only.
🗄️

Database Questions

POSTGRESQL · ORM · MIGRATIONS · REDIS
Migrations
"How do you handle database schema changes (migrations) safely in a production Django application?"
Strong: Run makemigrations to create the migration file, review the generated SQL (sqlmigrate), test on staging first, then apply (migrate) in production — never modify the database directly. For backwards-incompatible changes (dropping a column), use a two-step process: deploy new code that doesn't use the column, then run migration. Zero-downtime migrations require careful sequencing. Knows to back up before any production migration.

Average: "Run python manage.py migrate in production" — correct command but no awareness of risk management.

"I manually ALTER TABLE in the database" — bypasses the migration system, creates inconsistencies, no rollback path.
N+1 Problem
"What is the N+1 query problem in Django? Have you encountered it and how did you fix it?"
Strong: N+1 happens when Django fetches a list (1 query) then accesses a related object on each item (N additional queries). For 100 users, that's 101 queries instead of 2. Fix: use select_related() for foreign keys (JOIN) or prefetch_related() for many-to-many (separate optimized queries). Detected with Django Debug Toolbar or logging. Gives a concrete project example.

Average: Has heard of it and knows select_related but can't describe the root cause.

Unaware — ships code that makes 1000 database queries per page load.
Caching
"When would you use Redis caching versus database queries in a Python web app?"
Strong: Cache data that is: expensive to compute, frequently requested, and doesn't change often (product catalog, user profile, API aggregations). Cache at multiple levels: view-level (cache_page), fragment caching (specific template sections), per-object caching (individual queryset results). Sets appropriate TTL (Time To Live) — too long = stale data, too short = no benefit. Knows cache invalidation strategies — when data changes, invalidate the cached version. Redis is also used for session storage, Celery, and rate limiting.

Average: "Cache expensive queries" — correct intuition but no implementation detail.

No caching strategy awareness — ships apps that hit the database for every request.
SQL vs NoSQL
"Would you choose PostgreSQL or MongoDB for a new Python project? How do you decide?"
Strong: PostgreSQL for: structured, relational data (e-commerce orders, user accounts, financial records); when data integrity and consistency are critical; when complex joins and transactions are needed. MongoDB for: flexible/evolving data structures (content management, user activity logs, IoT data); when horizontal scaling is needed; document-style data. Notes that Django's ORM is designed for relational databases — using MongoDB with Django is awkward; FastAPI + MongoDB is a more natural pairing.

Average: Prefers one without explaining why.

"SQL is old, use MongoDB" or vice versa — shows no understanding of use cases.
🚀

DevOps & Testing Questions

DOCKER · PYTEST · DEPLOYMENT · CI/CD
Testing
"What's your approach to testing a Django API endpoint? Walk me through what you test."
Strong: Uses pytest with pytest-django. Tests: happy path (valid input, expected response), edge cases (empty input, boundary values), error cases (invalid input returns 400, unauthorized returns 401), authentication (protected endpoints reject unauthenticated requests). Uses Django TestCase's test client or pytest fixtures. Separate unit tests (individual functions) from integration tests (database). Mentions factories (Factory Boy) for test data, aims for >80% coverage.

Average: "I write tests for important functions" but only happy-path testing.

"We test manually in the browser" — no automated testing for any API code.
Docker
"Describe your Docker setup for a Django + PostgreSQL + Redis application."
Strong: docker-compose.yml with services: web (Django app, from custom Dockerfile), db (postgres:15 image), redis (redis:alpine), worker (same Django image but CMD overridden to celery worker). Environment variables for DATABASE_URL, REDIS_URL loaded from .env file. Healthchecks ensure postgres is ready before Django starts. Volume mounts for database persistence. Multi-stage Dockerfile (build stage for dependencies, slim production stage for smaller image).

Average: Has used Docker but only with simple setups, no multi-service experience.

"Docker is too complex, I just install everything locally" — limits deployability and team collaboration.
Deployment
"Walk me through deploying a new Django feature from code merge to production."
Strong: PR merged to main → GitHub Actions triggers: runs pytest suite → runs Ruff linter → if passing, builds Docker image → pushes to container registry → deploys to staging (Render/ECS/Heroku) → runs smoke tests → if staging passes, promotes to production with zero-downtime deployment (rolling update or blue-green). Migrations run as a pre-deploy step. Rollback plan if deployment fails.

Average: "Push to GitHub, Heroku auto-deploys" — functional but no testing gate, no zero-downtime strategy.

"I SSH into the server and pull the code manually" — no automation, error-prone, impossible to scale across a team.
Security
"What are the top security concerns for a Django web application and how do you address them?"
Strong: Django's built-in protections: CSRF protection (always enabled), XSS protection (auto-escaping in templates), SQL injection protection (ORM parameterizes queries), clickjacking protection (X-Frame-Options header). Additional: store secrets in environment variables (never in code); use HTTPS everywhere; rate limiting on authentication endpoints (django-ratelimit); keep Django and dependencies updated; configure allowed hosts (ALLOWED_HOSTS); disable DEBUG in production; use Django's SECRET_KEY as a real secret.

Average: "Use HTTPS and don't expose the admin URL" — basic but incomplete.

"Django is secure by default, I don't worry about it" — misunderstanding; Django provides tools but developers must use them correctly.

🚩 Universal Red Flags — Python Full-Stack Candidates

Warning signs that warrant deeper investigation regardless of résumé claims

Python 2 onlyPython 2 has been unsupported since January 2020. Any developer still writing Python 2-only code lacks currency. Ask: "Are you comfortable with f-strings?" (Python 3.6+).
No testing knowledge"We don't write tests" or "QA handles that" from a developer claiming senior Python experience is a serious red flag. Automated testing is non-negotiable in any professional Python team.
No virtual environmentsA Python developer who installs packages globally (without virtualenv/venv/poetry) shows a lack of professional Python development practices — this causes dependency conflicts across projects.
Hardcoded secretsDjango SECRET_KEY, database passwords, or API keys stored directly in code (not environment variables) signals a fundamental security gap that could put a company's entire application at risk.
DEBUG=True in productionDjango's DEBUG mode exposes sensitive stack traces and SQL queries to the public. Any Django developer who's worked in production should know this is the first thing disabled before launch.
No async awareness (FastAPI role)For FastAPI-specific roles, inability to explain async/await and why it matters signals the candidate can use FastAPI superficially but not leverage its core performance advantage.