semen.s.semenegorychпропущено...
для полноты картины у них должен быть ещё запрет в кодинг-стандарте на явное использование строковых литералов в коде)))

Какие еще кодинг стандарты

Весь кодинг стандарт это отношение к тебе со стороны вышестоящего

Условно говоря - код хорошие пока его автора некому лишить работы.

Поэтому у самого главного менеджера самый отличный код

У духа джуниора - самое Г

Лид пишет хороший код - пока менеджеру не захочется его глянуть и покритиковать

Армия е - мое, тупая армия
Я не знаю как в мире С++. Но в Java сегменте разработки чем ты синьорнее - тем ты меньше пишешь кода.
Фактически интервью в части middle/senyor/tech-lead будет не сильно отличаться. Основная разница в опыте
работы и в способности оценить сложность будущей разработки а также в способности понимать business
value той или иной фичи.

Кстати - самая большая ошибка Java-критикующих в том что они считают что EE-проект создается на Java.
Это не так. Современное EE-приложение это огромный слоистый торт из различных языковых технологий
которые на выходе дают код но в изначальном представлении - их исходник не является Java.

Я перечислю только те с которымми работал сам. Часть их них являют просто язык. Часть - фреймворк
с языком. Или часть можно назвать библиотекой но достаточно специфичной и требующей глубоких
знаний. Тоесть так просто "с пол-пинка" вы в нее не зайдете. Нужно читать concepts.
- Droolz (бизнес-правила, flow события в системе)
- Hibernate HQL (языки ORM)
- Spring Boot (в части configuration) это пожалуй более чем половина структурных описаний приложения
- FreeMarker (описание форм отчотности)
- Jasper (XML-подобное описание дизайна отчотов)
- Gradle (фреймворк и некий язык описания процесса сборки)
- Apache Camel DSL(XML - тоже flow бизнес процессов с очень развитыми возможностями по интеграции,
к примеру http-сервер является просто endpoint-ом c точки зрения Camel коих может быть очень
много и в разных протоколах в т.ч. и асинхронных)
- Maven (тоже описатель процесса сборки крупного проекта но декларативный. В отличии от Gralde
в нем нет проверок условий и вся логика запрятана в плагины)
- JBehave (конструктор языка описания интеграционных или конечных тестов на естественном языке для бизнеса)
- Liquibase/Flyway - языки контроля версий и описания патчей к реляционным DBMS.

Это не означает что на собесе спрашивают именно это. Это просто некий потенциальный перечень "нежданчиков"
с которыми надо будет работать и разбираться. Тоесть вариант "Выучил назубок Java-core и теперь я все знаю" - это миф.
Это просто стартовая точкая. Вы еще никто. После нее горизонт познания еще расширяется только.

Поэтому самый главный менеджер (техлид) проекта кода вообще не пишет. У него будет достаточно работ в части
code-review, архитектурных вопросов и бесконечных согласований изменений к BR.

По поводу того тчо менеджеру вдруг захочется глянуть и покритиковать.

Я не знаю где вы работали и как. В хорошей конторе есть определённый кодекс поведения (Code Of Conduct)
есть система ценностей (Values) и видение конечной цели. Если команда мотивирована. Получает оплату и
понимает что работа каждого зависит от teammates, то никакого подсиживания и критики быть не должно.

Вобщем мой вам совет в первую очередь. Пересмотрите своего работодателя. Поищите хороший
аутсорс который работает на западного заказчика.

Извини. Мне просто показалось что часть твоих сообщений содержат
горечь и злобу. Страницей раньше.

Будто ты был джуном. Тебя обижали. Мозк отбивали и прочее.

Ну это так... не факт а просто впечатление.

Хорошо проехали. Ты - не джун.

Можешь рассказать о текущем проекте? Разумеется я не прошу раскрывать NDA
и всякие имена и адреса.

Просто. Технологический стек.