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

Пример сильного ответа

Список изменяемый, кортеж — нет: после создания элементы tuple не поменять, зато он хешируемый, поэтому годится как ключ словаря или элемент множества. Кортеж занимает меньше памяти и создаётся быстрее, и это ещё сигнал читателю кода: набор фиксирован. Список беру, когда данные копятся и меняются — очередь задач, буфер, результаты запроса. Кортеж — для константных наборов, координат, полей записи, распаковки аргументов. В одном сервисе справочник из двенадцати неизменяемых статусов заказа хранился кортежем, и это защищало от случайной правки, а ревью кода шло заметно быстрее.

• Чётко разделены изменяемость, хешируемость и производительность.
• Есть практический пример с пользой для команды.
• Показан критерий выбора, а не только определение.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

GIL — глобальная блокировка интерпретатора: в каждый момент байт-код исполняет только один поток, даже на многоядерной машине. Поэтому потоки ускоряют задачи, которые ждут ввод-вывод: сеть, диск, база данных. Для нагруженных вычислений на процессоре потоки почти не дают прироста — там нужны процессы или C-расширения, которые отпускают блокировку. На практике у меня был сервис с сорока тысячами HTTP-запросов в сутки к внешнему API: на пуле из шестнадцати потоков время обработки пачки сократилось примерно в восемь раз по сравнению с последовательным обходом. Для тяжёлых расчётов выбираю multiprocessing или асинхронный ввод-вывод.

• Верно объяснена суть ограничения без лишней теории.
• Показано, какие задачи от него страдают и какие нет.
• Приведён личный измеримый результат.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Обычная функция считает всё сразу и возвращает результат, а генератор возвращает итератор и отдаёт значения по одному через yield, приостанавливаясь на каждом. Состояние сохраняется между вызовами, а элементы не хранятся в памяти целиком — это ключевое преимущество на больших объёмах. Ещё генераторы ленивы: вычисление идёт только по запросу, поэтому их удобно связывать в конвейеры, а генераторные выражения экономят и код, и память. В проекте лог размером около двадцати гигабайт обрабатывался построчно генератором, и процесс стабильно укладывался в лимит памяти, тогда как вариант со списком падал.

• Сравнение построено на памяти и моменте вычисления.
• Показано практическое применение в конвейере обработки.
• Реальный результат с цифрами и последствием.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Декоратор — функция, которая принимает другую функцию и возвращает обёртку, добавляя поведение без правки исходного кода. Работает за счёт того, что функции в Python являются объектами первого класса, а functools.wraps сохраняет метаданные. Применяю их для логирования, замеров времени, кеширования, проверки прав и повторных попыток при сетевых ошибках. В проекте был декоратор с таймаутом и тремя ретраями на внешние вызовы: количество падений фоновых задач из-за нестабильного API снизилось примерно на семьдесят процентов, а дублирование обработки ошибок в коде почти исчезло.

• Есть и определение, и механизм работы.
• Перечислены типовые сценарии применения.
• Результат подтверждён цифрой и устранением дублирования.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Python управляет памятью автоматически: объекты живут в приватной куче, а освобождает их сборщик мусора. Основной механизм — подсчёт ссылок: как только счётчик падает до нуля, память возвращается сразу. Циклические ссылки счётчик не ловит, поэтому работает дополнительный сборщик по поколениям, где молодые объекты проверяются чаще. Плюс пулы мелких объектов и арены снижают нагрузку на аллокатор. На практике слежу за утечками профилировщиком и слабыми ссылками: в одном сервисе такая оптимизация снизила потребление памяти примерно на треть при том же трафике.

• Названы оба механизма и их различие.
• Упомянуты аллокаторы — признак глубокого понимания.
• Есть личный результат с измеримым эффектом.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Для меня разница в том, что поверхностная копия создаёт новый контейнер, но вложенные объекты остаются общими, а глубокая рекурсивно пересобирает всю структуру. На практике мне приходилось сталкиваться с кэшем конфигураций на несколько сотен вложенных словарей: из-за поверхностного копирования правки одного запроса протекали в остальные. Моя задача была развести состояние по запросам. Решение — глубокое копирование через модуль copy на уровне сборочных функций и ручное копирование только нужных уровней на горячем пути. В итоге инциденты с «протекающими» настройками ушли, а накладные расходы по времени ответа остались в пределах 10–15%.

• Показано понимание вложенности и общих ссылок
• Ответ подкреплён реальным кейсом с числами
• Видно знание компромисса между надёжностью и скоростью

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Обычно я иду от ресурса и его жизненного цикла. Сначала согласовываю имя сущности во множественном числе, набор методов, коды ответов и единый формат ошибки. Дальше — пагинация, фильтры, сортировка, версия в пути, идемпотентность для повторных запросов и схема в OpenAPI, чтобы клиенты генерировали SDK автоматически. Важная часть — валидация на входе и разграничение прав. В одном проекте по такому чек-листу получилось 14 эндпоинтов для новой сущности, интеграция у фронтенда заняла два дня вместо обычной недели, а число уточняющих вопросов по контракту снизилось почти вдвое.

