36 вопросов для подготовки к собеседованию на Python-разработчика

На собеседовании Python-разработчика редко хватает пересказа синтаксиса. Интервьюер смотрит, умеете ли вы выбрать структуру данных, объяснить компромисс и довести решение до рабочего кода под уточняющие вопросы.

Ниже собраны вопросы на собеседовании Python-разработчика с разбором ответов. Разберём язык и ООП, конкурентность, SQL и ORM, опыт, кейсы и практические задания. Формулировки в компаниях разные. Важно уметь уточнить ограничения и нагрузку, а не перечислить тулы.

Грейд меняет глубину. Junior закрывает базу и рассуждает вслух. Middle связывает asyncio, БД и прод-ограничения. Senior держит архитектуру, наблюдаемость и откат.

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

Как проходит собеседование Python-разработчика, зависит от компании, но почти всегда это несколько встреч. Рекрутер сверяет стек и ожидания. Дальше отдельно смотрят язык, код и умение объяснить решение из опыта.

Типичная нарезка этапов выглядит так. HR 15–30 минут. Технический скрин 30–45. Основное техническое 45–90. Лайвкод или домашка. Финал с командой или нанимающим менеджером. Это ориентир, не единый ГОСТ.

Грейд меняет набор секций. Junior чаще проходит скрин и одну техническую встречу. Middle чаще получает системный дизайн или разбор БД. Senior глубже уходит в компромиссы масштаба, отказоустойчивость и сопровождение.

Ниже ориентир этапов. Продуктовый бэкенд дольше сидит в API и Postgres. Команда с ML или данными уйдёт в пайплайны, хотя ядро языка всё равно спросят.

Когда ответы на язык и БД уже складываются, полезно сверить стек с живыми вакансиями. В подборке разработки на HireHi видно, какие команды ждут Django, FastAPI, Postgres и очереди. Про вилки и рост на удалёнке есть отдельный разбор зарплаты Python-разработчика.

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

Какие вопросы задают на собеседовании Python-разработчика, обычно режут на несколько типов. Не пытайтесь учить всё подряд. Соберите примеры под каждый тип и потренируйте короткий ответ.

• Профессиональные: язык, ООП, конкурентность, SQL/ORM, API и тесты.
• Про опыт: сервис из резюме, инцидент, спорное техническое решение.
• Ситуационные: тормоза под нагрузкой, опасный рефакторинг, сломанная миграция.
• Практические: лайвкод, маленький модуль, разбор N+1 или retry.
• Поведенческие: как спорите в ревью, как признаёте пробел, как просите хелп.

Ниже сначала банк по темам с акцентом junior / middle / senior, затем опыт, кейсы и задания.

Профессиональные вопросы Python-разработчику

Профессиональные вопросы на собеседовании Python-разработчика проверяют не словарный запас, а выбор инструмента под задачу. Ниже темы, которые стабильно встречаются в топе подготовки.

Язык, коллекции и функции

Чем list отличается от tuple и когда брать frozenset?

Что проверяют. Понимаете ли изменяемость и зачем она в интерфейсе функции.

Как отвечать. List меняется после создания: append, pop, срезы с записью. Tuple неизменяем и годится как ключ словаря или элемент set, если внутри тоже hashable. Frozenset нужен, когда множество должно быть ключом или лежать в другом set.

Демонстрационный ход. «Для буфера событий возьму list. Для координат точки или пары id, которые нельзя случайно дописать, возьму tuple. Если нужен набор тегов как ключ кэша, сделаю frozenset.»

Что опасного в изменяемом аргументе по умолчанию?

Что проверяют. Знаете ли классическую ловушку Python, а не только PEP 8.

Как отвечать. Default вычисляется один раз при определении функции. Общий list или dict накапливает состояние между вызовами. Пишите items=None и создавайте новый список внутри.

Демонстрационный ход. «Если вижу def f(x=[]): в ревью, сразу прошу None. Иначе тесты зелёные поодиночке и красные пачкой.»

