# DevFilter Starter Screening Kit: Python / Django / FastAPI Screening Questions Use these to evaluate candidates for backend-heavy startup roles working with Python services, Django or FastAPI applications, databases, async workloads, and production operations. Pick 6 to 8 questions for an async screen or 10 to 12 for a live technical screen. ## How to Use This Pack - Ask for examples from shipped systems, not idealized architecture answers. - Push candidates to explain tradeoffs, data shape, failure modes, and monitoring. - Strong answers usually connect Python framework knowledge to database design, reliability, and delivery speed. ## Questions ### 1. Tell me about a Python service or Django app you improved substantially. What was wrong before, and what did you change? **Strong signal:** Gives a concrete before-and-after story involving maintainability, correctness, performance, developer speed, or operational reliability. ### 2. When would you choose Django over FastAPI for a new product, and when would you avoid Django? **Strong signal:** Understands framework tradeoffs around admin needs, ORM usage, batteries-included velocity, async requirements, and long-term team productivity. ### 3. What are the most common ORM mistakes you see in Django applications? **Strong signal:** Calls out N+1 queries, over-fetching, missing indexes, accidental cartesian joins, heavy model logic, and transaction misuse. ### 4. How do you design request validation and response schemas in FastAPI so the API stays maintainable as it grows? **Strong signal:** Uses typed models and boundary validation cleanly, separates transport models from domain logic where needed, and keeps contracts explicit. ### 5. Tell me about a performance issue caused by the database rather than Python itself. How did you diagnose it? **Strong signal:** Mentions query plans, indexes, slow query logs, selectivity, lock contention, pagination strategy, or schema changes backed by measurement. ### 6. When do you reach for background jobs in a Python product, and what mistakes do teams make with them? **Strong signal:** Explains asynchronous work boundaries, idempotency, retries, visibility, and why "just throw it in a worker" can hide reliability problems. ### 7. How do you approach transactions in Django or SQLAlchemy when a workflow updates multiple related records? **Strong signal:** Understands atomicity, rollback behavior, side effects outside the transaction, and how to prevent partial writes or duplicate work. ### 8. Describe a time an API endpoint looked simple but hid difficult edge cases. What were the edge cases? **Strong signal:** Identifies permission issues, race conditions, duplicate submissions, validation complexity, or legacy data inconsistencies. ### 9. What does a good production-ready FastAPI service include beyond just route handlers? **Strong signal:** Covers configuration, dependency injection boundaries, logging, health checks, tracing, tests, auth, rate limits, and deployment expectations. ### 10. How do you stop business logic from leaking everywhere in a Django codebase? **Strong signal:** Has a clear strategy for where domain logic lives, when to use services or modules outside models/views, and how to keep responsibilities sharp. ### 11. Tell me about a migration that touched a large table or critical model. How did you reduce risk? **Strong signal:** Talks about backfills, multi-step deploys, dual writes, data validation, observability, and rollback planning. ### 12. How do you handle authentication and permissions for both browser sessions and API consumers in the same product? **Strong signal:** Distinguishes authentication mechanisms from authorization rules, explains session or token tradeoffs, and addresses permission checks centrally. ### 13. What kinds of tests give you the most confidence in a Python backend, and what kinds of tests become noise? **Strong signal:** Balances unit, integration, API, and database tests and explains how to avoid brittle tests that mirror implementation details. ### 14. Suppose your Django admin is heavily used by operations staff. What changes would you make so it becomes a safe internal tool instead of a liability? **Strong signal:** Mentions custom permissions, auditability, bulk action safety, data validation, search/filter quality, and minimizing accidental destructive actions. ### 15. How do you reason about sync versus async code in Python? Where do teams misuse async? **Strong signal:** Understands actual I/O-bound benefits, event loop implications, blocking calls inside async code, and when simpler synchronous code is better. ### 16. Tell me about an incident where a Python service failed in production. How did you respond, and what did you change afterward? **Strong signal:** Shows ownership, calm diagnosis, practical remediation, and follow-through with monitoring, tests, or architectural fixes. ### 17. How would you evaluate whether a candidate really understands caching instead of just saying "we used Redis"? **Strong signal:** Pushes into cache invalidation, consistency tradeoffs, TTL strategy, hot keys, stampedes, and when caching is the wrong fix. ### 18. A product manager wants a reporting endpoint that joins several large tables and returns instantly. How would you frame the tradeoffs? **Strong signal:** Discusses precomputation, materialized views, async exports, pagination, query optimization, and expectation-setting with stakeholders. ### 19. What metrics or alerts would you put on a Python application immediately after launch? **Strong signal:** Includes request latency, error rate, job failures, queue backlog, database health, saturation signals, and a small set of business metrics. ### 20. In a startup backend role, what behaviors tell you an engineer can own systems end to end rather than only implement isolated tasks? **Strong signal:** Highlights judgment, communication, data awareness, operational responsibility, and ability to simplify solutions under real constraints.