Что не хочешь делать на новом проекте?

Что я не хочу делать на новом проекте: честный разговор

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

1. Работа в условиях отсутствия data infrastructure

Сценарий:

Новый проект:
- Нет event tracking
- Данные разбросаны по разным системам
- Никто не знает куда смотреть
- "Давай вручную соберём данные через сыски запросов"

Почему не хочу:

Это не аналитика, это data engineering. И более того — это плохая затея.

# Сценарий: Собираю данные вручную из разных источников

# День 1: Пишу 5 скриптов для каждого source
# День 2: Один source сломался, нужно переписать
# День 3: Данные не совпадают между source'ами
# День 4: Качество данных вызывает вопросы
# День 5: Тратю время на дебаг вместо анализа
# День 6-10: Чиню свои же скрипты

Что предпочитаю:

• Правильная архитектура: event tracking → ETL pipeline → data warehouse
• Роли: Backend инженер делает tracking, Data Engineer делает ETL, я делаю анализ

Как решаю на интервью:

Мне: "Текущая situationия: нет data infrastructure"
Я: "Видимо, нужно это построить, но это не моя роль.
    Я могу помочь спроектировать, какие события нужны.
    Но реализовывать — должен backend или data engineer.
    Я занимаюсь анализом, когда данные уже готовы."

2. Ручной анализ и reporting (без автоматизации)

Сценарий:

CEO: "Мне нужен отчёт каждый день"
Я: "OK, я буду писать SQL, экспортировать в CSV, 
    делать диаграммы в Excel, отправлять почтой..."
(Это 2 часа в день на рутину)

Почему не хочу:

• Боюсь ошибок (human error)
• Теряю время на рутину вместо insights
• Масштабируется плохо (если 2 отчёта → 4 часа в день)

Решение:

# Вместо ручного reporting → автоматизированные дашборды

# День 1: Создаю Looker/Superset dashboard
# День 2: Добавляю автоматические alerts (если метрика упала)
# День 3+: Система работает сама, я занимаюсь чем-то полезным

# Если уже есть manual reporting
Я: "Я переведу это на автоматику за неделю,
    потом это будет работать само. Стоит ли вложиться?"

# Обычно ответ: "Да, конечно!"

3. Анализ без context и стратегии

Сценарий:

PM: "Мне нужна статистика по юзерам"
Я: "OK, вот таблица с 100 метриками"
PM: "Эм... а что дальше?"
Я: "Не знаю, спроси у CEO?"

Почему не хочу:

• Анализ без цели — тратим время впустую
• Нет actionable insights — просто красивые диаграммы
• Никто не знает что делать с результатами

Хороший подход:

Перед анализом спрашиваю:

1. "Какой вопрос ты пытаешься ответить?"
   (Если не знают → они не готовы к анализу)

2. "Какое решение ты примешь на основе результата?"
   (Если нет решения → анализ бесполезен)

3. "Сколько времени у тебя на это?"
   (Быстрое приблизительное решение vs долгий точный анализ)

4. "Кто будет это использовать?"
   (Для CEO другой уровень детализации чем для PM)

Результат:

Я: "Окей, я вижу что тебе нужно. Дам тебе результат к пятнице
    с рекомендациями что дальше делать."
PM: "Спасибо! Это именно то что нужно для CEO."

4. Огромные Excel файлы вместо дашбордов

Сценарий:

CEO: "Пришли мне Excel с 50 листами и VLOOKUP'ами"
Я: (внутренне кричу)

Почему не хочу:

• Excel не масштабируется
• Ошибки (чел внёс неправильное значение → всё сломалось)
• Версионирование (какая версия актуальная?)
• Не обновляется автоматически

# Пример ужаса
Столбец A: =IF(B1>100, VLOOKUP(B1, Sheet2!A:B, 2, FALSE), 0)
Столбец B: (вручную вбитые данные)
Столбец C: (очень важный расчёт, но никто не знает формулу)
Молитва: "Боже, только не трогай этот файл"

Мой подход:

Я: "Давайте создадим Looker dashboard вместо Excel.
    
    Плюсы:
    - Автоматически обновляется
    - Все видят одну версию истины
    - Легко делиться
    - Можно фильтровать по параметрам
    - Мобильная версия работает
    
    Минусы:
    - Требует setup (3 дня)
    - Другой инструмент (но проще на самом деле)
    
    Стоит ли вложиться?"

5. Работа с грязными, несогласованными данными

Сценарий:

BD: "Вот таблица user_profiles"
Я: Открываю...

