247 Java-собесов в банках РФ: 12 вопросов в 80% случаев — и почему №7 валит 9 из 10

Обновление (июнь 2026). Цифры в статье — это срез на март 2026 года: 247 разобранных интервью. С тех пор база заметно выросла — сейчас в ней более 1200 переработанных собеседований и свыше 10 000 вопросов. Общие выводы остаются в силе, но частоты по конкретным вопросам с того момента уточнились; полную обновлённую статистику я выкладываю в канале.

Как всё началось

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

Я открыл блокнот и спросил у него простую вещь — а что вообще тебя спрашивали? Через час у меня было восемьдесят с лишним вопросов из четырёх интервью и стойкое ощущение, что я смотрю на верхушку айсберга. Завёл табличку, начал копаться в открытых видеоразборах, расспрашивать знакомых, собирать инсайды из приватных чатов. Я хотел понять одну простую вещь: что на самом деле спрашивают на Java-собесах в банках и больших ИТ-холдингах сегодня — а не год, два или пять назад.

К весне у меня была база из 247 разобранных интервью по двадцати семи компаниям — от Сбера и ВТБ до питерского ERP-вендора, о котором почти никто не слышал. В этой статье я расскажу о трёх вещах, которые увидел в этих данных. Во-первых — какие двенадцать вопросов повторяются настолько часто, что не знать их сегодня нельзя. Во-вторых — почему стандартный совет «возьми топ-50 вопросов с Хабра» в 2026 году работает плохо. И, в-третьих, почему вопрос номер семь из моего списка стабильно валит девять кандидатов из десяти, включая тех, кто прочитал Bloch и Goetz.

Откуда данные и почему я им верю

База собиралась из трёх источников. Основной — открытые видеоразборы технических собеседований, которые я методично смотрел на протяжении полугода; всего 184 интервью с разобранными транскриптами. Ещё 47 добавили текстовые инсайды и скрининги, опубликованные в открытых каналах. Последние 16 — мой собственный пул: интервью моих знакомых и менти, где я писал вопросы под диктовку прямо в процессе.

Распределение по компаниям получилось показательным. Больше всего интервью пришлось на Сбер — 83 штуки, если суммировать Java и DevOps. На втором месте уверенно сидит ТБанк с 16 интервью, дальше — ASTON, у которого в базе 11 собесов и это уникальная концентрация для одной компании. За ними подтягиваются Wildberries и Data_World с DevOps-вопросами, Иннотех, Газпромбанк, ВТБ. Альфа, ОТП, Совкомбанк, Самокат, МТС, Ozon и Дзен дали по два-три интервью каждая. Остальные — по одному-два.

Большинство интервью пришлось на Middle-уровень — почти две трети выборки. На Junior и стажировки в сумме приходится около 18 процентов, на Senior — 12, и небольшая часть осталась без грейда, потому что это были HR-скрининги.

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

12 вопросов, без которых сегодня нельзя

Вопрос я считал «частым», если он встретился минимум в восьми интервью и был задан в четырёх и более разных компаниях. Получилось двенадцать пунктов — и это, по сути, обязательная программа Middle Java в 2026 году.

Лидером оказался контракт equals и hashCode — он встретился в 41 интервью, почти каждом шестом. Этот вопрос задают на стажировку в Сбере, на Middle в ВТБ, на пробное техническое в ASTON. Самая частая ловушка — попросить кандидата назвать три свойства equals: рефлексивность, симметричность и транзитивность. Эти три слова знают 30% кандидатов. Сразу следом идёт подвопрос из репертуара Format-Кода: если hashCode всегда возвращает сорок два — что произойдёт? Правильный ответ — все элементы попадут в один бакет, HashMap деградирует либо в красно-чёрное дерево (с Java 8), либо в связанный список (до Java 8), и константная сложность поиска превращается в логарифмическую или линейную.

Второй по частоте вопрос — внутреннее устройство HashMap. Он появился в 38 интервью. Спрашивают про массив бакетов, переход в связный список при коллизиях и в красно-чёрное дерево при восьми элементах в бакете (с обратным переходом при шести). Дальше идёт стандартное напоминание о том, что HashSet под капотом — тот же HashMap, где значением выступает плейсхолдер, а интересен только ключ.

Третий — уровни изоляции и MVCC. 32 интервью. Все 4 уровня по стандарту SQL спрашивают регулярно, но особый акцент делают на двух фактах про PostgreSQL: в нём нет Read Uncommitted, а Repeatable Read благодаря MVCC уже без фантомов. Последний нюанс упомянули в 14 интервью отдельно, чтобы проверить, действительно ли кандидат работал с Postgres, а не просто слышал слово.

