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

Техническая секция собрана из пяти блоков: ядро языка, асинхронность и параллелизм, типизация, работа с данными и ORM, тестирование. Сверху — задача на живом коде: найти ошибку, отрефакторить фрагмент или спроектировать модуль вслух. Но есть нюанс, которого нет в подборках «100 вопросов»: у части классических вопросов в 2026 году изменился правильный ответ. Главный из них — про GIL. После выхода Python 3.14 в октябре 2025 года ответ «в Python нет настоящей многопоточности» стал неполным, и на интервью это слышно.

Ключевые факты

Общий процесс найма — этапы, роли интервьюеров, сроки — разобран отдельно в статье [о техническом собеседовании в ИТ](/blog/tehnicheskoe-sobesedovanie-v-it/). Здесь только техническая секция и только Python.

Из чего собрано техническое интервью Python-разработчика

Собеседование Python-разработчика в технической части длится 60–90 минут, ведёт его senior или техлид, иногда вдвоём с архитектором. Структура почти всегда одинаковая, меняются акценты: продуктовой команде важнее ядро языка и тесты, высоконагруженному сервису — асинхронность, дата-платформе — работа с данными.

Требования к junior за последние пару лет заметно сдвинулись: по обзорам вакансий 2026 года от начинающих ждут понимания типизации, асинхронности и основ системного дизайна — тем, которые раньше начинались на уровне middle.

Блок 1. Ядро языка: где заканчиваются заученные определения

Декораторы, генераторы, изменяемые типы, области видимости, менеджеры контекста. Спрашивают их у всех, но проверяют не формулировку — за каждым определением идёт «а зачем это нужно» и «где вы это применяли».

Декораторы встречаются примерно на трети собеседований по Python. Регулярно спрашивают встроенные — @staticmethod, @classmethod, @dataclass. Ответ «декоратор — это функция, которая принимает функцию и возвращает функцию» верен и бесполезен: следом идёт вопрос, как передать декоратору аргументы, что делает functools.wraps и зачем он вообще нужен. Здесь заученное заканчивается.

Генератор — итерируемый объект, который создаёт функция с yield в теле. Проверяют понимание ленивости: чем генератор отличается от списка по памяти, что произойдёт при повторном проходе, где генератор экономит, а где мешает отладке.

Две ловушки, которые дают почти всем.

Изменяемый аргумент по умолчанию. Функция с def add(item, target=[]) накапливает элементы между вызовами, потому что список создаётся один раз при определении функции. Кандидат, который сразу называет причину, а не только симптом, закрывает вопрос.

Замыкание в цикле. Лямбды, созданные в цикле, захватывают переменную, а не её значение, и после цикла все возвращают последнее. Классика, и она регулярно всплывает в проде — в обработчиках событий и отложенных задачах.

Блок 2. Асинхронность и параллелизм: вопрос, у которого сменился ответ

Это блок, где сильнее всего расходятся подготовка по старым подборкам и реальность 2026 года.

Классический вопрос звучит так: что такое GIL и как он влияет на многопоточность. Ответ из подборок — «глобальная блокировка интерпретатора не даёт потокам исполнять байт-код одновременно, поэтому для CPU-задач берут процессы». Он всё ещё верен для сборки по умолчанию. Но начиная с Python 3.14, вышедшего в октябре 2025 года, у языка есть вторая официально поддерживаемая сборка — без GIL.

Что произошло, если коротко. PEP 703 предложил free-threaded сборку, PEP 779 задал критерии, по которым её признали готовой. В версии 3.13 она была экспериментальной, в 3.14 получила статус официально поддерживаемой. Сборкой по умолчанию она при этом не стала: её ставят отдельно, бинарник помечен тегом 3.14t.

Полное отключение GIL по умолчанию сообщество ожидает ориентировочно в 2027–2028 годах. Это оценка, а не дата из плана релизов, и на интервью её стоит подавать именно так.

Практический вывод для кандидата: формулировка «GIL убрали» неверна и подставляет. Рабочий ответ звучит примерно так — в сборке по умолчанию GIL на месте и CPU-bound задачи по-прежнему уходят в процессы; с 3.14 есть официально поддерживаемая сборка без GIL, у неё своя цена по памяти и совместимости расширений; выбор зависит от того, на чём работает конкретный сервис. Такой ответ показывает, что кандидат следит за языком, а не за подборками вопросов.

Дальше идёт выбор модели под задачу — вопрос, который любят больше самого GIL.

Отдельный вопрос-щуп: что случится, если внутри корутины вызвать блокирующую функцию. Правильная реакция — не «всё сломается», а объяснение механики: event loop однопоточный, блокирующий вызов останавливает обработку всех остальных корутин, поэтому такие вызовы выносят в executor.

