Skip to main content
HireInterviewAIHireInterviewAI
ProductAI & MLProctoringPricingSkillsBlogDevelopers
Log inBook a Demo
  1. Home
  3. Blog
  5. How to interview a FastAPI developer: a concept-by-concept guide

Role Guide

How to interview a FastAPI developer: a concept-by-concept guide

How to interview a FastAPI developer concept by concept — dependency injection, Pydantic response boundaries, yield dependencies, the OAuth2/JWT flow, and the blocked event loop — to measure real depth, not tutorial recall.

HireInterviewAI Team·July 12, 2026·8 min read
An interviewer testing a FastAPI developer with dependency-injection, Pydantic, session, auth, and event-loop probes
On this page
  • Why "the endpoint works" isn't FastAPI knowledge
  • The concepts that separate real FastAPI engineers
  • 1. Depends & deferred resolution
  • 2. The response boundary (response_model)
  • 3. Yield dependencies & the session lifecycle
  • 4. Routing & request-data mechanics
  • 5. Auth — the OAuth2/JWT flow (and its tradeoffs)
  • 6. async def vs def & the event loop (the ceiling probe)
  • What a FastAPI depth report looks like
  • Mastery vs bluffing: the pattern

On this page

  • Why "the endpoint works" isn't FastAPI knowledge
  • The concepts that separate real FastAPI engineers
  • 1. Depends & deferred resolution
  • 2. The response boundary (response_model)
  • 3. Yield dependencies & the session lifecycle
  • 4. Routing & request-data mechanics
  • 5. Auth — the OAuth2/JWT flow (and its tradeoffs)
  • 6. async def vs def & the event loop (the ceiling probe)
  • What a FastAPI depth report looks like
  • Mastery vs bluffing: the pattern
HireInterviewAI Team

Written by

HireInterviewAI Team

AI Interview Research

The HireInterviewAI team builds adaptive AI technical interviews that probe candidates concept by concept and report exactly which topics they understand at depth.

hireinterviewai.com

HireInterviewAI

See what HireInterviewAI's per-concept interviews reveal

Stop hiring on a single fuzzy score. Run a live, adaptive AI technical interview that probes each concept to its ceiling and reports exactly which topics a candidate understands at depth.

See what HireInterviewAI's per-concept interviews revealExplore the developer API

Related reading

  • Role Guide

    How to interview a Python developer: a concept-by-concept guide

    How to interview a Python developer concept by concept — the object model, the data model, generators, decorators, EAFP, and the GIL — to measure real depth, not syntax recall.

    Read
  • Role Guide

    How to interview a Kubernetes engineer: a concept-by-concept guide

    How to interview a Kubernetes engineer concept by concept — reconciliation, scheduling, networking, RBAC, and security probes that separate real depth from kubectl fluency.

    Read
  • Role Guide

    How to interview a backend developer: a concept-by-concept guide

    How to interview a backend developer concept by concept — APIs, databases, concurrency, system design, reliability — to measure true depth, not vibes.

    Read
HireInterviewAIHireInterviewAI

AI-powered technical interviews that help engineering teams hire smarter, faster, and without bias.

Product

  • Features
  • Pricing
  • Security
  • Changelog

Company

  • About
  • Blog
  • Careers
  • Contact

Resources

  • Documentation
  • API Reference
  • Skill assessments
  • Status

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • GDPR

© 2026 HireInterviewAI, Inc. All rights reserved.

Built for engineers who deserve better interviews

Key takeaways
  • FastAPI's ergonomics make shallow understanding look deep — a working endpoint tells you the tutorial was good, not whether the candidate understands the dependency graph, the response boundary, or the event loop.
  • Probe six concepts: Depends and deferred resolution, response_model boundaries, yield dependencies & sessions, routing mechanics, the OAuth2/JWT flow, and async vs sync handlers. Each has a clean "understands it" vs "pattern-matched it" tell.
  • Mastery shows up as reasoning about what actually executes — when a dependency is called, which fields leave the process, who closes the session, what one blocking call does to every other request — not reciting that "FastAPI is fast and has automatic docs".
  • Adaptive, per-concept probing reveals each candidate's real ceiling on each concept instead of one misleading score.

To interview a FastAPI developer well, you have to get past the surface fluency — "it's async," "Pydantic validates everything," "the docs generate themselves" — that anyone who has followed the tutorial can recite, and probe whether they can reason about what actually executes: when the framework calls a dependency, which fields cross the response boundary, what happens to an open session when a handler raises, and what one synchronous call inside a coroutine does to every other request on the server. This guide gives you specific probes for six concepts and, for each, the difference between a developer who understands FastAPI and one who has memorized its decorators.

