С чем не хочешь работать на новом месте

Отличный и очень важный вопрос. Он показывает зрелость и понимание своих профессиональных границ. Как senior-разработчик с большим опытом, я сформировал четкое представление о среде, в которой могу быть максимально продуктивен и принести наибольшую пользу проекту.

Если говорить о том, с чем я не хотел бы работать, то это не столько конкретные технологии (хотя и здесь есть предпочтения), сколько определенные процессы, подходы и культура, которые, по моему опыту, гарантированно ведут к провалу проекта, выгоранию команды и созданию некачественного продукта.

1. Токсичная культура и неэффективные процессы

Я сознательно избегаю сред, где царят следующие антипаттерны:

• Гонка за дедлайнами любой ценой: Постоянный «хактаим», «критические» задачи каждую неделю и полное отсутствие времени на рефакторинг, технический долг и простое обдумывание архитектуры. Это путь к созданию хрупкой, неподдерживаемой «макаронной» кодовой базы.

  // Пример кода, который рождается в таких условиях - "работает, и ладно".
  void Update() {
      // Всё в одном методе, магические числа, дублирование кода.
      if (player.health <= 0 && !isDead) { /* ... */ }
      if (Input.GetKeyDown(KeyCode.Space) && canJump && isGrounded || isOnWall) { /* ... */ }
      // Прямые ссылки на глобальные менеджеры - теснейшая связанность.
      GameManager.Instance.score += 10;
      AudioManager.Instance.PlaySound("jump");
  }
  

• Отсутствие инженерной культуры: Когда нет места код-ревью, автоматизированному тестированию (юнит-тесты, интеграционные тесты), CI/CD. Когда любой скрипт можно залить прямо в прод, а понятия «версионность» и «билд-пайплайн» вызывают недоумение.
• Культура обвинений и микроменеджмент: Страх совершить ошибку убивает инновации и инициативу. Когда за каждым плечом стоит менеджер, диктующий «как правильно писать код», это демотивирует и лишает команду экспертизы.

2. Устаревшие и негибкие технологические стеки (с оговорками)

Здесь моя позиция более гибкая, но есть красные линии:

• Полное отсутствие современного инструментария: Проект на Unity 5.x без планов на миграцию, использование устаревших систем вроде UnityWebRequest без async/await, отказ от использования Addressables или Asset Bundles для управления контентом, игнорирование URP/HDRP для новых проектов. Работа с таким стеком — это постоянная борьба с ограничениями, а не разработка.
• «Not Invented Here» Syndrome (Синдром «изобретено не здесь»): Когда компания пишет свои движки для простых вещей (например, свой UI-фреймворк вместо использования UI Toolkit или адекватного UGUI), игнорируя проверенные industry-standard решения. Это колоссальная трата ресурсов.

3. Неясное видение и «feature creep»

• Отсутствие четкого Game Design Document (GDD) и Product Vision: Когда задачи ставятся по принципу «сделай как в той игре, только лучше», а требования меняются ежедневно. Это приводит к бесконечным переделкам и деморализации команды.
• Отсутствие прототипирования: Попытка сразу писать «продакшн-код» для непроверенной геймплейной механики. Я убежден, что сначала нужно быстро и грязно проверить fun-фактор на примитивном прототипе.

Что я, напротив, ищу и ценю:

Я стремлюсь к проектам, где есть:

• Здоровый баланс между скоростью и качеством.
• Доверие к экспертизе разработчиков. Меня нанимают за мои знания, и я ожидаю, что к ним будут прислушиваться.
• Четкие процессы: Agile/Scrum, которые применяются разумно, а не как догма. Регулярные планирования, ретроспективы, конструктивные код-ревью.
• Фокус на качестве кода: Понимание, что инвестиции в архитектуру, тестирование и чистоту кода окупаются на дистанции.
• Современный стек и готовность к его обновлению.

Таким образом, мой «отказ» — это не каприз, а профессиональная фильтрация сред, где я, как senior, не смогу реализовать свой потенциал для создания стабильного, масштабируемого и успешного продукта. Я ищу партнерство, а не просто место для написания кода.