Флант
Зарплаты мы действительно указываем только «на руки». Благо, это стало устоявшейся практикой для [более-менее] всей РФ.
А вот «старики» — это какой возраст? Скорее всего у нас их нет.
Хуже того: мы предоставляем бесплатные занятия английским своим сотрудникам ;-)
Знание английского для работы у нас — это не то же самое, что его знание для работы в западной компании. И уж совершенно точно далеко не каждому всё равно, на каком языке работать и общаться с коллегами, а DevOps — это много общения, постоянного взаимодействия.
Ну, зачем вы столь сурово… :-) Пока всё не так плохо (или хорошо? ;-)). К нам весьма активно — активнее, чем когда-либо — выходят новые инженеры.
И тут ещё одно уточнение для лучшего понимания: Senior'ов мы обычно не ищем. Бывают редкие случаи, но в целом выращиваем их у себя.
Во многом именно об этом и есть данная статья.
На протяжении всех комментариев с вами путаются/смешиваются «средние» (т.е. любой категории) инженеры и Senior'ы, а это две довольно разные категории. Наша вакансия (ссылка на неё была в статье) — не для Senior, а общая, и там указано до 250к на старте; от региона не зависит. Плюс, выше было замечание, что зарплаты мы очень регулярно пересматриваем.
Офиса больше нет, мы полностью на удалёнке.
Откуда у вас такая информация и про Москву, и про Киев? Вы не правы, если думаете, что 167к — это средняя ЗП для _Senior_ DevOps в Москве (выше вы пишете про 335к именно для Senior'ов). Этой цифре соответствует даже статистика от Хабр.Карьеры, приведённая в статье, но она: а) обо всех DevOps-инженерах в среднем (не Senior), б) во всех регионах (хотя выравнивание есть, оно ещё не всех «догнало»). Сами мы тоже видим другой расклад (и ожидания у людей в том числе).
Спасибо за полезное дополнение! Можно искренне порадоваться вашему случаю! Как нам это видится, такие возможности действительно есть, но назвать их массовыми, сколь-нибудь «средними» не получается — по крайней мере, на сегодня.
В конце статьи есть ссылка на Glassdoor, где указано: «national average salary for Devops Engineer is $103,218 per year in United States», и это gross. Поэтому, если вы говорите про уровень в 700-750 «на руки» (мы по умолчанию говорим про зарплаты только в таком ключе), то — да, такое бывает. Но если говорить об этом более масштабно, то есть несостыковка, что и с чем сравнивается.
Конкретно мы развиваемся в международном направлении, чтобы иметь возможность сокращать эту разницу для своих сотрудников.
Мы и сами сторонники удалёнки уже с каким-никаким стажем. Писали об этом недавно: https://vc.ru/flant/262084-my-rabotaem-udalenno-uzhe-5-let-vot-chto-ob-etom-dumayut-sotrudniki
Вы, наверное, про удаленку на западные компании? Это отличный выбор (хотя и со своими нюансами, поэтому вряд ли можно назвать его массовым).
Учитывая растущую нехватку кадров в нашей специализации, такой подход попросту «не взлетит». За весь ИТ говорить сложно, но мы проверяем именно фундаментальные знания (и необходимые для дальнейшего развития soft skills), а остальное навёрстывается по ходу работы.
Готовы спорить, что это про какие-то другие специализации, явно не «разогретый» DevOps! ;-)
3. Здесь не хватило важного момента: развита система регулярных (по умолчанию это каждые 3 месяца) performance reviews, где даётся развёрнутая обратная связь (и плюсуются финансы).
Сколько вопросов — спасибо за интерес!
1. Мы ещё не набирали тимлидов «со стороны»: все они были выращены внутри компании (из инженеров). Вкратце про наш тест для DevOps-инженеров: это квест со специальной виртуалкой без ограничений на использование любых материалов (Google и т.п.). На его прохождение уходит рабочий день (рекордный результат по отлично сделанной обязательной части — это, кажется, 5 часов). В нём проверяются базовые знания: алгоритмы, Linux в целом и веб-стек, сборка с Docker (ничего про Kubernetes нет).
В настоящий момент работаем над тем, чтобы сделать этот тест менее объёмным, не потеряв при этом важные для нас показатели. В случае его успешного прохождения (выставляется общий процент + мы смотрим на soft skills, проявленные по ходу его решения) — проводится интервью с тимлидами, где они присматриваются к кандидату и задают дополнительные тех. вопросы. Это уже более специфичные темы, чем та базу, которую проверяем в тесте.
Не могу поделиться актуальным квестом, но более раннюю версию нашего тестового задания выкладывали где-то здесь ;-) https://github.com/Asgoret/test_tasks
К слову, там же есть неплохой пример с вопросами на финальном интервью: https://github.com/Asgoret/test_tasks/tree/master/Task%204 (пусть это и не наш список).
2. Обычно собеседование на конкретную позицию, но регулярно происходят «смежные» истории: на первом интервью рекрутер понимает, что этот человек для нас скорее ПМ, чем инженер (или наоборот), в зависимости от чего дается другой тест. Или же такое ощущение появляется по итогам теста — предлагаем тогда другие позиции.
3. Мотивация — это в первую очередь атмосфера и ценности (компании в целом и каждой команды). Чисто технологически — мало где можно так круто прокачиваться (разнообразие проектов, современные технологии, грамотные коллеги). Тимлиды вырастают до партнеров компании.
4. «Флант» уже представлен на европейском рынке. Работаем и над дальнейшим развитием международных отношений.
5. На данный момент — только русскоязычные сотрудники. Прямо сейчас нет другой потребности.
В общем случае нам подходят, но может зависеть от специфики опыта (например, админство Windows-стека слабо пересекается с нужными знаниями). Напишите, пожалуйста, на hr@flant.ru.
Сейчас такая нагрузка на производство, что затруднительно выделить достаточные ресурсы на их качественное погружение (обучение). Тем не менее, очень надеемся это исправить в обозримом будущем… потому что иначе может стать ещё хуже :-)
Есть пара проверенных моделей ноутбуков, которые мы высылаем сотрудникам. Возможен вариант использования и другого (своего) компьютера в случае его соответствия всем нужным характеристикам — для этого надо получить добро у ответственного у нас за этот вопрос.
Жесткий диск с шифрованием, мультифакторная аутентификация, определённые требования к паролям, разграничение прав по ролям и большой комплекс прочих мер безопасности. Все основные данные хранятся онлайн, и для этого есть централизованное управление доступом в информационные системы. Выше уже упоминалась система Okta, которая для этого используется: хранит каталог пользователей и используется перед входом в тот же G Suite и т.п. Есть свои инструменты для специфичных задач (например, для SSH-доступа на обслуживаемые серверы).
Много лет разрешалась только GNU/Linux, но недавно одобрили и macOS.
Мы действительно сейчас о-очень быстро растём. Новые инженеры буквально каждую неделю. И всё больше новых должностей, каких в компании никогда не было (а ведь нам уже 13 лет…).
По умолчанию это нормальный рабочий день, с 10 до 19. В жизни получается так: новые сотрудники строго следуют ему, пока адаптируются. А те, кто работают дольше, присутствуют на обязательных мероприятиях (командные встречи и прочие договорённости по календарю), но в остальной деятельности становятся более гибкими, при этом не в ущерб производству(!). Что-то вроде «командной интуиции», которая приходит с опытом. Хорошо развито командное взаимодействие (и понимание ответственности каждого с одной стороны, и взаимопомощь — с другой). Вот реально у нас нет такой проблемы, чтобы кто-то пропадал и не отвечал, когда это требуется (опрос коллег только подтвердил это). Это бывало разве что в самом начале удалёнки, когда не хватало соответствующего опыта и культуры вокруг него.
О том, какими инструментами пользуемся, появился достаточно(?) развёрнутый ответ в комментарии к соседней ветке.
Без проблем. Основной секрет здесь скорее не в конкретных технологиях, а в отлаженных процессах вокруг них — в системном подходе, интеграции и упорядочивании всех этих знаний.
Самое главное средство — это Slack. В нём мы буквально живём. Это не только рабочие каналы: по командам, по продуктам, по клиентам, по технологиям и т.п. Это ещё и по-настоящему социальная среда, где есть чаты для обсуждения с коллегами практически любых тем: космос, автомобили, спорт, путешествия, домашние питомцы, дети…
(В качестве срочного резерва на время проблем со Slack — а такие бывали! — есть Telegram-канал. Но это именно бэкап, в жизни он практически не используется.)
Для более «живого» общения — Google Meet. Это ежедневные встречи команд и рабочих групп. Это регулярные переговоры с клиентами, performance review и т.п. Это и быстрые переговоры по какой-то срочной проблеме/задаче. Это и еженедельные встречи, где каждая команда рассказывает о своей деятельности для всей компании, чтобы все понимали, что происходит и к чему идём.
Для документов, почты, календарей — это тоже соответствующие инструменты G Suite. Они интегрированы со Slack, чтобы уведомлять сотрудников о ближайших встречах, о запросах, пришедших на почту… да хоть о днях рождения коллег.
Для базы знаний — хорошо организованные markdown-документы в GitLab, а также своя система поиска, которая умеет искать не только по этим документам, но и другим источникам информации: Slack-каналы, наши статьи на Хабре, некоторые GitHub-репозитории…
Для разработки внутренних инструментов — GitLab. А для публичных Open Source-проектов — GitHub (снова есть интеграция в Slack, чтобы мы оперативнее узнавали о запросах сообщества).
Для многих других задач: база сотрудников (с их контактными данными, привязкой по командам и т.п.), планирование задач для сотрудников, всякие более специализированные задачи (биллинг по клиентам, управление доступами к серверам и т.п.) — преимущественно самописные веб-приложения, которые учитывают множество особенностей наших рабочих процессов и, конечно, интегрируются со всем остальным. Кое-где используются дополнительные сервисы, поверх которых добавлены наши доработки. Например:
* Okta у нас выступает в качестве системы единой аутентификации и основы для каталога пользователей, а уже к ней докручен более простой интерфейс под нашу специфику;
* Redmine используется как хранилище задач, однако взаимодействуем мы с ним в основном через собственные веб-интерфейсы (приложение с текущими задачами для инженера, приложение для управления инцидентами у дежурных);
* …
У нас люди не работают, «когда им вздумается». Есть обязательные часы присутствия (по московскому часовому поясу), в которые даже люди с большой часовой разницей — будь то сотрудник, постоянно проживающий в Таиланде, или просто приехавший на Бали на зимовку — должны быть доступны. Этот диапазон может в некоторой степени варьироваться (в зависимости от роли человека в компании), но он явно оговаривается с каждым.
И обязательные уведомления об отсутствии, запланированном или нет, в общедоступных местах (у нас это Slack-каналы: общие для компании или могут быть командные, опять же в зависимости от роли).
Цель — поделиться нашим опытом и даже вдохновить других на удалёнку. По возможности, конечно. Нам очень нравится этот формат работы. Есть трудности, но их можно преодолеть — и получить и эффективный бизнес, и сотрудников, по-настоящему довольных таким форматом. Опрос, как нам кажется, это показал. Высветил он и некоторые сложности, которые есть; это тоже полезно учитывать и понимать. Причем не только владельцам бизнеса, но и самим сотрудникам.
Другие примеры компаний упомянуты для того, чтобы показать, что мы не какое-то очень особое или редкое исключение. На рынке (и в России, и в мире) есть более широкое явление — по меньшей мере, среди компаний, бизнес которых похож на нас (просто их мы знаем лучше других). А руководство того же GitLab — хорошее подтверждение и хорошая стартовая точка для тех, кто вдохновился и/или сомневался.
Да, мы делаем определённый вывод: работа в формате удалёнки может быть успешной (для некоторых). Но разговора о том, что он подходит всем, не было. О каком профессионализме речь? VC — прекрасный ресурс, чтобы делиться своим опытом. Мы не исследовательская компания и не эксперты в области психологии (поэтому — да, позволяем себе _шутить_ на тему прокрастинации и не только…), а работающий бизнес.
Действительно стало проще, но автор вроде как больше жаловался про «девопсеров поверх кубера». А для «мелкого бложика» это явные излишки, потому что получится… как на картинке выше (она именно про Kubernetes, не Docker).
С одним таким контейнером — скорее всего незачем. Помощь становится актуальной, когда речь идет уже не про один подобный контейнер, а более сложную инфраструктуру, состоящую из их множества. Когда жизнь превращается в боль из-за отсутствия (или недостаточного удобства и эффективности) процессов автоматизации сборки этих контейнеров и доставки в инфраструктуру (чтобы изменения в коде, сделанные разработчиками, легко и быстро становились доступными конечным пользователям). Когда сайт вырастает до проблем масштабирования и сталкивается с узкими местами в производительности. Когда для бизнеса становятся критичными вопросы доступности/отказоустойчивости.
Для мелкого — нет*. Пример был про достаточно большое СМИ — в частности, для этого выделили роль «сетевых инженеров» (небольшим сайтам такие специалисты ведь ни к чему).
* На эту тему есть картинка, быстро ставшая классической в среде DevOps и сочувствующих: «Deployed my blog on Kubernetes» :-)
Спасибо за развернутый комментарий от коллеги — это ценно! Но несколько моментов хотелось бы всё же прокомментировать.
1. «Сравните айтишные зарплаты в России и в Украине» — во многом в это и превратились комментарии к статье, но она была вообще не об этом. Возможно, Анна привела не самый удачное сравнение в конце, а мы действительно не обладаем полноценной картиной по другим странам, т.к. на них не специализируемся. Но всё послание статьи было о другом, а конкретно этот пассаж — о том, что здорово, что в РФ есть специализации, по которым работодатели способны (довольно массово) предложить достойную зарплату. Только разговоры о том, какие конкретно цифры являются достойными для _каждого_, тоже бесполезны, а речь больше про сравнение с большинством других отраслей в целом.
2. « Пожалуйста, не верьте статистике Хабра. Хабр – прекрасная платформа, но с обзорами зарплат у них из года в год треш, и цифры очень далеки от реальности» — пожалуйста, предложите публичный источник, который будет лучше? Стоит также помнить о том, что: а) это именно «средняя температура по больнице», б) DevOps — молодая специализация, испытывающая известные проблемы с самоидентификацией (кого, когда и по каким критериям начинают называть «DevOps-инженером»?).
3. «а как настолько же быстро увеличить доходы, чтобы удержать прибыль?» — хорошие, правильные вопросы. Конкретно мы оказались в более выигрышном положении, потому что см. цитату коллеги из отдела продаж в статье.
Компании, которые закрывают на это глаза, сами «выносят себе приговор» в среднесрочной перспективе. Мы как раз надеялись, что эта статья поможет им лучше почувствовать происходящее.