Интервью на backend в 2026-м редко проваливается из-за «не назвал все 12 видов индексов». Чаще ломается другое: человек знает язык, но не умеет связать данные, API и отказ. Рекрутер и нанимающий инженер проверяют не энциклопедию фреймворка, а вероятность, что вы не устроите двойное списание, не заблокируете таблицу на проде и сможете объяснить, почему выбрали очередь, а не синхронный вызов.
Ниже — типовые блоки, которые встречаются на скрининге и техэкране backend-роли, два полных ответа, которые можно сказать вслух, и подготовка на две недели без иллюзии «прорешаю LeetCode и закрою всё». Общий каркас вопросов — в материале вопросы на собеседовании. Здесь — только то, чем backend отличается от «просто разработки».
Коротко:
- Почти всегда спрашивают SQL, транзакции, индексы и что будет при одновременной записи.
- API проверяют через идемпотентность, статусы ошибок и повторные запросы, не через список HTTP-глаголов.
- Конкурентность — гонки, блокировки, таймауты, а не «расскажите про все примитивы языка».
- System design на middle+ — каркас рассуждения, не схема из блога на память. Отдельный разбор: system design с нуля.
- Готовьте 1–2 своих сервиса глубже, чем «я писал CRUD»: инцидент, узкое место, что бы сделали иначе.
Что на самом деле проверяют на каждом этапе
Скрининг с рекрутером: стек совпадает, вилка не разъехалась, вы можете за 60–90 секунд назвать роль. Самопрезентацию собирайте как обычно — рассказ о себе, не перечень технологий. Технический экран с инженером: как вы думаете про данные и отказы. Live coding, если есть, проверяет ход мысли под наблюдением — процесс разобран в гайде по live coding. Менеджерский этап: дежурства, онкол, как вы эскалируете, не геройствуете ли в одиночку.
Ошибка подготовки — зубрить определения «что такое ACID» как на экзамене. Вопрос почти всегда прикладной: «у вас два воркера пишут в одну строку — что будет». Если отвечаете учебником без сценария, интервьюер не видит, что вы делали это руками.
Как читать вакансию, чтобы не готовить не тот стек
За 15 минут выпишите из объявления четыре вещи: язык и рантайм, база, брокер или его отсутствие, зона ответственности (платежи, кабинет, интеграции, внутренние админки). Готовьте глубоко только это. Если в вакансии PostgreSQL и REST, не тратьте неделю на Cassandra «на всякий случай».
Вторая проверка — объём. «Backend» в стартапе на трёх человек и «backend платёжного контура» — разные интервью. В первом чаще спросят, умеете ли вы закрыть задачу без идеальной архитектуры. Во втором — идемпотентность, сверки, ретраи. Смотреть, какой тип слота вам ближе, удобно по актуальным backend-вакансиям, а не по чужому чеклисту из чата.
Язык и платформа — граница знания важнее списка фич
Спросят то, чем вы пишете в резюме. Для Python — GIL в одном предложении и где он вам мешал или не мешал, исключения, асинхронность, что происходит с задачей, если await забыли. Для Java/Kotlin — память, пулы потоков, что такое checked на практике, а не в учебнике. Для Go — горутины, каналы, когда канал — плохая очередь. Для Node — event loop и чем опасен синхронный файл в хендлере.
Интервьюер хочет услышать, где граница. «Не знаю точно, как устроен аллокатор, но вот как я ловлю утечку: профиль, метрика, гипотеза» сильнее заученного абзаца про поколения GC, который разваливается на follow-up. Структуры данных спрашивают умеренно: словарь, очередь, дерево, когда O(n) уже нельзя. Это не олимпиада, если в вакансии нет явного алго-раунда.
Базы: то, что спрашивают почти всегда
Если готовить один блок — готовьте SQL. Джойн, который вы можете нарисовать на бумаге. Индекс, который ускоряет конкретный запрос, и индекс, который только замедляет запись. Транзакция: что такое isolation на пальцах, не списком аббревиатур. Дедлок: два потока, две строки, разный порядок блокировок. «Почему этот SELECT тормозит» — план, кардинальность, лишний seq scan, не «надо кэш».
Реляционка против документной базы — не религиозная война. Нужен паттерн доступа: много связей и отчёты — обычно SQL; документ целиком по ключу — часто документное хранилище. Нормализация против денормализации: цена JOIN против цены рассинхрона копии. Если в вакансии только Postgres, не изображайте архитектора всех NoSQL за пять минут.
Скрипт: вопрос про индекс и «почему тормозит»
Типовая формулировка: «пользователи жалуются, что список заказов по user_id и дате открывается долго, таблица большая. Что будете смотреть?»
Сначала воспроизведу: тот же запрос, тот же фильтр, explain analyze, не «оптимизирую вслепую». Смотрю, seq scan это или index scan, сколько строк реально нужно и сколько читаем. Если фильтр по user_id и сортировка по created_at — проверяю, есть ли составной индекс (user_id, created_at). Отдельный индекс только по дате здесь часто бесполезен.
Параллельно смотрю, не тянем ли мы join на позиции заказа, когда на списке нужны три поля шапки. Если тянем — отдельный запрос или покрытие индекса. Кэш подключу только если запрос уже дешёвый, а бьют повторно одним и тем же. Иначе кэшируем медленный мусор.
Ограничение честно: без цифр селективности не пообещаю «композитный индекс всегда». Могу накидать гипотезу, проверить на копии, посмотреть bloat и не создать индекс «на всякий столбец» — запись тоже стоит.
Почему это слышат как сильный ответ: есть порядок действий, есть отказ от магии, есть цена записи. Нет лекции «B-tree работает так». Follow-up почти всегда будет про покрытие или про «а если user_id почти уникален» — к этому готовьте одну фразу про селективность.
API, очереди, идемпотентность
REST против gRPC на интервью — предлог спросить про контракт, таймауты и обратную совместимость, не про моду. Важнее: что вернёте клиенту, если запись уже прошла, а клиент повторил запрос. Идемпотентный ключ, уникальное ограничение в базе, статус «уже обработано» вместо второй проводки. Версионирование API — как не сломать старого клиента, а не «добавим /v2 потому что так принято».
Очередь спрашивают, когда в вакансии интеграции, письма, пайплайны, платежи. Зачем очередь: сгладить пик, не держать HTTP открытым, повторить при сбое. Цена: задержка, идемпотентность консьюмера, poison message, порядок, который вы почти наверняка потеряете, если обещали строгий. Фоновая задача без очереди — крон, который один раз в час чинит расхождения. Назовите, где у вас это уже было, иначе останетесь в теории.
Скрипт: повторный POST на создание платежа
Вопрос: «клиент нажал оплатить дважды, два запроса ушли на ваш endpoint. Что должно произойти?»
Не должно быть двух списаний. Клиент присылает idempotency-key, мы кладём его в уникальный индекс вместе со статусом операции. Первый запрос создаёт запись «в обработке» и идёт к провайдеру. Второй с тем же ключом не создаёт вторую проводку: отдаём тот же статус или 409 с телом уже существующей операции — как договорились в контракте, главное не молчаливую вторую запись.
Если ключа нет — это дыра. Тогда хотя бы уникальность по (user_id, order_id, amount) на коротком окне, плюс понятная ошибка. Ретраи воркера после таймаута провайдера идут с тем же ключом, иначе получим «неизвестно» в кабинете поддержки. Поддержке нужны три состояния, которые можно сказать человеку: ждём, прошло, не прошло. «Неизвестно» — отдельный карман на сверку, не новый платёж.
В код провайдера я не полезу на интервью с фантазией. Граница моей системы: не создать дубль у себя и уметь свериться. Это уже закрывает большинство инцидентов, которые я видел.
Этот ответ закрывает и API, и надёжность, и кусок «расскажите про сложный случай». Его стоит иметь готовым, даже если в резюме платежи не главные: тот же паттерн на «создать тикет», «отправить письмо», «списать промокод».