Собеседование на Backend-разработчика: 23 вопроса с ответами для подготовки
Интервьюер показывает таблицу остатков и спрашивает: «Два запроса одновременно списывают последний товар. Что будет?» Он смотрит, заметите ли вы гонку сами, предложите ли атомарный UPDATE или блокировку и спросите ли, что для бизнеса хуже: продать лишнее или потерять заказ.
Ниже — этапы собеседования, разбор вопросов по API, базам данных, транзакциям, кешам, очередям и архитектуре, вопросы об опыте, кейсы, тестовые задания и вопросы работодателю.
Главное, что проверяют у бэкендера, — понимает ли он цену решений: что будет с данными при сбое, нагрузке и повторном запросе. Языки в вакансиях разные, а база общая: в 219 активных вакансиях Backend-разработчика на РаботаМакс (срез 20 октября 2026) PostgreSQL упомянут в 69, микросервисы — в 52, очереди — в 46.
Как проходит собеседование Backend-разработчика
| Этап | Что проверяют | Как подготовиться |
|---|---|---|
| Скрининг с рекрутером | Опыт, стек, мотивацию, ожидания по деньгам | Рассказ о себе на полторы минуты и вилка, которую готовы назвать |
| Техническое интервью | Базы данных, транзакции, HTTP, конкурентность, язык из вакансии | Чек-лист ниже и пример из своего проекта к каждой теме |
| Live-coding | Как вы пишете код под наблюдением | Решать задачи вслух, с таймером, без подсказок редактора |
| Системный дизайн | Умение разбить систему на части и назвать компромиссы | Разобрать по схеме два своих сервиса и их узкие места |
| Финал с тимлидом | Как вы принимаете решения и отвечаете за прод | Две истории: спорное техническое решение и разобранный инцидент |
Чем выше грейд, тем меньше вопросов «что это» и больше «что выберете и почему». Junior проверяют на SQL, HTTP и live-coding, middle — ещё на транзакциях, кешах и очередях, senior и lead — на системном дизайне и своих решениях. В крупных компаниях этапов обычно больше, в небольших командах техническое интервью и финал часто совмещают. Рынок смещён к опытным: из 219 активных вакансий Backend-разработчика на РаботаМакс (срез 20.10.2026) 53 рассчитаны на middle, 48 — на senior, 14 — на lead и лишь 7 — на junior или стажёров.
Какие вопросы задают на собеседовании Backend-разработчика
- API и сеть: HTTP-методы, идемпотентность, REST и gRPC, версионирование.
- Базы данных: индексы, планы запросов, медленные запросы.
- Транзакции и конкурентность: уровни изоляции, блокировки, гонки.
- Кеширование и очереди: Redis, Kafka и RabbitMQ, гарантии доставки.
- Архитектура и надёжность: микросервисы, таймауты и ретраи, метрики.
- Язык из вакансии: конкурентность, ошибки, тесты.
Что чаще всего упоминают сами работодатели:
| Упоминание в вакансии | Вакансий | Доля |
|---|---|---|
| PostgreSQL | 69 | 32% |
| Python | 61 | 28% |
| Микросервисы | 52 | 24% |
| Kafka, RabbitMQ или NATS | 46 | 21% |
| Go | 45 | 21% |
| Redis | 45 | 21% |
| REST | 39 | 18% |
| Kubernetes | 31 | 14% |
| gRPC | 17 | 8% |
Срез 219 активных вакансий Backend-разработчика на РаботаМакс, 20 октября 2026: упоминание в описании, требованиях или ключевых навыках.
Вопросы и ответы на собеседовании Backend-разработчика
Вопросы сгруппированы по темам, а не по грейдам: junior и senior спрашивают об одном и том же, разница — в глубине ответа. От junior ждут механизм, от middle — пример из проекта, от senior — компромиссы. Цифры в примерах ответов условные.
API: HTTP, REST и gRPC
Какие HTTP-методы идемпотентны и почему это важно?
Понимаете ли вы, что запросы будут повторяться.
GET, PUT и DELETE идемпотентны: повтор даёт то же состояние. POST — нет: два одинаковых запроса создадут два заказа. А повторы неизбежны: клиент или прокси переотправит запрос по таймауту.
Путать идемпотентность с безопасностью: DELETE идемпотентен, но меняет состояние.
Как сделать создание платежа безопасным для повторов?
Умеете ли вы сделать POST идемпотентным.
Клиент шлёт ключ идемпотентности в заголовке. Сервер в одной транзакции пишет ключ в таблицу с уникальным индексом и создаёт платёж, а повтор получает сохранённый ответ. Плюс — срок хранения ключей и ответ 409, пока первый запрос в работе.
Проверка «был ли платёж» в коде без уникального ограничения: второй запрос проскочит между проверкой и вставкой.
REST или gRPC: что выберете для связи сервисов?
Видите ли вы компромиссы.
gRPC — строгий контракт в protobuf, HTTP/2 и стриминг: удобно между внутренними сервисами. REST с JSON проще отлаживать, его понимают браузеры, прокси и кеши — он для публичного API. Цена gRPC: браузеру нужен шлюз, трафик сложнее читать.
«gRPC быстрее, значит лучше». Узкое место обычно база и сеть, а не сериализация.
Базы данных и индексы
Как устроен B-tree индекс и когда он не поможет?
Понимаете ли вы, что у индекса есть цена.
Это сбалансированное дерево по отсортированным значениям, поиск — за логарифм. Не поможет, если запрос забирает большую часть таблицы, если колонку обернули в функцию (lower(email) без функционального индекса) или LIKE начинается с %. И каждый индекс замедляет запись.
Индекс на каждую колонку из WHERE.
Есть составной индекс (user_id, created_at). Какие запросы он ускорит?
Знаете ли вы правило левого префикса.
Фильтр по user_id, в том числе с диапазоном или сортировкой по created_at — типичная лента «заказы пользователя, новые сверху». Запрос только по created_at этот индекс толком не обслужит. Порядок колонок: сначала равенство, потом диапазон.
Считать, что порядок колонок не важен.
Запрос стал медленным. Как будете разбираться?
Есть ли у вас метод, а не набор догадок.
Нахожу запрос в pg_stat_statements и смотрю EXPLAIN (ANALYZE, BUFFERS): где последовательное сканирование, где оценка строк расходится с фактом — часто это устаревшая статистика. Пример: лента заказов тормозила из-за сортировки; составной индекс убрал её из плана, и ответ ускорился с секунды до десятков миллисекунд.
Сразу «добавить индекс», не открыв план.
Транзакции и конкурентность
Какие уровни изоляции знаете и какой по умолчанию в PostgreSQL?
Знаете ли вы, какие феномены допускает каждый уровень, а не только названия.
Read Committed, Repeatable Read и Serializable. В PostgreSQL по умолчанию Read Committed: грязного чтения нет, но возможны неповторяющееся чтение и потерянное обновление в схеме «прочитал — посчитал — записал». На Serializable приложение должно повторять транзакцию после ошибки сериализации.
Перечислить уровни и не назвать ни одного феномена: грязное, неповторяющееся или фантомное чтение.
Два запроса одновременно списывают остаток. Как не уйти в минус?
Видите ли вы гонку и способы её закрыть.
Проще всего — атомарный UPDATE с условием qty > 0 и проверка числа изменённых строк. Для сложной логики — SELECT … FOR UPDATE в транзакции или оптимистичная блокировка по колонке version. Объясните выбор: при сильной конкуренции за строку оптимистичная блокировка даёт много повторов.
Проверять остаток в коде без блокировки.
Как записать заказ в базу и отправить событие в очередь, ничего не потеряв?
Знаете ли вы проблему двойной записи.
Атомарно закоммитить базу и отправку в Kafka нельзя. Решение — transactional outbox: в транзакции заказа пишем событие в таблицу outbox, а фоновый процесс публикует его в брокер. Доставка — «хотя бы один раз», поэтому потребитель должен быть идемпотентным.
Отправлять событие после коммита без outbox.
Кеширование и очереди
Как вы кешируете данные и инвалидируете кеш?
Понимаете ли вы, что кеш может разойтись с базой.
Обычно cache-aside: читаем из Redis, при промахе идём в базу и кладём результат с TTL. При записи обновляем базу и удаляем ключ, а не перезаписываем — так меньше шансов закешировать устаревшее значение. TTL зависит от того, какую задержку актуальности терпит бизнес.
Забыть про недоступный Redis: кеш не должен стать точкой отказа.
Что такое cache stampede и как его предотвратить?
Работали ли вы с кешем под нагрузкой.
Популярный ключ истёк, и сотни запросов разом идут в базу пересчитывать одно и то же. Защита: блокировка на пересчёт (считает один запрос, остальные ждут или отдают старое значение), случайный разброс TTL, фоновое обновление горячих ключей.
«Увеличим TTL» — это откладывает проблему.
Kafka гарантирует доставку ровно один раз?
Понимаете ли вы семантику доставки.
На практике — «хотя бы один раз»: консьюмер упал до коммита офсета — получит сообщение снова. Поэтому обработчик делают идемпотентным: хранят id обработанных сообщений или пишут через upsert. Порядок — только внутри партиции, поэтому события заказа шлют с одним ключом.
Ответить «да», забыв, что транзакции Kafka не покрывают запись в вашу базу.
Архитектура, надёжность и наблюдаемость
Когда выносить часть монолита в отдельный сервис?
Умеете ли вы считать цену микросервисов.
Когда у части системы свой ритм релизов, своя нагрузка или своя команда — как у поиска или уведомлений. Цена — сетевые вызовы вместо функций, согласованность между сервисами, отдельный деплой и мониторинг. Разумный путь — модульный монолит, а модуль выносим, когда его граница себя доказала.
«Микросервисы — это современно».
Ваш сервис зависит от другого. Как не упасть вместе с ним?
Знаете ли вы защиту от каскадных отказов.
Таймаут на каждый вызов — короче, чем у вашего клиента. Ретраи только для идемпотентных операций, с экспоненциальной задержкой и джиттером. Circuit breaker, чтобы не добивать упавший сервис, и деградация: страница без блока рекомендаций лучше ошибки 500.
Ретраи без задержки и лимита: упавший сервис получает в разы больше запросов.
Как понять, что сервис работает нормально?
Думаете ли вы об эксплуатации, а не только о коде.
Метрики по RED: число запросов, доля ошибок, латентность по p95 и p99, а не по среднему. Логи с request id и трейсинг между сервисами. Алерты — по симптомам, которые видит пользователь, с привязкой к SLO, а не на каждый всплеск CPU.
«Смотрю логи, когда что-то сломалось».
Вопросы о мотивации и о себе
Общие вопросы
- «Расскажите о себе». Полторы минуты: чем занимаетесь сейчас (домен, стек, масштаб) → один результат → почему ищете новое место. Например: «Четыре года пишу бэкенд на Python, последние два — в платежах. Перевёл вебхуки на очередь, и мы перестали терять события на пиках. Хочу больше работы с данными».
- «Почему уходите?» О том, к чему идёте, а не от чего бежите: хочу задачи с нагрузкой, хочу отвечать за сервис целиком. Без претензий к работодателю.
- «Почему именно мы?» Одна конкретная деталь: стек из вакансии, статья из техблога, продукт, которым вы пользуетесь.
Если нет опыта или меняете профессию
Вакансий начального уровня мало: из 219 активных вакансий Backend-разработчика на РаботаМакс только 7 явно рассчитаны на junior или стажёров (срез 20.10.2026). Вместо опыта покажите работающий проект: API с PostgreSQL и очередью, тесты, запуск через docker-compose и README с объяснением решений. Если переходите из тестирования, аналитики или поддержки — расскажите о задачах, близких к бэкенду: SQL-отчёты, автоматизация, разбор инцидентов. Как оформить это — в статье Как составить резюме Backend-разработчика.
Какие вопросы задают об опыте работы Backend-разработчика
Расскажите о самом сложном инциденте в продакшене.
Как вы действуете под давлением и что меняете после.
Что сломалось и как узнали → как локализовали → как починили → что изменили, чтобы не повторилось. Пример: после релиза выросла латентность оплаты; по трейсам нашли запрос без индекса, откатили релиз, добавили индекс миграцией и проверку планов на ревью.
«Мы всей командой починили» — без вашей роли.
Расскажите о своей ошибке, которая дошла до продакшена.
Честность и системные выводы.
Реальная ошибка, её цена и исправление процесса, а не только кода. Например: индекс на большой таблице заказов создали без CONCURRENTLY, и запись в неё встала на время построения. После этого миграции схемы стали выкатывать отдельно от кода.
«Ошибок не было» или самопохвала вроде «слишком много работаю».
Какой компонент вы спроектировали сами?
Работали по ТЗ или принимали решения.
Компонент, нагрузка и объём данных, рассмотренные альтернативы и почему выбрали свою. Закончите тем, что сделали бы иначе сейчас: для senior это сильный сигнал.
Перечислять технологии вместо решений.
Масштаб описывайте цифрами: запросы в секунду, объём данных, латентность до и после. Разделяйте «мы» и «я»: команда выбрала архитектуру, а вы написали миграцию и настроили алерты. Результат — через то, что изменилось для бизнеса: меньше инцидентов, быстрее ответ, дешевле инфраструктура.
Какие ситуационные вопросы могут задать Backend-разработчику
После релиза латентность API выросла в три раза. Ваши действия?
Порядок действий и работу с гипотезами.
Сначала остановить ущерб: совпало с релизом — откатить. Потом данные: какие эндпоинты замедлились, выросла ли нагрузка, где по трейсам теряется время. Гипотезы — от дешёвых к дорогим: запрос без индекса, исчерпанный пул соединений, медленная зависимость.
Профилировать код, не проверив релиз и нагрузку.
В очереди скопились сотни тысяч сообщений. Что делаете?
Умение не сделать хуже.
Найти причину: консьюмеры упали, тормозят на зависимости или вырос входящий поток. Убрать застрявшее «отравленное» сообщение в очередь ошибок. Консьюмеры масштабируются до числа партиций и до лимита базы, в которую пишут. С бизнесом решить, можно ли пропустить устаревшие события.
Поднять в десять раз больше консьюмеров и положить базу.
Нужно изменить формат ответа API для мобильных приложений. Как поступите?
Заботу об обратной совместимости.
Не ломать старый контракт: добавлять поля, а не менять смысл существующих. Для несовместимых изменений — новая версия эндпоинта, и какое-то время работают обе. Старую отключают, когда трафик на неё по метрикам упал до нуля: приложения обновляются не сразу.
Выкатить изменение и попросить клиентов «просто обновиться».
Какие практические задания дают Backend-разработчику
Тестовое: небольшой REST-сервис, например сокращатель ссылок
Структуру кода, ошибки, работу с базой, тесты.
Минимальный рабочий вариант, затем валидация, обработка коллизий, индексы, тесты на ключевую логику и docker-compose для запуска одной командой. В README — принятые решения и что поменяете при росте нагрузки.
Архитектура «на вырост» вместо базовых тестов.
Схема базы для бронирования мест в кинотеатре
Ограничения и конкурентный доступ.
Таблицы сеансов, мест и бронирований; уникальное ограничение на пару «сеанс + место» не даст продать место дважды даже при гонке. Плюс временная бронь на время оплаты и индексы под главные запросы.
Проверять, свободно ли место, только в коде.
Красные флаги тестового задания
В тексте вакансии о тестовом обычно не пишут, поэтому про объём, сроки и критерии оценки спрашивайте на скрининге. Насторожитесь, если:
- задание похоже на кусок их бэклога;
- на него нужно больше пары вечеров, а об оплате молчат;
- нет критериев оценки и срока ответа.
Можно предложить вместо него разобрать ваш открытый проект.
Как подготовиться к собеседованию Backend-разработчика
Начните с вакансии: выпишите стек и требования и сверьте их с чек-листом.
- SQL и PostgreSQL: JOIN, индексы, EXPLAIN ANALYZE, изоляция, блокировки.
- HTTP и API: идемпотентность, коды ответов, пагинация, версионирование.
- Кеши и очереди: инвалидация, семантика доставки, идемпотентный консьюмер.
- Надёжность: таймауты, ретраи, circuit breaker, метрики RED.
- Язык из вакансии: конкурентность, обработка ошибок, тесты.
- Три истории из опыта: инцидент, ошибка, решение, которое вы отстаивали.
Как вести себя на собеседовании Backend-разработчика
| Ситуация | Слабо | Сильно |
|---|---|---|
| Не знаете ответа | «Не знаю» и пауза | «С этим не работал. Рассуждал бы так… Проверил бы через…» |
| Задача на дизайн без деталей | Сразу рисовать схему | Спросить о нагрузке, данных и требованиях к согласованности |
| Спросили о провале | Винить коллег или сроки | Что сломалось, ваша роль, что изменили после |
| Интервьюер не согласен с решением | Защищаться до последнего | Уточнить его аргумент, назвать компромисс |
Что делать, если не знаете ответа
Не изображайте знание — уточняющий вопрос это вскроет. Оттолкнитесь от похожего опыта: «С Cassandra не работал, но если это хранилище с записью по ключу, ожидал бы такие компромиссы…». Оценивают ход мысли, а не память.
Как справиться с волнением
Попросите полминуты подумать — это нормально. Запишите условие и план ответа, прежде чем говорить. На live-coding проговаривайте шаги вслух. И репетируйте заранее: сильнее всего волнуются на вопросах, которые слышат впервые.
Как говорить о зарплате на собеседовании Backend-разработчика
Цифру обычно спрашивают на скрининге. Называйте диапазон и привязывайте его к задачам: «Ориентируюсь на диапазон от … до … на руки, уточню, когда пойму объём ответственности и нагрузку». Нижняя граница — сумма, ниже которой вы не перейдёте. Если вас просят назвать цифру первым, а вилки в вакансии нет, спросите о бюджете позиции. Не занижайте ожидания из страха отказа: торговаться вверх потом сложнее.
Крупные IT-компании на своих карьерных сайтах вилку обычно не публикуют, поэтому готовьте цифру заранее. Отталкивайтесь от медианы по своему грейду и городу и сдвигайте её вверх за то, что ценит именно этот работодатель: опыт под нагрузкой, профильный домен вроде финтеха или e-commerce, стек из вакансии. Если оффер пришёл ниже ожиданий, не отвечайте сразу: спросите, из чего складывается сумма и когда пересмотр, и назовите, что могло бы закрыть разницу.
Кроме оклада обсудите премии и как их считают, пересмотр зарплаты, оплату дежурств, формат работы и бюджет на обучение и конференции. Медианы по грейдам и городам — в статье Сколько зарабатывает Backend-разработчик.
Какие вопросы задать работодателю на собеседовании Backend-разработчика
- Как код попадает в продакшен и как часто вы деплоите?
- Кто дежурит ночью, как разбирают инциденты, есть ли постмортемы?
- Какая нагрузка и объём данных у сервиса, в который я приду?
- Сколько времени уходит на техдолг и кто решает, что чинить первым?
- Как принимаются архитектурные решения: RFC, архитектурный комитет, решение тимлида?
- Что должен сделать человек на этой позиции за первые три месяца, чтобы вы считали найм удачным?
Частые ошибки на собеседовании Backend-разработчика
- Определение без примера. «Индекс ускоряет поиск» звучит как пересказ документации. Исправление: к каждой теме держите одну историю из проекта — что было, что сделали, что изменилось.
- Решение без цены. Любой выбор чем-то оплачен — скоростью, сложностью или деньгами. Проговаривайте компромисс: «выбрал Redis, потому что…, но платим за это…».
- Ответ без масштаба. Решение для ста запросов в секунду и для десяти тысяч — разные ответы. Сначала уточните нагрузку и объём данных, потом предлагайте схему.
- Тишина на live-coding. Молчание читается как «не понимает задачу». Думайте вслух, даже если идёте не туда: интервьюер успеет подсказать.
- Чужие заслуги. Несоответствие всплывёт на втором уточняющем вопросе. Разделяйте, что делала команда, а что — лично вы, и не стесняйтесь скромной роли.
- Спор о стеке. Доказывать, что ваш язык лучше, — пустая трата времени. Обсуждайте задачу и требования, а не вкусы.
- Нет вопросов к компании. Это выглядит как безразличие к работе. Подготовьте три-четыре вопроса из списка выше.
Что делать после собеседования
В течение суток отправьте рекрутеру короткое сообщение: поблагодарите за встречу и упомяните одну деталь из разговора — например, задачу с очередями, которую обсуждали. Если на какой-то вопрос ответили слабо, можно в двух-трёх предложениях дописать, как решили бы его сейчас. Длинное письмо с оправданиями не нужно.
В конце встречи спросите, когда ждать ответа и кто его сообщит. Если срок прошёл, напишите один раз и спокойно уточните статус. Пока ждёте, не останавливайте другие отклики: решение по вакансии может зависеть от того, что вы не контролируете, — бюджета, внутреннего кандидата, смены приоритетов в команде.
При отказе поблагодарите и попросите обратную связь: часто называют конкретную тему, которой не хватило. Не спорьте с решением. Запишите вопросы, на которых споткнулись, разберите их и прогоните ещё раз до следующего интервью — так отказ превращается в план подготовки, а следующая попытка проходит спокойнее. Отказ — не приговор: в ту же компанию можно вернуться позже, когда подтянете слабые темы.
Часто задаваемые вопросы
Можно ли потренироваться перед собеседованием онлайн?
Да. На РаботаМакс есть пробное собеседование с Максом — ИИ-консультантом в чате. Выберите формат — HR- или техническое собеседование, — напишите, к какой позиции и грейду готовитесь, и отвечайте как на интервью: Макс даёт обратную связь на ответы.
Какой язык выбрать для бэкенда?
Смотрите на вакансии своего города и домена. В 219 активных вакансиях Backend-разработчика на РаботаМакс Python упомянут в 61, Go — в 45, Java и C++ — в 26, PHP — в 12 (срез 20.10.2026). Базы, HTTP и очереди общие для всех.
Нужно ли решать алгоритмические задачи?
Зависит от компании: в крупных технологических компаниях алгоритмическая секция частая, в небольших чаще дают задачу на API и базу. Оценку сложности алгоритмов знать стоит всем.
Что спрашивают на собеседовании junior Backend-разработчика?
SQL с JOIN и группировками, устройство HTTP, простой эндпоинт на live-coding, Git и основы тестов. И почти всегда — ваш проект: почему такая схема базы.
Нужно ли знать Docker и Kubernetes?
Docker упомянут в 46 из 219 активных вакансий Backend-разработчика на РаботаМакс, Kubernetes — в 31 (срез 20.10.2026). Поднять сервис с базой через docker-compose стоит уметь всем, Kubernetes — плюс, чаще с middle.
Можно ли пройти собеседование, если стек в вакансии отличается от вашего?
Да, если сильная база: SQL, HTTP, транзакции и очереди не зависят от языка. Честно скажите, с чем не работали, и покажите небольшой проект на языке из вакансии.