Это собеседование на Python Backend-позицию в Группе Астра. Разговор начинается с опыта кандидата и быстро переходит к базам данных, тестированию, API, очередям и архитектуре микросервисов. Личные данные участников для разбора не нужны; важнее увидеть, где ответ подтверждён практикой, а где знакомое слово остаётся без механизма.
Когда использовать ORM, а когда писать SQL вручную?
Короткий ответ: ORM удобен для типовых операций с доменными объектами, а SQL нужен для сложных выборок, тонкой оптимизации и диагностики.
Сильный кандидат не противопоставляет эти подходы. Он объясняет, что ORM сокращает повторяющийся код и связывает модель приложения с таблицами. При этом разработчик обязан понимать запрос, который ушёл в базу: какие получились JOIN, сколько строк читается, используются ли индексы и не возникла ли проблема N+1. В документации SQLAlchemy ORM описан как высокий уровень над SQL-конструкциями, а не замена знания реляционной базы.
На интервью полезно привести пример: обычный CRUD оставить ORM, сложный агрегирующий отчёт собрать через SQLAlchemy Core или проверенный параметризованный SQL, затем посмотреть план выполнения.
Что на самом деле означает 100% покрытия тестами?
Короткий ответ: это означает, что измеритель увидел выполнение всех учитываемых строк или ветвей. Это не доказывает правильность проверок.
Тест может выполнить строку и ничего важного не проверить. Поэтому ответ продолжают сценариями: unit-тесты изолируют бизнес-правила, интеграционные проверяют работу с БД и брокером, end-to-end проходят важный путь через систему. Для критичной функции нужны нормальный случай, границы, ошибки и повтор операции.
Вместо хвастовства процентом покажите связь теста с риском. Например: «Для расчёта прав доступа проверяем роли, отсутствие разрешения, конфликт правил и сохранение результата». Покрытие помогает найти непроверенные участки, но решение о достаточности принимает команда.
Что должно входить в документацию API?
Короткий ответ: контракт запросов и ответов удобно генерировать из OpenAPI, а смысл операций, ошибки и ограничения нужно дополнять вручную.
FastAPI строит OpenAPI-схему из маршрутов и моделей и отдаёт интерактивные интерфейсы Swagger UI и ReDoc — это показано в официальном описании возможностей. Но список полей не объясняет, когда операция допустима, какие права нужны, идемпотентен ли запрос и что делать после частичного сбоя.
Хорошая документация содержит рабочий пример, коды ошибок, правила повторной отправки, версионирование и владельца контракта. Её проверяют вместе с кодом, иначе автогенерация честно опубликует неполную модель.
Можно ли назвать Redis брокером сообщений?
Короткий ответ: сначала нужно уточнить механизм. Redis Pub/Sub и Redis Streams решают разные задачи и дают разные гарантии.
Pub/Sub доставляет сообщение только подключённым подписчикам и работает по модели at-most-once: после потери соединения сообщение не восстановить. Redis прямо указывает это ограничение. Streams хранит записи как добавляемый журнал, поддерживает группы потребителей, подтверждения и повторное чтение.
Поэтому на интервью называем конкретику: как хранится сообщение, кто подтверждает обработку, возможна ли повторная доставка, как устроены retries и что происходит с ошибочной задачей. Фраза «использовали Redis» без этих деталей почти ничего не говорит об архитектуре.
Чем микросервис отличается от части монолита?
Короткий ответ: микросервис выделен вокруг бизнес-возможности и может развиваться и выпускаться достаточно независимо.
Отдельный процесс, язык или база — полезные сигналы, но не универсальное определение. Классическое описание microservice architecture подчёркивает независимо развёртываемые сервисы, бизнес-границы и децентрализованное управление. Если изменение одного компонента требует общего релиза, общей схемы данных и согласования со всеми командами, реальная независимость невелика.
В ответе стоит назвать цену: сетевые сбои, наблюдаемость, согласованность данных, версионирование контрактов и более сложная эксплуатация. Микросервисы — не автоматическое улучшение, а обмен локальной простоты на независимость частей системы.
Как правильно объяснить принцип подстановки Лисков?
Короткий ответ: объект подтипа должен заменять объект базового типа, не ломая ожидаемое поведение программы.
Наследник не должен усиливать предусловия, ослаблять обещанный результат или менять смысл операций неожиданным способом. Если базовый интерфейс обещает сохранить документ, реализация не может молча отказываться от части допустимых документов. Формальный принцип относится к абстракциям и подтипам; переносить его напрямую на «два микросервиса должны быть одинаковыми» неверно.
На архитектурном уровне похожая практическая мысль возникает у совместимых реализаций контракта, но это уже отдельное рассуждение. Сначала дайте точное объектно-ориентированное определение, затем аккуратно проведите аналогию.
Получил ли кандидат оффер?
Подтверждённый факт: запись завершается обсуждением условий, зарплатных ожиданий, проверки службы безопасности и срока обратной связи. Решение компании в неё не попало. Автор называет собеседование успешным, однако это не равно документально подтверждённому офферу.
Наша оценка: кандидат уверенно обсуждает производственный опыт и доходит до подробного знакомства с продуктом и командой. Это похоже на положительно пройденный верхнеуровневый этап, но технические определения местами требуют большей точности. Для следующей попытки мы бы отдельно отработали гарантии брокеров, признаки независимости сервисов и LSP в исходном смысле.
Проверить такие ответы вслух можно в тренажёре собеседований ЮНИКОД: цель не заучить определение, а выдержать два-три уточнения на механизм и ограничения.
Источники
частые вопросы
Короткие ответы
Нужно ли Python-разработчику знать SQL, если проект использует ORM?
Да. ORM удобен для типовых операций, но разработчику нужно читать сгенерированные запросы, понимать JOIN, индексы, транзакции и уметь диагностировать медленный или неверный SQL.
Является ли отдельная база обязательным признаком микросервиса?
Самостоятельное владение данными поддерживает независимость сервиса, но один признак нельзя оценивать отдельно. Важны бизнес-граница, независимый жизненный цикл, интерфейс и возможность менять сервис без общего релиза системы.
Получил ли кандидат оффер?
Запись заканчивается обещанием обратной связи. Название ролика называет собеседование успешным, но подтверждённого решения компании в материале нет, поэтому заявлять об оффере нельзя.