Дальше — проблема N+1 в Hibernate. 28 интервью. Стандартные ответы — JOIN FETCH, @EntityGraph, batch size. У Газпромбанка в интервью номер 28 есть фирменный подвох: «Индексы по внешним ключам помогут?» — и тут даже опытные разработчики иногда говорят «да», хотя правильный ответ — нет: индексы ускорят каждый отдельный запрос, но никак не уменьшат их количество. Это вопрос про понимание сути N+1, а не про индексы.

Пятый вопрос — propagation у @Transactional. 27 интервью. На Middle обычно ограничиваются тремя самыми частыми значениями, на Senior просят перечислить все семь, и почти всегда отдельно копают NESTED через savepoint: внутренняя транзакция откатывается, а внешняя продолжает.

Шестой — Kafka, partition key и порядок сообщений. 24 интервью. Самая узнаваемая формулировка повторяется почти дословно: «Три партиции и четыре консюмера в одной группе — что произойдёт?». Ответ — один консюмер будет простаивать.

Седьмой вопрос — отдельный разговор. К нему я вернусь чуть ниже, потому что именно он валит большинство кандидатов.

Восьмой — Code Review мини-сервиса на Spring. 21 интервью. Формат стабильно одинаковый везде: ASTON, ТБанк, Совкомбанк, Иннотех дают пятьдесят-двести строк кода и просят найти минимум восемь проблем. Стандартный набор:

