На собесе в банке тебе почти никогда не дают «сложный Spring». Тебе дают тест на зрение, дисциплину и вкус к а

На собесе в банке тебе почти никогда не дают «сложный Spring». Тебе дают тест на зрение, дисциплину и вкус к архитектуре.

Полсотни строк контроллера, и там обычно лежит всё, что убивает прод: бизнес-логика в web-слое, неправильные транзакции, лишние зависимости, кривой error-handling, утечки ответственности между сервисами.

И вот мой жёсткий вывод: если кандидат видит только 3–4 бага, он смотрит на код как исполнитель. Если находит 7–8 — он уже мыслит как инженер. Если замечает девятый, архитектурный, — это редкий случай. Таких на рынке мало.

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

Вот где реально отделяется Junior от Middle и Middle от Senior. Не по знанию аннотаций. По тому, видит ли человек систему 📌

Если хотите, я отдельно разберу, какие именно баги в таких задачах ищут чаще всего и почему банки любят именно такой формат.