Вопросы на собеседовании Backend-разработчика

Пример сильного ответа

Первым делом снимаю план выполнения запроса и смотрю, где реально уходит время: последовательное сканирование вместо индексного, большой разрыв между оценкой планировщика и фактическими строками, лишние сортировки и вложенные циклы. Дальше проверяю статистику и структуру индексов под условия фильтрации и сортировки. На практике в похожей ситуации таблица выросла до десятков миллионов строк, и запрос отчёта выполнялся около сорока секунд; после составного индекса под конкретный фильтр и переписывания подзапроса время сократилось до двух секунд. Результат фиксирую замером до и после и добавляю запрос в мониторинг медленных запросов.

• Сразу про план выполнения, а не про догадки
• Есть замеры до и после оптимизации
• Показывает системность: мониторинг на постоянной основе

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Индекс в PostgreSQL и MySQL чаще всего построен как сбалансированное дерево: поиск идёт по отсортированным ключам, а строки таблицы лежат отдельно. Индекс не используется, когда выборка возвращает большую долю строк и дешевле прочитать таблицу целиком, когда условие обёрнуто функцией или несовпадением типов, когда в составном индексе не задействован ведущий столбец, когда статистика устарела. В моей практике на таблице в несколько миллионов строк фильтр по нижнему регистру строки не попадал в индекс, пока не появился функциональный индекс — выборка ускорилась примерно в двадцать раз.

• Объясняет устройство, а не только синтаксис
• Перечисляет реальные причины отказа от индекса
• Подтверждает опыт конкретным ускорением

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Транзакция — это набор операций, который выполняется целиком или не выполняется вовсе, с гарантиями атомарности, согласованности, изоляции и долговечности. Уровни изоляции определяют, какие аномалии видят параллельные транзакции: грязное чтение, неповторяющееся чтение, фантомы. READ COMMITTED недостаточно, когда между двумя чтениями одной и той же строки другая транзакция успевает её изменить: например, при проверке остатка перед списанием. Тогда применяю REPEATABLE READ или явную блокировку строки. В проекте с балансами переход на более строгий уровень убрал расхождения в отчётах, которые раньше всплывали примерно в одном случае из тысячи операций.

• Даёт определение и сразу переходит к аномалиям
• Пример с остатком понятен любому собеседнику
• Показывает результат в цифрах

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Оптимистичная блокировка не захватывает строку, а при обновлении проверяет, что версия записи не изменилась: при расхождении операция повторяется или возвращает конфликт. Пессимистичная сразу удерживает строку на время транзакции, поэтому остальные ждут. Оптимистичную выбираю там, где конфликты редки, а держать блокировку долго нельзя: редактирование профиля, корзина, каталог. Пессимистичную — где конфликты часты и цена ошибки высока: списание остатка, резерв товара, изменение баланса. В одном сервисе оптимистичная схема при пиковой нагрузке давала до тридцати процентов конфликтов, и переход на короткую явную блокировку строки убрал повторы.

• Чётко разводит механики двух подходов
• Даёт критерий выбора, а не общие слова
• Цифра конфликтов подтверждает опыт

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Разделяю сущности: товар и его варианты, складские остатки, заказ и позиции заказа, платежи, статусы. Товар и вариант храню отдельно, потому что цена и артикул живут на уровне варианта, а описание — на уровне товара. В позиции заказа фиксирую цену и название на момент покупки, чтобы история не менялась при редактировании каталога. Остаток держу отдельной таблицей по складам и меняю его транзакционно вместе с созданием заказа, а движения остатков пишу в журнал для сверки. Индексы — по внешним ключам и по статусу с датой. Похожая схема держала около двух миллионов заказов без замедления выборок.

• Показывает логику нормализации по смыслу
• Отдельно продумана история цен в заказе
• Есть цифра по объёму данных

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом смотрю на профиль запросов: если большая часть обращений идёт по свежим данным, самое дешёвое решение — партиционирование по дате и вынос холодной истории в отдельное хранилище. Дальше проверяю индексы и планы: часто дело не в объёме, а в лишних полных сканах. Тяжёлые миграции делаю батчами с паузами, чтобы не держать блокировки. На одном проекте таблица около 400 млн строк: партиционирование и перенос истории сократили время тяжёлого запроса с минут до сотен миллисекунд, а миграции перестали блокировать прод. Шардирование предлагаю только после этих шагов.