• Ответ строится от ресурса и контракта
• Есть конкретные метрики по срокам интеграции
• Упомянуты OpenAPI, версионирование и идемпотентность

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Выбор для меня — это вопрос задач, а не вкуса. Django даёт готовый набор «всё в комплекте»: ORM, миграции, админку, аутентификацию, поэтому для монолита с админкой и большим объёмом CRUD он экономит недели. FastAPI легче, асинхронный по умолчанию, со схемами Pydantic и автодокументацией, поэтому выигрывает в микросервисах, высоконагруженных API и рядом с ML-моделями. На одном проекте перенос части эндпоинтов на FastAPI дал рост пропускной способности примерно в 2,5 раза на операциях ввода-вывода. Смотрю ещё на команду: если опыта с async нет, польза от FastAPI будет меньше.

• Сравнение идёт по критериям, а не по хайпу
• Есть метрика прироста производительности
• Учтён фактор зрелости команды

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом я смотрю на статистику по запросам: pg_stat_statements или медленный лог, чтобы понять, какой запрос даёт основную нагрузку по суммарному времени, а не только по длительности одного вызова. Дальше — EXPLAIN ANALYZE: где последовательное сканирование, где неподходящий план, где N+1 из ORM. Действия по ситуации: составной индекс, переписывание запроса, отказ от лишних джойнов, select_related и prefetch_related, кэш или предрасчёт. На одном проекте страница открывалась около двух секунд: после составного индекса и переноса агрегата в фоновый расчёт время ответа стало около 200 миллисекунд.

• Показан порядок диагностики от статистики к плану
• Перечислены типовые причины и способы лечения
• Есть измеримый результат в цифрах

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Транзакция — это набор операций, который либо применяется целиком, либо откатывается, и это спасает от частично записанных данных. Уровни изоляции закрывают разные аномалии: грязное чтение, неповторяющееся чтение, фантомы и потерянные обновления. Чем выше уровень, тем меньше аномалий и тем больше блокировок и откатов. На практике я обычно начинаю с уровня по умолчанию и повышаю его точечно, только для критичных операций, плюс явные блокировки или оптимистичная версия записи. В сервисе бронирования после перевода спорных операций на более строгий уровень и добавления проверок версии двойные брони сократились с нескольких десятков в месяц до нуля.

• Ясно объяснена суть транзакции
• Показаны аномалии и компромисс с блокировками
• Есть практический результат с числом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Мой подход такой: всё, что не нужно пользователю прямо в ответе — письма, отчёты, тяжёлые вычисления — уходит в очередь. Обычно это Celery или arq, брокер — Redis или RabbitMQ, а статус храню отдельно, чтобы задача была идемпотентной и переживала повтор. Обязательно настраиваю ретраи с растущей задержкой, dead letter queue и метрики по длине очереди. В одном сервисе такая схема убрала из HTTP-обработчика операции длиной восемь секунд, и средний ответ API стал около двухсот миллисекунд. Плюс периодические задачи запускаю по расписанию, а тяжёлые вычисления держу в отдельном пуле воркеров, чтобы они не мешали быстрым.

• Показан конкретный стек и архитектура очереди
• Есть числа: восемь секунд и двести миллисекунд
• Упомянуты идемпотентность, ретраи и мониторинг

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Смотрю на характер нагрузки. Если это сетевой ввод-вывод — запросы к внешним API, база, сокеты — беру async/await: одно ядро спокойно держит тысячи одновременных соединений, и на одном сервисе переход на асинхронный клиент поднял пропускную способность примерно втрое при том же железе. Если задача упирается в процессор — парсинг, шифрование, расчёты — async не помогает, там нужны отдельные процессы или вынос в очередь. Для простого CRUD с небольшой нагрузкой синхронный код понятнее и дешевле в поддержке. И отдельно слежу, чтобы внутри корутины не осталось блокирующих вызовов: их выношу в threadpool.

• Чёткий критерий выбора по типу нагрузки
• Есть результат: рост пропускной способности втрое
• Названа типичная ошибка — блокирующий вызов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом делаю сервис stateless: состояние живёт в базе, кэше или брокере, тогда инстансы масштабируются горизонтально за балансировщиком. Дальше снимаю нагрузку с базы: кэш горячих данных, пул соединений, реплики для чтения. Всплески сглаживаю очередью — запрос превращается в задачу, и это работает как backpressure, вместо того чтобы сервис падал. Обязательно ограничение скорости и продуманная деградация: при перегрузке отключаю второстепенные функции, но основной сценарий живёт. Перед запуском прогоняю нагрузочный тест. В одном проекте после такой схемы пик в десять раз выше обычного проходил без ошибок и без ручного вмешательства.

