Работали ли с другими ORM кроме Django ORM, например SQLAlchemy

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

Не привязаны ли вы к одному фреймворку. Django ORM прячет соединение, сессию и момент выполнения запроса, SQLAlchemy всё это показывает, поэтому по ответу видно, понимаете ли вы, что происходит под абстракцией.

Как отвечать

Опишите модель работы своими словами: есть слой выражений и есть объектный слой поверх него. Сессия это единица работы, объекты внутри неё отслеживаются, изменения копятся и уходят в базу одним сбросом перед фиксацией, а повторное обращение к той же строке возвращает тот же объект из карты идентичности.

stmt = select(User).where(User.is_active).options(selectinload(User.orders))
users = session.scalars(stmt).all()

Дальше отличия, которые заметны в работе:

• запрос это объект, собираемый по частям, поэтому сложная фильтрация читается лучше цепочки вызовов;
• стратегия подгрузки связи задаётся явно, отдельным запросом по списку ключей или соединением;
• миграции живут отдельно, в Alembic, и автогенерация сверяет описание моделей со схемой;
• есть асинхронный движок и асинхронная сессия, у Django асинхронность появилась позже и устроена иначе.

Уместно упомянуть, что ещё пробовали: Peewee для небольших утилит, Tortoise ORM в асинхронных сервисах, SQLModel как обёртку над тем же ядром.

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

Ждут, что объект будет жить после закрытия сессии. Атрибуты по умолчанию помечаются просроченными после фиксации, обращение к связи снаружи падает, а не тихо делает запрос. Об это первым делом разбивается привычка к Django.

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

Третья: не знать про лавину запросов по связям. Она есть в обеих библиотеках, лечится разными средствами, и умение увидеть её в журнале запросов ценится выше знания названий методов.