Туту — сервис путешествий. У нас есть расписание рейсов, билеты на поезда, самолёты, автобусы, электрички и аэроэкспрессы. А ещё много отелей, туров и экскурсий.
Мы — команда автоматизации отчетности. Внутренняя система для работы с отчётностью обеспечивает правильный сбор данных об оказанных услугах от продуктов, данных по движению денег от биллинга, обеспечивает контроль изменений с учётом требований бухгалтерии по закрытым периодам, обеспечивает доверие этим данным через разнообразные сверки, автоматизирует рутинные операции аккаунтов, саппортеров и финансовых аналитиков, чтобы эти данные и все сопутствующие им документы получила бухгалтерия.
Кого мы ищем
Сейчас мы ищем Middle Backend‐разработчика в новую команду внутреннего продукта, которая помогает построить прозрачную систему работы с отчётностью, чтобы справиться с переходом компании к концепции тревел-молла.
Немного про стек
- Микросервисы на Go, живут в Openshift.
- Mysql, ClickHouse для хранения наших данных.
- Логи/метрики Elastic, Prometheus, Grafana.
- Задачи ведутся в Jira, документация в Confluence.
Основные задачи
- Проектировать и разрабатывать новый функционал системы.
- Поддерживать работоспособность системы с учётом особенности предметной области: в периоды закрытия кварталов система должна максимально стабильно работать и на любые проблемы нужна быстрая реакция.
- Следовать командным процессам (pull request, планирование спринтов и т.д.).
- Участвовать в решении проблем в техническом контуре продукта и в смежных областях.
- Активно участвовать в процессе принятия решений технического и бизнесового характера.
- Коммуницировать со смежными подразделениями, активно погружаться в предметную область (aka говорить с пользователями на одном языке).
От вас нужно
- Опыт коммерческой разработки на Go от 2–3 лет.
- Стремление писать читаемый и поддерживаемый код.
- Умение открыто задавать интересующие вопросы и не проходить мимо проблем. Проактивность лучше реактивности.
- Работать нужно с финансами и учётом. Тут нет хайлоада, но важна точность до копейки и много неочевидных нюансов в процессах.
- Работать нужно для внутренних пользователей, нужно уметь работать с фидбэком и хотелками. Нужно уметь находить боли пользователей и разрабатывать для них решения.
Про команду и рабочий процесс
- В команде есть: руководитель отдела, в прошлом бэкенд-разработчик, фулстек-разработчик, бэкенд-разработчик, бизнес-аналитик.
- Сами пишем код, сами тестируем. В 100% покрытия юнитами не упарываемся, но в целом стараемся тесты писать. Выделенных тестировщиков нет.
- Как мы будем взаимодействовать?
Выкатили код на Code-Review (pull-request), получили апрув, нажали merge, и дальше всё само до прода доедет. У нас сильная платформенная команда в компании, которая делает классные штуки для улучшения жизни разработчиков. - В мастер стараемся не коммитить. Pull-request (PR) должен получить хотя бы один апрув от любого разработчика в команде. Длинные переписки в PR не приветствуются, проще голосом разобрать вопрос.
- Жёстких правил, кто, когда, чьи PR должен смотреть, нет, команда маленькая, и пока с этим проблем нет.