Why "the endpoint works" isn't FastAPI knowledge

FastAPI is the easiest modern framework to look competent in. The type hints do the parsing, the docs page writes itself, and a CRUD service is an afternoon of copy-adaptation. That's precisely the trap: the framework does so much that a candidate can ship working endpoints while holding a wrong mental model of every mechanism underneath — and those wrong models don't fail in a demo. They fail as a leaked connection pool, a password hash in a JSON response, or a service where every request stalls because one handler called a sync SDK. The interview can't be "build a todo API." It has to be "what actually happens when this runs, and why?"

The concepts that separate real FastAPI engineers

1. Depends & deferred resolution

Probe: "In def get_user(user = Depends(user_dep)) — why can't you write user = user_dep() as the default instead? And what does FastAPI do with user_dep's own parameters?"

  • Mastery: user_dep() would run once, at definition time, freezing one value into the signature; user_dep alone is just the function object. Depends defers the call to request time, and FastAPI first resolves the dependency's own declared parameters (Query, Header, other Depends) before calling it — it's a graph, resolved per request, cached within the request. Knows the payoffs that follow: sub-dependency chains for auth, router-level attachment, and app.dependency_overrides swapping the graph in tests.
  • Bluffing: "Depends is how you inject things" with no account of when anything runs; can't explain why the two alternatives are wrong; has never overridden a dependency in a test.

2. The response boundary (response_model)

Probe: "Your handler returns the full User ORM object, which includes hashed_password. The endpoint declares response_model=UserOut, which doesn't have that field. What does the client see — and why is this the pattern rather than deleting the field by hand?"

  • Mastery: The client sees only UserOut's fields — FastAPI filters the returned object against the declared schema, so the hash can't leak even if a refactor changes what the handler returns. Explains the In/DB/Out model split (what clients send vs what you store vs what you return), knows the decorator's response_model= beats the return annotation, and reaches for model_dump(exclude_unset=True) when the same thinking hits PATCH semantics.
  • Bluffing: Thinks the response is whatever you return; strips fields manually in each handler; uses one model for request, storage, and response "to keep it DRY".

3. Yield dependencies & the session lifecycle

Probe: "Here's the classic get_db dependency: create a session, yield it, close it. A teammate's version has no try/finally. Under load, the service exhausts its connection pool — but only when endpoints raise errors. Connect the dots."

  • Mastery: Code before yield runs before the handler, code after runs after the response — but when the handler raises, the code after a bare yield never executes, so failed requests leak sessions until the pool dies. try: yield db; finally: db.close() guarantees teardown on both paths. Maps the whole lifecycle: session-per-request, commit/refresh to read generated ids, rollback on IntegrityError → 409, and why a module-level shared session is the same disease in a different coat.
  • Bluffing: Copied get_db without knowing what the yield split means; can't say when the close runs; doesn't connect the error path to the leak.

4. Routing & request-data mechanics

Probe: "You add GET /tasks/search to a router that already has GET /tasks/{task_id} where task_id is an int. Searching returns 422 Unprocessable Entity. What happened, and where does each kind of request data actually belong?"

  • Mastery: Routes match in registration order — /tasks/search fell into /tasks/{task_id}, and "search" failed int validation, hence 422 (declare the fixed path first). Uses the miss to show the full map: path params for identity, query params for filters/pagination, body for structured payloads on POST/PUT/PATCH (never GET), headers/forms declared explicitly — and reads a 422 body's loc path like a stack trace instead of guessing.
  • Bluffing: Blames Pydantic or "a FastAPI bug"; has no model of match order; puts a JSON body on a GET or ships filters as path segments.

5. Auth — the OAuth2/JWT flow (and its tradeoffs)

