Backend-собеседование проверяет не набор модных слов, а способность видеть систему целиком. Запрос проходит через сеть, балансировщик, API, бизнес-логику, базу данных, кеш, очередь, логи, метрики и внешние сервисы. На каждом участке может возникнуть задержка, дубль, гонка, потеря данных, утечка токена или конфликт транзакций.
Вопросы с подвохом обычно звучат просто. «Добавим индекс?» «Поставим Redis?» «Повторим запрос?» «Вынесем в микросервис?» В продакшене такие ответы без оговорок часто ломают систему. Хороший backend-разработчик объясняет не только решение, но и цену решения, границы применимости и способ проверки.
Ниже - 100 вопросов с краткими ответами, разбитых на 5 уровней по 20 штук. Первый уровень проверяет базу HTTP и API, второй - SQL и транзакции, третий - кеши, очереди и распределенные сценарии, четвертый - безопасность и эксплуатацию, пятый - вопросы с подвохом для проверки инженерного мышления.
Уровень 1. HTTP, API и базовая логика backend
- Что происходит после запроса пользователя к backend-сервису?
Запрос проходит DNS, TLS, балансировщик, маршрутизацию, авторизацию, бизнес-логику, базу, кеш, логи, метрики и ответ клиенту. Слабый ответ начинается сразу с контроллера и забывает сеть.
- Чем backend отличается от API?
API задает контракт для клиента. Backend включает API, бизнес-правила, хранилища, фоновые задачи, интеграции, безопасность, мониторинг, миграции и эксплуатацию.
- Что такое endpoint?
Endpoint - конкретная точка API, обычно сочетание URL, HTTP-метода и контракта запроса. Один путь может иметь разные операции для GET, POST, PUT или DELETE.
- Чем GET отличается от POST?
GET используют для чтения и не должен менять бизнес-состояние. POST часто создает ресурс или запускает действие, поэтому повтор POST может быть опасен.
- Чем PUT отличается от PATCH?
PUT обычно заменяет ресурс целиком. PATCH меняет часть полей. В реальном API смысл должен быть явно описан контрактом.
- Что такое идемпотентность?
Идемпотентная операция при повторе дает тот же бизнес-результат. Идемпотентность нужна для платежей, заказов, вебхуков, ретраев и фоновых задач.
- Почему POST не считают идемпотентным по умолчанию?
Повтор POST может создать второй заказ, второе письмо или второе списание. Конкретный POST можно сделать идемпотентным через ключ операции и сохранение результата.
- Когда возвращать 400?
400 подходит для некорректного запроса. Например, битый JSON, неверный тип параметра, отсутствующее обязательное поле или несовместимая структура.
- Чем 401 отличается от 403?
401 означает, что пользователь не прошел аутентификацию. 403 означает, что пользователь известен, но права на действие отсутствуют.
- Когда лучше вернуть 404 вместо 403?
404 уместен, если API не должен раскрывать существование чужого приватного ресурса. Такой подход снижает риск перебора идентификаторов.
- Что означает 409?
409 показывает конфликт состояния. Например, заказ уже отправлен, а пользователь пытается отменить его как новый.
- Когда использовать 422?
422 часто используют для бизнес-валидации корректно сформированного запроса. Например, JSON валиден, но промокод истек или лимит уже исчерпан.
- Когда нужен 429?
429 показывает превышение лимита запросов. Такой ответ полезен при rate limiting, защите от злоупотреблений и управлении нагрузкой.
- Чем 502, 503 и 504 отличаются?
502 часто связан с плохим ответом от upstream. 503 говорит о временной недоступности. 504 обычно указывает на таймаут шлюза или прокси.
- Что такое REST?
REST - архитектурный стиль вокруг ресурсов, стандартных методов и представлений. В большинстве проектов встречается REST-подобный API, а не строгий REST.
- Чем REST отличается от RPC?
REST строится вокруг ресурсов и операций над ними. RPC строится вокруг вызова действий вроде createOrder или cancelPayment.
- Зачем API нужна схема ответа?
Схема фиксирует контракт между клиентом и сервером. Без контракта любое изменение поля может сломать фронтенд, мобильное приложение или интеграцию.
- Как версионировать API?
Версию можно держать в пути, заголовке или контракте. Главная задача - не ломать старых клиентов без периода миграции.
- Что такое backward compatibility?
Новая версия сервера продолжает работать со старыми клиентами. Опасны переименования полей, смена типов и новые обязательные параметры.
- Что должен содержать хороший ответ об ошибке API?
Ответ должен дать машинный код ошибки, понятное сообщение, безопасные детали для клиента и идентификатор для поиска в логах. Stack trace наружу отдавать нельзя.
Уровень 2. SQL, индексы и транзакции
- Что такое N плюс 1 запрос?
Приложение получает список одним запросом, а потом отдельно тянет связанные данные для каждой строки. На продакшен-объеме база получает сотни лишних запросов.
- Индекс всегда ускоряет запрос?
Нет. Индекс помогает только при подходящем запросе и хорошей селективности. Индекс замедляет запись, занимает место и может не попасть в план.
- Почему база может не использовать индекс?
Мешают функция над колонкой, несовпадение типов, низкая селективность, устаревшая статистика и неверный порядок полей в составном индексе.
- Как работает составной индекс?
Составной индекс лучше всего работает по левой части. Индекс по user_id и created_at полезен для заказов пользователя с сортировкой по времени.
- Что показывает EXPLAIN?
EXPLAIN показывает план выполнения запроса. По плану видно, использует ли база индекс, сколько строк читает и где тратит время.
- Почему EXPLAIN ANALYZE полезнее простого EXPLAIN?
EXPLAIN строит прогноз. EXPLAIN ANALYZE реально выполняет запрос и показывает фактическое время, строки и расхождение с оценкой.
- Что такое транзакция?
Транзакция объединяет операции так, чтобы база применила изменения целиком или откатила целиком. Без транзакции легко получить полусозданный заказ.
- Что означает ACID?
ACID описывает атомарность, согласованность, изоляцию и долговечность. На интервью важнее объяснить реальные гонки и сбои, чем просто расшифровать аббревиатуру.
- Что такое dirty read?
Одна транзакция читает данные другой транзакции, которая еще не зафиксировалась. Если вторая транзакция откатится, первая работала с несуществующим состоянием.
- Что такое non-repeatable read?
Транзакция повторно читает ту же строку и видит другое значение, потому что другая транзакция успела изменить и зафиксировать данные.
- Что такое phantom read?
Повторный запрос в той же транзакции видит новый набор строк. Проблема важна для правил, которые зависят от диапазона данных.
- Почему уровни изоляции надо проверять по конкретной СУБД?
Названия уровней одинаковые, но детали отличаются. Например, одна база может не показывать фантомы там, где стандарт допускает такое поведение.
- Как защитить баланс от двойного списания?
Нужна атомарная операция или транзакция с корректной блокировкой. Хороший вариант проверяет условие прямо в UPDATE и смотрит число измененных строк.
- Когда нужен SELECT FOR UPDATE?
Команда блокирует выбранные строки до конца транзакции. Подходит для конкурентного изменения конкретной записи.
- Почему SELECT FOR UPDATE не всегда спасает?
Блокировка существующих строк не защищает правило, где проблема возникает из-за новой строки в диапазоне. Нужны ограничения, другой уровень изоляции или отдельная модель блокировок.
- Что такое deadlock?
Две транзакции ждут друг друга по кругу. База обычно отменяет одну транзакцию, а приложение должно безопасно повторить операцию.
- Optimistic locking или pessimistic locking?
Оптимистичная блокировка дешевле при редких конфликтах. Пессимистичная дает более предсказуемый результат при частых конфликтах.
- Как менять схему базы без простоя?
Сначала добавляют новое поле, затем пишут в старое и новое, переключают чтение и только потом удаляют старое поле.
- Почему нельзя просто удалить старую колонку?
Старую схему могут читать фоновые задачи, отчеты или часть приложений при rolling deploy. Удаление без проверки превращается в мину с задержкой.
- SQL или NoSQL?
SQL хорош для связей, транзакций и сложных запросов. NoSQL выбирают под конкретную модель данных, а не просто «для масштаба».
Уровень 3. Кеши, очереди и распределенные сценарии
- Что такое eventual consistency?
Система не обещает мгновенно одинаковое состояние во всех узлах, но со временем приходит к согласованности.
- Где eventual consistency подходит?
Подход часто подходит для лайков, счетчиков, уведомлений и аналитики. Для денег, лимитов и бронирований нужна более строгая модель.
- Как работает cache-aside?
Приложение сначала читает кеш. При промахе идет в базу, кладет результат в кеш и возвращает ответ.
- Почему инвалидация кеша сложная?
База уже изменилась, а кеш может отдавать старое значение. Иногда поток случайно возвращает устаревшую версию обратно в кеш.
- Что такое TTL?
TTL задает срок жизни ключа в кеше. Слишком короткий TTL перегружает базу, слишком длинный TTL держит устаревшие данные.
- Что такое cache stampede?
Популярный ключ истек, и множество запросов одновременно пошли в базу. Кеш формально есть, но база получает удар.
- Как защититься от cache stampede?
Помогают блокировка на ключ, объединение одинаковых запросов, случайный разброс TTL и раннее обновление популярных ключей.
- Когда Redis не стоит делать единственным источником истины?
Когда нужны сложные запросы, дешевые большие объемы, строгая долговечность и привычная транзакционная модель. Persistence снижает риск, но не отменяет trade-off.
- Зачем нужны очереди?
Очередь отделяет быстрый прием запроса от долгой или нестабильной обработки. Подходит для писем, отчетов, вебхуков, интеграций и повторов.
- Почему очередь не делает систему надежной автоматически?
Нужны идемпотентность, дедупликация, мониторинг лага, повторная обработка, DLQ и понятная политика ошибок.
- Что такое DLQ?
Dead letter queue хранит сообщения, которые не удалось обработать после заданного числа попыток. Потом инженер разбирает причину отдельно.
- Что делать, если обработчик выполнил задачу дважды?
Дубли надо считать нормой распределенной системы. Помогают уникальные ключи операций, таблица обработанных сообщений и проверка состояния.
- Exactly once существует?
В некоторых системах есть exactly-once semantics внутри их модели. Но внешний бизнес-эффект требует идемпотентности, дедупликации и контроля частичного успеха.
- Что такое outbox pattern?
Приложение в одной транзакции пишет бизнес-данные и событие в outbox-таблицу. Отдельный процесс отправляет событие в брокер.
- Какую проблему решает outbox?
Outbox закрывает дыру, когда запись в базу прошла, а сообщение в брокер потерялось из-за сбоя между двумя операциями.
- REST или gRPC?
REST проще для внешних API и ручной отладки. gRPC удобен для внутренних сервисов, строгих контрактов, стриминга и низкой задержки.
- Зачем нужен contract testing?
Контрактные тесты проверяют, что сервисы одинаково понимают формат запроса и ответа. Особенно полезны при независимых релизах команд.
- Что такое retry?
Retry повторяет операцию после сбоя. Без идемпотентности и ограничений повтор может создать дубль или усилить аварию.
- Что такое exponential backoff?
Каждая следующая попытка ждет дольше предыдущей. Такой подход снижает давление на зависимость, которая уже деградирует.
- Зачем нужен jitter?
Jitter добавляет случайный разброс к задержке ретраев. Без разброса клиенты могут повторять запросы волнами и снова перегружать сервис.
Уровень 4. Безопасность, наблюдаемость и эксплуатация
Вопросы про SQL injection, CSRF, JWT, SSRF, логи и авторизацию предназначены для легальной и ответственной разработки. Такие знания нельзя применять для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений. При работе с безопасностью нужно соблюдать законы своей страны, особенно России.
- Как проектировать авторизацию?
Аутентификация отвечает на вопрос, кто пришел. Авторизация отвечает, что пользователь может делать.
- Где должна жить проверка прав?
Проверка прав должна быть рядом с бизнес-операцией, а не только на уровне маршрута. Иначе появляется риск обхода через другой путь.
- Что такое IDOR?
IDOR возникает, когда пользователь меняет идентификатор ресурса и получает доступ к чужим данным из-за слабой проверки прав.
- Как хранить пароли?
Пароли хранят через специализированные медленные схемы хеширования с солью и корректными параметрами. На практике используют Argon2id, scrypt, bcrypt или PBKDF2 по требованиям.
- Почему SHA-256 не подходит для паролей?
SHA-256 слишком быстрый для паролей. Атакующий сможет перебирать варианты быстрее, чем при использовании адаптивного password hashing.
- Чем опасно небрежное использование JWT?
Риски связаны с долгим сроком жизни, сложным отзывом, небезопасным хранением, лишними claims и ошибками проверки подписи.
- Как снизить риски JWT?
Используют короткий access token, контролируемый refresh token, проверку подписи, минимальный набор claims и безопасное хранение.
- Что такое CSRF?
CSRF заставляет браузер авторизованного пользователя выполнить нежелательный запрос. Риск особенно заметен при cookie-based auth.
- Как защищаться от CSRF?
Помогают SameSite cookies, CSRF-токены, привязка токена к сессии и проверка Origin или Referer для чувствительных операций.
- Что такое SQL injection?
SQL injection возникает, когда пользовательский ввод попадает в SQL как часть команды. Защита строится на параметризованных запросах и минимальных правах.
- Что такое SSRF?
SSRF позволяет заставить сервер сходить по нежелательному адресу. Риск важен для сервисов, которые загружают URL, картинки, вебхуки или документы.
- Почему логирование может стать уязвимостью?
В логи легко попадают токены, пароли, персональные данные и содержимое документов. Нужны маскирование, контроль доступа и срок хранения.
- Какие метрики нужны backend-сервису?
Минимум включает latency, traffic, errors, saturation, RPS, p95 и p99 задержки, размер очереди, лаг обработчиков и ошибки зависимостей.
- Почему средней задержки мало?
Среднее значение скрывает боль части пользователей. p95 и p99 лучше показывают хвост задержек.
- Чем лог отличается от метрики?
Лог описывает конкретное событие. Метрика показывает численное состояние системы во времени.
- Зачем нужна трассировка?
Трассировка связывает путь запроса через несколько сервисов. При инциденте видно, где именно запрос потерял время.
- Почему высокая кардинальность метрик опасна?
Метки вроде user_id или request_id резко увеличивают число временных рядов. Система мониторинга становится дорогой и медленной.
- Почему timeout по умолчанию опасен?
Без таймаута поток или соединение может зависнуть надолго. Слишком большой таймаут забивает пул, слишком маленький режет нормальные ответы.
- Как работает circuit breaker?
После серии ошибок circuit breaker временно перестает ходить в проблемный сервис. Через паузу пропускает пробные запросы.
- Что такое backpressure?
Система явно замедляет прием новой работы, когда обработчики, база или очередь не успевают. Без backpressure сервис падает тяжелее.
Уровень 5. Подвохи, архитектура и продакшен-мышление
- Добавим Redis и все ускорим?
Не обязательно. Без стратегии TTL, инвалидации, промахов и устаревших данных Redis может добавить баги быстрее, чем скорость.
- Добавим индекс и запрос станет быстрым?
Не всегда. Нужно смотреть план запроса, селективность, объем данных и цену записи.
- Вынесем в микросервис и станет проще?
Микросервис добавляет сеть, ретраи, версионирование, трассировку и согласованность данных. Плохой дизайн микросервисы не лечат.
- Монолит всегда хуже микросервисов?
Нет. Монолит проще запускать, тестировать и менять на старте. Микросервисы полезны при зрелых границах доменов и команд.
- Как выделить сервис из монолита?
Сначала находят границу домена и владельца данных. Потом переносят чтение, запись и только затем удаляют старый путь.
- Почему общая база у микросервисов опасна?
Сервисы начинают ломать данные друг друга напрямую. Граница сервиса становится декоративной, а независимый релиз исчезает.
- Можно ли просто повторить неудачный запрос?
Только если операция безопасна для повтора. Нужны идемпотентность, лимиты, backoff, jitter и понимание частичного успеха.
- Что такое частичный успех?
Одна часть операции уже прошла, а другая упала. Например, деньги списались, но статус заказа не обновился.
- Почему внешний сервис нельзя вызывать внутри долгой транзакции?
Транзакция держит блокировки, пока внешний сервис отвечает. Один медленный вызов может заблокировать важные строки и ухудшить всю систему.
- Почему локально быстро, а в продакшене медленно?
На продакшене другие объемы данных, сеть, конкуренция, пулы соединений, индексы, холодные кеши и внешние зависимости.
- Почему тесты прошли, а релиз сломался?
Тесты могли не покрыть миграцию, старых клиентов, реальные данные, порядок деплоя, конфигурацию или поведение под нагрузкой.
- Чем health check отличается от readiness check?
Health check показывает, жив ли процесс. Readiness check показывает, готов ли сервис принимать трафик.
- Почему canary-релиз снижает риск?
Новая версия получает малую долю трафика. Команда видит ошибки и задержки до полного раската.
- Что такое blue-green deploy?
Две среды работают параллельно. Трафик переключают на новую среду, а при проблеме быстро возвращают назад.
- Чем опасны feature flags?
Флаги копятся, усложняют поведение и создают комбинации, которые никто не тестировал. Старые флаги нужно удалять.
- Почему rollback не всегда прост?
Если новая версия изменила схему данных несовместимо, старая версия может не запуститься. Поэтому миграции должны быть обратимо совместимыми.
- Почему Kubernetes не решает проблемы приложения?
Kubernetes перезапустит контейнер, но не исправит гонки, неверные таймауты, плохие индексы, утечки соединений и слабую модель данных.
- Как расследовать деградацию API?
Сначала смотрят метрики, ошибки, p95 и p99. Затем проверяют трассировки, логи, базу, кеш, очереди и внешние зависимости.
- Что должно быть в хорошей postmortem?
Нужны таймлайн, причина, вклад технических и процессных факторов, ущерб, действия для предотвращения повтора и владельцы задач.
- Как отличить сильного backend-разработчика на собеседовании?
Сильный кандидат говорит не только что сделать, но и какую цену заплатит система, где решение сломается и как проверить гипотезу.
Как отвечать на backend-собеседовании
Сильный ответ строится вокруг причины, а не вокруг названия технологии. Не «нужна очередь», а «внешний сервис отвечает нестабильно, пользовательский запрос нельзя держать открытым, поэтому кладем задачу в очередь, возвращаем статус, повторяем обработку и защищаем бизнес-операцию от дублей».
Перед собеседованием полезно освежить базовые проверки. Команды не заменяют мышление, но быстро показывают, понимает ли кандидат, где искать проблему.
curl -i https://api.example.com/orders/123
EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC, id DESC
LIMIT 20;
wrk -t4 -c100 -d30s https://api.example.com/orders/123Первая команда показывает контракт API и заголовки. Вторая показывает реальный план SQL-запроса. Третья вскрывает поведение сервиса под параллельной нагрузкой. На собеседовании не всегда просят запускать команды, но кандидат должен понимать, какую проверку выбрал бы в реальной системе.
Красные флаги в ответах
| Фраза кандидата | Что не так |
|---|---|
| Redis все решит | Нет разговора про TTL, инвалидацию, промахи кеша, persistence и устаревшие данные |
| Добавим индекс | Нет плана запроса, селективности, цены записи и проверки на реальных данных |
| Сделаем микросервисы | Нет границ домена, владельца данных, трассировки и стратегии деплоя |
| Просто повторим запрос | Нет идемпотентности, дедупликации, backoff, jitter и понимания частичного успеха |
| JWT решает авторизацию | Смешаны аутентификация, авторизация, отзыв токенов и хранение секретов |
Что повторить перед собеседованием
- HTTP-методы, коды ответа, кеширование, идемпотентность, rate limiting и версионирование API.
- SQL, индексы, транзакции, уровни изоляции, блокировки и планы запросов.
- Redis, cache-aside, TTL, инвалидацию, cache stampede, stale data и persistence.
- Очереди, ретраи, DLQ, outbox pattern, дедупликацию и лаг обработчика.
- Пароли, JWT, CSRF, SQL injection, SSRF, IDOR и безопасное логирование.
- Метрики, логи, трассировки, алерты, health checks, readiness checks и SLO.
- Монолит, микросервисы, backpressure, circuit breaker, canary, rollback и postmortem.
Готовиться лучше не по списку терминов, а по сценариям одного продукта: создание заказа, оплата, отмена, возврат, уведомление, отчет. Для каждого сценария надо понять, где транзакция, где внешний вызов, где повтор, где идемпотентный ключ, где метрика, где лог и что увидит пользователь при сбое.
Backend-разработчика нанимают не за способность произнести Kafka, Redis и Kubernetes в одном предложении. Нужен инженер, который понимает цену каждого решения, видит отказ до релиза и может проверить работу системы. На собеседовании выигрывает не самый громкий ответ, а самый проверяемый.
