Материал Эйч · Опубликовано 27 октября 2026
Микросервисы переводов в Сбербанк Онлайн: Java 17, Go, Kafka, PostgreSQL, Spring Boot 3 и контрактное API-First развитие.
Фишка: Сильный акцент на банковский домен (переводы, расчёты), API-First/SDD, надёжность интеграций (идемпотентность, retry, DLQ) и культуру расследования production-инцидентов.
| Этап | Длительность | Что проверяют |
|---|---|---|
| Скрининг / HR | 30–45 мин | Мотивация, формат работы (офис/гибрид, 10:00–19:00), английский B2, интерес к финтеху и домену переводов, отсутствие конфликтов по графику. |
| Техническое интервью | 60–90 мин | Java (коллекции, generics, исключения), Spring (@Transactional, интеграции), SQL, задачи на код и разбор сниппетов; вопросы по Kafka и надёжности интеграций. |
| Углубление / команда | 60–120 мин | Опыт микросервисов, REST/Kafka-контракты, тестирование (JUnit, Testcontainers), production-инциденты, взаимодействие с аналитиками и SDD; возможна секция на Go. |
| Финал | 30–60 мин | Согласование ожиданий, софт-скиллы, безопасность и процессы Сбера при необходимости. |
Обязательный минимум
Плюсом будет
Почему HashSet может не находить уже добавленный объект через contains()?
Контракт Set опирается на equals/hashCode; без согласованных переопределений или при изменении полей после add бакет и сравнение расходятся.
Какие варианты переопределения метода с checked-исключениями допустимы?
Сигнатуру сохранить; checked — только сужать (подтипы) или убирать; unchecked можно добавлять; расширять checked в override нельзя.
В чём ошибка в addAll с wildcards List<? super T> и List<? extends T>?
Направление копирования и PECS: в extends-список нельзя безопасно писать; типичная ошибка — second.addAll(first) вместо first.addAll(second).
Ловушка: Задачи на сниппеты часто содержат синтаксические ловушки — сначала проговори контракт API, потом ищи баг.
Совет: Для коллекций всегда проговаривай equals/hashCode и мутабельность ключей.
Что зафиксируется в БД при вложенных @Transactional и пустом catch вокруг исключения из внутреннего сервиса?
По умолчанию propagation REQUIRED — одна транзакция; поглощённое исключение может помешать rollback; уточни rollbackFor и self-invocation через proxy.
Как выглядит идеальный unit-тест для маппинга DTO с ~60 полями?
Табличные/параметризованные кейсы: null/отсутствие поля, граничные значения, регресс на бизнес-правила; не 60 assert в одном тесте без структуры.
Как проверять код, сгенерированный ИИ?
Ревью, статический анализ, тесты на поведение и границы; не доверять без прогона CI и сценариев из контракта.
Фишка: В команде «Переводы» важны идемпотентность, retry и DLQ — связывай ответы про транзакции с гарантиями между БД и Kafka.
Что такое высоконагруженная система и как понять, что она справляется с нагрузкой?
Нет универсального RPS — смотри SLO (latency, error rate, availability), нагрузочные тесты и метрики в prod (lag, saturation).
Как обеспечить идемпотентность обработчика сообщений о переводе?
Ключ идемпотентности, уникальные ограничения в БД, dedup store, outbox/inbox, аккуратный retry и DLQ для poison messages.
Consumer groups и гарантии доставки — что важно для разработчика?
Партиции и порядок внутри партиции, commit offset, at-least-once vs exactly-once, дубли при rebalance и retry.
Совет: Упомяни опыт Spring Kafka / caldera-kafka-lib, если есть — это прямо из стека вакансии.
Топ-10 номеров с наибольшим числом SMS (только с count > 1)?
GROUP BY phone_number HAVING COUNT(*) > 1 ORDER BY COUNT(*) DESC LIMIT 10.
Сотрудники с максимальной зарплатой в каждом отделе?
ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) = 1 или коррелированный подзапрос с MAX.
Самый свежий договор на клиента?
DISTINCT ON (client) … ORDER BY client, date DESC или ROW_NUMBER по client.
Ловушка: В банке часто спрашивают блокировки и изоляцию — свяжи SQL-задачу с конкурентными обновлениями баланса/статуса перевода.
Где считать данные, видимые клиенту (например годовые проценты): backend или frontend?
Финансовые расчёты и единая бизнес-логика — на backend; фронт — отображение; важны округление, регуляторика и защита от подмены.
Какие признаки хороших системных требований?
Проверяемость, однозначность, границы, нефункциональные требования, критерии приёмки, трассировка к контракту API.
На что смотришь в системных требованиях и как работаешь с аналитиком?
Happy path + ошибки, идемпотентность, совместимость версий API, вопросы до оценки сроков.
Фишка: SDD/API-First: изменения начинаются с контракта OpenAPI, затем генерация и контрактные тесты.
Как бы спроектировал HTTP-хендлер перевода с валидацией и таймаутами?
context с deadline, middleware, structured logging, метрики, graceful shutdown, разделение transport и domain.
Отличия error handling в Go от Java в микросервисе?
Явные ошибки, wrapping, не смешивать бизнес-ошибки и инфра; маппинг в HTTP-коды на границе.
Совет: Покажи, что Go не «второй язык для галочки» — пример сервиса с Kafka или REST из продакшена.
Устранение повторяющихся символов в строке
Удалить эффект «залипания клавиши»: подряд идущие одинаковые символы (без учёта регистра для латиницы/кириллицы по условию задачи) схлопнуть до одного. Пример: «Ззддррррррааавствввууй, Сссссбееееррр!» → «Здравствуй, Сбер!».
Один проход: char[] или StringBuilder; если текущий символ равен предыдущему (с нормализацией регистра при необходимости) — пропуск, иначе append. O(n) по длине строки, O(n) память для результата.
Сложность: O(n)
Разбор влияния вложенных вызовов на транзакцию
doA() @Transactional вызывает doB() @Transactional, doB бросает IllegalStateException, исключение ловится пустым catch в doA. Что в БД?
При REQUIRED одна транзакция: unchecked из doB помечает rollback-only, но если исключение поглощено и не rethrow — commit может пройти без отката (зависит от rollback-only и настроек). Корректный ответ: риск частичной фиксации; нужен rethrow, rollbackFor или отдельная propagation REQUIRES_NEW осознанно.
Сложность: концептуально
Почему HashSet не распознаёт объект
Person в HashSet, contains(person) возвращает false после add.
Нет согласованных equals/hashCode (Lombok не подключён/не сгенерировал), либо поля изменились после add. Решение: неизменяемый ключ или стабильные equals/hashCode по бизнес-идентификатору.
Сложность: O(1) ожидание для contains
Переопределение методов с исключениями
Допустимы ли сохранение сигнатуры, добавление/удаление исключений?
Сигнатура (имя, аргументы, return) та же. Checked: можно не объявлять или объявлять подтипы; нельзя добавлять новые checked. Unchecked и Error — гибче. Совместимость с контрактом родителя обязательна.
Сложность: —
Дефект в addAll с wildcards
addAll(List<? super T> first, List<? extends T> second) { second.addAll(first); }
Неверное направление и нарушение PECS: в second (extends) нельзя добавлять элементы произвольно. Должно быть first.addAll(second).
Сложность: O(n+m)
Топ‑10 номеров по числу SMS
Номера с более чем одной SMS, сортировка по убыванию count, limit 10.
SELECT phone_number, COUNT(*) AS cnt FROM sms GROUP BY phone_number HAVING COUNT(*) > 1 ORDER BY cnt DESC LIMIT 10;
Сложность: O(rows) с индексом на phone_number
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| Java Core | можешь объяснить баг HashSet и исправить addAll с wildcards |
| Spring | можешь нарисовать цепочку транзакции и сказать, когда будет rollback |
| Kafka | можешь описать идемпотентный consumer и роль DLQ |
| SQL | пишешь топ-10 и max-salary-per-dept без подсказок |
| Домен | можешь связать требования переводов с backend-расчётами и API |
| Soft | есть честные ответы про инциденты, ИИ и ожидания от роли |
В день собеседования
