Питання на співбесіді Python-розробника

Список (list) змінюваний: елементи можна додавати, видаляти й змінювати. Кортеж (tuple) незмінний, тому його можна використовувати як ключ словника, і він трохи економніший за пам'яттю.

Кортежі зручні для фіксованих наборів даних, наприклад координат (x, y) або повернення кількох значень із функції, списки — для колекцій, що змінюються.

Значення за замовчуванням обчислюється один раз — під час визначення функції. Тому def add(item, items=[]) використовує той самий список при кожному виклику, і елементи накопичуються.

Правильно: def add(item, items=None): і всередині if items is None: items = [].

Генератор — функція з yield, яка повертає значення по одному і зберігає свій стан між викликами. Значення обчислюються ліниво, тому генератор не тримає всі дані в пам'яті.

Наприклад, для обробки файлу на кілька гігабайтів рядок за рядком генератор використовує мінімум пам'яті, тоді як список зі всіма рядками міг би її вичерпати.

Віртуальне оточення ізолює залежності проєкту: різні проєкти можуть використовувати різні версії бібліотек без конфліктів.

Сьогодні часто використовують uv — він швидко створює оточення, встановлює залежності й фіксує їхні версії в lock-файлі. Класичні варіанти — venv + pip або Poetry.

Декоратор — функція, що приймає функцію і повертає нову, розширюючи поведінку без зміни коду оригіналу.

import functools, time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        print(f'{func.__name__}: {time.perf_counter() - start:.3f}s')
        return result
    return wrapper

functools.wraps зберігає ім'я й документацію оригінальної функції — про це часто забувають.

GIL (Global Interpreter Lock) у CPython дозволяє виконувати байт-код лише одному потоку одночасно. Тому потоки не прискорюють CPU-задачі, але добре працюють для I/O — під час очікування GIL звільняється.

Для обчислень використовують multiprocessing, нативні бібліотеки (NumPy) або винесення в інші мови. Починаючи з Python 3.13 існує експериментальна збірка без GIL (free-threaded), а в 3.14 її офіційно підтримують — але багато бібліотек ще адаптуються.

asyncio ефективний, коли застосунок переважно чекає: тисячі мережевих запитів, вебсокети, звернення до зовнішніх API. Один потік обслуговує багато задач, перемикаючись на await.

Не варто: для CPU-задач і коли весь стек синхронний — один блокуючий виклик (requests, синхронний драйвер БД) зупиняє весь event loop. Таке виносять у asyncio.to_thread або використовують асинхронні бібліотеки (httpx, asyncpg).

Основні інструменти:

• select_related для зв'язків ForeignKey/OneToOne (JOIN);
• prefetch_related для ManyToMany та зворотних зв'язків (окремий запит);
• only() / values() — щоб не тягнути зайві колонки;
• індекси на полях фільтрації й сортування;
• bulk_create / bulk_update замість циклу зі save().

Виявляють проблеми через django-debug-toolbar, логування SQL або assertNumQueries у тестах.

Ключові питання — надійність, вартість і якість:

• виклики моделі — асинхронно або через черги, з таймаутами й повторами;
• структуровані відповіді (JSON Schema, Pydantic) та валідація результату;
• кешування однакових запитів, ліміти токенів і моніторинг витрат;
• RAG для відповідей за власними документами: векторний пошук + контекст у промпті;
• набір тестових прикладів (evals), щоб порівнювати якість при зміні промпту чи моделі;
• захист від prompt injection і контроль персональних даних.

Добре навести приклад: що вимірювали і як зменшили кількість помилок.

Типовий стек — Celery, RQ, Dramatiq або arq з брокером (Redis, RabbitMQ). Задачі мають бути ідемпотентними, з обмеженою кількістю повторів і експоненційною затримкою.

Важливі деталі: таймаути, окремі черги для повільних і швидких задач, dead-letter для задач, що постійно падають, моніторинг довжини черги (Flower, Prometheus). Не можна передавати в задачу ORM-об'єкти — лише ідентифікатори, бо дані можуть змінитися.

Анотації типів разом із mypy або pyright знаходять помилки до запуску, полегшують рефакторинг і роблять код самодокументованим. Pydantic і dataclasses дають валідацію даних на межах системи.

У великих проєктах типізацію вводять поступово: спочатку нові модулі та публічні інтерфейси, потім суворіші налаштування в CI. Важливо не перетворювати типи на самоціль — Any у кількох місцях кращий за нечитабельні конструкції.

Django — коли потрібні адмінка, ORM, автентифікація й багато готових рішень «з коробки»: CRM, контентні сайти, внутрішні системи. FastAPI — для API-сервісів, асинхронності, високої швидкодії й автоматичної документації OpenAPI на основі Pydantic.

Вибір залежить також від команди: досвід розробників і наявні бібліотеки часто важливіші за бенчмарки. Сильна відповідь — з прикладом, де ви обирали й чому.