В ноябре на Хабр Карьере завершилась карьерная неделя бэкенда. Карьерная неделя — это что-то вроде дня открытых дверей, который длится всю неделю. В гонке за специалистами участвовали шесть компаний: РТЛабс, МойОфис, Лига Цифровой Экономики, Контур, НЛМК и Nexign. 

Традиционно в конце недели специалисты задают вопросы представителям компаний-работодателей. Мы выбрали самые интересные из тех, что не успели обсудить на круглом столе, и отправили спикерам. 

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

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

---

Трудоустройство

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

Петр: Достаточно лояльно, особенно, если это специалист уровня junior. Нельзя исключать  фактор стресса во время собеседования. Иногда кандидаты задают вопросы из серии «лишь бы спросить» — это выглядит более странным, чем вовсе не задавать вопросов. Кандидатам важно понимать, что не только его выбирают как сотрудника, но и он выбирает себе работодателя. Не стоит бояться задавать вопросы.

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

Сергей: Если у кандидата немного вопросов на собеседовании, мы сами подробно расскажем о компании, процессах, проекте, задачах и преимуществах работы. Собеседование мы проводим в диалоге с кандидатом, если нет вопросов, мы сами их инициируем и создаем атмосферу доверия и открытости.

Денис: Такое бывает, это необязательно признак чего-то нехорошего. Отсутствие вопросов само по себе не значит ничего. А вот в совокупности со множеством других признаков может натолкнуть на мысль, что кандидат не заинтересован в вакансии компании. 

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

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

Если перед вами стоит выбор между двумя претендентами на вакансию, то кому вы отдадите большее предпочтение: кандидату с высоким уровнем хард-скиллов и низким уровнем софт-скиллов или, наоборот, кандидату с высоким уровнем софт-скиллов и низким уровнем хард-скиллов?

Петр: Многое зависит от самой вакансии, куда требуется специалист. Скорее, мы будем отталкиваться от задач, чем просто выбирать между хард-скиллс и софт-скиллс. Если человек не удовлетворяет требованиям вакансии по хард-скиллам и он не потянет те задачи, на которые мы сейчас ищем человека, то зачем нам его брать? То же самое и по софт-скиллам. Процесс разработки и развития хорошего продукта без тесных коммуникаций внутри команды не построить! Везде нужен баланс. Важны и софты, и харды.  

Александр: Безусловно, hard skills важны, ведь вся наша команда обладает высокой экспертизой. Оценка soft skills кандидата проводится всегда и также может стать основным критерием выбора. Финальное решение всегда сильно зависит от конкретной вакансии и требуемого уровня специалиста. 

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

Денис: Здесь нет универсального правильного ответа. Всё зависит от уровня вакансии, конкретного кандидата. Хард-скиллы — широкое понятие, они могут быть на достаточном уровне, но у кандидата может не быть знаний конкретных необходимых технологий. В одних случаях их легко наверстать, в других — нет. 

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

Владимир: Зависит от позиции, на которую нанимаем. В идеале ищем комбо, но для джунов, конечно, важнее софты и, в частности, обучаемость. Для сеньоров важна база, которой обладает специалист.

Есть ли какие-то вопросы на собеседованиях, на которых чаще всего люди показывают свое незнание?

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

Сергей: Собеседование — это творческий процесс, конкретной статистики каверзных вопросов мы не ведем. Важно быть естественным и если случилось, что ответа на вопрос нет — лучше так и сказать!

Иван: Есть такие вопросы: это computer science и вопросы о том, как различные технологии работают «под капотом». 

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

Как правильно представлять себя в резюме и на собеседовании?  

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

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

Денис: Как есть. Аккуратно показывать успехи, анализировать опыт, рефлексировать о фейлах.

Иван: Важно указывать стек и технологии, с которыми ты работал на каждой позиции, а на собеседовании уметь подтвердить свои компетенции по каждой из них.

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

Я указываю свой репозиторий в сопроводительном письме и в теле вакансии. Но складывается ощущение что это никому не интересно. Правда ли не интересно? Если да то почему?

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

Александр: Конечно, интересно. Обычно, если репозиторий указан, в нем смотрим проекты на нашем стеке технологий и вклад автора в открытые проекты. Если в репозитории давно не было активности и он выглядит заброшенным, то и смотреть его неинтересно — скорее всего, он не отражает текущие навыки и интересы кандидата.

