Какие есть вопросы к компании?

Давай разберём твои вопросы, как взрослые люди, без этих ваших корпоративных соплей. Устраивайся поудобнее, щас будет мясо.

1. Продукты и проекты: на чём пашем? Слушай, у нас тут не какая-нибудь лавочка на коленке. Основной продукт — это монстр, который уже лет пять на рынке, система управления всякой хуйнёй для крупного ритейла. Ты попадёшь именно на него. Зелёного поля тут, блядь, не жди — это типичный браунфилд, где под капотом легаси, который иногда смотрит на тебя пустыми глазницами и шепчет «убей меня». Но мы его не убиваем, а планомерно ремонтируем на ходу. Соотношение? Ну, как повезёт. В идеальном мире — 70% на фичи, 30% на баги и долг. В реальности, перед релизом — хуй там, все тушат пожары. Но в целом, стратегия есть — не даём системе превратиться в болото.

2. Технологии и процессы: чем и как долбим? Стек — классическая джава-спринг-бутовая банда для бэкенда (17-я, не гони лошадей), фронт на Реакте, базы — Постгре и Монго, всё в докере, летает на кубере. Менять кардинально ничего не планируем, но версии поднимаем регулярно — спать нельзя, а то отстанешь навсегда. Работаем по гибриду Scrum и Kanban — спринты двухнедельные, но если что-то горит, прёт вне очереди. Планирование, демо, ретро — строго по календарю, без фанатизма, но и без «ой, да похуй». CI/CD? Да не ссы, тут всё серьёзно. Полный пайплайн в GitLab: мерж-реквест → автоматический билд → прогон юнит- и интеграционных тестов (без этого никуда) → линтеры (SonarQube наш верный сторож) → деплой сначала на staging, потом, после одобрения, — в прод. Ручного заливания джарников по FTP тут, блядь, не найдёшь.

3. Команда и культура: с кем и в какой атмосфере? Команда — это unit из 5-6 бэкендеров, 2 фронтендеров, QA-инженера и DevOps-шамана. Рулит всем техлид, который реально в теме, а не просто митингы проводит. Взаимодействие — в Слаке и на ежедневных стендапах, без воды. Код-ревью — это святое. Мерж без хотя бы одного апрува — низзя. Есть чек-лист: покрытие тестами, читаемость, отсутствие тупых костылей. Стиль кода — гайдлайны, проверяемые линтером, так что споры о пробелах и скобках — это детский сад, который мы прошли. Техдолг? Его признают все, а борется с ним не каждый. Но у нас есть правило: если лезешь в модуль, почисть за собой говнецо. Плюс раз в квартал можем выделить спринт на «техническое оздоровление». Архитектурные улучшения продвигаем через ADR (Architecture Decision Record) — всё по-взрослому.

4. Рост и развитие: куда расти и как учиться? Рост? Да сколько угодно. Бюджет на курсы (Coursera, Udemy) есть, на конференции — подавай заявку, обоснуй пользу — и вперёд. Внутри проводятся воркшопы, когда кто-то что-то круто освоил. Онбординг — не «вот тебе комп, разбирайся». Будет бадди, который первые недели две тебя за ручку проведёт: доступы, процессы, покажет, где что лежит и кого просить, если что. Документация есть, живая. Performance review — раз в полгода. Карьерный путь прозрачный: джун → миддл → сеньор → лид. Для тех, кто не хочет в менеджеры, есть Individual Contributor track — можно расти до архитектора, просто глубже в технологии уходя.

5. Рабочий процесс: как живём? Гибридка: офис 2-3 дня в неделю для важных митингов и социализации, остальное — откуда хочешь. График гибкий: главное — быть онлайн в core-часы (с 11 до 17) и задачи тащить. Нагрузка… Ну, бывает разная. Перед крупным релизом могут попросить поднажать, но это, блядь, не правило, а исключение. Регулярных авралов и ночных бдений нет — мы же не на скорой работаем. Ценим work-life balance, иначе люди просто сгорают и уходят, а нам нанимать новых — дороже.

Ну и по твоему примеру технического вопроса: Путь фичи? Да легко, слушай сюда:

1. Идея. Рождается у продуктолога или из поддержки. Летит в Jira, обрастает первоначальным описанием.
2. Проработка. Продукт + техлид/архитектор щёлкают мозгами: что, зачем, как примерно делать. Рисуют примерные схемы, оценивают сложность.
3. В бэклог. Попадает в бэклог продукта, приоритизируется.
4. Планирование. На планировании спринта команда разбирает задачу, дробит на подзадачи, даёт более точную оценку.
5. Разработка. Программист (ты) берёт задачу в работу. Пишешь код, покрываешь тестами. Всё пушишь в Git, создаёшь Merge Request.
6. Ревью и CI. MR висит, коллеги смотрят, CI пайплайн гоняет проверки. Всё ок — мержим в основную ветку.
7. Тестирование. Автоматом поднимается на тестовом стенде. QA проверяет по чек-листу. Нашли баг — возвращают в разработку.
8. Деплой. После успешного теста и одобрения продуктолога — кнопка «деплой в staging». Там финальный smoke-тест.
9. Продакшн. В запланированный релиз-окно (часто ночью) изменения мержатся в релизную ветку, пайплайн катит их в прод. Мониторинг (у нас Grafana + Alertmanager) начинает смотреть, не поломалось ли чего.
10. Пост-релиз. Смотрим метрики, не упала ли производительность, не посыпались ли ошибки. Всё чисто — можно выдохнуть.

Инструменты: Jira, GitLab, Docker, K8s, ну и куча вспомогательной мелочёвки. Всё прозрачно, как слеза младенца, если, конечно, не считать легаси-кода, который иногда прозрачностью не отличается.