Канал по Машинному обучению
@ai_machinelearning_big_data
Перейти
Гайд по собеседованию Python-разработчика (Middle) 2025 года
В этом гайде собраны реальные и актуальные вопросы из интервью в крупных технологических компаниях и стартапах (Google, Amazon, Stripe, Booking и др). Каждая тема разобрана через призму того, что именно проверяют интервьюеры, как лучше структурировать ответ и какие подводные камни важно учитывать.
У меня в тг канале разобрано 1900 вопросов с собеседований. А здесь я собрал целую папку для полноценно подготовки к собеседованию.
Объектно-ориентированное программирование (ООП)
Вопрос: Чем отличаются методы __str__ и __repr__ в Python?
Что проверяют: Понимание механизмов представления объектов в виде строк, умение правильно переопределять специальные методы. Часто на собеседовании хотят убедиться, что кандидат знает назначение каждого метода – один для отладочной, “сырой” репрезентации, другой для пользовательского вывода.
Разбор: В Python можно определить два специальный метода для строкового представления объекта. Метод __repr__ должен выдавать однозначное и подробное представление объекта (чаще всего, как его конструировать), в то время как __str__ возвращает более удобочитаемую версию для пользователя[1][2]. Если кратко, __repr__ – для разработчика, а __str__ – для конечного пользователя[1]. Например, у объекта даты datetime.now() репрезентация через __repr__ может выглядеть как конструктор с параметрами (полный timestamp), а __str__ – как отформатированная дата для отображения[3]. Если в классе не определить __str__, то при печати объекта будет использован __repr__ по умолчанию. Подводные камни: Многие начинающие путают назначения этих методов. Правильно реализованный __repr__ позволяет в идеале восстановить объект по этой строке, а __str__ – лишь предоставить человеку понятную информацию[4]. На собеседовании ожидается ответ, что __repr__ – “официальная” строка (как можно создать объект), а __str__ – дружелюбное описание[1].
Вопрос: Как сделать пользовательский класс сортируемым и итерируемым?
Что проверяют: Знание специальных методов Python для реализции “протоколов” последовательностей и порядка. Интервьюеру важно увидеть, что кандидат умеет перегружать методы сравнения и протокол итерации.
Разбор: Чтобы экземпляры класса можно было сравнивать и сортировать, класс должен определить по крайней мере метод сравнения, например __lt__ (для операции <). Часто также определяют __eq__ для корректной работы сортировки и поиска равных элементов. Можно упростить задачу, используя functools.total_ordering, если определён один базовый метод сравнения. Для итерируемости класс должен поддерживать протокол итерации – то есть иметь метод __iter__, возвращающий итератор (обычно return self в сочетании с определённым __next__), либо определить метод __getitem__. Например, можно в __iter__ просто вернуть генератор: def __iter__(self): for item in self.data: yield item. Подводные камни: Забыть про методы равенства (__eq__) – тогда сортировка может работать неинтуитивно. Для итерации проще возвращать итератор самого объекта (реализовав __next__), либо использовать встроенные генераторные возможности. Демонстрация:
class MyRange:
def __init__(self, n):
self.n = n
def __iter__(self):
self.current = 0
return self
def __next__(self):
if self.current < self.n:
val = self.current
self.current += 1
return val
else:
raise StopIteration
r = MyRange(3)
print(list(r)) # Вывод: [0, 1, 2]Для сравнения объектов можно сделать так:
from functools import total_ordering
@total_ordering
class Person:
def __init__(self, name, age):
self.name = name; self.age = age
def __eq__(self, other):
return self.age == other.age
def __lt__(self, other):
return self.age < other.age
people = [Person("Алиса", 30), Person("Боб", 25)]print(sorted(people)) # сортировка по ageЗдесь мы определили, что люди сравниваются по полю возраста. total_ordering добавит остальные методы сравнения на основе наших __eq__ и __lt__. В ответе важно упомянуть названия dunder-методов: __iter__/__next__ для итерации, __lt__/__eq__ (и др. при необходимости) для сравнения.
Вопрос: Как сделать так, чтобы ваш класс работал как контекстный менеджер (with)?
Что проверяют: Понимание управления ресурсами и протокола контекстного менеджера (методы __enter__ и __exit__). Это демонстрирует знание, как правильно закрывать файлы, соединения и т.д.
Разбор: Контекстный менеджер позволяет использовать объекты в конструкции with … as. Для этого класс должен определить методы __enter__(self) и __exit__(self, exc_type, exc_val, exc_tb). В __enter__ обычно выполняется настройка и возврат ресурса, а в __exit__ – освобождение ресурса (закрытие файла, соединения). Например, класс файлового менеджера: [5]
class FileManager:
def __enter__(self):
self.file = open('file.txt', 'w')
return self.file
def __exit__(self, exc_type, exc_value, traceback):
self.file.close()
# Использование:
with FileManager() as f:
f.write("Hello, world!")Пояснение: при входе в блок with вызывается __enter__, возвращаемый объект привязывается к имени после as (в примере f). При выходе из блока (with завершился или возникло исключение) вызывается __exit__, где мы закрываем файл. Возможные ошибки: забыть обработать параметры исключений в __exit__ (если вернуть False, исключение пробросится выше; если вернуть True, оно подавляется). Также интервьюер может уточнить про готовый декоратор contextlib.contextmanager из стандартной библиотеки, позволяющий писать контекстные менеджеры через генератор (с конструкцией yield). В ответе желательно упомянуть оба способа.
Вопрос: Что такое Singleton и как его реализовать в Python?
Что проверяют: Знание порождающих паттернов проектирования и понимание механики создания объектов в Python. Singleton – это паттерн, гарантирующий существование единственного экземпляра класса.
Разбор: В Python строгих приватных конструкторов нет, поэтому часто Singleton реализуют либо через переменную модуля (модуль сам по себе является синглтоном в смысле единственного объекта при импорте), либо переопределяя метод __new__. Например, через __new__:
class Singleton:
_instance = None
def __new__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
def __init__(self, value):
self.value = value
obj1 = Singleton(10)
obj2 = Singleton(20)
print(obj1 is obj2, obj1.value, obj2.value) # True 20 20Здесь при попытке создать новый объект мы возвращаем уже существующий _instance. Альтернативный простой подход: хранить единственный экземпляр в модуле и обращаться к нему. Подводные камни: Singleton может усложнять тестирование и не всегда оправдан. В Python зачастую вместо одиночек передают нужный объект в функции (внедрение зависимостей) или используют модули. Но знать классический паттерн полезно – интервьюер ожидает либо реализацию через __new__, либо упоминание, что импортируемый модуль сам единственен в рамках программы.
Вопрос: В чем разница между методами @staticmethod и @classmethod?
Что проверяют: Базовое понимание устройства классов в Python – какие методы привязаны к экземпляру, к классу, а какие вовсе не получают неявных параметров.
Разбор: Метод, помеченный декоратором @staticmethod, не получает ссылку ни на экземпляр (self), ни на класс (cls). Это по сути обычная функция, вложенная в пространство имён класса, и вызывается как MyClass.method() без аргументов кроме своих. Обычно статические методы используются для логически связанной утилитарной функции, которая не трогает состояние класса. Метод с @classmethod, напротив, получает первым аргументом класс (cls) и может, например, создавать экземпляры этого класса (return cls(…)). Класс-методы часто применяются как альтернативные конструкторы. Например:
class MyClass:
factor = 2
@classmethod
def make_with_factor(cls, base):
return cls(base * cls.factor)
@staticmethod
def is_string(obj):
return isinstance(obj, str)Здесь make_with_factor – метод класса, который знает про cls и может использовать атрибуты класса (factor) или вызвать конструктор cls(…). А is_string – статический метод, не зависящий от конкретного класса (его можно было бы вынести и на уровень модуля). Ошибки: на практике новички путаются, когда использовать что – если метод не использует ни состояние экземпляра, ни класс, можно делать его статическим (или вообще вынести наружу). Если нужен доступ к информации класса (например, разные подклассы должны иметь разное поведение), то применяется classmethod. Это знание достаточно базовое, и крупные компании ожидают, что middle-разработчик ответит уверенно.
Вывод: В части ООП от кандидата уровня Middle ждут уверенного знания ключевых концепций: принципы инкапсуляции (например, соглашения об именовании приватных атрибутов), наследование (включая множественное и MRO), полиморфизм и композицию. Полезно упомянуть, что Python поддерживает “duck typing” – типы определяются не наследованием от интерфейсов, а наличием нужных методов. Интервьюеры часто проверяют знание специальных методов (dunder-методов) для перегрузки операторов и протоколов – как мы рассмотрели выше. Грамотный кандидат покажет, что умеет проектировать классы, следуя принципам: например, предпочитать композицию наследованию там, где это уместно (что повышает модульность и снижает связность кода[6][7]).
Асинхронность (async/await)
Вопрос: Объясните, как работает асинхронное программирование в Python и зачем нужны async/await.
Что проверяют: Понимание модели кооперативной конкурентности в Python, умение объяснить роль цикла событий (event loop) и корутин. Middle-разработчик должен знать, в чем отличие асинхронности от потоков, и в каких случаях она дает выигрыш.
Разбор: Асинхронность в Python реализуется с помощью корутин – функций, объявляемых как async def, которые могут приостанавливаться на операциях ввода-вывода (через await). Ключевая идея в том, что одна нить выполнения (event loop) обслуживает множество задач, переключаясь между ними, когда те ожидают I/O. Это конкурентность (concurrency), но не параллельность на уровне потоков ОС. В процессе исполнения такой программы запускается цикл событий (asyncio.get_event_loop()), который планирует корутины к выполнению. Когда корутина доходит до await (например, await asyncio.sleep(1) или ожидание сетевого ответа), управление возвращается циклу, и он может переключиться на другую задачу. Таким образом, одна OS-тред выполняет по очереди множество задач, не простаивая на ожидании ввода-вывода. Простой пример:
import asyncio
async def fetch(url):
print(f"Запрос к {url}")
await asyncio.sleep(1) # имитация сетевого запроса
print(f"Получен ответ с {url}")
async def main():
await asyncio.gather(fetch("site1.com"), fetch("site2.com"))
asyncio.run(main())Здесь оба запроса выполняются конкурентно: пока первая корутина “ждет” (await) внутри sleep, цикл событий переключается на вторую. В результате общее время ~1 секунду, а не 2, несмотря на однопоточность. Интервьюеру важно услышать, что async/await – способ писать неблокирующий код синхронно выглядящим образом, и что выигрыши проявляются на большом количестве сетевых/файловых операций ввода-вывода. Для CPU–bound задач asyncio не ускорит исполнение, так как действует всё тот же GIL в единственном потоке.
Возможные ошибки в ответе: путаница concurrency vs parallelism. Следует подчеркнуть: асинхронность – это про конкурентность (многозадачность), но без создания параллельных потоков выполнения[8][9]. Также нужно упомянуть про event loop – центральный диспетчер, который управляет выполнением корутин.
Вопрос: Когда вы предпочтете использовать asyncio вместо многопоточности?
Что проверяют: Умение выбрать инструмент под задачу, знание ограничений GIL и разницы в моделяхConcurrency.
Разбор: Асинхронность стоит использовать, когда приложение сильно нагружено операциями ввода-вывода (сетевыми запросами, ожиданием файловых операций, запросами к БД и т.п.) и нужно масштабировать количество одновременных задач. Например, для чат-сервера, обработчика веб-запросов или web-scraper’а, где тысячи соединений простаивают в ожидании – asyncio позволит одному потоку обслужить их все без создания тысячи потоков ОС. С другой стороны, при CPU-интенсивных вычислениях (парсинг большого XML, вычисление математических моделей) asyncio не поможет загрузить несколько ядер, потому что из-за GIL Python-потоки не могут реально параллельно исполнять Python-байткод. В таких случаях лучше использовать multiprocessing или вынести вычисления в C-расширения. Кандидат должен четко дать критерий: I/O-bound задачи → async/await или многопоточность, CPU-bound задачи → многопроцессность или native threads via C. Асинхронность выигрывает по памяти и контекстным переключениям, т.к. не требует полноценного треда на каждую задачу.
Примечание: Часто спрашивают и в обратную сторону: “что происходит, если сделать блокирующий вызов внутри async функции?”. Ответ: он заблокирует весь event loop и приостановит все задачи. Например, вызов time.sleep(5) или длительная CPU-вычислительная функция внутри корутины остановит цикл на 5 секунд. Правильный подход – выносить блокирующие части в отдельный поток или процесс. В Python для этого есть метод loop.run_in_executor – он позволяет выполнить функцию в пуле потоков, не блокируя основной цикл. Это демонстрирует глубокое понимание модели asyncio.
Вопрос: Как запустить несколько асинхронных задач параллельно и дождаться результатов?
Что проверяют: Владение практическими аспектами asyncio: умение работать с Tasks и синхронизировать их.
Разбор: В asyncio есть несколько способов конкуррентного запуска: высокоуровнево – функции вроде asyncio.gather или asyncio.wait. Например, чтобы одновременно отправить несколько запросов и получить результаты, используется await asyncio.gather(*tasks), где tasks – список корутин (или уже созданных Task-объектов через asyncio.create_task). Интервьюер ожидает либо упоминания gather, либо описания, что корутины запускаются и управление возвращается циклу, позволяя другим выполняться. Также могут спросить, как отменить задачу – ответ: у Task объекта вызвать .cancel(), и при следующей точке ожидания внутри корутины выбросится asyncio.CancelledError. Ещё один нюанс: запуск event loop. В современных версиях используется asyncio.run(my_coro()) для старта программы (он сам создаёт и сразу закрывает цикл). Нельзя вызывать дважды asyncio.run внутри уже запущенного цикла – это вызовет ошибку. Нужно использовать либо вложенный await, либо создать отдельный поток для нового цикла. Эти детали иногда всплывают в вопросах, чтобы проверить, гуглил ли кандидат распространённые ошибки (“RuntimeError: event loop is closed” и т.п.). В ответе достаточно уверенно рассказать, что для параллельного выполнения корутин следует использовать asyncio.gather или create_task, а для синхронизации – await их.
Вывод: Темы асинхронности относительно новые, но на позицию Middle ожидается понимание, почему введён asyncio и где он полезен. В крупных веб-компаниях (типа Google, Amazon) могут спросить концептуально: “как масштабировать сервер на Python под тысячи соединений?” – ожидая услышать про асинхронный подход. Ключевые моменты: async/await экономят ресурсы на ожидании I/O, но не ускоряют вычисления (т.к. не обходят GIL). Нужно уметь сравнить три модели конкурентности Python – потоки, процессы, асинхронность[10], и выбрать правильно. Отвечая, подчеркните, что asyncio — про конкурентность без новых потоков, и что код под него пишется иначе, чем синхронный (нужно оперировать корутинами, await-ами и пр.).
Многопоточность и multiprocessing
Вопрос: Чем отличаются многопоточность и многопроцессность в Python? Когда какой подход лучше использовать?
Что проверяют: Глубокое понимание ограничения GIL, умение объяснить, почему потоки не дают прироста на CPU-задачах, а процессы – дают. Также ожидается знание практических деталей: обмен данными между потоками/процессами, накладные расходы.
Разбор: Многопоточность (модуль threading) в Python реализует параллелизм задач внутри одного процесса. Однако интерпретатор CPython имеет Global Interpreter Lock (GIL) – глобальную блокировку, позволяющую исполняться только одному потоку Python-байткода в единицу времени. Это значит, что два потока не могут реально параллельно выполнять Python-инструкции на разных ядрах. Они могут лишь чередоваться. Исключение – если один поток уходит в ожидание ввода-вывода или выполняет внешнюю Си-функцию (например, численные операции NumPy освобождают GIL), тогда другой поток может исполняться. Многопроцессность (модуль multiprocessing) запускает несколько процессов с собственной памятью и интерпретатором, поэтому каждый из них имеет свой GIL. Это позволяет реально параллельно выполнять код на разных ядрах CPU. Процессы изолированы, и обмен данными между ними сложнее – через очереди, каналы, сокеты или общий memory mapping. Когда что использовать: для задач, нагружающих CPU (численные расчёты, обработка изображений и т.п.), в чистом Python выгоднее запускать несколько процессов, разделяя работу между ними – так можно задействовать несколько ядер и обойти GIL[11][12]. Например, с помощью multiprocessing.Pool можно распределить вычисление по процессам. Для задач ввода-вывода (много ожидания сетевых ответов, файловых операций) зачастую проще использовать потоки: GIL не мешает, потому что пока поток ждёт I/O, интерпретатор автоматически переключится на другой поток. Таким образом, потоки годятся для I/O-bound (с учётом, что каждый поток также может привлечь C-библиотеки без GIL), а процессы – для CPU-bound.
Пример (демонстрация GIL): предположим, мы хотим посчитать большую сумму. Запустим два потока против одного:
import time, threading
COUNT = 10**7
def countdown(n):
while n:
n -= 1
# Однопоточно
t0 = time.time()
countdown(COUNT)
print("1 thread:", time.time() - t0, "sec")
# Два потока
t0 = time.time()
t1 = threading.Thread(target=countdown, args=(COUNT//2,))
t2 = threading.Thread(target=countdown, args=(COUNT//2,))
t1.start(); t2.start()
t1.join(); t2.join()
print("2 threads:", time.time() - t0, "sec")На CPython оба варианта займут примерно одинаковое время, а иногда версия с потоками даже медленнее из-за накладных переключений[13][14]. Причина – GIL не позволил двум потокам считать одновременно, они работали по очереди на одном ядре. Если же заменить потоки на два процесса через multiprocessing.Process, то время почти в 2 раза сократится (каждый процесс занял своё ядро). Этот опыт ожидается в ответе: упоминание, что GIL – главная причина, почему потоки не масштабируют CPU-загрузку[15].
Возможные подводные камни: Необходимо отметить, что создание процессов тяжелее потоков (создается новый интерпретатор, копируется память). Поэтому для очень большого числа параллельных задач или короткоживущих задач потоки/асинхронность могут быть лучше. Также в Python есть concurrent.futures – абстракция, позволяющая легко запускать и потоки, и процессы через единый интерфейс (ThreadPoolExecutor vs ProcessPoolExecutor). Интервьюер может спросить, как поделиться данными между процессами – правильный ответ: через multiprocessing.Queue, Pipe или менеджер, либо использовать общую память (модуль multiprocessing.shared_memory). Межпоточное взаимодействие проще – общие объекты в памяти и примитивы синхронизации (Lock, Event и т.д.). Кандидату важно упомянуть про защиту общих данных в многопоточной среде: поскольку потоки разделяют память, могут возникать гонки. Нужно использовать блокировки (Lock) или безопасные очереди (queue.Queue) для координации. Эта тема может всплыть с вопросом “как обеспечить thread-safety?”. Ответ: с помощью механизмов синхронизации, или избегать изменяемого общедоступного состояния (иммутабельность, локальные копии данных).
Вопрос: Что такое GIL и почему он существует в Python?
Что проверяют: Историческое и техническое понимание ограничения интерпретатора.
Разбор: GIL (Global Interpreter Lock) – это глобальная мутекс-блокировка в интерпретаторе CPython, которая не дает двум потокам одновременно выполнять байткод. Он был введен для упрощения реализации интерпретатора: обеспечивать безопасность памяти при взаимодействии с С-расширениями и сборщиком мусора без тонких локов на каждую мелкую операцию[16][17]. Положительный эффект – однопоточные программы немного выигрывают в скорости за счет отсутствия лишних локов, и интеграция с несостоятельными к потокам Си-библиотеками проще. Минус – невозможность полноценно использовать многопроцессорность через threading. Важно отметить, что альтернативные реализации Python (Jython, IronPython) не имеют GIL, но CPython по-прежнему доминирует, и GIL в нем остается из соображений совместимости и производительности однопоточного кода[18][19]. В ответе достаточно сказать: “GIL – глобальная блокировка интерпретатора, сделанная для упрощения памяти и потокобезопасности; из-за нее один Python-процесс не масштабируется на несколько ядeр через потоки”. Также можно упомянуть, что сообщество пыталось убрать GIL, но столкнулось с падением производительности или сложностями; поэтому его убирают неохотно. Например, усилия Gilectomy идут, но пока не включены в мейнлайн. Для обхождения GIL на практике – либо переход на multiprocessing, либо вынесение вычислительной нагрузки в C (например, numpy или написание расширений).
Вывод: При обсуждении потоков и процессов кандидат должен уверенно оперировать терминами I/O-bound vs CPU-bound, знать про GIL и его эффекты[15]. Современные интервью нередко включают мини-задачи: написать параллельный код и найти, почему не получен прирост (ожидается ответ: “в Python нужна multiprocessing для параллельности CPU, т.к. GIL”). Также хорошо упомянуть инструменты: threading vs multiprocessing, concurrent.futures для упрощения, примитивы синхронизации. Компании вроде Amazon и Stripe ценят практические примеры, поэтому мы привели код выше – он наглядно демонстрирует, что просто использовать потоки для ускорения вычислений – ошибка[13]. Правильный вывод: потоки – для задач с ожиданием, процессы – для тяжёлых вычислений, при этом нужно учитывать накладные расходы и сложность коммуникации.
Основы архитектуры
Вопрос: Как вы подходите к проектированию приложений и обеспечению поддерживаемости кода?
Что проверяют: Общую инженерную культуру: знает ли кандидат принципы SOLID, умеет ли разбивать систему на модули, писать чистый код, использовать инструменты контроля качества. На уровне Middle ожидают знакомство с этими концепциями.
Разбор: Тут нет единственно верного ответа, но хороший кандидат упомянет несколько ключевых практик: разделение ответственности (Single Responsibility – каждый модуль/класс отвечает за свою функцию), слабую связность и высокую сцепленность (код организован в независимые компоненты, которые общаются через четко определенные интерфейсы), Dependency Injection (в Python проще – передача зависимостей через параметры или атрибуты вместо жёсткого создания внутри). Также стоит упомянуть написание тестов (Unit-тесты) и принцип TDD/BDD как средство поддерживать архитектуру чистой. Инструменты статического анализа кода – linters (flake8, pylint) и форматтеры (black) – помогают поддерживать стиль и выявлять проблемы ранно. Документирование и понятные имена – важная часть. Интервьюер может спросить: “Как бы вы улучшили существующий запутанный код?” – ожидается рассказ про рефакторинг: выделение функций, удаление дублирования, покрытие тестами, постепенное улучшение дизайна.
Совет: Хорошо, если кандидат упомянет реальные примеры. Например: “В моем прошлом проекте мы разделили слой бизнес-логики и доступа к данным, что следовало принципу разделения ответственности и позволяло тестировать логику отдельно от базы данных”. Это покажет практическое понимание архитектурных решений.
Вопрос: Чем отличается фреймворк от библиотеки?
Что проверяют: Понимание высокоуровневых архитектурных терминов, умение выразить мысль четко.
Разбор: Классический ответ: “Inversion of Control” (переворот управления). Библиотека – это набор функций/классов, которые мы вызываем при необходимости. Фреймворк же сам управляет потоком выполнения, вызывая наш код по нужным точкам (наши обработчики, настройки). То есть, при использовании библиотеки контроль остается у разработчика, а при использовании фреймворка – у фреймворка. Пример: Flask можно назвать фреймворком веб-приложений – он сам принимает запросы и вызывает наши функции-контроллеры. А библиотека Requests – мы сами решаем, когда и как вызвать requests.get(). Интервьюер ожидает именно такой ответ.
Вопрос: Что такое “monkey patching” и допустимо ли его применять?
Что проверяют: Знание динамической природы Python, способность критически оценивать нестандартные приёмы.
Разбор: Monkey patching – это динамическая подмена кода во время выполнения. Например, переопределение функции или метода “на лету” в уже импортированном модуле. В Python это возможно, т.к. все является объектом и ссылки можно переназначать. Интервьюеры в крупных компаниях любят спросить об этом явлении, потому что оно демонстрирует знания о внутренностях языка и о том, что такой приём рискован. Ожидается ответ: да, Python позволяет monkey patching (например, заменить метод класса в runtime), но использовать это следует очень осторожно. Частый допустимый кейс – в тестировании, когда с помощью библиотеки типа unittest.mock мы временно подменяем функцию, чтобы изолировать внешний вызов. В боевом же коде монкипатчить чужие модули – плохая практика, так как ухудшает поддержку: сложно отследить, что и где было подменено. Например, можно вручную присвоить module.function = my_function для перехвата вызовов – но если это сделать глобально, другой код, рассчитывающий на оригинальное поведение, может сломаться. Таким образом, правильный ответ: Monkey patching – подмена атрибутов/методов модулей или классов в runtime. Применяется в основном для тестов или hot-fix’ов, но несет риски и в продакшене обычно не используется без крайней необходимости. Упоминание этого покажет, что кандидат знает продвинутые возможности языка, но также понимает архитектурные минусы.
Вопрос: Почему часто говорят “композиция предпочтительнее наследования”?
Что проверяют: Знание принципов ООП-дизайна, умение объяснить преимущества слабой связности.
Разбор: Этот вопрос – классика дизайна. Идея: наследование жестко связывает классы (сильная зависимость родитель-потомок), изменения в суперклассе могут неожиданно аукнуться в подклассах (проблема хрупкой базы). Композиция же означает, что вы включаете объект одного класса внутрь другого (отношение “имеет” вместо “является”). Это более гибко: можно менять внутренние части без влияния на внешнее API. Также композиция позволяет динамически комбинировать поведения, тогда как наследование задано статически. Интервьюер ожидает таких доводов. Можно упомянуть, что Python не ограничивает множественное наследование, но это еще более усложняет иерархии – зачастую лучше внедрить нужный функционал через атрибут (композицию) или миксин, чем делать глубокую иерархию наследников. Ссылаясь на известное правило: “Prefer composition over inheritance”, можно отметить, что композиция ведет к более модульному, легко модифицируемому коду[6]. Например, вместо наследования класса Car от Engine, лучше сделать Car имеющим Engine – тогда можно менять тип двигателя без переписывания иерархий. В ответе стоит также указать, что наследование уместно, когда есть строгие отношения “является” (например, Круг – подкласс Фигуры), а композиция – когда отношения “имеет” (Автомобиль имеет двигатель, имеет колеса). Такой ответ продемонстрирует зрелое понимание архитектурных решений.
Вывод: В разделе архитектуры важно показать, что вы не просто пишете код, но и умеете его организовать и поддерживать в долгой перспективе. Современные компании (Stripe, Notion и др.) ценят, когда разработчик знаком с принципами чистого кода. В ответах хорошо упоминать: SOLID, DRY, KISS – и сразу коротко пояснять, как это отражается в коде на Python. Например, “я избегаю дублирования кода (DRY), вынося повторяющуюся логику в общие функции или микросервисы”. Также полезно показать знание инструментов: линтеры, форматтеры, типизация (Python typing) – все это части поддерживаемости. Если задают вопрос типа “как спроектировать…”, структурируйте ответ: уточните требования, выделите компоненты, опишите взаимодействие. На уровне Middle не ждут идеального UML-диаграммного решения, но важна грамотная декомпозиция. Главное – продемонстрировать, что вы думаете о читаемости и сопровождении кода, а не только о том, чтобы он “работал”.
Python в контексте задач ИИ и данных
Вопрос: Как эффективно распарсить и проанализировать очень большой лог-файл с помощью Python? (реальный вопрос Amazon[20])
Что проверяют: Умение работать с большими данными, знание Python-инструментов для этого, понимание ограничений памяти и времени.
Разбор: Ключевой момент – не пытаться читать весь файл целиком в память, а обрабатывать стримингом. Правильный подход: открыть файл и читать построчно (итерация по файловому объекту в Python уже читает лениво построчно). Например:
with open(‘logs.txt’) as f:
for line in f:
# обработка линии
Таким образом, в памяти хранится только текущая строка, а не весь файл. Если нужна параллельная обработка, можно разбить файл на части (по позициям или по разделению на несколько файлов) и воспользоваться multiprocessing (каждый процесс обрабатывает свой кусок) – однако синхронизация результатов потребует дополнительной работы. Также, если лог-файл структурированный (JSON Lines, CSV), можно использовать модули вроде pandas в режиме чтения чанками: pandas.read_csv(…, chunksize=10000), перебирая по 10000 строк. Это позволит пользоваться мощью pandas, не держа весь набор данных сразу. Оптимизация анализа: Если мы ищем определенные паттерны, можно использовать регулярные выражения (модуль re) – их стоит скомпилировать заранее для скорости. Если агрегируем данные (например, подсчет частот), эффективно использовать структуры вроде collections.Counter или defaultdict(int). Вопрос от Amazon предполагает ответ, где кандидат покажет осведомленность о больших данных: возможно, упомянет, что для экстремально больших логов (гигабайты) Python может быть медленным, и тогда стоит рассмотреть утилиты вроде Apache Spark или языки типа Scala/Java. Но даже без этого, важно: итерация чанками, ленивое чтение, использование эффективных библиотек (pandas, numpy) для обработки. Возможно, ожидается и mention AWS-specific: например, “залить логи в S3 и использовать Amazon Athena (SQL on S3)”, однако в контексте Python-разработчика скорее интересует именно код на Python. Не забывайте упомянуть, что парсинг можно распараллеливать по CPU, если I/O позволяет (например, файл на SSD). И обязательно – профилировать узкие места: возможно, самым медленным окажется парсинг строк, и стоит использовать csv или json модуль, которые написаны на C. Такой развернутый ответ покажет зрелый подход к оптимизации.
Вопрос: Объясните разницу между list comprehension и генераторным выражением. Когда какой использовать и почему? (реальный вопрос Amazon[20])
Что проверяют: Понимание Python-идиом для создания списков/итераторов, и осознание влияния на потребление памяти.
Разбор: List comprehension (списковое включение) – это конструкция в квадратных скобках, сразу создающая список в памяти. Например: [x*x for x in range(1000)] создаст список из 1000 элементов. Generator expression (генераторное выражение) – то же, но в круглых скобках, возвращает объект-генератор, который по запросу выдаёт элементы. Например: (x*x for x in range(1000)) сам по себе не вычисляет ничего, а при итерации будет генерировать значения. Разница: list comp вычисляет сразу все результаты и хранит их, generator expr – ленивый, отдаёт по одному. Соответственно, генераторные выражения экономят память на больших данных. Например, если нужно просто один раз пройтись по вычисленным значениям, нет смысла держать их список – генератор лучше. Однако, генератор можно итерировать только один раз (он “исчерпаемый”), тогда как список – произвольно. Когда использовать: Если требуется многократно обращаться к результатам или случайный доступ – нужен список. Если же мы фильтруем/преобразуем большой поток данных и каждое значение используем однократно (например, читаем файл строчка за строчкой и сразу обрабатываем) – генератор идеально подходит. В ответе хорошо упомянуть, что генераторы позволяют обрабатывать последовательности, превышающие память, “по частям”. Также list comprehension обычно чуть быстрее на небольших объёмах, потому что выполнен на C уровне целиком, но плата – память. А генераторы могут немного медленнее при итерации из-за интерпретатора, но масштабируются на большие объёмы.
Пример:
import sys
lst = [i for i in range(1000000)]gen = (i for i in range(1000000))
print(len(lst), sys.getsizeof(lst)) # 1000000 и размер списка в байтах
print(sys.getsizeof(gen)) # размер объекта-генератора (очень малый)
Вы увидите, что список занимает много памяти, а генератор – всего несколько десятков байт, вне зависимости от “длины” последовательности. Это наглядно подтверждает: генераторы эффективны по памяти. Интервьюер хочет услышать именно это – “списковое включение возвращает список, генераторное – итератор; генератор ленивый (lazy), поэтому экономит память, но каждое значение вычисляется на лету”[21].
Вопрос: Почему NumPy часто используется в задачах машинного обучения и чем он лучше обычных Python-списков?
Что проверяют: Понимание, как Python справляется с вычислениями в наукоёмких задачах, знание про векторизацию и внутреннее устройство NumPy.
Разбор: NumPy – библиотека для эффективных многомерных массивов. Главные преимущества: (1) компактное хранение данных в непрерывном блоке памяти (без накладных объектов Python на каждый элемент), (2) реализация вычислений на C (без участия интерпретатора для каждой операции). Обычные списки Python хранят элементы как объекты, каждое число – полноценный Python int с собственным управлением, и список хранит лишь ссылки (указатели) на них[22]. Это гибко (список может содержать объекты разных типов), но очень неэффективно по памяти и скорости для больших числовых вычислений[23]. NumPy же хранит массив одного типа (например, float64) подряд, как Си-массив. Поэтому он занимает в разы меньше памяти (нет накладных на объекты и указатели) – например, массив из миллиона чисел может занять ~8 MB, тогда как список из миллиона Python-чисел займёт десятки мегабайт[24][25]. И операции в NumPy реализованы на низком уровне: когда вы пишете A + B для numpy-массивов, выполняется высокопроизводительный C/форTRAN код, часто с векторизацией SIMD. Это приводит к ускорению в порядке десятков раз и более по сравнению с Python-циклом. Почему это важно для ИИ: задачи в ML/DL оперируют большими матрицами, и Python сам по себе слишком медленный для этого. Но используя NumPy, Pandas, TensorFlow, PyTorch – мы под капотом вызываем оптимизированный код. Поэтому Python стал популярен в AI: он предоставляет удобный язык обвязки, а тяжелые вычисления происходят на C/C++/CUDA. В ответе стоит упомянуть, что “Python медленный, но за счёт библиотек как NumPy мы получаем C-производительность”. Также отметить удобство: NumPy предоставляет множество функций (линейная алгебра, статистика) и позволяет писать код в высокоуровневом стиле (операции над массивами целиком, а не явные loops)[26][27]. Это облегчает разработку и уменьшает вероятность ошибок.
Пример подтверждения: Если спросить, в чём разница, можно привести тест:
import numpy as np, time
N=10_000_000
lst = list(range(N))
t0=time.time(); sum(x*x for x in lst); print(“Python sum:”, time.time()-t0)
arr = np.arange(N, dtype=np.int64)
t0=time.time(); np.sum(arr*arr); print(“NumPy sum:”, time.time()-t0)
Практически всегда NumPy вариант будет на порядок быстрее. По памяти тоже: один элемент int64 в numpy – 8 байт, а один Python int – 28 байт (на 64-разрядной системе) плюс накладные расходы списка на хранение референсов[25].
Интервьюер может уточнить про “векторизацию”: это как раз исполнение операций сразу над всей коллекцией элементов, без Python-цикла. Хорошо, если кандидат упомянет это слово.
Аналитике данных
Ниже — компактный, но насыщенный гайд для data-аналитика: актуальные темы собеседований, реальные вопросы (с указанием источника) и готовые паттерны решений: SQL, Pandas/EDA, визуализация, A/B-тесты и статистика, продуктовые метрики и тайм-серии.
1) SQL-аналитика (ядро 80% собеседований)
Вопрос (реальный): «Города со средней ценой выше национальной»
Источник: DataLemur (вариация Zillow) — сравнить среднюю цену по городу со средней по всей стране. DataLemur
Идея: агрегируете по city, сравниваете с глобальным AVG во вложенном подзапросе.
SELECT city
FROM zillow_transactions
GROUP BY city
HAVING AVG(mkt_price) > (SELECT AVG(mkt_price) FROM zillow_transactions)
ORDER BY city;
Что проверяют: GROUP BY + HAVING по агрегату, понимание, что фильтр по агрегату не в WHERE.
Вопрос (реальный): «Топ-N по сумме метрики с учетом тай-брейка»
Источник: наборы Google SQL Q (2025) / DataLemur. DataLemur+1
Идея: агрегируете, затем оконная функция для ранга; выбираете rnk <= N.
WITH s AS (
SELECT user_id,
SUM(distance) AS total_km
FROM rides
GROUP BY user_id
)
SELECT user_id, total_km
FROM (
SELECT s.*,
RANK() OVER (ORDER BY total_km DESC, user_id) AS rnk
FROM s
) t
WHERE rnk <= 10;
Что проверяют: оконные (RANK/ROW_NUMBER), адекватный тай-брейк, объяснение различий RANK vs DENSE_RANK.
Вопрос (реальный): «Exclusive users / anti-join»
Источник: StrataScratch (частые для DA). StrataScratch+1
Идея: посчитать, кто закреплён только за одним клиентом.
WITH counts AS (
SELECT employee_id, COUNT(DISTINCT engagement_id) AS c
FROM staffing
GROUP BY employee_id
)
SELECT e.client_name,
COUNT(DISTINCT s.employee_id) AS total,
COUNT(DISTINCT CASE WHEN c.c = 1 THEN s.employee_id END) AS exclusive
FROM staffing s
JOIN engagement e ON e.engagement_id = s.engagement_id
JOIN counts c ON c.employee_id = s.employee_id
GROUP BY e.client_name
ORDER BY e.client_name;
Что проверяют: подзапросы/CTE, условные агрегаты, аккуратный DISTINCT.
2) Pandas / EDA (быстрый анализ без SQL)
Шаблон: «top-k аномалий по метрике в группе»
import pandas as pd
# df: [city, price]
g = df.groupby('city', as_index=False).agg(avg_price=('price', 'mean'))
top = g.nlargest(10, 'avg_price')
Объясните: когда groupby возвращает индекс vs колонку, когда nlargest быстрее, чем sort_values().head().
Вопросы по Pandas (ожидаемые)
Типовые срезы из свежих подборок (время серии, merge, pivot, apply vs vectorize). DataCamp+1
Мини-паттерны:
# 1) Скользящее окно по времени
df = df.sort_values('ts').set_index('ts')
roll = df['value'].rolling('7D', min_periods=3).mean()
# 2) "Top within group" (эквивалент ROW_NUMBER=1)
out = (df.sort_values(['city','value'], ascending=[True,False])
.groupby('city').head(1))
3) Визуализация и сторителлинг
Ожидают: 1–2 уместных графика, читаемые подписи, «ошибки визуализации» (ось Y, лог-масштаб, агрегации). На практике — Matplotlib/Seaborn/Plotly. (Подготовьте короткий питоновский сниппет + пояснение выбора типа графика под цель.)
4) A/B-тесты, статистика, метрики
Вопрос (реальный): «Как выбрать длительность A/B-теста и мощность?»
Свежая подборка DataLemur (2025): дизайн, метрики, power, pitfalls. DataLemur
Короткий фреймворк ответа:
- Z- или t-тест (зависит от известной дисперсии/размера, ЦПТ).
- α (обычно 0.05), β/мощность (≥80%), ожидаемый effect size.
- Сэмпл-сайз калькулятор, стратификация/кластеризация, сезонность.
- Guardrail-метрики и SRM-чек (sample ratio mismatch).
Вопрос (реальный): «Топ метрик и trade-offs»
Интервью-срезы: Interview Query (2025) и подборки A/B Q. Interview Query+1
Ответ-шаблон: определите primary metric (North Star), lag/lead, чувствительность, задержки, конфликт метрик → приоритизация по бизнес-цели.
Мини-код: z-тест пропорций (быстро объяснить на доске)
import numpy as np
from math import sqrt
# конверсия A/B
p1, n1 = 0.047, 50000
p2, n2 = 0.051, 50000
p_pool = (p1*n1 + p2*n2)/(n1+n2)
se = sqrt(p_pool*(1-p_pool)*(1/n1 + 1/n2))
z = (p2 - p1)/se
# интерпретируете z через нормальное распределение (|z|>1.96 ~ p<0.05)
5) Продуктовые кейсы (аналитик в компании)
Типовые вопросы: «Почему упал DAU?», «Как измерить успех фичи?», «Сегментируйте пользователей». Структура:
- явно выбираете единицу анализа и окна времени,
- строите фанел и координационные срезы,
- показываете SQL/Pandas-костяк и визуал «до/после».
6) Тайм-серии (анализ тренда/сезонности)
Подборки вопросов (хоть и классические, всё ещё спрашивают): тренд/сезонность/шум, скользящие окна, эксп. сглаживание, отличие MA/AR/ARIMA, детрендинг/десезонализация. Analytics Vidhya
Паттерн в Pandas:
import pandas as pd
s = (df
.set_index('date')
.asfreq('D')['metric']
.sort_index()
.ffill())
trend = s.rolling(28, min_periods=14).mean()
season = s - trend
7) Набор быстрого ответа (cheat-sheet)
SQL:
HAVINGпо агрегату, оконные:ROW_NUMBERvsRANK/DENSE_RANK, anti-join (LEFT JOIN ... WHERE right.id IS NULL), условные агрегатыSUM(CASE...).- Нормализуйте, но помните про денормализацию для BI.
Pandas:
groupby + agg,transform(перенос агрегата на уровень строк),merge_asofдля событий по времени,pd.Grouper(freq='W')для календарной агрегации.
A/B:
- SRM-чек, guardrails, MDE→n, доверительные интервалы, множественные сравнения (Bonferroni/Benjamini–Hochberg).
8) Мини-трек подготовки с «реальными» задачами
- SQL тренажёры с реальными кейсами: DataLemur (Google/DA SQL, общий пул), StrataScratch (разборы), Interview Query (карта тем 2025). Interview Query+5DataLemur+5DataLemur+5
- A/B и статистика: свежие списки Q&A и фреймворки. DataLemur+2Interview Query+2
- Pandas-вопросы: актуальные подборки (включая time-series/merge/pivot). DataCamp+1
Приложение: короткие «сухие» ответы (для live-coding/whiteboard)
- Top-1 per group (SQL)
SELECT *
FROM (
SELECT t.*,
ROW_NUMBER() OVER (PARTITION BY city ORDER BY price DESC) AS rn
FROM homes t
) x
WHERE rn = 1;
- Cohort retention (Pandas)
users['signup_month'] = users['signup'].dt.to_period('M')
ev['month'] = ev['ts'].dt.to_period('M')
cohort = (ev.merge(users[['user_id','signup_month']], on='user_id')
.assign(age=lambda d: (d['month'] - d['signup_month']).apply(lambda p: p.n))
.groupby(['signup_month','age'])['user_id'].nunique()
.unstack(fill_value=0))
retention = cohort.div(cohort[0], axis=0)
- AB uplift + CI (быстрый скелет)
import numpy as np
p1, n1 = conv_A/vis_A, vis_A
p2, n2 = conv_B/vis_B, vis_B
uplift = p2 - p1
# Wald CI:
from math import sqrt
se = sqrt(p1*(1-p1)/n1 + p2*(1-p2)/n2)
ci = (uplift - 1.96*se, uplift + 1.96*se)
Итог
Если у вас ограничено время, тренируйте связку: (SQL оконные + HAVING) → Pandas groupby/merge → A/B-дизайн + power → тайм-серии rolling. Для каждого блока выше есть «реальные» источники и точечные сниппеты — используйте их как опорный набор перед интервью.
Вопрос: Какие библиотеки Python вы бы использовали для решения задачи машинного обучения (без углубления в модели)?
Что проверяют: Знание экосистемы Python для Data Science/ML на базовом уровне. Middle-разработчик, даже не специалист по ML, ожидаемо знаком с основными инструментами.
Разбор: На такой вопрос стоит перечислить основные библиотеки и кратко их роль: NumPy – для базовых операций с массивами и линейной алгебры, Pandas – для обработки таблиц/данных (удобно работать с CSV, SQL данными, делать агрегаты), scikit-learn – классическая библиотека машинного обучения (содержит реализации алгоритмов классификации, регрессии, кластеризации, подготовку признаков и пр., позволяет быстро построить модель без написания всего с нуля). Можно упомянуть Matplotlib/Seaborn для визуализации данных, чтобы показать умение представлять результаты. Если контекст подразумевает “AI” шире, можно сказать: для глубокого обучения используют TensorFlow или PyTorch, но это уже тяжёлая артиллерия – хоть и хорошо известная. Так как условие было “но не углубляясь в ML”, возможно, они ожидают ответ скорее про data processing: например, “использовал бы Pandas для очистки и агрегирования данных, NumPy для числовых операций, а готовые библиотеки вроде scikit-learn чтобы применить базовые модели (решающее дерево, Random Forest и т.п.)”. Можно добавить: “для развертывания модели рассмотрел бы Flask/FastAPI для API, но это уже вокруг ML инфраструктура”.
Почему Python доминирует в ИИ: потому что имеет эти библиотеки, плюс простота языка позволяет быстро писать экспериментальный код. Иногда интервьюер хочет удостовериться, что вы осознаете – Python сам не быстрый, но экосистема делает его эффективным для ML. Можно сказать: “Python выступает как клей: на нём удобно оркестрировать вызовы высокопроизводительных библиотек (на C/C++/CUDA), поэтому он стал фактическим стандартом в Data Science”. Такой уровень рассуждения покажет вашу зрелость как инженера.
Вывод: Python – язык выбора для науки о данных и ИИ не потому, что он быстр, а благодаря богатому набору библиотек. На интервью по Python могут спросить что-то из этой области, даже если позиция не Data Scientist, чтобы проверить широту кругозора. Мы рассмотрели вопросы, которые реально задавались: про парсинг логов (актуально для больших платформ), про list vs generator (проверка на понимание памяти) и про использование NumPy. Для успешного ответа стоит помнить главные тезисы: генераторы – ленивые, экономят память[23], NumPy/пандемы – используют C оптимизации, существенно выигрывая в скорости и памяти над чистым Python[24]. Также продемонстрируйте знакомство с основными библиотеками для ML/AI – это плюс даже на бэкенд позиции, т.к. показывает ваш интерес к современным технологиям.
[1] [2] [3] [4] When Should You Use .__repr__() vs .__str__() in Python? – Real Python
[5] [2025] Python Interview Questions for Experienced Developers – Web Asha Technologies
[6] [7] Composition vs Inheritance | DigitalOcean
[8] [9] GitHub – Devinterview-io/concurrency-interview-questions: Concurrency interview questions and answers to help you prepare for your next software architecture and design patterns interview in 2025.
[10] Python Interview Questions. Part III. Senior
[11] [12] [13] [14] [15] [16] [17] [18] [19] What Is the Python Global Interpreter Lock (GIL)? – Real Python
[20] [21] Amazon Data Scientist Interview Guide (27 Questions Asked in 2025)
[22] [23] [24] [25] [26] [27] arrays – What are the advantages of NumPy over regular Python lists? – Stack Overflow
+1
+1
1
+1
+1
1
+1