@Servicepublic class OrderService {    @Autowired                                   // 1. Field injection вместо конструктора    private OrderRepository repo;     @Transactional                               // 6. Без isolation/propagation/rollbackFor    public void process(Map<String, Object> body) {        double amount = (double) body.get("amt"); // 3. double для денег вместо BigDecimal        if (amount > 1000000) {            System.out.println("Big: " + amount); // 2. System.out вместо логгера        }         Order o = repo.findAll().stream()        // 5. findAll вместо findById/existsById            .filter(x -> x.getId() == 1L)            .findFirst().get();                  // (+ Optional.get без isPresent)         RestTemplate rt = new RestTemplate();    // 7. new вместо переиспользуемого бина        rt.postForObject(URL, o, String.class);  // (+ вызов в транзакции, нет timeout)    }}

Девятый — CPU throttling и OOMKilled в Kubernetes. 14 интервью. Любимый кейс A-Деньги и Иннотеха формулируется так: «У вас шестнадцать инстансов сервиса в K8s. Один из них падает раз в неделю по CPU throttling. С чего начнёте?». Правильный план диагностики — Grafana с метриками CPU, памяти и GC, дальше — нагрузочное тестирование на отдельном стенде, потом — поднятие уровня логирования.

Десятый — SELECT FOR UPDATE и проблема lost update. 13 интервью. Самая красивая формулировка у Совкомбанка в Senior-интервью номер 211: «Прилетело пятьсот параллельных запросов «оплатить». Какую блокировку выберете?». Правильный ответ — оптимистичная блокировка через @Version хороша при редких конфликтах, но для платежей она бесполезна: при частых конфликтах она будет постоянно сыпать исключениями и заставлять делать retry. Поэтому в платёжных сценариях используют пессимистичную через SELECT FOR UPDATE.

Одиннадцатый — логическая задача про мост и фонарик. Пять интервью, и все — из ВТБ Senior. Я был уверен, что это городская легенда из старых статей на Хабре, пока не увидел эту задачу в реальном январском интервью 2026 года. Условие: четыре человека (1, 2, 5 и 10 минут), мост выдерживает двоих, фонарик один. Правильный ответ — семнадцать минут, а не девятнадцать.

Алгоритм такой: сначала идут двое самых быстрых — 1 и 2 (две минуты), потом 1 возвращается с фонариком (ещё минута), затем идут двое самых медленных — 5 и 10 (десять минут), 2 возвращается (две минуты) и, наконец, 1 и 2 переходят вместе (ещё две минуты). Итого две плюс одна плюс десять плюс две плюс две — семнадцать минут. Принцип, который надо понять: самых медленных всегда отправлять вместе, чтобы не платить дважды за десять минут.

Двенадцатый и последний — «расскажи про прод-инцидент, который ты чинил». 11 интервью, все на Senior. Формат — STAR: ситуация, задача, действия, результат. Готовых историй у Senior должно быть две-три, иначе у интервьюера сразу возникает подозрение, что человек никогда не дежурил on-call.

Почему вопрос номер семь валит девять из десяти

Я специально не стал разворачивать его в общем списке. Вопрос на первый взгляд тривиальный: про @Transactional и self-invocation.

Разворачивается это всегда одинаково. Кандидат уверенно рассказывает про прокси, перечисляет уровни propagation, объясняет разницу между JDK Dynamic Proxy и CGLib. Интервьюер слушает, кивает, а потом задаёт вопрос:

Метод A в классе OrderService вызывает метод B того же класса. На методе B стоит @Transactional. Какая транзакция откроется при вызове A?

Девять кандидатов из десяти начинают рассуждать в одном из трёх ключей. Кто-то говорит, что откроется новая с propagation REQUIRES_NEW. Кто-то — что присоединится к существующей через REQUIRED. Кто-то — что всё зависит от настройки прокси-фабрики.

Правильный ответ короче и неприятнее: никакая транзакция не откроется. Прокси Spring оборачивает только внешние вызовы — те, что приходят через сам proxy-объект, который контейнер положил в DI. Когда A делает this.B(), это прямой invokevirtual через байт-код, минующий обёртку. Аннотация @Transactional на B в этот момент просто игнорируется.

Я насчитал этот вопрос в 31 интервью из 247. Угадайте, сколько раз кандидат ответил правильно с первой попытки? 4. 4 из тридцати одного, и это, обратите внимание, те самые кандидаты, которые до этого уверенно рассказывали про прокси. Они читали про self-invocation, но не задумывались, что значит это правило на уровне байт-кода. И в момент, когда нужно применить знание к конкретному коду, оно рассыпается.

Лечится это четырьмя способами, и знание про каждый — отдельная маленькая победа на собеседовании. Самый частый — self-injection через @Lazy: бин получает ссылку на самого себя в качестве зависимости, и вызов self.B() идёт через прокси. Чище с точки зрения дизайна — вынести B в отдельный сервис: это и SRP, и неявная гарантия, что прокси всегда отработает. Если хочется, чтобы и this.B() тоже шло через транзакционную обёртку — можно включить AspectJ-режим через @EnableTransactionManagement(mode = AdviceMode.ASPECTJ), но за это придётся заплатить compile-time или load-time weaving. Наконец, есть TransactionTemplate — программное управление транзакцией без аннотаций, удобное в местах, где @Transactional плохо ложится на архитектуру.

Запомните эту четвёрку решений и сам принцип «прокси оборачивает только внешние вызовы». Это пять минут на собеседовании, которые в десять раз больше говорят о вас, чем безупречный пересказ propagation-таблицы из документации.

Чем ASTON отличается от Сбера

Эти 11 ASTON-интервью и 83 Сбер-интервью — самая большая концентрация однотипных данных в моей базе, и она показывает любопытную закономерность. Два самых сильных работодателя на банковском Java-рынке собеседуют по принципиально разным правилам.

ASTON — это аутсорсер, и его внутреннее техническое — это пробег по тридцати темам за полтора часа. Первый вопрос почти всегда про SQL и виды JOIN, дальше — широкая трасса по Java Core, коллекциям, Spring, Hibernate, REST, тестам, Docker. Любимая ловушка — задача про HashMap с мутабельным ключом; рядом — peek без терминальной операции и allMatch на пустом стриме. От кандидата на этом собесе ждут широты: знать всего по чуть-чуть и уметь быстро переключаться. После пробного интервью в ASTON следует основное у клиента — обычно банк или маркетплейс, — где уже подключается специфика проекта.

Сбер устроен иначе. Это инхаус-гигант, и темп собеседования у него совсем другой: за полтора часа интервьюер копнёт три-четыре темы, но каждую — глубоко. Любимое начало — рассказ о проекте, причём слушают с пристрастием. Дальше идут MVCC и VACUUM ANALYZE, чтение плана EXPLAIN (ANALYZE, BUFFERS), тонкости порядка инициализации полей при наследовании, State Machine без локальной переменной. Алгоритмическая секция у Сбера, особенно на Senior, — отдельный мир: Flood Fill, префиксные суммы, реализация бинарного дерева. И, наконец, System Design — у Senior это отдельная секция 60 минут.

Главный вывод из этого сравнения простой: к Сберу и ASTON нельзя готовиться по одному списку. К Сберу надо учить меньше тем, но втрое глубже; к ASTON — больше тем, но допустимо знать каждую поверхностно. Если попробовать совместить и подготовиться «средне по обоим», провалитесь и там и там.

Что меня удивило больше всего

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

Первое — питерские «Бизнес Технологии» на студенческую стажировку требуют больше, чем Сбер. Эта компания делает Global ERP — отечественную альтернативу SAP — и берёт стажёра только в том случае, если тот готов реализовать ArrayList с нуля и обойти бинарное дерево всеми тремя способами на доске. Зарплата на старте — восемьдесят тысяч на руки. Сбер на эквивалентной стажировке требует существенно меньше и платит больше; разница в уровне ожиданий объясняется только тем, что в «Бизнес Технологиях» собственный фреймворк, и они ищут людей, способных читать чужой исходник без подсказок.

Второе — Senior Java в Альфа-Банке местами выходит на уровень книжного автора. В одном из интервью был вопрос: «Как гарантировать обработку сообщения ровно один раз со стороны приложения?». Полноценный ответ занимает пятнадцать минут и требует уверенного владения idempotency-key, дедупликацией через UUID в БД, транзакционным producer’ом Kafka и параметром isolation.level=read_committed у consumer’а. Это уровень главы из официальной книги Confluent, а не повседневной работы Senior-разработчика.

Третье наблюдение я уже упоминал, но повторю — задача про мост и фонарик в ВТБ действительно существует. Я был убеждён, что это городская легенда из статьи на Хабре две тысячи пятнадцатого года, и каждый раз, когда видел её в подборках вопросов, мысленно ставил кавычки. Пока не наткнулся на реальное январское интервью 2025 года в ВТБ Senior, где этот мост обсуждали двадцать минут. Если у вас собеседование в ВТБ — заучите алгоритм наизусть. Я серьёзно.

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

Топ-50 вопросов с указанием источников

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

📋 Развернуть топ-20 (категориями)

Java Core (пять вопросов). Контракт equals/hashCode с тремя свойствами. Внутреннее устройство HashMap с переходом в дерево при восьми элементах. Иммутабельный класс с final-полями и defensive copy. String immutable и final — почему оба свойства одновременно. Stream API ленивый — без терминальной операции peek ничего не выведет.

Многопоточность (три). volatile и отношение happens-before. synchronized на static и на instance — на каком объекте монитор. Singleton thread-safe через double-checked locking с обязательным volatile.

Spring (четыре). Жизненный цикл бина от BeanDefinition до @PreDestroy. @Transactional propagation — все семь значений, особенно NESTED через savepoint. self-invocation обходит прокси — четыре способа лечения. Prototype в Singleton: четыре варианта решения через @Lookup, ObjectFactory, Provider и scoped-proxy.

Hibernate (три). N+1 и три способа лечения. LazyInitializationException после закрытия сессии. final class нельзя сделать Entity из-за прокси.

База данных (три). Четыре уровня изоляции и почему в Postgres дефолтный — Read Committed. MVCC и почему в Postgres Repeatable Read решает фантомы. SELECT FOR UPDATE при параллельных платежах.

Kafka (два). Partition key для гарантии порядка по бизнес-ключу. Три партиции и четыре консюмера в одной группе — один консюмер простаивает.

Что важно понимать, прежде чем действовать

Я ещё раз скажу про ограничения, потому что считаю это важным.

Эта подборка — выборка интервью, попавших в открытый доступ через видеосервисы и инсайды. Она сильно перекошена в банки и крупные интеграторы — Сбер, ВТБ, ТБанк, ASTON и Иннотех представлены непропорционально много. Продуктовые компании и стартапы дают совсем другой набор вопросов, и эта статья — не про них. Я не учитываю молчаливо проваленные собесы, по которым не сохранилось транскриптов. И каждая цифра вроде «тридцать один раз спросили» имеет погрешность около десяти процентов — двойного контроля я не проводил.

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

Что дальше

Если статья оказалась полезной — расскажите в комментариях, какие вопросы валили лично вас и в какой компании. Я добавлю их в базу, и в следующем разборе мы возьмём Senior-уровень с подробной секцией про System Design: какие задачи дают чаще всего, как банки оценивают глубину архитектурного мышления и почему многие кандидаты на Senior проваливаются именно здесь, а не на коде.

Особенно — спасибо тем, кто дочитал до конца. Это значит, я попал в нерв, и тема живая. Удачи на собесах. 🍀

---

P.S. Это была только верхушка. В моём канале @Java_Jub база уже перевалила за 10 000 вопросов, и под каждую вакансию есть отдельный гайд — что именно спрашивают в конкретной компании на конкретной позиции, с разбором ответов и примерами кода. Заходите: проще готовиться точечно под свой собес, чем учить «топ-50 вопросов».