Flask interview questions

What a strong answer covers

• Explain that Flask provides core WSGI utilities and routing but leaves choices for databases, ORMs, and other components to the developer.
• Discuss the benefits like flexibility, less boilerplate, and suitability for APIs/smaller apps.
• Mention the "batteries not included" philosophy, requiring developers to choose and integrate components.
• Contrast with full-stack frameworks like Django, which offer more built-in features and opinions.

Where people lose the point

• ×Not knowing what WSGI is or its relevance.
• ×Failing to explain the "why" behind the microframework design (flexibility, choice).
• ×Only stating it's "small" without elaborating on its architectural implications.

What a strong answer covers

• Describe the `@app.route()` decorator as the primary way to define routes.
• Explain how to specify allowed HTTP methods using the `methods` argument (e.g., `methods=['GET', 'POST']`).
• Provide an example of a view function handling both GET (to display a form) and POST (to process form submission) requests.
• Mention using `request.method` inside the view function to differentiate logic based on the HTTP method.

Where people lose the point

• ×Forgetting to import the `request` object when demonstrating method handling.
• ×Not understanding the difference between `request.method` and the `methods` argument in `@app.route()`.
• ×Providing an example that doesn't clearly separate GET and POST logic.

What a strong answer covers

• Define `request` as a global proxy object that holds all incoming request data for the current request.
• Explain `request.form` for accessing data from POST requests (e.g., HTML form submissions).
• Describe `request.args` for accessing query parameters from the URL (e.g., `?key=value`).
• Explain how to access URL variables (dynamic parts of the URL path) by defining them in the route decorator (e.g., `<int:post_id>`) and receiving them as function arguments.

Where people lose the point

• ×Confusing `request.form` with `request.args` or vice-versa.
• ×Not understanding that `request` is a context-local proxy and only available within a request context.
• ×Incorrectly trying to access URL variables via `request.args` or `request.form`.

What a strong answer covers

• Explain that `url_for()` is a function that generates a URL for a given view function.
• Discuss its primary benefit: avoiding hardcoded URLs, which makes applications more robust to URL changes.
• Mention that it correctly handles dynamic URL parts by taking keyword arguments corresponding to the route's variable components.
• Provide an example demonstrating how `url_for()` is used and why it's better than a static string.

Where people lose the point

• ×Not mentioning the robustness benefit against URL changes.
• ×Incorrectly using `url_for()` with a string literal URL instead of a view function name.
• ×Failing to explain how `url_for()` handles dynamic parameters.

What a strong answer covers

• Explain Jinja2 as Flask's default templating engine, allowing dynamic content generation in HTML.
• Describe the `render_template()` function used in Flask view functions to load and render templates.
• Show how to pass Python variables from the view function to the template using keyword arguments in `render_template()`.
• Mention basic Jinja2 syntax for displaying variables (`{{ var }}`) and control flow (`{% if %}`, `{% for %}`).

Where people lose the point

• ×Confusing Jinja2 syntax with standard Python syntax.
• ×Not understanding the role of `render_template()` in bridging Python logic and HTML.
• ×Failing to explain how variables passed to `render_template` become accessible in the template.

What a strong answer covers

• Explain the concept of a base template (`base.html`) that defines common page structure and `{% block %}` tags.
• Describe how child templates use `{% extends 'base.html' %}` to inherit the base layout.
• Explain how child templates can then override or append to specific blocks defined in the base template.
• Discuss advantages such as code reuse, maintaining a consistent look and feel across the application, and easier maintenance.

Where people lose the point

• ×Not understanding the `extends` and `block` relationship in Jinja2.
• ×Creating redundant HTML across multiple templates instead of leveraging inheritance.
• ×Failing to articulate the benefits of consistency and maintainability.

What a strong answer covers

• Explain that Flask sessions are client-side by default, storing data in a cryptographically signed cookie on the user's browser.
• Describe the `session` object as a dictionary-like interface to store user-specific data across requests.
• Emphasize that the `SECRET_KEY` is crucial for cryptographic signing of the session cookie, preventing tampering and ensuring data integrity.
• Clarify that the `SECRET_KEY` signs the data, but does not encrypt it by default, meaning session data is readable but not modifiable by the client.

Where people lose the point

• ×Believing `SECRET_KEY` encrypts session data, rather than just signing it.
• ×Not understanding that session data is stored on the client-side (in a cookie).
• ×Forgetting to mention the importance of a strong, unique, and securely stored `SECRET_KEY`.

What a strong answer covers

• Define Blueprints as a way to organize related functionality into modular, reusable components within a Flask application.
• Explain that blueprints can define their own routes, templates, static files, and error handlers, independent of the main application.
• Discuss benefits such as improved code organization, better maintainability, and enhanced reusability of components across projects.
• Provide a high-level example of how to create a blueprint and register it with the main Flask application instance.