Как устроен dict и почему ключ должен быть hashable?

Что проверяют. Связь хеш-таблицы с O(1) доступом и ограничениями ключа.

Как отвечать. Dict хранит пары ключ–значение через хеш. Ключ должен быть hashable и сравниваться стабильно: str, int, tuple из hashable. List и обычный set ключом быть не могут. Средний доступ по ключу быстрый, но при плохом хеше возможны коллизии.

Чем is отличается от ==?

Что проверяют. Не путаете ли идентичность объекта с равенством значений.

Как отвечать. is сравнивает identity (один и тот же объект в памяти). == вызывает сравнение значений. Для None пишите is None. Для чисел и коротких строк кэш интернирования иногда совпадает, но на это нельзя опираться в логике.

Что такое генератор и чем generator expression отличается от list comprehension?

Что проверяют. Ленивость и работу с большими объёмами.

Как отвечать. Генератор отдаёт элементы по одному через yield или (x for x in ...). List comprehension сразу строит весь список в памяти. Генератор экономит RAM на больших потоках, но его нельзя индексировать и пройти дважды без пересоздания.

Что такое декоратор и зачем functools.wraps?

Что проверяют. Понимание «функция оборачивает функцию», а не только синтаксис @.

Как отвечать. Декоратор принимает вызываемый объект и возвращает обёртку с допповедением: лог, таймер, ACL, retry. wraps копирует __name__ и __doc__, иначе стек и отладка показывают wrapper.

Демонстрационный ход. «Сначала объясню идею, потом простой wrapper(*args, **kwargs), потом wraps. Параметры декоратора оставлю на follow-up.»

Как работает with и как написать свой контекстный менеджер?

Что проверяют. Управление ресурсами и исключениями.

Как отвечать. with вызывает __enter__/__exit__ или генератор с @contextmanager. Файл, соединение, лок закрываются даже при ошибке. Свой менеджер пишу, когда важно гарантировать cleanup и не размазывать try/finally.

Что такое LEGB и когда нужен nonlocal?

Что проверяют. Области видимости без магии global на всё подряд.

Как отвечать. Поиск имени идёт Local → Enclosing → Global → Built-in. nonlocal пишет во enclosing-область замыкания. global трогает модуль. На собеседовании лучше показать замыкание со счётчиком, чем лекцию.

ООП и ошибки

Когда выбрать наследование, а когда композицию?

Что проверяют. Не рисуете ли глубокие иерархии «потому что ООП».

Как отвечать. Наследование уместно при стабильном «является». Композиция лучше, когда поведение собирается из частей и меняется независимо. В Python часто хватает протоколов, миксинов точечно и явных зависимостей в __init__.

Как устроены исключения: try/except/else/finally и свои типы?

Что проверяют. Не глотаете ли Exception молча.

Как отвечать. Ловите ожидаемое узко. else выполняется без ошибки. finally закрывает ресурсы. Свои типы помогают отличить доменную ошибку от инфраструктурной. В API наружу отдайте понятный код ответа, внутрь оставьте traceback в лог.

Конкурентность и async

Что такое GIL и когда threading не ускорит CPU?

Что проверяют. Связь GIL с профилем нагрузки, а не мем про «Python медленный».

Как отвечать. В CPython GIL не даёт двум потокам одновременно исполнять байткод. CPU-bound в threading почти не ускоряется. I/O-bound потоки могут помогать, потому что на ожидании GIL отпускается. Для чистого CPU берите процессы, C-расширения или вынос в сервис.

Когда выбрать asyncio, threading и multiprocessing?

Что проверяют. Умение выбрать модель исполнения под задачу.

Как отвечать. asyncio для многих одновременных ожиданий HTTP/БД/сокетов в одном процессе. threading для блокирующих библиотек, которые жалко переписывать, через thread pool. multiprocessing для CPU-bound и обхода GIL ценой памяти и IPC. Не смешивайте «ускорим всё async» без профиля.

Что будет, если забыть await?

