На собеседованиях по Java у крупных банков всё чаще крутят один и тот же приём: не «знаешь ли ты Spring», а ум

На собеседованиях по Java у крупных банков всё чаще крутят один и тот же приём: не «знаешь ли ты Spring», а умеешь ли быстро найти системные ошибки в коде.

Мне уже несколько раз попадался один и тот же паттерн — контроллер на 40–50 строк, который с виду рабочий, но внутри набит ловушками от уровня Junior до Senior.
Типовые места, где обычно прячут баги: неверная транзакционность, утечки через логирование, невалидируемые входные данные, гонки за счёт состояния в singleton, неправильная обработка исключений, проблемы с временем/таймзонами, неидемпотентные операции и слабые границы между контроллером и бизнес-логикой.

Интереснее другое: девятый баг часто не в коде, а в архитектуре. И вот его на интервью почти никто не видит — потому что он выглядит «нормально» для маленького сервиса, но ломается на реальной нагрузке и в распределённой системе.

Хороший тест для команды: если за 15 минут нашли 4–5 дефектов — уровень крепкий. Если 8 — человек реально умеет code review. Если больше — значит, смотрит не только на синтаксис, а на поведение системы целиком 🔍