Какие фреймворки использовали кроме Django

Что проверяют

Насколько широк ваш опыт за пределами одного инструмента и понимаете ли вы, чем синхронный мир WSGI отличается от асинхронного ASGI. Обычно следом просят сравнить FastAPI с Django REST Framework или рассказать, как вы работали с асинхронностью.

Как отвечать

Вопрос про ваш опыт, поэтому назовите один или два фреймворка, с которыми действительно работали, и для каждого: задача, почему выбрали, что понравилось и что мешало. Нужны свои примеры и свои цифры: сколько сервисов, какая нагрузка, что именно вы сделали. Для опоры полезно знать карту:

• FastAPI: ASGI, построен на Starlette и Pydantic. Валидация и сериализация по аннотациям типов, OpenAPI-документация генерируется сама, зависимости внедряются через Depends;
• Flask: WSGI-микрофреймворк, маленькое ядро плюс расширения (Flask-SQLAlchemy, Flask-Login). Разрешает async def во вьюхах, но остаётся WSGI и настоящей асинхронности не даёт, для неё есть Quart с тем же API;
• Litestar, Sanic, aiohttp: асинхронные альтернативы, aiohttp заодно HTTP-клиент;
• Tornado и Pyramid: живы, но в новых проектах редки, чаще встречаются при поддержке старого кода.

Хорошо добавить инструменты вокруг фреймворка: SQLAlchemy 2.0 с асинхронным движком, Alembic для миграций, Celery для фоновых задач, Uvicorn или Gunicorn с воркерами Uvicorn для запуска.

Если кроме Django опыта нет, так и скажите. Сильнее прозвучит «в продакшене работал с Django и DRF, FastAPI пробовал в учебном сервисе, и вот чем он отличается», чем пересказ документации трёх фреймворков.

Где спотыкаются

Вызывают блокирующий код внутри async def в FastAPI, например синхронный драйвер базы или requests. Это останавливает event loop для всех запросов, а обработчики, объявленные через обычный def, FastAPI сам уводит в пул потоков.

Перечисляют фреймворки списком без единого факта из реального проекта. На первом же уточнении ответ рассыпается.

Называют «тысячи пользователей» и не могут объяснить, откуда цифра, как её мерили и что было узким местом.