Ответ
На новой работе я хотел бы видеть следующие возможности и условия:
Технологический стек и задачи:
- Работа с современным стеком Java: Spring Boot, микросервисная архитектура, облачные платформы (AWS, Azure, GCP).
- Интересные и сложные задачи, позволяющие применять и углублять знания best practices, принципов SOLID и паттернов проектирования.
- Возможность влиять на архитектурные решения и процессы разработки.
Команда и культура:
- Профессиональная команда с сильными коллегами, у которых можно учиться.
- Практика code review как инструмент обмена знаниями и поддержания качества кода.
- Гибкий график и здоровый баланс между работой и личной жизнью.
Пример ожиданий от кодовой базы:
// Ожидаю возможность писать чистый, поддерживаемый код
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor // Использование Lombok для инъекции зависимостей
public class UserService {
private final UserRepository userRepository;
private final UserMapper userMapper;
@Transactional
public UserDto createUser(CreateUserRequest request) {
User user = userMapper.toEntity(request);
User savedUser = userRepository.save(user);
return userMapper.toDto(savedUser);
}
}
Профессиональный рост:
- Прозрачные критерии и пути карьерного роста.
- Возможность участия в конференциях, обучения за счет компании.
Ответ 18+ 🔞
Да ты посмотри, какие запросы! Прямо как на собеседовании в какой-нибудь ебученький финтех, где тебе за красивые глаза обещают золотые горы, а потом заставляют на древнем монолите хуйню править.
Ну что ж, разбираем по пунктам, как этот твой манифест.
По технологиям и задачам: Современный стек, говоришь? Spring Boot, микросервисы, облака... Ну, это сейчас у всех в требованиях, как «не пидарас». Но, чувак, главное — чтобы за этим не скрывался пиздец, где «микросервисы» — это просто размазанный по десяти репам такой же спагетти-код, только теперь ещё и с ебучой сетевой связностью. «Влиять на архитектуру» — это звучит охуенно, пока не понимаешь, что архитектурное решение — это «делай как в прошлый раз, и не выёбывайся». Best practices и SOLID — это святое, конечно, но часто на них всем насрать, когда горит дедлайн и бизнес орёт, как резаный.
По команде и культуре: Сильная команда — это мечта. Это когда не ты один тащишь на себе весь долбаный проект, а есть с кем мозги почесать. Code review — это вообще must have, чтобы не было такого, что какой-то гений напишет хуйню вроде:
// Вот этого я ожидаю НЕ видеть, блядь
public class UserUtilHelperFactoryManagerImpl {
public void process() {
// 500 строк спагетти, где всё перемешано с бд, логикой и выводом в консоль
}
}
А гибкий график... Ну, гибкий он до тех пор, пока в четыре утра не начнут слать сообщения: «А мы тут подумали, а давай сделаем вот так...».
По росту: «Прозрачные критерии роста» — это вообще, блядь, как розовый единорог. Чаще всего это туманные формулировки в духе «прояви больше лидерских качеств» или «возьми на себя больше ответственности», что на нормальном языке означает «работай больше, а денег тебе не прибавят». Конференции за счёт компании — это реально круто, если, конечно, компания не считает, что лучшая конференция — это внутренний митап с пиццей и уставшим тимлидом.
Короче, суть-то вот в чём: всё, что ты перечислил — это не просто хотелки, это, по сути, чек-лист на вшивость работодателя. Если они тебе всё это могут дать — ты попал, можно сказать, в рай для разраба. Но будь готов, что в реальности из этого списка выполнится процентов 60, и это уже будет охуенный результат. Главное — смотри не на слова, а на дела. Задавай на собеседовании ебаные уточняющие вопросы: «А какой у вас самый долгий микросервис? Покажите пару примеров пулл-реквестов. Как часто пересматриваются грейды?». Если начнут мычать и увиливать — всё, пидары налетели, это красный флаг размером с хуй с горы.
Удачи, надеюсь, найдёшь место, где не будут ебать мозг и дадут делать дело.