Но если на собеседовании при рассказе о решенных проблемах вы скинете ссылку на свой коммит в открытый проект и расскажете про него — это будет прямо здорово.

Денис: Репозиторий отдельно не позволит сделать выводы о кандидате. Это лишь вспомогательный источник информации и повод поговорить. Если там множество контрибьюшенов в разные проекты — это повод покопать мотивацию и кругозор кандидата. Если там различные учебные проекты — здорово, значит, человек учится. И так далее. 

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

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

А почему С# в вакансиях не указываете? 

Петр: Мы указываем в вакансиях только тот стек, который нам необходим.

Денис: Указываем, если вакансия на С#. Может быть просто в моменте таких вакансий нет, но могут открыться в будущем, по мере открытия новых проектов.

Владимир: В Nexign нет открытых вакансий C#. Чаще всего эта потребность закрывается Full-stack специалистами.

Если я пришел из другой профессии, как показать, что я классный парень, которого надо брать? Например, хард-скиллов недостаточно много, но много софт-скиллов. 

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

Иван: Тут зависит от позиции. Для каждого уровня разработчиков есть определенные требования к коммерческому опыту. В ряде случаев на джуниор позиции мы рассматриваем кандидатов с минимальным коммерческим опытом. Это в том случае, если есть длительное обучение на серьезных курсах, интересные pet-проекты.

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

На вакансиях мидлов слишком много уделяют внимания опыту работы (3-5 лет). Если человек год работал в крутой компании и занимался крутыми продуктами, его не возьмут?

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

Александр: Если человек покажет знания и навыки, которые требуются в вакансии, — возьмем.

Сергей: Опыт работы измеряется в знаниях, умениях и навыках. У нас было много примеров найма middle-кандидатов с разным количеством опыта работы: от 1 года до 5 лет.

Иван: Зависит от бекграунда и того, как пройдет собеседование. Но, честно говоря, коммерческий опыт — довольно важный аспект, он ощутимо отличается от работы «для себя».

Владимир: В Nexign на middle-позиции рассматриваем кандидатов с опытом от 1,5 лет. Сложно ориентироваться только на цифры, мы чаще смотрим на реализованные проекты. Если вы сможете доказать, продемонстрировать хард-скиллы, соответсвующие мидл-позиции, то никаких преград к трудоустройству не будет.

В последнее время заметил, что от мидлов требуют знание devOps. Как у вас с этим?

Петр: Зависит от конкретной вакансии. Если мы говорим о вакансии разработчика, хорошо, когда у человека есть понимание, что такое Docker и Kubernetes (или аналогичные). А также знание инструментов сборки и деплоя, но для автоматизации всех этих процессов, как правило, есть отдельные люди.

Александр: Смотря что вы под этим понимаете.

Если умение запустить контейнер в Docker, разобраться, почему несколько частей приложения «не видят» друг друга, сгенерировать ssh-ключ для доступа в гит, то это кажется довольно базовыми навыками.

Если же мы говорим о настройке серверов, сетей, правки CI/CD, то, конечно же, это не требуется на уровне middle.

Иван: Нет, мы такого знания не требуем. Для DevOps у нас есть выделенные специалисты, но важно, чтобы разработчик в общих чертах понимал, что дальше будет с его кодом, после принятия MR. Но, если есть желание развиваться в направлении DevOps, то это вполне возможно.

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

Насколько важно знание и умение тестирования кода (Unit, интеграционные, BDD), особенно, если душа не лежит?

Петр: Всё зависит от вакансии, но руководители, как правило, требуют от разработчика проверить работоспособность того, что он написал. Другой вариант — если в эту часть кода залезут другие разработчики и что-то сломают, то потом придут с вопросами. Единственным решением будет покрыть этот функционал тестами. Так что в первую очередь — это нужно нам самим. Ну и желательно, чтобы тесты стартовали автоматически при сборке данного компонента.

Александр: Вопрос несколько «смешанный». Попробую ответить по частям:

Unit-тесты у нас пишут разработчики. Как минимум, придется разбираться, почему ваши правки сломали тот или иной тест. Кроме того, Unit-тесты являются «доказательством» для самого разработчика, что его код работает именно так, как ожидается. И еще они очень сильно помогают при рефакторинге. Так что умение писать Unit-тесты и код, который можно ими покрыть, для нас довольно важно.

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

