Наша рубрика «Где работать в ИТ» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Сотрудники компании рассказывают о найме, условиях, командах и технологиях. 

Участник этого выпуска — компания Wallarm (Валарм), которая разрабатывает решения для защиты от взлома веб-приложений, микросервисов и API.

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

→ оценить работодателя

Кто отвечал на вопросы

Обо всех процессах в Wallarm нам подробно рассказали:

Иван Новиков

Генеральный директор

Анастасия Новикова

Исполнительный директор

Михаил Пронякин

Технический директор

Иван Мелентьев

Руководитель команды рекрутмента

О компании

Wallarm — платформа для защиты приложений технологических компаний на всем пути их развития, от устаревших приложений до API-интерфейсов в облачных инфраструктурах.

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

На Хабр Карьере сотрудники оценили Wallarm на 4.63 из 5, особо отметив интересные задачи, карьерный рост и то, что компания делает мир лучше.  Детально изучить оценки и почитать комментарии сотрудников можно в профиле Wallarm на Хабр Карьере.

Об условиях работы

Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

Иван Новиков: График сложился у каждого индивидуальный, мы remote-first компания, и мы находимся в 8 разных часовых зонах, до 15 часов разницы между некоторыми. Например, я сейчас заполняю анкету из Лос-Анджелеса и через 4 часа (то есть в 19:30 по моему времени) у меня звонок с Томском, разница 15 часов. Переработки и дежурства оплачиваются по часам, команда поддержки работает по сменам, так как она 24/7.

Какие бытовые условия ждут нового сотрудника на рабочем месте?

Иван: Пакет оборудования, обычно это MacBook Pro или Acer. Мы спрашиваем сотрудника перед выходом, на чем ему удобнее будет работать. Техника приезжает вместе с пакетиком добра от компании домой каждому. Если для работы нужен дополнительно монитор или ещё что — также отправляем. Офис у нас необязательный, рабочие места там ни за кем не закреплены, мы просто смотрим, чтобы их всех хватало.

Есть ли возможность удаленной работы?

Иван: Это основное, мы remote-first компания.

Какой социальный пакет получают сотрудники?

Анастасия Новикова: Для большей части компании у нас работает квартальный бонус по результатам работы (определяется руководителем). У продавцов бонус привязан к плану и квотам каждого сотрудника. Есть бонусы за выступления на конференциях, разработку программ по внутреннему обучению и развитию нашей базы знаний. И конечно бонус за рекомендацию новых сотрудников.

Какие есть перспективы для образования и личного развития у сотрудников?

Анастасия: В этом году мы запустили отдельную программу по обучению для тимлидов и руководителей. Мы оплачиваем профильные конференции для сотрудников, какие именно они могут выбрать сами. Есть компенсация обучения без привязки к профилю (мы смеёмся, что можно пойти учиться вязать крючком).

О найме

Во сколько этапов проходит найм и что на них ожидает соискателя?

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

Практика показала, что такие звонки по итогам всех этапов помогают кандидату более осознанно принять решение и расставить для себя все точки над “i”, получив больше информации от потенциального руководителя и HR менеджера.

Даете ли вы тестовое задание кандидатам? Как оно устроено?

Иван: Почти нет, в очень редких случаях. Например, когда мы ищем человека на новую позицию, которой раньше у нас не было или хотим проверить какой-то навык, который в ходе собеседования никак не посмотреть. Последний раз мы в качестве тестового задания мы просили кандидата на позицию рекрутера написать пример вакансии.

Как отличается подход к найму в зависимости от позиции и стека?

Иван: У джунов и мидлов больше проверяем базовые знания и опыт. Начиная с уровня «Старший инженер» и особенно для руководящих позиций нам очень важны лидерские качества и умение драйвить продукт. В спорных случаях можем проводить даже отдельное интервью по культуре, понять «наш» человек или нет.

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

Иван: «Я ненавижу легаси». Шутка. На самом деле нет конкретной фразы. Например, если смотрим лида, то может насторожить долгий рассказ о личных достижениях без привязки к команде. Если это мидл и синьор позиции, будет отталкивать подход в духе «я работаю от забора до обеда» и нежелание понимать взаимозависимость с другими задачами и командами. На интервью с младшими ребятами будет настораживать неоправданно завышенная амбициозность в духе «через год я уже хочу быть лидом». Разумеется, есть исключения и реально талантливые ребята, которые могут достичь этой цели, но в этом случае стремление открыть дверь с ноги и заявить о себе таким образом будет не восхищать, а наоборот, отталкивать.

Кого последнего вы уволили и почему?

Иван: Новый сотрудник в команде технической поддержки спустя месяц после найма не прошел внутренний экзамен по продукту. Честно сам сказал, что не потянет, даже несмотря на то, что мы дали вторую попытку. Расстались очень по-доброму, поддерживаем с ним связь через Инстаграм и смотрим, как у него классно получается кататься на скейтборде.

Вообще, с внутренними экзаменами в команде техподдержки у нас довольно строго, так как это наш основной канал общения с клиентами. Чтобы держать планку, мы сделали специальную программу по обучению и тестированию для всех новичков. Если кто-то по ее итогам не готов выйти в «поля» (на самостоятельное дежурство), то приходится расстаться.

Как происходит онбординг нового сотрудника?