Проблемы:
- Дубликаты (same user_id но разные email'ы)
- NULL'ы в критических полях
- Формат разный (в January 2024 написано как 1/2024, в другом как Jan-24)
- user_id иногда строка иногда число
- Даты в будущем (user created 2099-01-01)
- Логические ошибки (created_at > updated_at)

Я: "Это не data, это swamp"

Честный разговор:

Я: "Перед тем как я начну анализ, нам нужна data quality.
    
    Это значит:
    1. Data Engineer чистит данные
    2. Backend переиграет логику если нужно
    3. Я проверяю что данные в порядке
    4. Потом я могу анализировать
    
    Если я буду чистить данные → я буду тратить 80% времени
    на то чтобы сделать грязные данные чистыми.
    Это не мой job.
    
    На что вы готовы вложиться?"

6. Политические игры вместо фактов

Сценарий:

Ст. PM: "Нам нужен анализ, который покажет что моя фича хорошая"
Я: "Окей, обкой статистику..."
Ст. PM: "Нет, я хочу вот эту цифру 87%"
Я: "Но в данных 62%..."
Ст. PM: "Может, неправильно считаешь?"

Почему не хочу:

• Мне нужна вера в данные
• Анализ ради анализа вредит компании
• Потом все думают что аналитика это лжецы

Мой красный флаг:

Если человек спрашивает результат ДО анализа → проблема.
Если человек хочет чтобы я "подгонял" данные → красный флаг.

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

7. Бесконечное расширение scope'а

Сценарий:

Первая задача: "Дай мне конверсию за месяц"
Я: (Прошло 2 часа, сделал)
ПМ: "Кстати, можешь ещё добавить retention по когортам?"
Я: "Конечно, даю в 11 утра"
ПМ: "О, кстати, а по странам? И по устройствам?"
Я: (тихо рыдаю)

# В итоге я закончу в 2 ночи вместо того чтобы закончить в 4 вечера

Как я это решаю:

На первую задачу:
Я: "Окей, конверсия за месяц. Когда тебе нужно?"
ПМ: "К концу дня"
Я: "Ок, к 5 вечера я дам базовый анализ.
    Потом у меня есть 2 часа на расширение.
    Если нужно больше — это отдельная задача."

В середине дня:
ПМ: "Кстати, нужна retention по когортам"
Я: "Это новая задача. Давай оценим:
    - Базовый анализ: 4 часа
    - С деталями: 8 часов
    Что важнее?"

ПМ обычно выбирает базовый вариант.

8. Работа с отсутствием feedback

Сценарий:

Я: "Вот мой анализ, дал 15 инсайтов и рекомендаций"
Стейкхолдер: "Спасибо, скинул в архив"
Я: "Окей... а что с этим случилось?"
Стейкхолдер: "Не знаю, PM сказал собрать, я собрал"

Почему не хочу:

• Нет feedback loop
• Не знаю что сработало а что нет
• Тратится труд впустую

Мой подход:

Я: "Я могу дать анализ, но хочу знать:
    1. Сделал ли ты что-то на основе моего анализа?
    2. Какой результат?
    3. Что я мог лучше объяснить?
    
    Без feedback я не знаю эффективен ли я.
    И это мне важно."

# Хорошая команда ценит это

Общий паттерн: Чего я избегаю

1. ENGINEERING работа (пусть инженеры делают)
   - Data cleaning, ETL, infrastructure
   
2. РУТИНА (пусть автоматизация делает)
   - Ручной reporting, копировка данных
   
3. ПОЛИТИКА (вместо фактов)
   - Подгонка результатов, игры stakeholders
   
4. БЕЗ КОНТЕКСТА (бесцельная работа)
   - Анализ без вопроса, без решения
   
5. МАСШТАБИРУЕМАЯ ГРЯЗЬ (data quality)
   - Анализ грязных данных = мусор из мусора
   
6. БЕЗ FEEDBACK (не знаю результата)
   - Анализ в пустоту

Что я ХОЧУ делать

✓ Анализировать интересные вопросы
✓ Находить non-obvious insights
✓ Помогать компании расти через данные
✓ Работать с хорошей data infrastructure
✓ Сотрудничать с умными людьми
✓ Видеть результаты своей работы
✓ Учиться новому
✓ Иметь влияние на решения

Финальный ответ

На интервью я бы сказал:

"Я не хочу работать с разбитыми системами, где я трачу время
на чинку infrastructure вместо анализа. Также хочу знать
что случилось с моим анализом — есть ли impact.

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

Какая ситуация у вас?"

Это честный ответ, который показывает:

• Я понимаю мою роль
• Я забочусь о качестве работы
• Я хочу видеть impact
• Я готов к переговорам
• Я не претензионен, просто честен