Интервью на 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, и надёжность, и кусок «расскажите про сложный случай». Его стоит иметь готовым, даже если в резюме платежи не главные: тот же паттерн на «создать тикет», «отправить письмо», «списать промокод».

Конкурентность, гонки, таймауты

Спрашивают не «что такое mutex», а сценарий. Два инстанса сервиса, один redis, один ряд в orders. Что если оба прошли if not exists. Где вы ставите блокировку: в базе уникальным индексом, advisory lock, распределённым замком. Что опаснее: потерять замок и задвоить, или держать замок слишком долго и положить очередь.

Таймауты — отдельная дыра. Сервис А ждёт Б 30 секунд, Б уже записал, ответ потерялся, А ретраит. Снова идемпотентность. Circuit breaker не как модное слово, а как «перестали долбить мёртвого провайдера и показали статус». Назовите один случай из своего опыта: даже учебный сервис с гонкой на счётчике лучше, чем «в теории бывает race condition».

System design на этом интервью

На junior часто ограничиваются «нарисуйте сервис объявлений: клиент, API, база». На middle просят оценить RPS, выбрать хранилище, сказать, где кэш врёт. На senior — компромиссы и отказ. Не начинайте с коробок. Сначала требования и масштаб. Полный каркас и разбор типичных задач — в подготовке к system design. Здесь достаточно уметь за 10 минут пройти: нагрузка, запись/чтение, точка отказа, что мониторите.

Если design-раунда нет, тот же навык всплывает в вопросе «как устроен ваш текущий сервис». Готовьте схему своего контура: вход, база, очередь, кто ретраит, где идемпотентность. Это сильнее чужой схемы shorten URL, которую вы учили ночью.

Как рассказывать про свой проект, чтобы копали вглубь

Интервьюер почти всегда даст: «расскажите про сервис, который вы знаете лучше всего». Это не самопрезентация на минуту — это приглашение к техразбору. Держите пять слоёв: что делает, какой трафик примерно, где данные, какой самый неприятный инцидент, что бы упростили.

Цифры скромные нормальны: «сотни запросов в минуту», «очередь до нескольких тысяч», «релиз раз в неделю». Враньё про миллионы всплывает на вопросе «а как шардировали». Лучше честный объём и ясный инцидент, чем космос.

Последний год я закрывал сервис статусов заказов: API для кабинета и для поддержки, Postgres, очередь на письма об изменении статуса. Чтение сильно больше записи. Узкое место было не в CPU, а в запросе списка с join на историю статусов — убрали join, историю отдаём отдельным экраном.

Инцидент: провайдер доставки два часа отдавал 500, ретраи писем раздули очередь, поддержка видела старый статус. Остановили консьюмер писем по этому типу события, статус в API перевели на «задержка у перевозчика», очередь разобрали без дублей по ключу event_id. Из этого вынес: ретрай без потолка и без идемпотентности — это уже инцидент, не устойчивость.

После такого ответа копать будут в индекс, в ключ, в то, кто принимал решение остановить консьюмер. К этому и готовьтесь, не к гимну микросервисам.

Две недели подготовки без распыления

  1. Дни 1–3. SQL: join, explain, транзакция, один дедлок на бумаге. Напишите три запроса по своей предметной области.
  2. Дни 4–5. Идемпотентность и ретраи. Проговорите вслух скрипт про двойной POST.
  3. Дни 6–7. Свой сервис: схема, инцидент, что мониторили. Запись на диктофон на 3 минуты, потом сжать до двух.
  4. Дни 8–10. Если в вакансии есть алго-раунд — средний уровень вслух, как на live coding. Если нет — не заменяйте этим базы.
  5. Дни 11–12. Каркас system design на одну задачу из вашего домена, не на все классические сразу.
  6. Дни 13–14. Самопрезентация, вилка, 2–3 behavioral-истории. Деньги — отдельно: ожидания по зарплате и как говорить о зарплате. Поведенческое — STAR с примерами.

Живые прогоны удобнее делать в подготовке к интервью, чем в голове по дороге на звонок. Один mock с человеком, который перебивает, стоит десяти молчаливых конспектов.

Частые вопросы

Нужно ли знать алгоритмы на уровне олимпиады?

Нет, если вакансия про продуктовый backend без явного раунда. Нужны структуры, сложность на пальцах и умение решить среднюю задачу вслух. Если в описании есть competitive programming — готовьте отдельно, не вместо SQL.

Спрашивают ли ORM или «чистый SQL»?

Оба. ORM не освобождает от понимания запроса, который он сгенерирует. Умейте показать, какой join уйдёт в базу, и где вы бы написали SQL руками.

Что делать, если не работал с очередями?

Честно сказать границу и разобрать учебный сценарий: зачем очередь, какой ключ идемпотентности, что с poison. Притвориться «прод с Kafka» на первом вопросе про consumer group развалится.

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

Глубоко — тот, что в вакансии. Второй достаточно на уровне «чем отличается модель ошибок». Путаница двух рантаймов в одном ответе выглядит слабее, чем ясный основной стек.

Junior без продакшена — о чём говорить?

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

Стоит ли учить system design, если в вакансии его нет?

Короткий каркас — да, чтобы рассказать свой сервис. Полный трек классических задач — если цель middle+ или в описании явно есть design-раунд.

Что сделать сейчас

Выберите одну реальную backend-вакансию, не абстрактный «бэкенд». Выпишите из неё базу, API и зону ответственности. За вечер соберите: схему своего сервиса на полстраницы, ответ про тормозящий SELECT, ответ про двойной POST. Проговорите все три вслух на диктофон и сократите до минуты каждый.

Завтра закройте вилку и самопрезентацию — без этого техэкран часто не случится. Затем один mock: пусть вас перебьют вопросом «а что делали вы, не команда?» и вопросом «что будет при двух инстансах». Это ближе к настоящему интервью, чем ещё одна глава про индексы в тишине.