Probe: "Walk me through what happens between POST /token with a username and password, and a later authenticated call to GET /users/me. Then: a token leaks — what can you do about it before it expires?"

  • Mastery: /token receives form fields (OAuth2PasswordRequestForm, not JSON), verifies the password against a bcrypt hash (never plain text), signs a JWT with sub and exp; later requests carry Authorization: Bearer, extracted by an OAuth2PasswordBearer dependency, decoded and expiry-checked with no database hit. Then the honest tradeoff: a signed stateless token can't be directly revoked — you mitigate with short expiries, and true revocation needs state again (denylist, key rotation). Knows 401 means unauthenticated, and role checks are just one more dependency in the chain.
  • Bluffing: "JWTs are encrypted" (they're encoded and signed — readable); stores or compares plain-text passwords; no idea revocation is a problem; can't say where the token travels.

6. async def vs def & the event loop (the ceiling probe)

Probe: "One handler is async def and calls a synchronous SDK that takes two seconds. Under concurrent load, users of completely unrelated endpoints start timing out. Why? And why would declaring that handler as plain def have masked the problem?"

  • Mastery: All async handlers share one event-loop thread; a sync call inside async def never yields, so every in-flight request stalls behind it. Plain def handlers run in a threadpool, so the same blocking call would only have occupied a worker thread. The real fixes: await an async client (httpx, an async driver) or deliberately take the threadpool — and knows the benchmark shape: sync and async tie at 10 concurrent calls and diverge brutally at 100, because async reclaims waiting, not compute. Bonus: CPU-bound work doesn't belong on the loop at all — processes or a queue.
  • Bluffing: "async makes it faster" with no mechanism; doesn't know the threadpool exists; can't explain why unrelated endpoints suffered; sprinkles async/await as syntax.

What a FastAPI depth report looks like

Interviewed this way, a candidate doesn't get one FastAPI score — they get a profile that tells you exactly what to trust and what to verify in onboarding:

Concept depth report

FastAPI · 'senior' backend candidate, depth view

Dependency injection8/10
Pydantic models & validation7/10
SQL databases & ORM integration6/10
Authentication & security5/10
Async & the event loop3/10

This candidate would sail through most take-home FastAPI screens — their dependency and schema design is genuinely strong. The depth view surfaces the risk you'd otherwise find in production: a shaky model of the async runtime, exactly the gap that ships a sync database driver inside async routes and turns one slow upstream into a site-wide stall. That's a hire-with-a-known-gap, not a guess. A single "FastAPI: 6.5/10" would have hidden both the strength and the risk. (Here's why one number is useless.)

Mastery vs bluffing: the pattern

Across all six concepts the tell is the same. Bluffers describe what things are ("Depends injects dependencies," "Pydantic validates the body," "async is non-blocking"). Developers who actually understand FastAPI describe what happens and why — the dependency resolved per request, the field filtered at the boundary, the finally that runs on the error path, the loop thread everyone shares — and how they'd catch it. Mechanism reasoning is the signal. Vocabulary is noise.

That's also why a fixed question can't carry the interview: a strong developer clears your first probe instantly and you learn nothing about their ceiling. You have to keep raising difficulty — which is precisely what an adaptive interview does automatically, finding each candidate's real boundary on each concept instead of stopping at the first correct answer.

HireInterviewAI probes concepts like these adaptively and reports the per-concept depth above instead of a pass/fail. See the FastAPI assessment, the sibling guides to interviewing a Python developer and interviewing a backend developer, or the framework for how to evaluate developer skills.

Frequently asked questions

What is the single best question to interview a FastAPI developer?
The blocked event loop — a sync two-second call inside an async def handler, and why unrelated endpoints time out under load. It instantly separates developers who hold the runtime model (one shared loop thread for async handlers, a threadpool for plain def) from those who use async as syntax, and it opens naturally into driver choice, gather-based fan-out, and when concurrency helps at all.
Should I interview FastAPI separately from Python?
Yes, as a framework track on top of the language track. Python probes cover the data model, generators, typing, and the GIL; FastAPI probes cover framework judgment — dependency injection, response boundaries, session lifecycles, auth flows, and the async runtime as FastAPI exposes it. A candidate can be strong in one and weak in the other, and the hire decision needs both signals.
How do you tell FastAPI mastery from tutorial recall?
Push past definitions to mechanism and failure modes. Tutorial recall reproduces the happy path — the get_db snippet, the /token endpoint. Mastery predicts what breaks: the session that leaks when a handler raises, the hash that leaks without response_model, the 422 caused by route registration order, the token that cannot be revoked. Asking "why is this line here, and what fails without it" about their own pasted patterns is the fastest tell.
Which FastAPI concepts matter most for a senior hire?
Async and the event loop, dependency-injection design, and the auth/security surface — the concepts a passing take-home barely touches but that cause the most expensive production incidents (a stalled loop, an exhausted pool, a leaked credential). Routing and Pydantic basics are table stakes; how someone reasons about what executes where, and what fails on the unhappy path, is what separates senior engineers.

Interview for what actually executes when the request arrives, not what they can recite — and report it per concept so you know exactly what you're hiring. See how HireInterviewAI does it on the FastAPI assessment, or check pricing.