Подборка объединяет вопросы, отмеченные на этапах интервью в Т-Банк. Здесь можно понять структуру технической проверки и заранее повторить связанные темы. В подборке чаще встречаются темы: database, backend, api.
Точные значения предсказать нельзя: incA++ и incB++ неатомарны, поэтому обновления теряются. CountDownLatch ждёт завершения и обеспечивает видимость, но не делает инкременты безопасными.
Вывод: true, false, true, true. Оператор == сравнивает ссылки, а String.equals — последовательность символов, поэтому отдельный объект third равен первым по содержимому.
Будет выведено только [dog, cat, parrot]. У стрима нет терминальной операции, поэтому sorted, peek и map не выполняются; исходный список не изменяется.
Основные ошибки: double для денег, неоднозначные границы комиссии, два Fee при сумме выше 5000 и отсутствие комиссии ровно при 1000. Внешние вызовы внутри транзакции создают дополнительные риски.
SQL Hibernate можно увидеть через logger org.hibernate.SQL на DEBUG. В Hibernate 6/7 bind-параметры логирует org.hibernate.orm.jdbc.bind на TRACE; категории зависят от версии.
Расскажите, что проверяли unit-тестами изолированно, а что интеграционными — вместе с реальными компонентами. Приведите один тест, который обнаружил важную ошибку.
Сначала локализуйте: медленная конкретная операция, все запросы или ожидание пула соединений. Затем сопоставьте изменения нагрузки, планы запросов, locks, I/O, CPU и память.
Возвращать entity из репозитория внутри persistence-слоя нормально. Проблемы возникают при переносе её за нужную транзакционную границу: lazy-loading, лишние запросы и утечка внутренней модели.
Выберите реальную задачу, где отвечали за полный путь: уточнение требований, проектирование, реализацию, проверки и выпуск. Самостоятельность не исключает review и согласование с коллегами.
Если Redis — только ускоряющий кэш, допустим контролируемый fallback к БД после короткого timeout. Ошибку кэша нужно отличать от отсутствующего ключа и не превращать в бесконечные повторы.