LINUX.ORG.RU

Senior Java Engineer, Berlin

 , , , ,


0

4

Всем привет.

Мы ищем в команду сильных инженеров в наш офис в Берлине (с переездом поможем). Обязательные требования: опыт Java, разработки сервисов и высокопроизводительных приложений, хороший английский.

Про проект можно почитать в соседнем треде: $500,000 за канал с открытым данными.

Ниже по тексту подробности про технологии, задачи, процесс, команду, место и деньги.

Технологии.

Нашу команду объединяет то, что мы пишем, в основном, на 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, подарит вам ЗП за пару лет. А ещё, если вы топ-перформер, то вы сможете рассчитывать на бонусы пару раз в год.

P.S. Возможно, я не очень хорошо раскрыл именно те детали, которые интересуют сильных технических специалистов, в которых мы нуждаемся. Есть вопросы - задавайте их здесь или пишите на iroslyakov@satori.com.

А где описание розовых пони, которые скачут по улицам Берлина? Вот тут человек расписал, что все писаются радугой в Германии.

Для новых сотрудников мы предлагаем срочные контракты на год с последующим продлением на ещё год, и потом автоматически конвертируем в бессрочные.

С зарплатой в 50% от постоянки.. а потом не продлим пста.

UVV ★★★★★ ()
Ответ на: комментарий от UVV

А где описание розовых пони, которые скачут по улицам Берлина? Вот тут человек расписал, что все писаются радугой в Германии.

Я ищу в первую очередь будущих коллег, чтобы вместе делать крутые вещи. Людей, которым нравятся описанные технологии, проекты, продукт, кто готов учиться и учить других.

А информацию о Берлине можно легко найти в Интернете. Кому-то он нравится, кому-то нет - это дело личное.

С зарплатой в 50% от постоянки.. а потом не продлим пста.

Забыл про это написать, потому что уже забыл, что такое вообще бывает. :) Мы сразу платим всю ЗП, без понижения на испытательный срок. Мы даже контракторов (onshore) нанимаем, имея ввиду, что они будут работать минимум пару лет, иначе смысла нет даже начинать.

day4ree ()

А ещё, если по какой-то причине мы вынуждены использовать сторонние или open-source продукты, мы всегда задаемся вопросом: чего именно нам не хватает? Может быть, мы можем добавить эту фичу в наш проект?

Массовый NIH? Почему не задаться вопросом «можно-ли добавить эту фичу в открытый проект»?

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

А нельзя-ли примеры подобного? Не сочтите за потенциального кандидата - жаба (да ещё и под высокой нагрузкой, lol) как-то не вдохновляет, просто любопытно.

zabbal ()
Ответ на: комментарий от zabbal

Массовый NIH? Почему не задаться вопросом «можно-ли добавить эту фичу в открытый проект»?

В плане написания кода, первое, что мы делаем - это пытаемся использовать готовые решения, а не изобретать велосипед. Лучший код - это не написанный код.

При этом нас уже есть готовый продукт с некоторым набором фич. Вполне разумно дополнять его в плане функционала тем, что хорошо ложится на концепцию и может дать существенный выигрыш в смежной области.

Представьте, что у вас уже есть своё KV хранилище. И вы видите, что пользователи вынуждены по-прежнему использовать memcached только потому что там есть atomic increment. Почему бы не добавить эту фичу и в ваше KV хранилище и заманить этих пользователей? Однозначного ответа нет, но хотя бы подумать стоит - ни больше ни меньше.

А нельзя-ли примеры подобного? Не сочтите за потенциального кандидата - жаба (да ещё и под высокой нагрузкой, lol) как-то не вдохновляет, просто любопытно.

У нас есть внутренние продукты, которые были придуманы, внедрены и продолжают поддерживаться или разрабатываться простыми инженерами. Это поощряется. И также отдельно поощряется OpenSource. Пересечения и того и другого происходят не часто, но есть и пример - MZBench.

day4ree ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.