Что проверяют. Реальный опыт async-багов.

Как отвечать. Получите объект корутины, который не выполнился. Часто RuntimeWarning и тихий пропуск побочного эффекта. В тестах ловлю забытый await моком и явным asyncio.run. Блокирующий вызов внутри корутины тоже убивает loop: его выносят в executor.

SQL, ORM и данные

Как найти и починить N+1 в ORM?

Что проверяют. Диагностику, а не лозунг «ORM плохой».

Как отвечать. Симптом: один запрос списка плюс запрос на каждый связанный объект. Смотрю лог SQL, debug toolbar, explain количества round-trip. В Django: select_related для JOIN, prefetch_related для M2M. В SQLAlchemy: joinedload/selectinload. Иногда проще один явный SQL.

Зачем уровни изоляции транзакций на практике?

Что проверяют. Не путаете ли ACID-плакат с кейсом lost update.

Как отвечать. Read committed часто дефолт и допускает non-repeatable read. Repeatable read / snapshot защищают повторное чтение в рамках транзакции. Serializable дороже. На интервью расскажите кейс: два воркера списывают остаток, как ловите optimistic lock или SELECT FOR UPDATE.

Как читать EXPLAIN без магии?

Что проверяют. Базовый план, а не заученные картинки.

Как отвечать. Смотрю Seq Scan vs Index Scan, оценку строк, стоимость, фильтры. Если функция над колонкой в WHERE, индекс может не использоваться. Сначала уточняю кардинальность и селективность, потом предлагаю индекс или переписывание запроса.

Продвинутый язык и API

Как написать декоратор с параметрами?

Что проверяют. Три уровня вложенности без потери сигнатуры.

Как отвечать. Внешняя фабрика принимает параметры, средняя принимает функцию, внутренняя wrapper вызывает исходную. Для async нужен async wrapper и await. wraps обязателен. Пример применения: retry(times=3) или timeout(seconds=2).

Зачем typing в проде: Optional, Protocol?

Что проверяют. Прагматизм, а не лекцию про variance.

Как отвечать. Аннотации ловят ошибки в CI через mypy/pyright и помогают IDE. Optional явен про None. Protocol описывает утиную типизацию без жёсткого наследования. Если в вакансии нет mypy, не читайте доклад на 10 минут.

Где lru_cache помогает, а где ломает логику?

Что проверяют. Понимание кэша и инвалидации.

Как отвечать. lru_cache хорош для чистых функций с дорогим пересчётом. Ломается на аргументах с меняющимся смыслом, на больших объектах в памяти и когда результат должен зависеть от времени или БД. Для запросов пользователя чаще Redis/HTTP cache с TTL и ключом.

Когда хватит REST, а когда нужна очередь?

Что проверяют. Границы синхронного API.

Как отвечать. REST удобен для запрос–ответ с коротким SLA. Очередь нужна, когда работа долгая, нужна повторная доставка, пики нагрузки или несколько потребителей. На интервью назовите идемпотентный ключ, DLQ и что отдадите клиенту сразу: 202 и id задачи.

Архитектура и сопровождение

Как спроектируете API с ретраями и идемпотентностью?

Что проверяют. Senior-мышление про частичные сбои.

Как отвечать. Уточню семантику операции. Для create дам Idempotency-Key. Ретраи только на безопасных или идемпотентных вызовах с backoff и лимитом. Таймауты на клиента и на downstream. Повтор не должен удваивать списание.

Как режете latency p99 без «просто Redis»?

Что проверяют. Диагностику узкого места.

Как отвечать. Сначала профиль: CPU, SQL, сеть, локи. Часто p99 ест N+1, холодный кэш или синхронный внешний вызов. Потом кэш точечно, батчинг, async I/O, индексы. Redis без понимания ключа и TTL маскирует проблему на неделю.

Когда реально нужны __slots__ или дескрипторы?

Что проверяют. Не тащите ли экзотику без боли.

