По каким критериям ищешь новый проект

# По каким критериям ищу новый проект

За годы я научился отличать хорошие проекты от плохих. Вот мой чеклист.

1. Техническая сложность (главное)

Есть ли архитектурные вызовы?

Я ищу проекты, где нужно решать нетривиальные задачи:

✅ Микросервис с высокой нагрузкой (10k+ RPS)
✅ Distributed system с консистентностью данных
✅ Real-time система с low latency требованиями
✅ Интеграция со сложными external systems
✅ Complex event processing

❌ CRUD приложение (даже большое)
❌ "Страничка с формой"
❌ Простая обёртка над БД

Есть ли место для роста?

Глядишь не на текущее состояние, а на потенциал:

"Сейчас монолит, но планируем микросервисы" — хорошо
"Будет миграция на Spring Boot 3, virtual threads" — интересно
"Нужна оптимизация с 100ms до 10ms latency" — вызов

2. Техстек (вторичное, но важно)

Java версия

✅ Java 21+ (modern, лучшая производительность)
✅ Java 17+ LTS (нормально, поддержка 8 лет)
⚠️  Java 11 (старая, но ещё нормально)
❌ Java 8 (if новый проект — красный флаг)

Если в 2025 стартуют новый проект на Java 8 — это признак того, что не понимают современный Java.

Фреймворк

✅ Spring Boot (современный, гибкий)
✅ Quarkus (cloud-native, fast startup)
⚠️  Legacy Spring (старая, но управляемо)
❌ Custom IoC контейнер (reinventing the wheel)

БД

✅ PostgreSQL (мой выбор, мощная, надёжная)
✅ MySQL 8+ (normalno)
⚠️  MongoDB (only если really нужен нестрогий schema)
❌ "Используем 3 БД для одного микросервиса" (красный флаг)

3. Коллектив (решающий фактор)

Уровень команды

Это больше всего влияет на качество жизни:

✅ Senior разработчики, которые могут учить
✅ Code review с обсуждением, не просто approval
✅ Инженеры, которые думают о решении, а не просто кодят

❌ Junior-only команда без лидов
❌ Code review = "смотрю 10 файлов за 1 минуту"
❌ "Давайте переделаем, потому что я хочу"

Есть ли лидер (tech lead / architect)?

✅ Есть человек, который отвечает за архитектуру
✅ Он объясняет WHY, а не только WHAT
✅ Готов пересмотреть решение, если дать аргументы

❌ Архитектура — стихийно
❌ Все решения сверху, без обсуждения

Культура обсуждения

Это видно сразу на интервью:

✅ "Почему вы выбрали микросервисы?" — объясняют
✅ "Какие проблемы у вас с этим подходом?" — говорят честно
✅ "Как вы приняли это решение?" — было обсуждение

❌ "Это решение архитектор, не трогай"
❌ "Потому что так надо"

4. Практики (качество)

Testing

✅ Есть unit тесты, code coverage > 80%
✅ Integration тесты для сложных сценариев
✅ E2E тесты для критичных flows
✅ Тесты параллельные (быстрый feedback)

❌ "Тесты — потеря времени, пусть QA ловит"
❌ Coverage < 30%

CI/CD

✅ Автоматические тесты на каждый PR
✅ Развёртывание в staging автоматически
✅ Production deployment простой (один click)
✅ Возможность откатиться за 5 минут

❌ Ручное развёртывание
❌ Тесты не запускаются на PR
❌ Deploy = страх

Code standards

✅ Linter / formatter настроены и обязательны
✅ Architecture decision log
✅ Design document для новых фич

❌ "Кодим как хотим"
❌ Нет стандартов

5. Business (понимание)

Есть ли product vision?

✅ Понимаю, зачем мне эта задача
✅ Вижу, как это помогает пользователям
✅ Есть roadmap (3-6 месяцев вперёд)

❌ "Не знаем, что будет на следующей неделе"
❌ Постоянные приоритеты меняются

Finansial stability

✅ Компания прибыльна или хорошо финансируется
✅ Не из последних 6 месяцев на runway
✅ Зарплата market rate (не ниже конкурентов)

❌ Startup, который просит работать дешево "за equity"
❌ Финансовые проблемы в air

6. Work-life balance

Часы

✅ 40 часов в неделю норма
✅ Возможность remote (хотя бы 3 дня в неделю)
✅ Flextime (приходишь в 10 или 9 — не важно)

❌ 50+ часов стандарт
❌ Микроменеджмент ("где ты находишься прямо сейчас?")

On-call

Если есть on-call:

✅ Ротация (не один человек 365 дней)
✅ Оплата за on-call время
✅ В production редко падает, большой MTBF

❌ "Всегда на связи"
❌ Оплата символическая

7. Рост и обучение

Есть ли budget на обучение?

✅ Конференции (оплачивают)
✅ Курсы и сертификаты (budget)
✅ Tech books (небольшой budget)

❌ "Обучайся за свой счёт"

Есть ли менторство?

✅ Более опытный разработчик помогает
✅ Code review от людей, которые умнее
✅ Design discussion до кодирования

❌ "Ты senior, разбирайся сам"

8. Стабильность и долгосрочность

Есть ли план развития на 2+ года?

✅ Видишь, как проект растёт
✅ Есть место для evolution
✅ Не боишься, что вот-вот закроют

❌ "Неизвестно, что будет в мае"

Мой чеклист (в порядке приоритета)

1. Есть архитектурные вызовы? (обязательно)
2. Коллектив senior level? (обязательно)
3. Есть культура обсуждения? (обязательно)
4. Testing + CI/CD в норме? (обязательно)
5. Зарплата market rate? (обязательно)
6. Комфортный работа? (очень важно)
7. Есть growth opportunity? (важно)
8. Tech stack modern? (желательно)

Если первые 5 галочек есть — рассматриваю. Если одна из первых 3 — нет.

Как проверить во время интервью

Технические вопросы

"Какие основные challenges сейчас?"
"Почему вы выбрали микросервисы?"
"Что вы хотели бы переделать в архитектуре?"
"Как вы балансируете между скоростью и качеством?"

Ответы покажут, насколько они глубоко думают.

Про команду

"Кто будет мой tech lead?"
"Как проходит code review?"
"Какая самая интересная задача была решена в последние 6 месяцев?"

Позволяет понять культуру и уровень.

Про работу

"Какой средний стаж на позиции в команде?"
"Если человек в команде 2+ года, это хороший знак"
"Если все junior, красный флаг"

Красные флаги

🚩 "Мы слишком быстро растём" (часто = плохой QA) 🚩 "Java 8, это норма" (старое мышление) 🚩 "Нет тестов, QA ловит" (хаос) 🚩 "Deploy в production вручную" (риск) 🚩 "Один senior на 10 junior" (невозможно обучать) 🚩 "Startup без бюджета на зарплату" (выгорание) 🚩 "Микросервисы без необходимости" (сложность)

Итог

Делаю выбор не по зарплате, а по техническому росту, команде и качеству жизни. Проект с хорошей командой и интересными задачами дороже денег. Лучше работать в хороших условиях на 30% меньше, чем выгорать на деньги.