Блок 3. Типизация: почему она стала обязательной темой

Аннотации типов перестали быть признаком аккуратности и превратились в требование: по обзорам вакансий 2026 года типизация входит в ожидания даже от junior.

Спрашивают про Optional и Union, дженерики, Protocol и структурную типизацию, про pydantic как способ валидации на границе системы. Но первый вопрос почти всегда проверочный: что происходит с аннотациями в рантайме. Ответ «интерпретатор их проверяет» — сразу минус. Аннотации сами по себе ничего не проверяют, проверку выполняет статический анализатор вроде mypy, и работает он в CI, а не при запуске.

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

Блок 4. Данные, ORM и запросы из кода

Вопрос «какие ORM использовали и в чём их преимущество перед прямыми запросами» входит в устойчивый набор тем. Ответ про удобство и переносимость засчитывается наполовину: следом спросят про цену этого удобства.

Цена — потеря контроля над тем, какой SQL уйдёт в базу. Отсюда главный вопрос блока: что такое проблема N+1 и как вы её обнаружили в своём проекте. Кандидат, который называет определение, знает теорию. Кандидат, который рассказывает, как увидел сотню одинаковых запросов в логе или в APM и заменил ленивую загрузку на жадную, работал с этим руками.

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

Синтаксис SQL здесь спрашивают реже, чем у аналитиков: у разработчика проверяют не умение написать запрос, а понимание, какой запрос породит его код. Смежная тема разобрана в статье [о собеседовании системного аналитика](/media-center/voprosy-i-zadachi-sobesedovanie-sistemnogo-analitika/) — там SQL идёт вглубь, с планами запросов и индексами.

Блок 5. Тестирование и качество кода

Вопрос «пишете ли вы тесты» не задают: ответ известен заранее. Задают другой — что вы тестами не покрываете и почему.

Хороший ответ содержит границу: покрываем бизнес-логику и граничные случаи, не покрываем тривиальные геттеры и сторонние библиотеки, интеграционными тестами закрываем стыки, а не каждую функцию. Дальше идут pytest и фикстуры, параметризация, моки — и вопрос, когда мок вредит. Ответ есть: когда замокан весь мир вокруг и тест проверяет, что мок вернул то, что в него положили.

Про покрытие спрашивают с подвохом. Цифра в 90% ничего не гарантирует, если тесты не содержат проверок; 60% с продуманными кейсами полезнее. Кандидат, называющий покрытие целевой метрикой команды, обычно не вёл такие споры внутри проекта.

Задачи на живом коде: четыре формата

Практическая часть показывает то, чего не покажет ни один вопрос: как человек рассуждает, когда решение не приходит сразу. Форматов четыре.

Формат 1. Небольшая задача на структуры данных

Не олимпиадная — что-то вроде группировки записей или поиска дубликатов. Оценивают выбор структуры и умение оценить сложность. Начинать стоит с уточнения: объём данных, допустима ли дополнительная память, важен ли порядок. Типичная ошибка — броситься писать до того, как условие уточнено.

Формат 2. Найти ошибку в готовом фрагменте

Обычно подкладывают классику: изменяемый аргумент по умолчанию, замыкание в цикле, забытый await, изменение коллекции во время итерации. Оценивают внимательность и умение объяснить причину, а не только заметить симптом. Ошибка — сказать «тут баг» и не объяснить механику.

Формат 3. Отрефакторить рабочий, но плохой код

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

Формат 4. Спроектировать модуль или эндпоинт вслух

«Опишите API для загрузки файлов» — и дальше диалог. Оценивают, задаёте ли вы вопросы про объёмы, ограничения, обработку ошибок. Ошибка — сразу называть фреймворк, не выяснив требований.

Общее для всех четырёх: молчаливое решение оценивается ниже незаконченного, но проговорённого. Интервьюер видит код на экране и не видит мышления, а оценивает именно его.

[Вставка: обезличенные задачи, которые команда iFellow даёт Python-разработчикам, и критерии их оценки. Разбор выше — типовая отраслевая практика.]

Один вопрос — три ответа: junior, middle, senior

Возьмём вопрос «как обработать 10 000 HTTP-запросов к внешнему API». Одна формулировка, три разных разговора.

Разница не в объёме знаний, а в горизонте. Junior отвечает «как сделать», middle — «как сделать правильно для этой задачи», senior — «что будет, когда это сломается в три часа ночи».

[Вставка: грейдовая матрица iFellow — как компания различает уровни по одному вопросу.]

Что изменилось к 2026 году

