С чем не хотел бы столкнуться на новой работе

Question

claude-haiku-4.5 · Accepted Answer

## С чем не хотел бы столкнуться на новой работе

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

### 1. Отсутствие юнит-тестов и качества кода

**Что я имею в виду:**
```java
// ❌ Кошмар разработчика
public class UserService {
    public void process(Object obj) throws Exception {
        try {
            // 500+ строк логики БЕЗ структуры
            if (obj != null) {
                List items = (List) obj;  // БЕЗ типизации
                for (int i = 0; i < items.size(); i++) {
                    // Непонятная логика
                    // Нет документации
                    // Нет unit-тестов
                }
            }
        } catch (Exception e) {
            e.printStackTrace();  // Логирование через println
            // Ошибка проглочена
        }
    }
}
```

**Почему это проблема:**
- Невозможно рефакторить без страха сломать что-то
- Баги легко добавляются и трудно отлавливаются
- Техдолг растёт экспоненциально
- Team velocity падает

**Мой подход:**
> "Я не хотел бы работать в кодовой базе без юнит-тестов и code review. Я верю в TDD и clean code. Если компания серьёзна относится к качеству, я готов работать в любых условиях — даже с legacy кодом, если есть время на его улучшение."

### 2. Отсутствие Code Review и культуры развития

**Проблема:**
```
Разработчик пишет код → сразу в production
         ↓
    Никто не проверяет
         ↓
      Баги в production
         ↓
    Паника и переделки
```

**Почему это важно:**
- Code review — единственный способ поддерживать quality
- Без review нет knowledge sharing
- Зелёные разработчики не растут
- Архитектурные ошибки не ловятся рано

**Мой подход:**
> "Я хочу работать в команде, которая ценит code review и continuous improvement. Code review — это не контроль, это возможность учиться. Я готов быть ревьюером и получать feedback."

### 3. Микроменеджмент и отсутствие доверия

**Признаки микроменеджмента:**
- Ежедневные reports о том, что ты делал
- Вопросы о каждом коммите
- Требование работать на месте 8 часов в день
- Контроль времени вместо результатов

**Почему это токсично:**
```
Микроменеджмент → Дистресс → Низкая производительность
                        ↓
              Текучка кадров
```

**Мой подход:**
> "Я предпочитаю работать в среде, где меня оценивают по результатам, а не по времени в офисе. Я ценю доверие и автономию. Ежедневные скраме и планирование спринтов — да, микроменеджмент — нет."

### 4. Технический долг и отсутствие refactoring

**Типичная ситуация:**
```
Проект: 10 лет
Кодовая база: 500k LOC
Историческое наследие: Legacy Java 1.4
Удобство разработки: 2/10

Техдолг: 1000+ часов
BugFix velocity: 30% от времени разработки
```

**Опасность:**
- Каждая новая фича требует обхода legacy кода
- Impossible to refactor (слишком переплетено)
- Разработчики уходят, потому что работа неинтересная

**Мой подход:**
> "Я не боюсь legacy кода и могу работать с большими кодовыми базами. НО я хочу видеть план по улучшению quality. Хотя бы 10-20% спринта на техдолг. Без этого система будет медленно умирать."

### 5. Отсутствие ясных требований и постоянная смена приоритетов

**Сценарий ада:**
```
Понедельник:  "Нужна фича A"
Вторник:      "Срочно фича B" (A переделается)
Среда:        "А, нужна фича C" (B переделается)
Четверг:      "Почему A ещё не готова?!"
Пятница:      "Всё переделать под фичу D"
```

**Последствия:**
- Невозможно спланировать
- Context switching убивает productivity
- Никто не доволен результатом
- Burnout неизбежен

**Мой подход:**
> "Я хочу работать в компании с чётким product management. Я понимаю, что приоритеты меняются, но смена должна быть обоснована и нечастой. Я предпочитаю спринты с ясными целями, а не постоянный chaos."

### 6. Отсутствие технического роста и учебных возможностей

**Проблема:**
```
Разработчик пишет один и тот же код 10 лет
                  ↓
    Навыки не развиваются
                  ↓
        Человек становится liability
                  ↓
        Компания страдает
```