Как отвечать. __slots__ экономит память на миллионах однотипных объектов. Дескрипторы нужны для контролируемого доступа к атрибутам, ORM-полям, валидации. В обычном сервисе чаще хватает dataclass/pydantic и property.

Как наблюдаете Python-сервис: логи, метрики, трейсы?

Что проверяют. Сопровождение, а не только «напишем print».

Как отвечать. Структурные логи с request_id. Метрики latency/error rate/насыщенности. Трейсы между сервисами. Алерты на симптомы пользователя, не только на CPU. На интервью свяжите метрику с действием: откат, scale, feature flag.

Что спрашивают про опыт Python-разработчика

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

Расскажите о сервисе, где снижали ошибки или latency

Что проверяют. Умение связать действие с эффектом.

Как отвечать. Контекст → узкое место → что сделали → как измерили. Без выдуманных процентов. Если цифр нет, опишите наблюдаемый симптом и критерий «стало лучше».

Инцидент в проде: что сломалось и как откатили

Что проверяют. Спокойствие и процедуру, а не героизм.

Как отвечать. Симптом, гипотеза, откат или feature flag, постмортем без поиска виноватых. Упомяните, что изменили в мониторинге или тестах после.

Спор ORM vs raw SQL: как решали

Что проверяют. Прагматизм в команде.

Как отвечать. ORM для типового CRUD и безопасности. Raw SQL там, где план критичен. Решение фиксировали критерием: читаемость, план EXPLAIN, кто будет сопровождать.

Код-ревью, где поймали гонку или опасный default

Что проверяют. Внимание к деталям Python.

Как отвечать. Коротко опишите баг: общий list в default, shared state в потоках, забытый await. Что предложили взамен и какой тест закрыл дыру.

Какие ситуационные вопросы могут задать Python-разработчику

Ситуационные вопросы на собеседовании Python-разработчика проверяют порядок действий. Начинайте с уточнений и гипотез, не с переписывания стека.

Ручка тормозит под нагрузкой: с чего начнёте?

Что проверяют. Диагностический скелет.

Как отвечать. Уточню SLA, RPS, p50/p99, зависимость от БД и внешних API. Сниму профиль и SQL-лог. Отделю CPU от I/O. Только потом кэш, индекс или вынос в очередь.

Коллега тянет метаклассы «для красоты»

Что проверяют. Вкус и сопровождаемость.

Как отвечать. Спрошу задачу, которую нельзя решить декоратором, Protocol или явной фабрикой. Если выгоды нет, предложу простой код. Метаклассы оставлю для фреймворков и регистраций.

Нужно ускорить CPU-bound отчёт в Django

Что проверяют. Понимание GIL в веб-стеке.

Как отвечать. Не обещаю threading внутри воркера как cure-all. Вынесу расчёт в задачу Celery/RQ, процессный пул или отдельный сервис. Веб-ручка останется тонкой: приняла запрос, отдала id job.

Ночная миграция сломала прод

Что проверяют. Миграции без даунтайма.

Как отвечать. Откат кода и миграции по заранее продуманному плану. Expand/contract: сначала совместимая схема, потом код, потом удаление старого. Блокирующие ALTER на большой таблице не катим без окна.

Product просит «индекс на все колонки»

Что проверяют. Умение говорить о цене записи.

Как отвечать. Индекс ускоряет чтение выбранных предикатов и замедляет запись. Покажу запросы из EXPLAIN, предложу составной индекс под реальный WHERE/ORDER BY, а не ковёр по таблице.

Какие практические задания дают Python-разработчику

Какие практические задания дают на собеседовании Python-разработчика, зависит от грейда. Junior чаще пишет чистую функцию. Middle собирает маленький модуль с тестами. Senior объясняет интерфейс и отказные сценарии.

Напишите подсчёт частот и найдите первый уникальный символ

Что проверяют. Dict как счётчик и один проход после подсчёта.

Как отвечать. Сначала Counter или словарь частот, затем второй проход по исходной строке. Проговорите пустую строку и строку из повторов. Не начинайте с вложенных циклов O(n²), если n может быть большим.