Вопрос про GIL требует нового ответа. Подробно разобрано выше: после Python 3.14 существует официально поддерживаемая сборка без глобальной блокировки. Заученная формулировка трёхлетней давности теперь выдаёт кандидата, который не следит за языком.

Типизация и асинхронность спустились в требования к junior. Раньше эти темы начинались на middle. Сейчас, по обзорам вакансий 2026 года, их ждут от начинающих вместе с базовым пониманием системного дизайна.

ИИ вошёл в интервью с двух сторон. Как инструмент: спрашивают, как вы проверяете сгенерированный код, где модель ошибается в вашей предметной области, что не отдаёте ей из закрытого кода. Как проблема найма: по публикации РБК от 14 января 2026 года есть случаи, когда позиции получали люди без базовых навыков, прошедшие тестирование с помощью ИИ. Следствие — формат сместился к разбору собственного кода кандидата и вопросам «почему так, а не иначе».

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

[Вставка: позиция iFellow по использованию ИИ при выполнении тестового задания и способ проверки.]

Как подготовиться: план по блокам

Готовиться к собеседованию Python-разработчика по спискам вопросов малоэффективно: их тысячи, и спросят не те. Работает подготовка, привязанная к пяти блокам выше.

1. Разберите свой код, а не чужие подборки. Возьмите два своих модуля и объясните вслух: почему такая структура, что бы изменили сейчас, где узкое место. Это закрывает половину интервью.

2. Проверьте версию Python на целевом проекте. Вопрос про GIL звучит по-разному для сервиса на 3.10 и на 3.14. Если в вакансии указана свежая версия — прочитайте, что в ней изменилось, хотя бы по списку основных нововведений.

3. Прогоните асинхронную задачу вслух. Возьмите сценарий с тысячей запросов и проговорите решение целиком: ограничение конкурентности, таймауты, повторы, обработка частичных отказов.

4. Освежите типизацию до уровня Protocol и дженериков. Проверьте себя вопросом, что делают аннотации в рантайме — если ответ неочевиден, тема требует часа.

5. Найдите N+1 в своём проекте. Включите логирование SQL и посмотрите, что порождает ORM на типовой странице. История с конкретными числами весит больше определения.

6. Подготовьте вопросы к команде. Версии и стек, покрытие тестами, как устроен код-ревью, есть ли техдолг, кто принимает архитектурные решения.

Ошибки, из-за которых отказывают сильным разработчикам

1. Решает молча. Ход мысли не виден, оценивать нечего. Верный итог спасает не всегда.

2. Заученное определение без «зачем». Формулировка из учебника закрывается уточняющим вопросом за десять секунд.

3. «Я всегда так делаю» без обоснования. Практика без объяснения читается как карго-культ, даже когда практика хорошая.

4. Не проверяет граничные случаи. Пустой список, None, дубликаты, отказ внешнего сервиса. Разработчик, который сам вспоминает про них, экономит команде инциденты.

5. Нет вопросов о проекте и процессах. Читается как безразличие к тому, чем предстоит заниматься следующие два года.

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

1. Сколько длится техническая секция и из чего состоит?

   Обычно 60–90 минут: ядро языка, асинхронность и параллелизм, типизация, данные и ORM, тестирование, плюс задача на живом коде. Акценты зависят от проекта — высоконагруженному сервису важнее асинхронность, дата-платформе работа с данными. Общий процесс найма с этапами и сроками разобран в отдельной статье блога.

2. Нужно ли учить алгоритмы?

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

3. Правда ли, что GIL больше нет?

   Не совсем. В Python 3.14, вышедшем в октябре 2025 года, free-threaded сборка получила статус официально поддерживаемой (PEP 703, PEP 779), но сборкой по умолчанию не стала — она ставится отдельно и помечена тегом 3.14t. В стандартной сборке GIL на месте. Полное отключение по умолчанию сообщество ожидает ориентировочно в 2027–2028 годах, и это оценка, а не дата из плана релизов.

4. Спрашивают конкретные фреймворки или общий Python?

   И то и другое, но в разной пропорции. База по языку — всегда, фреймворк — по вакансии. При этом глубокое знание Django не компенсирует незнания того, как работают генераторы: фреймворк учится за месяц, механика языка — нет.

5. Дают ли домашнее тестовое и сколько оно занимает?

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

6. Можно ли пользоваться ИИ при выполнении тестового?

   Единой нормы на рынке нет. Одни компании запрещают, другие допускают при условии, что вы объясните каждую строку на защите решения. По публикации РБК от января 2026 года есть случаи найма специалистов без базовых навыков, прошедших тестирование с помощью ИИ, — из-за этого требования ужесточаются. Спросите правила у рекрутера заранее.