Where people lose the point

• ×Not understanding that blueprints are registered with the main app, not standalone applications.
• ×Confusing blueprints with Python modules without explaining their specific Flask-related functionality.
• ×Failing to articulate the benefits for application scalability and team collaboration.

What a strong answer covers

• Define the **application context** as making `current_app` available, pushed when the Flask application starts or for CLI commands.
• Define the **request context** as making `request`, `session`, and `g` available, pushed for each incoming web request.
• Explain that both contexts are necessary for Flask's global proxy objects to function correctly, as they provide access to context-specific data.
• Discuss their lifecycle: application context can exist longer, while request context is tied to a single HTTP request.

Where people lose the point

• ×Confusing the two contexts or their respective lifecycles.
• ×Not understanding the concept of context locals and why they are needed for global proxies.
• ×Incorrectly assuming `request` or `session` are always available outside of a request context.

What a strong answer covers

• Explain using the `@app.errorhandler()` decorator (or `blueprint.errorhandler()`) to register a function for specific HTTP status codes or exceptions.
• Show how the error handler function takes the error object as an argument.
• Demonstrate returning a rendered template along with the appropriate HTTP status code (e.g., `render_template('404.html'), 404`).
• Discuss the importance of providing user-friendly and informative error pages.

Where people lose the point

• ×Not returning the correct HTTP status code along with the error page.
• ×Forgetting to register the error handler with `@app.errorhandler()` or `blueprint.errorhandler()`.
• ×Only handling generic exceptions without specific HTTP status codes.

What a strong answer covers

• Explain that Flask automatically serves files from a `static` folder located in the application's root directory by default.
• Describe how to link to static files in Jinja2 templates using `url_for('static', filename='path/to/file.css')`.
• Mention that `url_for('static', ...)` generates the correct URL path to the static asset.
• Briefly note that for production deployments, it's common practice to use a dedicated web server (like Nginx or Apache) to serve static files directly for performance.

Where people lose the point

• ×Hardcoding static file paths in templates instead of using `url_for('static', ...)`.
• ×Not understanding the default `static` folder convention.
• ×Confusing Flask's static file serving with a production-grade static file server.

What a strong answer covers

• Define WSGI (Web Server Gateway Interface) as a standard Python interface between web servers (e.g., Nginx, Apache) and Python web applications.
• Explain that Flask applications are WSGI-compliant, meaning they adhere to this standard.
• Discuss how a WSGI server (like Gunicorn or uWSGI) acts as an intermediary, receiving requests from a front-end web server and passing them to the Flask application.
• Emphasize that Flask's built-in development server is not suitable for production, and a WSGI server is required for robust, scalable deployment.

Where people lose the point

• ×Confusing Flask itself with a WSGI server.
• ×Not understanding the role of a front-end web server (Nginx/Apache) in conjunction with a WSGI server.
• ×Suggesting Flask's development server is adequate for production.

What a strong answer covers

• Explain that Flask extensions are separate Python packages that provide pre-built integrations for common web development tasks.
• Discuss how they simplify development by reducing boilerplate code, promoting best practices, and offering robust solutions for complex features.
• Provide Flask-WTF as an example: it simplifies form creation, validation, and CSRF protection by integrating WTForms.
• Briefly mention other examples like Flask-SQLAlchemy (database ORM) or Flask-Login (user session management).

Where people lose the point

• ×Not understanding that extensions are separate, installable packages.
• ×Describing a core Flask feature as an extension.
• ×Failing to explain *how* an extension simplifies a specific task.

What a strong answer covers

• Explain `g` as a global object (short for "global") that is specific to the current request context.
• Describe its purpose: to store data that needs to be accessed by multiple functions or parts of the application during a single request.
• Provide concrete examples of its use, such as storing a database connection, the current authenticated user object, or other request-specific resources.
• Emphasize that its lifecycle is tied to the request context, meaning data stored in `g` is cleared after the request ends.

Where people lose the point

• ×Confusing `g` with the `session` object (which persists across requests).
• ×Using `g` to store application-wide data instead of data specific to the current request.
• ×Not understanding that `g` is a context-local proxy.

What a strong answer covers

• Mention Flask's built-in `app.test_client()` for making simulated HTTP requests to the application without running a live server.
• Explain how to set up a testing environment, often using an in-memory database (e.g., SQLite) to ensure tests are isolated and fast.
• Discuss testing view functions, route responses (status codes, content), and interactions with the database.
• Suggest using a testing framework like `pytest` or `unittest` for structuring tests and assertions.

Where people lose the point

• ×Not knowing about `app.test_client()` as the primary tool for integration testing Flask apps.
• ×Focusing only on unit testing helper functions rather than the web interaction.
• ×Failing to mention the importance of an isolated test database.