Расскажите про сложные сервисы, которые реализовывали

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

Что вы называете сложным: объём бизнес-логики, нагрузку, количество интеграций или цену ошибки. Это сильный сигнал об уровне. Дальше проверяют, умеете ли вы описать архитектуру словами, назвать компромисс и объяснить, почему выбрали одно решение, а не соседнее.

Как отвечать

Возьмите один сервис и доведите рассказ до деталей, остальные упомяните строкой.

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

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

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

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

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

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