• Системный ответ: stateless, кэш, очередь, деградация
• Есть пример пиковой нагрузки в десять раз
• Показано понимание backpressure

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Держу пирамиду. Внизу — юнит-тесты на бизнес-логику и чистые функции, их много и они быстрые. Выше — интеграционные: реальная база и брокер в контейнерах, проверяю репозитории, миграции и транзакции, потому что моки здесь только вредят. Дальше — тесты API через клиент: коды ответов, валидация, права доступа. Отдельно контрактные тесты с внешними сервисами и немного нагрузочных. На критичных модулях держу покрытие около восьмидесяти процентов, но гонюсь не за цифрой, а за тем, чтобы регрессии ловились в CI, а не в production. И тесты стараюсь писать так, чтобы они не зависели от порядка запуска.

• Показана пирамида тестов и роль каждого уровня
• Названо покрытие 80% на критичных модулях
• Упомянуты CI и независимость тестов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Исключения ловлю на границах приложения: в слое API — чтобы вернуть понятный ответ и не отдать наружу трейсбек, в фоновых задачах — чтобы одна упавшая задача не роняла воркер. Внутри логика пробрасывает ошибки наверх, без глушения. Логи — только структурные, в JSON, с уровнем, идентификатором запроса и пользователем, чтобы по одному идентификатору собиралась вся цепочка. Секреты и персональные данные маскирую. Всё уходит в централизованное хранилище и в систему отслеживания ошибок, а алерты ставлю на метрики — долю ошибок и задержки, а не на каждую строчку в логе. Транзиентные сбои закрываю ретраями.

• Обработка ошибок разделена по границам сервиса
• Структурные логи с request id и маскировкой
• Алерты по метрикам, а не по каждому логу

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Идемпотентность — это свойство операции давать один и тот же результат при повторном выполнении. Для API это значит, что повторный запрос из-за таймаута не создаст вторую заявку, а для очередей — что повторная доставка сообщения не спишет деньги дважды. В моей практике основой служат идемпотентные ключи, уникальные ограничения в базе и проверка статуса перед записью. На одном проекте через очередь проходило около 1,2 млн событий в сутки, и после внедрения ключей дубликаты в отчётах сократились практически до нуля, а количество ручных разборов упало примерно на 95 процентов.

• Сразу даёт определение и переводит его в практику
• Есть цифры объёма и измеримый результат
• Назван конкретный набор технических приёмов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Решение о разбиении принимаю по границам бизнес-процессов, а не по слоям кода. Сначала смотрю, где чаще всего меняется код, где узкие места по нагрузке и где разным командам мешают общие релизы. Кандидат на сервис — это участок с понятным контрактом, своей моделью данных и отдельным циклом релиза. Дальше выделяю его по strangler-подходу: новый сервис работает рядом, трафик переводится постепенно. В одном случае выделение сервиса отчётов, который тормозил основное приложение, помогло убрать из релиза монолита около 40 процентов изменений и сократить время выката с 40 минут до 10.

• Показан критерий решения, а не мода на микросервисы
• Упоминается безопасный постепенный переход
• Есть измеримый эффект от выделения сервиса

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Code review для меня — это в первую очередь проверка логики и граничных случаев, а не стиля: стиль закрывают линтеры и форматтеры в CI. Смотрю на читаемость, на обработку ошибок, на работу с транзакциями и внешними вызовами, на тесты к новой логике. Комментарии стараюсь формулировать как вопрос, а не как приговор, и отделяю блокирующие замечания от необязательных. В среднем держу один проход ревью в пределах часа-двух, чтобы не тормозить команду. В команде из шести человек такой режим ревью сократил возвраты задач из тестирования примерно на треть.

• Разделены стиль и логика — зрелый подход
• Подчёркнута культура общения в комментариях
• Названы сроки ревью и результат для команды

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Подход строю по слоям. На входе — валидация схемы запроса и строгие типы, чтобы не доверять данным клиента. Дальше — параметризованные запросы к базе вместо склейки строк, разграничение прав по ролям и проверка доступа к объекту, а не только факта авторизации. Отдельно — ограничение частоты запросов, лимиты размера тела, секреты только в защищённом хранилище и регулярное обновление зависимостей с проверкой уязвимостей в CI. Ещё важны корректные заголовки безопасности и понятные сообщения об ошибках без внутренних деталей. На одном проекте после подключения сканера зависимостей число критичных находок в релизе сократилось с десятков до нуля.

• Ответ структурирован по слоям защиты
• Названы типовые риски и способы их закрытия
• Есть измеримый результат проверки зависимостей

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.