LINUX.ORG.RU
ФорумJob

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.



Последнее исправление: day4ree (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

day4ree
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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