FastAPI interview questions

What a strong answer covers

• Import `FastAPI` from `fastapi`.
• Instantiate the `FastAPI` application object.
• Define a path operation using a decorator (e.g., `@app.get('/')`) and an asynchronous function.
• The function should return a simple dictionary or string.
• Explain running the application using Uvicorn (e.g., `uvicorn main:app --reload`).

Where people lose the point

• ×Forgetting `async` for the path operation function, leading to synchronous blocking behavior.
• ×Not specifying the correct module and app object when running Uvicorn (e.g., `main:app`).
• ×Attempting to run the Python file directly without an ASGI server like Uvicorn.

What a strong answer covers

• Pydantic is used for data validation and serialization/deserialization.
• It allows defining data schemas using Python type hints.
• Automatically validates incoming request data (e.g., JSON bodies) against defined models.
• Serializes Python objects into JSON responses.
• Generates clear, automatic error messages for invalid data.

Where people lose the point

• ×Confusing Pydantic's role with database ORM or business logic.
• ×Understating the importance of automatic documentation generation and error handling.
• ×Not mentioning the use of Python type hints as the foundation for Pydantic models.

What a strong answer covers

• Path parameters are part of the URL path, used to identify a specific resource (e.g., `/items/{item_id}`).
• Query parameters are key-value pairs appended to the URL after a `?`, used for filtering, sorting, or pagination (e.g., `/items/?skip=0&limit=10`).
• FastAPI automatically infers their types from function arguments.
• Provide a code example for a path parameter (e.g., `@app.get('/items/{item_id}')`).
• Provide a code example for a query parameter (e.g., `def read_items(skip: int = 0, limit: int = 10):`).

Where people lose the point

• ×Incorrectly placing query parameters within the path string.
• ×Confusing the syntax for defining each type of parameter in the path operation function.
• ×Not explaining the typical use cases for each parameter type.

What a strong answer covers

• Import `HTTPException` from `fastapi`.
• Raise it within a path operation using `raise HTTPException(status_code=..., detail=...)`.
• FastAPI automatically catches `HTTPException` and returns a proper JSON response with the specified status code and detail message.
• Benefits include consistent API error responses, automatic documentation of error schemas, and avoiding raw server errors.
• Contrast with standard Python exceptions which would typically result in a 500 Internal Server Error without custom handling.

Where people lose the point

• ×Forgetting to import `HTTPException`.
• ×Not providing a `status_code` or `detail` argument.
• ×Failing to explain that `HTTPException` is caught and handled by FastAPI automatically, unlike generic Python exceptions.

What a strong answer covers

• A dependency is a callable (function or class) that FastAPI executes before a path operation.
• Its return value is then passed as an argument to the path operation function.
• Dependencies are declared using `Depends()` in the path operation's function signature.
• Example: A function `get_current_user()` that returns a user object.
• Benefits include code reuse, modularity, and easier testing.

Where people lose the point

• ×Not using `Depends()` to declare the dependency.
• ×Confusing dependencies with middleware or background tasks.
• ×Failing to explain that the dependency's return value is injected into the path operation.

What a strong answer covers

• FastAPI is built on ASGI, which is designed for asynchronous I/O operations.
• `async`/`await` allows the server to handle multiple requests concurrently without blocking, improving performance for I/O-bound tasks.
• If synchronous code (e.g., blocking database calls, `time.sleep()`) is used directly in an `async` path operation, it will block the entire event loop.
• This blocking prevents other concurrent requests from being processed, negating the benefits of asynchronous programming.
• FastAPI provides `run_in_threadpool` for safely executing synchronous code in a separate thread.

Where people lose the point

• ×Incorrectly stating that `async`/`await` makes CPU-bound tasks faster.
• ×Not understanding that synchronous code *blocks* the event loop, not just slows down the specific request.
• ×Failing to mention `run_in_threadpool` as the solution for synchronous operations.

What a strong answer covers

• Request bodies are defined using Pydantic models as type-hinted parameters in path operation functions.
• FastAPI automatically parses the incoming JSON request body.
• Pydantic validates the data against the model's schema, including type checks, required fields, and custom validators.
• If validation fails, FastAPI returns a `422 Unprocessable Entity` response with detailed error messages.
• This ensures data integrity, reduces boilerplate validation code, and provides clear feedback to API consumers.

Where people lose the point

• ×Not explicitly mentioning Pydantic models as the primary mechanism.
• ×Confusing request body validation with path or query parameter validation.
• ×Failing to state the specific HTTP status code (422) returned on validation failure.

What a strong answer covers

• **Code Reusability:** Common logic (e.g., database sessions, authentication) can be defined once and reused across multiple endpoints.
• **Modularity and Separation of Concerns:** Path operations focus on their core logic, delegating setup/validation to dependencies.
• **Testability:** Dependencies can be easily overridden during testing, allowing for isolated unit tests without mocking complex setups.
• **Reduced Boilerplate:** Eliminates repetitive code for common tasks like database connection management or user authentication.
• **Automatic Documentation:** Dependencies are automatically reflected in the OpenAPI schema, improving API documentation.

Where people lose the point