Про BDD скажу, что это крайне полезно при разработке задачи, в которой задействовано более одного разработчика. Проще заранее договориться о том, как компоненты будут взаимодействовать и покрыть с одной стороны тестами, а с другой — «заМОКать». Тогда этап совмещения изменений начинает меньше напоминать старый анекдотический рассказ «Что было бы, если бы программисты строили дома».

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

Иван: У нас есть определенные требования к покрытию Unit тестами, а остальными уровнями тестирования занимается QA-команда.  

Удаленка/релокация​​​​​​​​​

А можно ли работать в вашей компании из-за рубежа? Или нужно обязательно находиться в России? 

Петр: Мы свободно предоставляем удаленную работу, но только на территории РФ. 

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

Сергей: Всё индивидуально и зависит от проекта, на котором вы работаете.

Готовы ли компании/руководители/лиды работать асинхронно с разработчиками из Владивостока и подобных часовых поясов? Или только онлайн-общение и участие во всех дейли и митингах?

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

Александр: У нас есть 5 офисов в России в городах с разными часовыми поясами: два в Москве, один — в СПб, один — в Иннополисе и летом 2022 года открылся в Самаре. Также у нас есть удаленщики в более чем 20 городах России. При этом, конечно, нужна согласованность по времени на командных встречах. 

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

Денис: У нас сейчас не получится работать совсем без общения и онлайн-коммуникаций. В распределенных командах важен контакт, поэтому в таком формате мы сейчас не работаем. 

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

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

Возможно ли попасть к вам на стажировку, если иногородний?

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

Сергей: Лига Цифровой Экономики регулярно проводит стажировки по разным направлениям и форматам. Есть стажировки в очном и онлайн формате На наших стажировках вы не только получите знания, но и сможете их применить на тестовом проекте для закрепления эффекта. Лучших кандидатов по окончанию стажировки мы с радость приглашаем на работу в наши команды. 

Отследить старт запуска стажировок можно по ссылкам на нашем официальном сайте в разделе «Ищем сотрудников» — «Стажировки» и в наших соц.сетях.

Денис: Да, мы привозим ребят из других городов в Екатеринбург, Новосибирск, Ижевск, «Иннополис», Самару — туда, где у нас есть крупные офисы разработки. Контур оплачивает проезд в оба конца и проживание. 

Иван: Да, это возможно. Например, наша программа развития для студентов «Академия стальных возможностей» дает возможность переехать в один из городов, где находятся площадки НЛМК.

Владимир: Пройти стажировку можно в любом из 9 офисов компании. Такая возможность доступна при одном важном условии — в данном филиале должна быть команда с открытой потребностью и задачами для стажёра.

Нанимаете ли работников из Беларуси?

Сергей: Мы трудоустраиваем граждан Беларуси на территории РФ, а также можно работать в нашем офисе в Минске!  

Иван: Это возможно, если физически вы находитесь в России.

Процессы

Как компания относится к трате рабочего времени на повышение квалификации и написание вспомогательного работе, но не инициируемого работодателем, ПО. При позитивной реакции на последнее — кому, на ваш взгляд, должны доставаться исключительные права на такое ПО?

Петр: Очень сложный вопрос – давайте по порядку:

1) Если время, затраченное на написание вспомогательного ПО, не влияет на основную работу — это приветствуется, особенно, если это ПО помогает упростить рутинные процессы или предоставить удобный инструмент другим командам. 

2) Если ПО написано с использованием программного обеспечения и техники, предоставленных работодателем, да и еще в рабочее время, то исключительные права на данное ПО принадлежат работодателю.

Иван: Мы положительно относимся к повышению квалификации. Это возможно и в рабочее время, например, так проходит всё наше внутреннее обучение.

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

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

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

Причины для этого разные:

1)  Нормативные ограничения, требования технического задания.

2) Преемственность изменений — код, написанный одним разработчиком, должен быть понятен другому.

3) Некоторые решения требуют лицензий на использование, особенно в режимах high load на продуктиве.

4) Разработчик, из-за своего опыта или незнания остальных частей системы, может выбрать неподходящую технологию.