• Показан порядок действий: от партиционирования к шардированию
• Есть конкретные цифры вместо общих рассуждений
• Учтены миграции и блокировки — реальная боль команды

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Версионирование держу в URL, например v1: ломающие изменения идут только в новой версии, а внутри версии поля добавляю, но не удаляю. Ошибки отдаю корректным HTTP-статусом и единым JSON: машинный код, человекочитаемое сообщение и request-id для логов. Пагинация — курсорная по стабильному ключу, offset оставляю только для админских выборок, иначе при вставках строки теряются и дублируются. Размер страницы ограничиваю сверху. В одном сервисе переход на курсорную пагинацию сократил p95 ответа списка примерно втрое на выборках в миллионы записей.

• Закрыты все три темы: версии, ошибки, пагинация
• Объяснено, почему курсор лучше offset
• Результат подкреплён метрикой p95

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

REST выбираю для публичного контракта: он простой, кэшируемый и понятный внешним клиентам. gRPC — для внутренних синхронных вызовов, где важны latency, строгая схема и стриминг: бинарный формат и генерация клиентов экономят время на интеграции. Брокер сообщений беру, когда операция асинхронная, её можно отложить или одно событие должны получить несколько потребителей, а отправитель не ждёт ответа: платежи, письма, пересчёт отчётов. Ключевой критерий — готовность вызывающей стороны ждать и требования к согласованности. На одном проекте вынос уведомлений в очередь и ретраи сократили нагрузку на основной сервис примерно на треть и убрали таймауты на пике.

• Чёткий критерий выбора между тремя вариантами
• Пример из практики с измеримым эффектом
• Видно понимание асинхронности и согласованности

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Кэш нужен, чтобы снять с базы повторяющиеся чтения и уложиться в SLA по времени ответа. Проблемы, которые он приносит: устаревшие данные, сложная инвалидация и лавина запросов при промахе, когда все клиенты одновременно идут в базу. Поэтому продумываю TTL, ключи с версией, прогрев и защиту от одновременного пересчёта, чтобы значение обновлял только один процесс. И помню, что кэш — не источник истины: критичные данные всегда сверяю с базой. На одном сервисе горячие справочники в кэше с TTL дают экономию около 70% чтений базы и заметный выигрыш по p95.

• Сначала польза, потом риски — зрелый взгляд
• Названы инвалидация и лавина запросов
• Подчёркнуто, что кэш не источник истины

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Redis использую не только как кэш. В первую очередь — распределённые блокировки и идемпотентность: ключ с TTL гарантирует, что повторный запрос не создаст второй платёж. Дальше — очереди и streams для фоновых задач, счётчики и rate limiting, лидерборды на sorted sets, сессии и короткоживущие токены, pub/sub для мгновенных уведомлений между инстансами. При этом помню про ограничения: память дорогая, данные могут потеряться при падении, поэтому критичное состояние всё равно пишу в основную базу. На одном проекте блокировки по ключу с TTL убрали дубли заказов и сократили повторные операции примерно на 3% потока.

• Показаны сценарии применения помимо кэша
• Названы честные ограничения Redis
• Есть результат с конкретной цифрой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Возьму Kafka: продюсер пишет в партицию, внутри партиции порядок гарантирован, между партициями — нет, поэтому ключ партиционирования выбираю осознанно. Потребитель читает пачками и коммитит офсет. Если коммит идёт после обработки, получаем семантику at-least-once: при падении между обработкой и коммитом сообщение придёт повторно. В RabbitMQ логика похожая — через подтверждения и возврат сообщения в очередь. Поэтому там, где сообщение запускает платёж или рассылку, обязательна идемпотентность. На одном сервисе доля дублей на пике — около 0,1% потока, и защита от повторной обработки убирает расхождения в отчётности.

• Показан механизм, а не заученное определение
• Сделан практический вывод про идемпотентность
• Есть цифра из личного опыта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Мой основной язык — Go, и конкурентность там встроена в рантайм. Горутина — дешёвая задача, которую планировщик раскидывает по потокам операционной системы, поэтому тысячи одновременных операций — норма. Общение строится на каналах, а не на общей памяти: не передавай через общую память, передавай память через каналы. Для защиты состояния применяю мьютексы, для ожидания группы — WaitGroup, для отмены — context. На одном сервисе держали до 5 тысяч параллельных соединений на нескольких инстансах, и утечек горутин не было: профилирование помогало находить их заранее.