Сделайте retry-декоратор с backoff

Что проверяют. Обёртки, исключения, аккуратность API.

Как отвечать. Параметры: times, exceptions, delay. Между попытками sleep или async sleep. Не ретрайте всё подряд. Логируйте номер попытки. wraps сохраняет имя функции. Для прода добавьте jitter.

Ограничьте concurrency в async-загрузчике URL

Что проверяют. asyncio.Semaphore и отмену.

Как отвечать. Semaphore(n) вокруг fetch. gather или TaskGroup. Таймаут на запрос. Ошибки одного URL не роняют весь батч, если так договорено. В конце закройте сессию клиента.

Как подготовиться к собеседованию Python-разработчика

Как подготовиться к собеседованию Python-разработчика, лучше строить вокруг своего стека из вакансии. Закройте базу языка, затем БД и один способ конкурентности, которым реально пользовались.

• Повторите коллекции, функции, исключения, ООП, генераторы и декораторы.
• Разберите GIL на примерах I/O vs CPU, не как определение из статьи.
• Поднимите один сервис из резюме: схема, узкое место, тест, мониторинг.
• Решите 20–40 задач на строки, хеши, два указателя, простые деревья.
• Напишите маленький модуль с pytest: happy path, краевой случай, ошибка.
• Проговорите ответы голосом, иначе на лайвкоде язык застынет.

Шаг 1. Выберите специальность, грейд и формат

В форме укажите разработку, Python, свой грейд и тип встречи. Для секции про язык, БД и async берите технический формат: так вопросы ближе к коду и компромиссам, а не к общему рассказу о себе.

Шаг 2. Запустите тренировку и отвечайте

Отвечайте голосом, как на встрече. Уточняйте входные данные и ограничения. Если не знаете точный API, скажите идею и краевые случаи. Молчаливый идеальный код ценится ниже живого рассуждения.

Шаг 3. Посмотрите результат

В разборе смотрите сильные стороны и зоны роста по темам: коллекции, async, SQL, архитектура. Зафиксируйте 2–3 пункта, которые реально успеете закрыть до интервью.

Шаг 4. Повторите слабые темы

Второй прогон делайте узко: только декораторы, только N+1 или только инцидент. Так подготовка к собеседованию Python-разработчика остаётся управляемой, а не бесконечным чтением гигантских банков.

Как вести себя на собеседовании Python-разработчика

Как вести себя на собеседовании Python-разработчика, важнее заученных определений. Интервьюер покупает ход мысли.

• Уточните входы, ограничения по времени и памяти, что считать ошибкой.
• Начните с простого рабочего решения, затем улучшайте.
• Проговаривайте выбор list/dict/генератора и оценку сложности.
• Честно маркируйте пробел: «не писал метаклассы в проде, опирался на dataclass».
• Для async и БД называйте профиль нагрузки, а не модный инструмент.
• В конце оставьте время на вопросы про релиз, тесты и on-call.

Неудачный ход: молча писать 10 минут или блефовать про GIL. Удачный ход: «Сначала сделаю корректно за O(n), потом обсудим память и параллелизм.»

Какие вопросы задать работодателю на собеседовании Python-разработчика

Какие вопросы задать работодателю на собеседовании Python-разработчика, лучше привязать к стеку и сопровождению. Универсальный список «какой у вас тимбилдинг» здесь слабо работает.

• Какой основной стек сейчас: Django, FastAPI, Flask, и что нельзя трогать полгода?
• Как устроены релизы и откаты? Есть ли feature flags?
• Как тестируете: pytest, контрактные тесты, доля покрытия на критичном контуре?
• Где крутятся фоновые задачи и кто дежурит по очередям?
• Как смотрите p99 и ошибки: метрики, трейсы, алерты?
• Что ожидают от грейда в первые 90 дней: фичи, стабилизация, платформа?
• Как проходит ревью и кто принимает архитектурные решения?