Иван: В первый день человек подписывает документы, получает технику и небольшой набор сувениров с айдентикой Wallarm. Потом он знакомится с HR и своей командой, которые проводят общий и специализированный вводные курсы, соответственно.

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

О команде

Какая методология разработки у вас используется и почему?

Михаил Пронякин: Все зависит от контекста. Команды сами выбирают подходящий им режим работы. Если про процессы, то это больше похоже на Disciplined Agile Delivery. Если про разработку, то просто на классический системный инженерный подход.

Каковы размеры и структуры команд?

Михаил: Мы стараемся держать команды компактными в размере до 7 человек — так легче концентрироваться на выполнении поставленных целей и задач. По структуре стараемся, по возможности, работать в кросс-функциональном стиле.

По каким критериям вы разбиваете разработчиков на джунов, мидлов и сеньоров?

Михаил: Нам нравится общий подход, когда оценивается размер области влияния и ответственности сотрудника: junior держит в контексте только свои задачи, от middle зависит результат работы всей команды, а senior распространяет свое влияние на смежные отделы.

Кто чаще возглавляет команды — продуктовый специалист или технический?

Михаил: Формально командами руководит технический специалист. Сейчас мы движемся в сторону разделения ролей Team Leads на роли Tech Leads и Engineering Managers. Но по сути в командах существуют равноправные параллельные ветки: техническая, продуктовая и QA, которые уравновешивают друг друга.

Как часто люди меняют команды?

Михаил: Исторически складывается, что люди срабатываются вместе, и поэтому переходы людей по командам в рамках одной специальности происходят нечасто. Гораздо чаще происходят ситуации когда люди развиваются и из отдела, например, технической поддержки переходят в тестировщики или в программисты.

Что важнее, софт-скиллы или хард-скиллы?

Михаил: Очевидный ответ — всегда нужен баланс и лучше обходиться без крайностей.

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Михаил: Мы работаем удаленно и собрания у нас удаленные. Все тоже стандартно — лишние собрания никому не нужны, собрания происходят по требованию. Из трудностей — иногда тяжело совмещать много часовых поясов, чтобы собрать нужных участников вместе.

Как вы боретесь с выгоранием сотрудников?

Михаил: У нас есть 15 day off помимо отпуска, которые можно брать, если чувствуешь, что нет вдохновения к работе. Или если увлекся и поработал на выходных и нужно отдохнуть. Или если хочешь отдельно поработать, ни на что и ни на кого не отвлекаясь.

О технологиях

Какие языки, фреймворки и библиотеки используются на проекте?

Михаил: Для backend разработки мы используем Ruby, Golang и немного Python, для Frontend — JS/React, для автотестов — Python, и отдельно С для написания непосредственного фильтрующего атаки узла (где нужна максимальная производительность). В плане платформы все стандартно: GitLab, Terraform, k8s, helm, prometheus, grafana и т.д. Из необычного — иногда используем Tarantool и встроенную логику на lua коде.

Что вы можете рассказать об архитектуре проектов?

Михаил: Глобально у нас есть 2 части: облако c микросервисной архитектурой и фильтрующий узел. Фильтрующий узел написан на С и должен уметь поточно без задержек обрабатывать проходящий сетевой трафик — парсить всевозможные форматы данных и искать в них атаки. С микросервисами же все более-менее стандартно. Из интересного — используем Ruby на полную и не только в формате RoR. Например, для написания правил сканирования и детектов уязвимостей через YAML DSL.

Какая у вас принята политика код-ревью?

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

Как тестируется код?

Михаил: Качество — это не только про тесты. Все начинается с ревью тестировщиками постановки задачи. Далее идет разработка. С одной стороны используется классическая пирамида тестирования: unit/component tests за разработчиками, integration/e2e test за QA Engineers. В компании давно сделан упор на автоматизацию, ручных действий стараемся делать по минимуму.

С другой стороны есть плавная выкатка сервисов в test/staging/prod окружения с плавным включением измененной функциональности (с метриками/алертами и т.д.), что замыкает SDLC. Из особенностей — у нас у каждого разработчика/тестировщика есть возможность автоматизированно поднять полную копию облака с нужными версиями сервисов в специальном k8s кластере, после чего с кластером можно производить любые эксперименты, которые ни на кого более влиять не будут.

Как устроен процесс документации и ведения базы знаний на проектах?

Михаил: Все начинается с политики по написанию документации для политик. Ну а по факту мы просто используем Confluence, стараемся документировать тайные знания и держать все в актуальном состоянии. За последний год достигли в этом деле неплохих успехов: практически весь onboarding новичков теперь проходит, в основном, через чтение документации. Ведем паспорты микросервисов.

Чтобы документация не устаревала используем подход: заметил неточность — поправь сразу, ограничений в правах ни у кого нет. Ну и есть отдельный мир внешний документации с техническими писателями.

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Михаил: Любой код устаревает через секунду после написания. Рефакторинг — это нормальный процесс для любой разработки. Написание кода только увеличивает энтропию Вселенной, а мы можем только стремится достичь идеала. Поэтому, чтобы наша система не деградировала со временем, мы занимаемся рефакторингом на постоянной основе. Сам процент legacy кода оценить трудно, все зависит от методики подсчета, для кого-то Ruby — уже legacy.

Оценивайте компании на Хабр Карьере и делитесь мнением о них с теми, кто сейчас ищет работу в ИТ. Это анонимно.

→ оценить работодателя