• ×Only listing one or two benefits without elaboration.
• ×Confusing dependency injection with simple function calls.
• ×Not emphasizing the impact on testing and maintainability.

What a strong answer covers

• Define a custom Python exception class (e.g., `class ItemNotFound(Exception):`).
• Register an exception handler using `@app.exception_handler(YourCustomException)`.
• The handler function takes the request and the exception as arguments.
• Inside the handler, construct and return a `JSONResponse` with a custom status code and detail.
• Choose custom handlers for internal application errors that don't directly map to standard HTTP errors, or when you need highly specific response formats.

Where people lose the point

• ×Trying to use `HTTPException` for internal, non-HTTP-specific errors.
• ×Forgetting to return a `JSONResponse` from the custom handler.
• ×Not explaining the distinction between `HTTPException` (for standard HTTP errors) and custom handlers (for application-specific errors).

What a strong answer covers

• **Use Case:** Implementing Cross-Origin Resource Sharing (CORS) for an API.
• Middleware functions execute for every request, both before the path operation and after the response is generated.
• They wrap the entire application, allowing modification of requests before processing and responses before sending.
• For CORS, a middleware can add appropriate `Access-Control-Allow-*` headers to all responses based on the incoming `Origin` header.
• Conceptually, it's a 'man-in-the-middle' that can inspect and modify requests/responses globally.

Where people lose the point

• ×Confusing middleware with dependencies (middleware operates on the raw request/response, dependencies on parsed data).
• ×Not explaining that middleware runs for *every* request.
• ×Providing a vague use case without concrete implementation details.

What a strong answer covers

• Define an `OAuth2PasswordBearer` instance to extract tokens from the `Authorization` header.
• Create a dependency function (e.g., `get_current_user`) that uses `OAuth2PasswordBearer` to get the token, decodes it, and retrieves the user.
• Create a `/token` endpoint (e.g., `app.post('/token')`) that accepts `OAuth2PasswordRequestForm`.
• In the `/token` endpoint, validate user credentials, create a JWT (e.g., using `jose`), and return it.
• Protect other endpoints by adding the `get_current_user` dependency to their path operation signatures.

Where people lose the point

• ×Confusing `OAuth2PasswordBearer` with the actual token generation logic.
• ×Forgetting the `/token` endpoint where users obtain their JWT.
• ×Not mentioning the use of `jose` or a similar library for JWT encoding/decoding.

What a strong answer covers

• Use `BackgroundTasks` for operations that should run after the HTTP response has been sent to the client.
• Ideal for non-critical, long-running tasks that don't need to block the user's request (e.g., sending emails, logging, data processing).
• Import `BackgroundTasks` from `fastapi`.
• Declare `background_tasks: BackgroundTasks` as a parameter in your path operation function.
• Use `background_tasks.add_task(your_function, *args, **kwargs)` to schedule a task.

Where people lose the point

• ×Confusing background tasks with asynchronous operations within the request-response cycle.
• ×Trying to use `BackgroundTasks` for tasks that *must* complete before the response is sent.
• ×Forgetting to inject `BackgroundTasks` as a dependency into the path operation.

What a strong answer covers

• FastAPI's `app.dependency_overrides` context manager or `app.dependency_overrides_provider` allows replacing dependencies during testing.
• You set `app.dependency_overrides[original_dependency] = new_dependency`.
• This enables mocking external services (e.g., databases, external APIs) without modifying the actual application code.
• Crucial for creating isolated, fast, and reliable unit/integration tests.
• Ensures tests don't have side effects and can run independently.

Where people lose the point

• ×Attempting to mock dependencies directly within the path operation function.
• ×Not understanding that overrides are typically managed within a test client's context.
• ×Failing to explain *why* this is important for testing (isolation, speed, reliability).

What a strong answer covers

• Create separate Python files/modules for different logical groups of endpoints (e.g., `users.py`, `items.py`).
• In each module, instantiate an `APIRouter` (e.g., `router = APIRouter(prefix='/users', tags=['users'])`).
• Define path operations on this `router` object instead of the main `app` object.
• In the main `app.py` file, import these routers and include them using `app.include_router(router_object)`.
• Explain benefits like better organization, modularity, and easier management of prefixes and tags.

Where people lose the point

• ×Defining all endpoints directly on the main `app` object, leading to a monolithic file.
• ×Not using `prefix` or `tags` arguments in `APIRouter` for better organization and documentation.
• ×Failing to explain how `APIRouter` helps in scaling the application structure.

What a strong answer covers

• `lifespan` events (startup and shutdown) allow you to run code when the application starts up and when it shuts down.
• They are defined using an `async with lifespan_context()` block or `@app.on_event('startup')` and `@app.on_event('shutdown')` decorators.
• **Startup Use Cases:** Initializing database connections, loading machine learning models, connecting to message queues, setting up logging.
• **Shutdown Use Cases:** Closing database connections, flushing logs, gracefully shutting down external client connections.
• Ensures resources are properly initialized and cleaned up, preventing resource leaks or data corruption.

Where people lose the point

• ×Confusing `lifespan` events with middleware or background tasks.
• ×Not understanding that these events run only once at application start/stop, not per request.
• ×Failing to provide concrete examples for both startup and shutdown scenarios.