Вернуться в видеотеку

Python: мок-собеседование с разработчиком Avito

Публичное мок-техническое собеседование на Python Backend. Кандидат отвечает на вопросы о типах и хешируемости в Python, словарях, асинхронности и GIL, Redis, Kafka, HTTP и RPC; в конце получает подробную обратную связь и оценку уровня Middle/Middle+.

Источник: ШОРТКАТ — менторская программа

Открыть на YouTube

Коротко о видео

Интервьюер проводит мок-собеседование для разработчика с недавним опытом Python, последовательно проверяя базовые структуры данных, устройство словарей, асинхронный ввод-вывод, потоки и GIL. Затем разговор переходит к Redis, обработке больших файлов, очередям и AWS Lambda, порядку событий в Kafka, HTTP и RPC/gRPC. Часть ответов кандидат формулирует неточно, а интервьюер уточняет подходы и в финале отмечает сильную базу, но рекомендует глубже изучить персистентность Redis, Python-теорию, Kafka и RPC. Итоговая оценка — стабильный Middle с потенциалом Middle+.

Затронутые темы

Что взять на заметку

  • Ключ словаря Python должен быть хешируемым: tuple подходит только тогда, когда хешируемы все его элементы.
  • Асинхронность особенно полезна для I/O-bound задач; CPU-bound обработку в CPython обычно выносят в процессы или фоновые воркеры, поскольку GIL ограничивает параллельное исполнение Python-байткода потоками.
  • При рассказе о Redis важно явно обозначать его роль: кэш или источник данных, время жизни записей, настройки персистентности и репликации.
  • Реплики Redis помогают масштабировать чтение, а шардирование — распределять данные и нагрузку на запись; это разные решения для разных узких мест.
  • Kafka сохраняет порядок записей внутри одной партиции, а не всего топика. Стабильный ключ, например user_id, направляет связанные события в одну партицию.
  • POST сам по себе не защищает персональные данные: нужны HTTPS, осторожное логирование и отказ от чувствительных данных в URL-параметрах.
  • RPC/gRPC выбирают по контракту и характеру межсервисного взаимодействия, а не из предположения, что он всегда быстрее REST; gRPC обычно использует Protobuf поверх HTTP/2.

Рекомендуем посмотреть