На собеседовании Python Backend проверяли кандидата без прежней коммерческой роли Python-разработчика. Основные темы — безопасность API, REST, базы данных, очереди и устройство Python. Компания и заявленный уровень в открытой части не названы, поэтому мы оцениваем только показанные технические ответы.
Чем аутентификация отличается от авторизации
Аутентификация отвечает на вопрос «кто вы?», авторизация — «что вам разрешено?». Логин и пароль могут подтвердить личность, после чего сервер выдаёт сессию или токен. При каждом защищённом запросе приложение проверяет данные токена и права на конкретное действие.
Bearer-токен обычно передают в заголовке Authorization. JWT — один из форматов: он содержит набор утверждений и может быть подписан. Подпись защищает целостность, но не скрывает содержимое. Поля exp, iss и aud определены в RFC 7519.
Типичная ошибка. Называть получение токена «авторизацией» и не объяснять проверку прав.
Как лучше. Развести три шага: подтвердили личность, получили токен, проверили разрешение на ресурс.
Коротко: аутентификация подтверждает личность, авторизация проверяет права, а токен переносит данные, необходимые для этих проверок.
Что означает REST в практическом API
REST — архитектурный стиль, а не синоним JSON поверх HTTP. В ответе полезно назвать ресурсы с устойчивыми адресами, единый интерфейс методов, отсутствие серверного состояния клиентской сессии и возможность кэширования там, где это допустимо.
Для ресурса /orders/42 можно ожидать GET для чтения, PUT для полной замены, PATCH для частичного изменения и DELETE для удаления. Но конкретный контракт задаёт API: метод сам по себе не объясняет обязательные поля и коды ошибок. Семантика HTTP-методов описана в RFC 9110.
На уточняющий вопрос приводите не определение, а сценарий: какой ресурс меняем, что отправляем, какой статус и тело получаем, что случится при повторе.
Коротко: REST-ответ оценивают по ресурсу, методу, статусу и контракту, а не по наличию JSON.
Как защититься от SQL-инъекции
SQL-инъекция возникает, когда пользовательский ввод склеивают с текстом запроса и база воспринимает данные как SQL-код. Главная защита — параметризованные запросы. OWASP рекомендует prepared statements, потому что они отделяют структуру запроса от значений.
import sqlite3
def find_user(connection: sqlite3.Connection, email: str):
# Знак вопроса — место для значения, а не часть SQL-строки пользователя.
query = "SELECT id, email FROM users WHERE email = ?"
# Драйвер передаст email отдельно и не выполнит его как SQL-команду.
return connection.execute(query, (email,)).fetchone()Валидация всё равно нужна для бизнес-правил, но она не заменяет параметры. Также применяем минимальные права пользователя базы: приложению не нужен доступ к административным операциям.
Коротко: параметризованный запрос отделяет SQL-код от пользовательских данных и закрывает основной путь SQL-инъекции.
Что нужно объяснить про очередь сообщений
Очередь или брокер развязывает отправителя и обработчик. Producer публикует сообщение, consumer читает его и подтверждает обработку. Если обработчик упал до подтверждения, сообщение может прийти повторно. Поэтому операция должна быть идемпотентной: повтор не создаёт второй платёж или заказ.
Сильный ответ включает:
- зачем синхронный HTTP-вызов заменили сообщением;
- что находится в событии и как меняется его схема;
- когда сообщение подтверждается;
- сколько раз выполняется повтор;
- куда попадают необрабатываемые сообщения;
- как команда видит задержку очереди.
Необязательно администрировать Kafka или RabbitMQ, чтобы уверенно объяснить свой контракт и границу ответственности.
Коротко: очередь сообщений требует не только producer и consumer, но и правил подтверждения, повторов и идемпотентности.
Как отвечать про коллекции Python и GIL
Python-список в CPython хранит ссылки на объекты. Поэтому рядом могут находиться число, строка и пользовательский объект: сами значения лежат отдельно, а ссылки имеют одинаковый размер. Словарь сопоставляет хешируемые ключи значениям; требования к ключам описаны в модели данных Python.
GIL в стандартной GIL-сборке CPython позволяет одному потоку одновременно исполнять Python-байткод. Потоки всё равно полезны при ожидании сети и файлов, потому что интерпретатор может переключиться во время блокирующей операции. Для тяжёлых вычислений используют процессы, нативные библиотеки или сборку с другой моделью исполнения. Актуальные ограничения собраны в документации threading.
Коротко: сильный Python-ответ связывает устройство коллекции или GIL с выбором инструмента для конкретной нагрузки.
Итог: получил бы кандидат оффер
Фактический результат в открытой записи не сообщается. По доступной части кандидат мог продолжить отбор: он поддерживал разговор по backend-темам и не терялся при уточнениях. Но для уверенного оффера ответам не хватало точности в различии аутентификации и авторизации, устройстве токенов и объяснении GIL.
Наш вывод — данных недостаточно. Для позиции начинающего разработчика показанная база выглядит рабочей, а для уверенного middle понадобились бы более глубокие примеры из реального проекта и точные ответы на вопросы о сбоях.
Коротко: финальный результат не раскрыт; показанной базы достаточно для продолжения диалога, но не для уверенного оффера.
Чек-лист подготовки
- Различаю аутентификацию, авторизацию и сессию.
- Могу описать контракт одного REST-метода.
- Пишу параметризованный SQL-запрос без подсказки.
- Объясняю повторы и идемпотентность consumer.
- Выбираю потоки или процессы по типу нагрузки.
- Подтверждаю каждый навык настоящим проектом.
Источники
частые вопросы
Короткие ответы
Можно ли пройти собеседование Python Backend без коммерческого опыта?
Можно пройти технический этап, если вы умеете объяснить базовые механизмы и подтвердить их собственными проектами. Итог зависит от требований к уровню и качества практики.
Что повторить перед первым backend-собеседованием?
Повторите HTTP и REST, аутентификацию, SQL и транзакции, очереди, коллекции Python, исключения, GIL, asyncio и устройство своего учебного проекта.
Нужно ли придумывать коммерческий опыт?
Нет. Сильнее подробно показать настоящие проекты, личный вклад и рабочий процесс. Выдуманная история обычно ломается на вопросах об ограничениях и результатах.
Получил ли кандидат оффер?
В доступной записи результат работодателя не назван, поэтому утверждать, что оффер был получен, нельзя.