• Названы конкретные примитивы языка
• Есть принцип, а не только список терминов
• Цифра подтверждает реальный опыт

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Список хранит элементы по порядку, доступ по индексу быстрый, а поиск по значению — линейный. Хеш-таблица даёт поиск, вставку и удаление в среднем за константу, но не хранит порядок и требует памяти под бакеты. Выбор простой: нужен доступ по позиции, обход по порядку или данные маленькие — беру список. Нужны частые проверки «есть ли элемент» и поиск по ключу — беру хеш-таблицу. Ещё важен профиль нагрузки: если вставок и удалений много, а обход редкий, выигрывает хеш-таблица. В одном сервисе замена линейного поиска по списку на множество ускорила обработку запроса примерно вдвое на 50 тысячах записей.

• Сравнение по свойствам, а не по определению
• Показан критерий выбора структуры
• Есть измеримый результат оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Логику закрываю unit-тестами: чистые функции, валидация, расчёты, обработка ошибок. Их много, они быстрые и запускаются на каждый коммит. Интеграционные тесты закрывают то, что зависит от инфраструктуры: работу с базой, брокером, HTTP-слой, транзакции и миграции. Обычно поднимаю их в контейнерах, чтобы результат был воспроизводим. Отдельно проверяю идемпотентность и повторную обработку сообщений — именно это чаще всего ломается в проде. В одном проекте довели покрытие ключевых модулей до 80% и снизили число дефектов на релизе примерно на треть.

• Чёткое разделение уровней тестирования
• Упомянуты сложные сценарии, а не только happy path
• Есть метрика, подтверждающая эффект

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сначала смотрю на корректность: решает ли код задачу, нет ли гонок, утечек и необработанных ошибок, что с транзакциями и повторными запросами. Затем — на читаемость и поддерживаемость: понятные имена, небольшие функции, отсутствие дублирования. Проверяю, что логика покрыта тестами и что нет лишних зависимостей. Стиль ловят линтеры, тратить на него время ревью не нужно. Ещё важно, чтобы изменения были небольшими: ревью на 200 строк проходит за полчаса, а на 2000 застревает на дни. Комментарии стараюсь писать так, чтобы автор понимал причину замечания.

• Расставлены приоритеты ревью
• Показано делегирование стиля линтерам
• Есть аргумент про размер изменений

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Защита для меня — это набор слоёв, а не одна библиотека. На входе — валидация и нормализация данных, параметризованные запросы, чтобы исключить инъекции, и экранирование вывода. Дальше — аутентификация и авторизация с проверкой прав на каждом эндпоинте, ограничение частоты запросов, защита от подбора. Секреты храню только в защищённом хранилище, не в коде и не в репозитории. Обязательно сканирование зависимостей и образов в CI. Такой подход с регулярной проверкой по списку типовых рисков дал результат: число инцидентов, связанных с безопасностью, сократилось примерно на 70 процентов за год, а нагрузочные тесты и пентесты не выявили критичных находок.

• Показан системный подход из слоёв, а не один инструмент
• Есть конкретная цифра и измеримый результат
• Названы проверяемые практики: CI, сканирование, пентесты

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Наблюдаемость строю на трёх опорах: метрики, логи и трассировки. Метрики — по каждому сервису: задержка, доля ошибок, трафик и насыщение ресурсов; алерты настраиваю на SLO, а не на каждый всплеск, чтобы дежурный не тонул в шуме. Логи — структурированные, с идентификатором запроса, чтобы связать всю цепочку вызовов. Трассировки — сквозные, по общему стандарту, чтобы видеть, где именно теряется время. Плюс дежурные дашборды и понятный плейбук на типовые сбои. Результат: среднее время восстановления сократилось с нескольких часов до получаса, а количество ложных срабатываний алертов упало примерно на 60 процентов.

• Классическая схема метрики-логи-трассировки, понятная интервьюеру
• Алерты привязаны к SLO, а не к шуму
• Есть цифры по MTTR и снижению ложных алертов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.