Как использовали очереди?

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

Вопрос про опыт, но за ним стоит техника: понимаете ли вы, зачем очередь в системе и что она ломает. Интервьюер ждёт конкретный случай, а следом спросит, что будет, если воркер упадёт посреди задачи, и как вы избегаете повторной обработки.

Как отвечать

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

• queue.Queue: потокобезопасная очередь внутри одного процесса, классический producer/consumer на потоках;
• asyncio.Queue: то же для корутин, но не потокобезопасна. maxsize даёт обратное давление: put ждёт, пока освободится место;
• multiprocessing.Queue: передача между процессами через pickle, всё содержимое должно сериализоваться;
• Celery, RQ, Dramatiq: фоновые задачи между сервисами. В Celery различайте брокер (RabbitMQ или Redis), куда кладутся задачи, и result backend, где лежат результаты, это разные роли;
• RabbitMQ, Kafka: обмен событиями между сервисами, Kafka ещё и хранит лог и позволяет перечитать его.

Дальше расскажите про надёжность: подтверждение после выполнения (acks_late=True в Celery), повторы через autoretry_for с retry_backoff, отдельная очередь для задач, которые падают раз за разом, и идемпотентность, потому что доставка «хотя бы один раз» означает дубли.

Если опыта с брокерами не было, так и скажите и опишите то, что было: пул потоков с queue.Queue или asyncio.Queue в парсере. Затем объясните, как перенесли бы это на Celery. Честный небольшой пример лучше чужой истории.

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

Называют Redis «хранилищем задач» и путают брокер с result backend. Первый же вопрос про настройку это вскроет.

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

Приносят круглые проценты вроде «на 50% больше заказов» без способа замера. Интервьюер спросит, как измеряли, и ответ развалится.