**Что я ценю:**
- Возможность учиться новым технологиям
- Конференции и курсы
- Менторинг от синиоров
- Возможность вести другие проекты

**Мой подход:**
> "Я ценю компании, которые инвестируют в развитие людей. Это может быть обучение, конференции, или просто возможность работать над интересными технологиями. Я не хочу застрять на одном stack 10 лет."

### 7. Непредсказуемые дедлайны и переработки

**Red flags:**
- "Это критичное, работаем через выходные"
- "Deadline — уже вчера, нужно catch up"
- 60-часовые рабочие недели — нормальное дело
- Отпуск отменяется в последний момент

**Долгосрочный эффект:**
```
Переработка → Burnout → Health issues → Уход из компании
```

**Мой подход:**
> "Я готов работать интенсивно и иногда задержаться для критичного релиза. НО это должно быть исключением, а не правилом. Я хочу здоровый work-life balance и предсказуемый graph нагрузки."

### 8. Отсутствие документации и knowledge sharing

**Результат:**
```
Новичок: "Как это работает?"
Опытный: "Ну, это сложно объяснить. Смотри код"
      ↓
Новичок читает 500 строк спагетти-кода и плачет
```

**Почему это проблема:**
- Onboarding занимает месяцы
- Knowledge умирает с разработчиком
- Bugs в непонимаемом коде
- Преемственность невозможна

**Мой подход:**
> "Я хочу работать там, где документация актуальна и knowledge sharing — часть культуры. Это может быть Wiki, ADRs, или код с комментариями. Главное — понимание системы должно быть доступно."

### Честный ответ на интервью

**Что я буду говорить:**

> "Есть несколько вещей, которые мне важны на новой работе:
>
> **1. Качество кода** — я хочу работать в среде, где код review и testing — стандарт, не исключение.
>
> **2. Доверие и автономия** — я не хочу микроменеджмента. Я готов отчитываться по результатам, а не по часам.
>
> **3. Ясные требования** — я люблю менять приоритеты, когда это обоснованно. Но chaos в planning убивает продуктивность.
>
> **4. Technical growth** — я хочу развиваться и учиться новым технологиям. Компания, которая инвестирует в людей, — моя компания.
>
> **5. Health-work balance** — я готов работать интенсивно, но не на постоянной основе. Burnout — это не норма.
>
> **6. Communication** — я хочу понимать, что я строю и для кого. Это мотивирует работать.
>
> Если компания ценит эти вещи, я готов работать над чем угодно — legacy системами, новыми технологиями, сложными проблемами. Мне важна культура и люди вокруг."

### Что НЕ говорить

❌ "Я не хочу работать с legacy кодом"
❌ "Я не хочу писать документацию"
❌ "Я не буду работать с неинтересными задачами"
❌ "Я не буду учиться новым технологиям"
❌ "Я не хочу помогать другим разработчикам"

Этого звучит как entitled и непрофессионально.

### Положительный фокус

**Трансформируй** "Я не хочу..." в "Я ценю...":

```
❌ Я не хочу микроменеджмент
✅ Я ценю автономию и доверие

❌ Я не хочу работать на старом Stack
✅ Я ценю возможность работать с современными технологиями

❌ Я не хочу писать код без tests
✅ Я ценю quality и want to work in a team that cares about testing
```

### Вывод

Этот вопрос — отличная возможность показать:
- Твой профессиональный стандарт
- Что тебя мотивирует
- Что для тебя важно на работе
- Что ты ищешь на долгосрок

Звучи **честно**, но **дипломатично**. Компания оценит разработчика, который знает свои стандарты и не готов на компромисс с качеством.

С чем не хотел бы столкнуться на новой работе

Комментарии (1)

С чем не хотел бы столкнуться на новой работе

1. Отсутствие юнит-тестов и качества кода

2. Отсутствие Code Review и культуры развития

3. Микроменеджмент и отсутствие доверия

4. Технический долг и отсутствие refactoring

5. Отсутствие ясных требований и постоянная смена приоритетов

6. Отсутствие технического роста и учебных возможностей

7. Непредсказуемые дедлайны и переработки

8. Отсутствие документации и knowledge sharing

Честный ответ на интервью

Что НЕ говорить

Положительный фокус

Вывод