Подготовка к собеседованию — Python-разработчик

Короткий ответ: SELECT извлекает строки из таблиц. Логический порядок выполнения НЕ совпадает с порядком написания: сначала FROM, затем WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, LIMIT.

Подробно:

Порядок написания (синтаксический):

SELECT   DISTINCT col1, agg(col2)
FROM     t
WHERE    cond
GROUP BY col1
HAVING   agg_cond
ORDER BY col1
LIMIT    10 OFFSET 20;

Логический порядок исполнения:

1. FROM / JOIN      -- какие таблицы, как соединить
2. WHERE            -- фильтр строк ДО группировки
3. GROUP BY         -- группировка
4. HAVING           -- фильтр групп ПОСЛЕ агрегации
5. SELECT           -- вычисление выражений, алиасов
6. DISTINCT         -- удаление дублей
7. ORDER BY         -- сортировка
8. LIMIT / OFFSET   -- срез

⚠️ Ловушка: алиас из SELECT нельзя использовать в WHERE (т.к. WHERE выполняется раньше SELECT), но можно в ORDER BY и часто в GROUP BY (зависит от СУБД). Пример ошибки:

SELECT salary * 12 AS annual FROM emp WHERE annual > 100000; -- ОШИБКА
SELECT salary * 12 AS annual FROM emp ORDER BY annual;        -- ОК

Короткий ответ: HTTP (HyperText Transfer Protocol) — текстовый прикладной протокол клиент-сервер поверх TCP (в HTTP/3 — поверх QUIC/UDP). Клиент отправляет запрос, сервер возвращает ответ; соединение без сохранения состояния между запросами (stateless).

Подробно:

Запрос состоит из стартовой строки (метод + путь + версия), заголовков и опционального тела:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Content-Length: 38

{"name": "Анна", "email": "a@ex.com"}

Ответ состоит из строки статуса (версия + код + reason phrase), заголовков и тела:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/users/42

{"id": 42, "name": "Анна", "email": "a@ex.com"}

⚠️ Ловушка: «HTTP работает только поверх TCP» — неверно для HTTP/3, который использует QUIC поверх UDP. И reason phrase («OK», «Created») носит чисто информативный характер — клиенты должны опираться на числовой код, а не на текст.

Короткий ответ: Big O описывает, как растёт время работы или потребление памяти алгоритма при увеличении размера входных данных n, отбрасывая константы и младшие члены. Это верхняя оценка скорости роста.

Подробно:

Big O отвечает на вопрос «что произойдёт, когда n станет очень большим?». Нас не интересует точное число операций, а только характер роста. Поэтому O(2n + 100) упрощается до O(n), а O(3n² + n) — до O(n²).

Основные классы роста (от лучшего к худшему):

# O(1) — константа: не зависит от n
def first(arr):
    return arr[0] if arr else None

# O(log n) — логарифм: каждый шаг делит задачу пополам (бинарный поиск)
def binary_search(arr, target):
    lo, hi = 0, len(arr) - 1
    while lo <= hi:
        mid = (lo + hi) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            lo = mid + 1
        else:
            hi = mid - 1
    return -1

# O(n) — линейная: один проход
def total(arr):
    s = 0
    for x in arr:        # n итераций
        s += x
    return s

# O(n log n) — эффективные сортировки (merge, quick, Timsort)
def sort_it(arr):
    return sorted(arr)

# O(n^2) — квадрат: вложенный цикл
def has_dup_naive(arr):
    for i in range(len(arr)):
        for j in range(i + 1, len(arr)):
            if arr[i] == arr[j]:
                return True
    return False

# O(2^n) — экспонента: наивный Фибоначчи, перебор подмножеств
def fib_naive(n):
    if n < 2:
        return n
    return fib_naive(n - 1) + fib_naive(n - 2)

Ориентир по росту при n = 1 000 000: O(1) — 1 операция, O(log n) — ~20, O(n) — миллион, O(n log n) — ~20 млн, O(n²) — триллион (уже слишком), O(2^n) — нереально даже при n = 50.

⚠️ Ловушка: Big O — это про асимптотику (поведение при больших n), а не про реальное время. O(n) алгоритм может быть медленнее O(n²) на маленьких данных из-за больших констант. Также путают: Big O (верхняя граница, Ω — нижняя, Θ — точная), в собесах под «O» обычно подразумевают Θ.

Короткий ответ: Docker — это платформа контейнеризации, которая упаковывает приложение вместе со всеми его зависимостями, библиотеками и конфигурацией в изолированный, переносимый образ. Решает проблему «у меня на машине работает, а на сервере нет».

Подробно:

Классическая боль: разработчик написал код на своём ноутбуке (Python 3.11, конкретная версия libpq, переменные окружения), а на сервере другая версия ОС, других библиотек нет, переменные не выставлены — приложение падает. Docker фиксирует всё окружение в образе, и этот образ одинаково запускается локально, в CI и на проде.

Что даёт Docker:

• Воспроизводимость — один и тот же образ везде. Окружение описано кодом (Dockerfile), его можно версионировать в git.
• Изоляция — контейнеры не мешают друг другу (зависимости, порты, процессы).
• Переносимость — образ работает на любой машине с Docker, независимо от хостовой ОС.
• Быстрый старт — контейнер поднимается за секунды (в отличие от VM).

# Собрать образ из Dockerfile в текущей директории
docker build -t myapp:1.0 .

# Запустить контейнер из образа, пробросить порт, в фоне
docker run -d -p 8000:8000 --name myapp myapp:1.0

# Посмотреть запущенные контейнеры
docker ps

# Зайти внутрь работающего контейнера
docker exec -it myapp bash

# Логи контейнера
docker logs -f myapp

⚠️ Ловушка: Docker не «виртуализирует железо» и не запускает полноценную ОС. Контейнеры используют ядро хоста. Поэтому Linux-образ нативно не запустится на ядре Windows — на Windows/macOS под капотом работает лёгкая Linux-VM (через WSL2 или гипервизор), и уже в ней крутятся контейнеры.

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

Подробно:

import sys
print(sys.getsizeof([1, 2, 3]))   # ~88 байт
print(sys.getsizeof((1, 2, 3)))   # ~64 байта

Почему list больше: он держит переаллокацию (over-allocation) — заранее выделяет место под будущие append, чтобы амортизировать стоимость роста до O(1). tuple фиксирован, ему запас не нужен.

Когда что выбирать:

• tuple — когда количество и смысл элементов фиксированы: координаты (x, y), возврат нескольких значений из функции, ключ словаря.
• list — когда коллекция растёт/меняется/сортируется.

⚠️ Ловушка: «tuple быстрее» — правда лишь для создания литерала и доступа, но не магически во всём. И помни про вложенный мутабельный объект: tuple гарантирует неизменность ссылок, а не объектов, на которые они указывают.