Мы ищем в команду сильных инженеров в наш офис в Берлине (с переездом поможем).
Обязательные требования: опыт Java, разработки сервисов и высокопроизводительных приложений, хороший английский.
Про проект можно почитать в соседнем треде про Satori.
Ниже по тексту подробности про технологии, задачи, процесс, команду, место и деньги.
Технологии.
Нашу команду объединяет то, что мы пишем, в основном, на Java.
Мы используем и другие языки: например, Python — для CLI, скриптов, маленьких и не критичных в production сервисов. Ещё есть немного Erlang и Bash.
Так как данные принято где-то хранить, нас спасает опыт работы с базами данных, будь то KV или MySQL. Мы уже активно используем ELK, MySQL, Kafka, и прочее по мелочи.
Большинство сервисов критично к производительности. Мы создаем бенчмарки для всех систем, используя распределенное нагрузочное тестирование, профилируем весь стек: от балансера AWS до io конкретной ноды Kubernetes в локальном DC. И тут определенно помогает знание linux и знакомство с теорией и практикой нагрузочного тестирования.
Хотя мы и пытаемся выжать максимум из каждой отдельно взятой железки, давно уже стало очевидно, что куда более важно линейное масштабирование. Мы много внимания уделяем шардингу, балансировке, распределенным вычислениям. У нас есть собственные наработки в области алгоритмов репликации данных.
Для успешного взаимодействия с ядром системы со стороны наших Java сервисов не лишним оказывается знание языка, на котором оно написано — С++. А ещё, если по какой-то причине мы вынуждены использовать сторонние или open-source продукты, мы всегда задаемся вопросом: чего именно нам не хватает? Может быть, мы можем добавить эту фичу в наш проект? И если ответ “да”, то можно пойти и самому добавить. Ну, или попросить коллег.
В целом компании есть по нескольку тысяч строк кода на Golang, C#, NodeJS и чем-то ещё, наверняка. А ещё есть front-end инженеры, но это — уже отдельная история.
Важно также, что мы имеем возможность применить очень широкий спектр знаний и технологий, если сами того захотим и сможем отстоять свою позицию. Именно так рождаются собственные реализации TSDB, и даже небольшие реляционные базы данных, написанные по доброй воле в свободное время.
Задачи.
У нас множество разных задач из зачастую не слишком пересекающихся областей. В целом суть нашего существования сводится к тому, чтобы, ясно осознавая наши способности и ресурсы, мы могли взять проект под свою ответственность, и максимально быстро и четко завершить каждый из его этапов, методично направляя компанию к цели. Требования к проекту могут изменяться, поэтому важно отнюдь не выполнить последовательность задач в трекере, а решить конкретную проблему бизнеса.
Звучит немного размыто, но тому есть причины. Часть наших задач приходит “от бизнеса”, который имеет видение продукта. В таком случае мы обсуждаем требования, сами пишем спецификации в удобном и понятном обеим сторонам формате, а потом разрабатываем план работ и утверждаем его. Далее идет прототип, MVP, и к этому моменту обычно уже есть огромный список фич, ожидающих в очереди. Некоторые задачи являются прямым или косвенным следствием запросов пользователей (через письма, тикеты, личные сообщения). Иногда наши пользователи — внешние, а иногда — внутренние. Также компанией приветствуется самостоятельная идентификация проблем и задач. Вполне возможно, что кто-то предложит нечто, нужное компании, но не похожее ни на что ранее существовавшее в отделе: новый проект, сервис, или даже просто фичу, и вся команда займется именно этим в ближайшую неделю, или месяц, или даже полгода. Естественно, перед этим придётся убедить множество людей в своей правоте. Зато в итоге можно почувствовать себя полноценным владельцем продукта, и даже разместить его в OpenSource.
Процесс.
Наш процесс разработки построен на системе сдерживаний и противовесов. Иначе — здравого смысла. У нас есть итерации, Agile, Kanban, Lean, мы используем Jira и немного Trello. Для документации есть и Confluence, и README.md. У нас нет никакой бюрократии, потому что первичная цель — доставка того, что нужно. Тогда, когда нужно. От команды требуется результат, и команда может работать по тому процессу, который удобен ей, никто не будет ни к чему принуждать “сверху”. Если же кому-то покажется, что бюрократия есть, то стоит просто спросить “почему?” — ответ будет.
А что в итоге? Иногда это означает, что один человек пишет две недели код практически без отчетов и взаимодействия окружающим миром — так рождается прототип. А иногда это большая команда, стендапы пару раз в неделю, куча задач в Jira, огромный backlog, статистика производительности команд и отдельных разработчиков, расчеты по времени ожидаемого закрытия каждой задачи, прикрепленный проектный менеджер и отдельный менеджер продукта, периодические демонстрации перед заказчиками, куча приемочных и интеграционных тестов, TDD, RDD и ещё множество подходов и методик, которые мы действительно используем, а не просто знаем расшифровки.
Также мы сильно озабочены тем, как все работает в проде. У нас есть тесное взаимодействие с SRE командой, есть отдельная команда TechOps, которая отвечает за базы данных, ELK кластера и прочее. С ними всеми можно посоветоваться на этапе дизайна, или же придется потом защищать свою архитектуру. У нас есть мониторинги (Datadog, Zabbix, Sensu), графики (Graphite), on-call, расписания дежурств и звонки от автоматической системы (OpsGenie) на мобилку в 4 часа ночи, если упал прод — но последнее не часто.
Само собой, у нас есть code-review, GIT (свои инстансы GitHub Enterprise и BitBucket), тесты, и всё прочее, что полагается в инженерном мире.
Команда.
У нас довольно сильная команда. Просто для примера: со мной в одной комнате сидит Staff SRE, работавший три года в Гугле. А ещё в Гугле много лет работал мой нынешний непосредственный директор из Калифорнии. У нас тут нет дедовщины. И я лично реально ощущаю себя частью большой команды из примерно 100 человек.
Место.
Компания всячески готова помогать с перемещением: обсудить релокационный пакет, назначить персонального помощника по оформлению визы, который будет отвечать на письма каждый день. Мы поможем с перевозкой вещей, и даже дадим человека, который будет лично сопровождать вас уже в Берлине в особо важных государственных учреждениях.
К сожалению, без высшего профильного образования у вас могут возникнуть трудности с визой (голубой картой).
Для новых сотрудников мы предлагаем срочные контракты на год с последующим продлением на ещё год, и потом автоматически конвертируем в бессрочные.
Деньги.
Публиковать явно вилку ЗП было бы по множеству причин некорректным. В целом мы стараемся платить зарплату вместе с опционами и бонусами в сумме больше, чем 75% компаний на нашем рынке.
Это означает, что у вас будет возможность получать ЗП, близкую к максимальной планке, или даже выше той, которую показывает Glassdoor в своей статистике по Берлину. Вы будете иметь опцион, который, в случае выхода компании на IPO, подарит вам ЗП за пару лет. А ещё, если вы топ-перформер, то вы сможете рассчитывать на бонусы пару раз в год.
Условия.
Удаленная работа: невозможна.
Расположение офиса: Berlin (Mitte).
График работы: полный рабочий день, возможна периодическая работа из дома, обсуждается отдельно.
Испытательный срок: полгода, влияет на сроки уведомления об увольнении с обеих сторон, не влияет на ЗП.
Контактный телефон: +4916093136460.
P.S. Возможно, я не очень хорошо раскрыл именно те детали, которые интересуют сильных технических специалистов, в которых мы нуждаемся. Есть вопросы — задавайте их здесь или пишите на iroslyakov@satori.com.
Здравствуйте, R, Вы писали: R>P.S. Возможно, я не очень хорошо раскрыл именно те детали, которые интересуют сильных технических специалистов, в которых мы нуждаемся. Есть вопросы — задавайте их здесь или пишите на iroslyakov@satori.com.al
На мой взгляд вакансия описана очень хорошо и подробно! Другим работодателям стоит поучится привлекать разработчиков аналогичным образом.
Все детали осветить очень не просто. Думаю, что если будут вопросы — Вам их зададут.
Не могу, к сожалению, претендовать на данную позицию. Но думаю, что Вы найдете своих кандидатов.
Удачи!