Александр: Это осознанный выбор команды бэкенда, которая разрабатывает конкретный проект. При этом нужно учитывать платформу этого стека, лицензионные ограничения, насколько сложно будет найти специалистов по этому стеку на рынке, а также совместимость этого стека с другими продуктами компании.

Денис: Это выбор команды, не только одного инженера. Если каждый будет выбирать что-то свое, то получится хаос. Поэтому каждый может предложить наиболее эффективный в конкретной ситуации инструмент, но команда должна это одобрить. 

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

Рост и успехи в развитии зависят только от каждого из нас, а Лига, в свою очередь, готова вам предоставить все возможности для реализации ваших желаний.

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

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

Насколько быстро происходит переход на новые версии фреймворков? На примере дотнета: текущая 6, вот-вот выйдет 7.

Петр: Дотнет плохой пример, большинство проектов у нас на Java. Мы стараемся использовать LTS, а также переводить старые компоненты на новые версии. 

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

Иван: Сейчас перешли на .NET6, в новых проектах используется Java17. В целом стараемся использовать современные стабильные версии фреймворков с длительным периодом поддержки.

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

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

Денис: Стать лидером в IT-отрасли, построить экосистему продуктов.

Иван: Сейчас мы активно создаем и развиваем новые решения на современном технологическом стеке, также постепенно заменяем легаси системы. Новым вызовом для нас, как и для многих российских компаний, является замена софта ушедших с нашего рынка вендоров, в эту сторону мы также активно двигаемся. 

Владимир: Цель Nexign — дать клиентам возможность модернизировать свои BSS-системы, адаптировать сети к эпохе 5G и создавать конвергентные цифровые экосистемы нового поколения. Помимо этого, Nexign выходит за пределы телекома и начала работу с более широким рынком: компания пополнила свой портфель решениями, которые можно предложить производителям различных сфер, и которые способны заменить иностранные аналоги.

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

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

Планируете переход на Го?

Петр: У нас есть некоторые решения, где используется Go. Глобально переписывать всё, что есть сейчас, не планируем.

Александр: Часть продуктов компании пишутся на Go, а часть — на других стеках. Мы применяем Go, к примеру, при создании корпоративной почтовой системы Mailion. В блоге МойОфис на Хабре была серия публикаций про разработку этого продукта.

Денис: Нет. Но у нас уже сейчас есть команда, разрабатывающая сервис Moira на Go.

Иван: У нас GO используется, но довольно локально, глобально пока не планируем.

Владимир: В Nexign большое количество проектов, часть из них пишут на Golang. Разнообразие проектов позволяет каждому найти своё место и использовать скилы на максимум.

Как компании поддерживают высокий уровень экспертизы? Какие конкретные шаги предпринимаются?

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

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

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

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

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

Владимир: Нанимаем в основном middle и senior-специалистов, так как довольно долгий процесс адаптации и знакомства со сложными продуктами. Также в компании серьёзно относятся к повышению квалификации. Сотрудники регулярно составляют индивидуальный план развития. Можно проходить как внутреннее обучение: у нас есть собственная корпоративная академия с курсами по хард- и софт-скиллам, так и внешнее, например, Nexigner`ы часто участвуют в IT-конференциях.

Как происходит онбординг специалистов выше сеньора?

Александр: Адаптация сеньоров включает все основные этапы, принятые в компании. 

Онбординг любого сотрудника в МойОфис стартует в тот момент, когда рекрутер сообщает о выходе новичка службам, которые участвуют в приёме и подготовке рабочего места, включая оборудование, создание учётных записей, подготовку приветственного набора, добавление в рабочие чаты и рассылки.

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

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

Рука об руку с адаптацией идёт обучение: мы помогаем освоиться с нашими инструментами работы, получить полезные навыки. Сотрудник узнаёт, как влиться в рабочие процессы, освоить базу по работе с приложениями МойОфис. 

Денис: Так же, как и других уровней. С оглядкой на то, что у таких ребят уже есть сложившийся опыт и надо это уважать и принимать.

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

Владимир: В нашей компании сам процесс адаптации состоит из нескольких базовых опций: портал адаптации с нужными и интересными инструкциями, вводные встречи с ТОП-менеджерами, помощь от buddy и технического наставника. Далее у каждого уровня должности есть дополнительные встречи и инструкции в зависимости от позиции.  

---

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