В каких доменах не хочешь работать?

Отличный, глубокий и честный вопрос, который раскрывает профессиональную зрелость кандидата. Отвечая на него, я исхожу из 10-летнего опыта, который сформировал не только технические предпочтения, но и понимание того, в какой среде я могу приносить максимальную пользу. Мои «нехотелки» — это не капризы, а осознанный выбор в пользу проектов, где я силен и мотивирован.

Я структурирую ответ по двум ключевым направлениям: предметные области (Domain) и типы продуктов/компаний.

Предметные области (Domain)

Здесь речь идет о содержании приложения. Есть домены, где мой интерес и экспертиза близки к нулю, что негативно скажется на качестве работы и моей продуктивности.

1. Индустрия азартных игр и букмекерские конторы. Это этический и личный выбор. Я не хочу применять свои навыки для создания продуктов, которые, по моему убеждению, эксплуатируют психологические слабости людей и могут причинять реальный вред. Архитектура или технические задачи там могут быть сложными (высокие нагрузки, реальное время), но цель продукта для меня неприемлема.

2. Криптовалютные проекты высокого риска (скам, нерегулируемые биржи, гиперспекулятивные NFT). Сама по себе блокчейн-технология интересна. Однако огромный сегмент рынка — это продукты, построенные на финансовой пирамиде, неясном регулировании и агрессивном маркетинге. Я не готов нести даже косвенную ответственность за потенциальные потери пользователей из-за неочевидных рисков или уязвимостей в коде, который я пишу.

3. Гипермаркеты низкокачественного контента (clickbait, fake news агрегаторы). Проекты, чья бизнес-модель строится на дезинформации, накрутке engagement за счет гнева или шока, противоречат моему представлению о том, как технологии должны улучшать жизнь. Технически это может быть просто лента с рекламой, но смысловая наполненность важна для долгосрочной мотивации.

Типы продуктов и организаций

Даже в интересной предметной области важен контекст работы. Вот что для меня является «красной зоной»:

1. Проекты с «черной» или «серой» UX-стратегией. Речь о намеренно вводящих в заблуждение интерфейсах (Dark Patterns). Например:

    *   Сложная, многоступенчатая отмена подписки.
    *   Навязчивые пуш-уведомления с ложными срочными сообщениями.
    *   Дизайн, который заставляет пользователя случайно купить что-то или подписаться.

```swift
// Условный пример "плохого" кода, реализующего dark pattern
class TrickySubscriptionViewController: UIViewController {
    // Кнопка "Отмена" едва видна и находится за пределами видимой области
    private let cancelButton: UIButton = {
        let button = UIButton(type: .system)
        button.setTitle("Отмена", for: .normal)
        button.titleLabel?.font = .systemFont(ofSize: 10)
        button.setTitleColor(.lightGray, for: .normal)
        // Кнопка размещается за пределами safe area
        return button
    }()

    // Основная, яркая кнопка ведет к немедленному списанию средств
    private let confirmButton = UIButton(type: .system) // Яркая, большая кнопка "Попробовать"
}
```

    Работа над таким продуктом демотивирует, ведь задача разработчика — решать проблемы пользователя, а не создавать их.

1. Компании с токсичной культурой разработки. Конкретные антипаттерны:

    *   **Постоянный «героизм» как норма:** Если авралы, работа по ночам и выходным — это стандартный процесс, а не исключительная ситуация, значит, в компании фундаментально broken процесс планирования.
    *   **Отсутствие инженерных практик:** Полный отказ от code review, автоматических тестов, CI/CD под предлогом «скорости». В долгосрочной перспективе это приводит к **техническому долгу**, который делает развитие продукта мучительным и рискованным.
    *   **Культура страха и обвинений:** Когда за баг в production начинаются поиски виноватого, а не анализ причин и улучшение процессов.

1. Чисто «скипеточные» или «таск-дробильные» роли. Я не хочу быть просто исполнителем, который получает сверхдетализированные ТЗ от менеджера/дизайнера и просто «переводит» их в код. Мне важен этап обсуждения, возможность задать вопрос «Зачем?», предложить альтернативное, более эффективное с технической точки зрения решение, повлиять на архитектуру и долгосрочное качество кодабазы.

Заключение и баланс

Важно отметить, что этот список — не догма. Исключением может стать уникальная техническая задача. Например, если в той же криптоиндустрии есть проект с открытым исходным кодом, фокусом на приватность и реальные инновации в области распределенных систем, я готов его рассмотреть. Или если в «нежелательной» отрасли есть команда, которая открыто борется с ее недостатками (например, приложение для ответственной игры с лимитами и самоконтролем).

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