Вопросы для собеседования Python-разработчика

Что хотим услышать

• Внешняя функция принимает func, возвращает обёртку
• Обёртка принимает *args, **kwargs и передаёт их дальше
• Возвращает результат func
• functools.wraps сохраняет имя и docstring
• Время через time.perf_counter, вывод в finally или после вызова
• Код декоратора выполняется при определении, обёртки при каждом вызове

Если ответил, копните глубже

Что хотим услышать

• Сервер приложений создаёт HttpRequest через WSGI или ASGI
• Middleware по списку: безопасность, сессия, CSRF, аутентификация
• URL-резолвер находит вьюху и параметры по urlpatterns
• Вьюха работает с ORM и шаблоном, возвращает HttpResponse
• Ответ проходит middleware в обратном порядке
• Исключения превращаются в 404 или 500 через обработчики

Если ответил, копните глубже

Что хотим услышать

• WHERE фильтрует строки до группировки, HAVING фильтрует группы после
• В WHERE нельзя агрегаты, в HAVING можно
• Порядок: FROM, WHERE, GROUP BY, HAVING, SELECT
• Условия без агрегатов лучше писать в WHERE: меньше строк до группировки
• Пример: WHERE status = 'paid' и HAVING SUM(total) > 10000

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• Называет, что такое n (и m, если входов несколько)
• Считает циклы: вложенные перемножаются, последовательные складываются
• Помнит скрытые циклы: includes, indexOf, slice, sort, spread
• Отдельно оценивает память, включая стек рекурсии
• Сравнивает с ограничениями: при n до 10⁵ O(n²) уже не годится

Если ответил, копните глубже

Что хотим услышать

• граф зависимостей от точки входа
• трансформация: TS, JSX, современный синтаксис, CSS
• резолв пакетов из node_modules
• склейка в чанки, минификация, tree shaking
• хеши в именах для долгого кеша
• dev-сервер с HMR и source maps

Если ответил, копните глубже

Что хотим услышать

• Жёсткая ссылка: ещё одно имя того же inode, равноправное с оригиналом
• Данные живут, пока счётчик ссылок больше нуля и файл никто не держит открытым
• Жёсткую нельзя на каталог и между разными ФС
• Символьная: отдельный файл, внутри которого путь к цели
• Символьная ломается при удалении или переносе цели, зато работает с каталогами и через ФС
• Пример: symlink на текущий релиз current -> releases/42 для атомарного переключения

Если ответил, копните глубже

Что хотим услышать

• Контейнер это процесс (или группа) на ядре хоста, а не отдельная ОС
• Namespaces изолируют видимость: PID, сеть, ФС, hostname, пользователи
• Cgroups ограничивают ресурсы: память, CPU, число процессов
• Файловая система из слоёв образа плюс записываемый слой (overlay2, copy-on-write)
• ВМ эмулирует железо и запускает своё ядро: изоляция сильнее, старт медленнее, накладные расходы больше
• Следствия: общее ядро, быстрый старт, данные в контейнере эфемерны

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• Отдельное виртуальное окружение на проект
• Зависимости в pyproject.toml, разделение на основные и dev
• Lock-файл с точными версиями для воспроизводимости
• Инструмент: uv, Poetry или pip-tools
• Обновления зависимостей контролируемо, проверка уязвимостей
• В Docker ставить по lock-файлу

Если ответил, копните глубже

Что хотим услышать

• Валидация и сериализация по аннотациям через Pydantic
• Автоматическая OpenAPI-документация
• Dependency injection через Depends
• ASGI и async из коробки, но и sync-обработчики в пуле потоков
• Минимум магии, но нет встроенных ORM, админки, миграций
• Сравнение с Django: что брать для какого проекта

Если ответил, копните глубже

Что хотим услышать

• Метрики и трейсы: какой эндпоинт, p95/p99, где время (БД, внешние API, CPU)
• Профилирование: py-spy на живом процессе, cProfile локально
• Типичные причины: N+1 запросы, отсутствие индексов, синхронные вызовы в async, неверные структуры данных
• Исправления: батчи и prefetch, кеш, индексы, перенос тяжёлого в фон
• CPU-bound: алгоритм, встроенные функции, numpy, процессы
• Проверка результата нагрузочным тестом

Если ответил, копните глубже

Что хотим услышать

• Постановка после коммита или outbox
• acks_late и reject_on_worker_lost для гарантии выполнения
• Идемпотентность: проверка состояния, уникальные ключи, ключ идемпотентности во внешних API
• Ретраи только временных ошибок с backoff, лимит попыток
• Лимиты времени, мониторинг очередей и упавших задач
• Передача id, а не объектов; маленькие задачи

Если ответил, копните глубже

Что хотим услышать

• UPDATE создаёт новую версию строки, старая остаётся с xmax; DELETE только помечает версию
• Каждая транзакция видит версии по своему снимку, поэтому чтение не блокирует запись и наоборот
• VACUUM удаляет версии, которые уже никому не видны, обновляет visibility map и замораживает старые строки
• Долгие транзакции и забытые слоты репликации мешают очистке и раздувают таблицы
• Autovacuum настраивают по таблицам: autovacuum_vacuum_scale_factor, лимиты стоимости; мониторинг через pg_stat_user_tables
• HOT-обновления и fillfactor уменьшают нагрузку на индексы

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
• несколько e2e smoke-тестов на критичные пути
• unit-тесты на чистую логику: расчёты, форматирование, утилиты
• интеграционные тесты компонентов и API на новых и изменяемых местах
• тесты в CI как обязательная проверка PR
• регрессионный тест на каждый найденный баг, борьба с флаки

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• Подтвердить: describe (Reason OOMKilled, 137), не путать с Evicted
• Посмотреть график памяти контейнера до падения: резкий пик или постоянный рост (утечка)
• Сравнить лимит с реальным пиком; проверить лимит кучи рантайма (JVM, Node, Go) относительно лимита контейнера
• Учесть всю память процесса: нативные буферы, потоки, page cache в cgroup
• Утечка: профилирование кучи, heap dump, сравнение снимков
• Решение: исправить утечку или ограничить кучу, выставить лимит по данным, requests = limits для памяти

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• ABC: номинальная типизация, нужно наследование или register
• ABC проверяет абстрактные методы при создании экземпляра в рантайме
• Protocol: структурная типизация, достаточно совпадения методов
• Protocol удобен для сторонних классов и фейков в тестах
• @runtime_checkable для isinstance, проверяет только наличие методов

Если ответил, копните глубже

Что хотим услышать

• Lost update: прочитал, изменил, записал
• Атомарные обновления через F-выражения и условные update
• select_for_update в transaction.atomic, порядок блокировок, nowait и skip_locked
• Ограничения в БД: unique, check, как последняя линия защиты
• Идемпотентность и уникальные ключи для повторных запросов
• Побочные эффекты через on_commit

Если ответил, копните глубже

Что хотим услышать

• Deadlock это цикл ожидания: транзакции держат блокировки и ждут друг друга
• PostgreSQL проверяет цикл после deadlock_timeout (1 с по умолчанию) и откатывает одну из транзакций с ошибкой 40P01
• В логе есть оба запроса и тип блокировок; включаю log_lock_waits для долгих ожиданий
• Главное лечение: единый порядок взятия блокировок, короткие транзакции, блокировка заранее через SELECT ... FOR UPDATE в порядке ключа
• Приложение должно уметь повторять транзакцию при 40P01 и 40001

Если ответил, копните глубже