Итак, диспозиция на начало года
- Мы быстро растем – нам нужно набирать новых сотрудников
- Сообщество разработчиков о нас думает примерно «Ну это сайт с расписанием электричек – там наверно 3 человека работает в подвале». На самом деле у нас сейчас 7 бизнес-направлений и два десятка команд, которые над ними трудятся.
Кстати, немного об электричкахКстати, в команде Электричек 7 разработчиков, а еще там высоконагруженные микросервисы, которые мы начали переписывать на go - На собеседовании мы задаем логические задачи, задачи по синтаксису php, ООП и базам данных
Честно говоря, подбор шел медленно. Забегая вперед, скажу, что к концу года мы увеличили скорость набора в 4 раза, при этом не потеряв в качестве кандидатов. Надеюсь, я вас заинтересовал. Читатель, если ты совсем суровый технарь и хочешь почитать только о техническом собеседовании, то тебе в этап 2 :)
Наш подбор состоял из трех этапов:
- собеседование с HR;
- техническое собеседование;
- собеседование с руководителем отдела (мной).
В принципе, это довольно стандартная схема для рынка. Наверное, это единственное, что уцелело в процессе преобразования. Давайте конкретно рассмотрим каждый этап в отдельности
Этап 0: привлечение кандидата
Как говорят умные воротилы бизнеса: если хочешь увеличить воронку продаж, увеличь количество людей, которые в нее попадают. В начале года с этим у нас было довольно скучно: мы выставляли вакансии на hh.ru, на которые практически никто не откликался. HR-менеджер искал резюме и отправлял на ревью руководителю.
Мы увидели две проблемы:
- о нас мало кто знает, как о технологичной компании (количество откликов близко к нулю);
- вакансия написана «примерно как у всех».
Что же делать?
А давайте перепишем вакансию
Переписали более модно-молодежно. Но продуктовая разработка нас научила все проверять на данных. Решили проверить двумя АВ-тестами:
- создали две одинаковых вакансии на hh.ru сначала с разным названием должности;
- поставили в этих вакансиях еще и разный текст.
Оба АВ-теста показали 0. «Просто» решить проблему не получилось, нужно решать системно. Это мы тоже любим. Какие гипотезы мы выдвинули из этого эксперимента: похоже, что текст вакансии мало влияет на желание людей у нас работать (значит нужно качать HR-бренд) и что люди хотят прочитать что-то другое.
Повышаем узнаваемость
Мы решили начать с малого и, кажется, не прогадали. Мы не стали придумывать мега-докладов или ставить стендов на огромной конференции, а решили проводить свои митапы. Но вот проблема: из живых php-сообществ в Москве есть только Symfoniacs, а мы как-то ну совсем не про Symfony. Решили сделать свой: искали спикеров, рисовали бейджики, гоняли доклады по 7 раз. И таки получилось, и получилось два раза: раз, два. Будет и третий, и дальше.
По прошествии времени можно сказать определенно: митапы не дают мгновенного эффекта (вам не пришлют сразу десятки резюме), но они заметно повышают узнаваемость. Я все чаще слышу: «О, а я у вас был».
Экономим время кандидата
Все знают, что рынок разработчиков сейчас – это рынок соискателя. Хорошие специалисты чуть ли не каждый день получают сообщения с предложением работы или приглашением на интервью. А теперь попробуем представить, сколько нужно ездить на очные встречи (да еще и в каждую компанию по несколько раз). Поиск работы мечты может превратиться в «о, Господи, хватит уже». Как мы, как потенциальный работодатель, можем помочь с этим кандидату?
Например:
- разумно уменьшить время, которое нужно потратить на общение;
- пробовать что-то узнавать о кандидатах удаленно.
Так мы ввели «оффер за один день» и «предварительное техническое собеседование». Если с «оффером за один день» все понятно: мы можем провести все три собеседования за раз, экономя время соискателя на дорогу, то на «предварительном техническом собеседовании» хочется остановиться подробнее. Технические специалисты зачастую хороши в разработке программного обеспечения, но не в написании резюме. Хорошо оформленных резюме, из которых понятно, что же кандидат делал на предыдущем месте работы, я бы сказал, что не более 30 процентов на рынке. А ведь интересно узнать не только что, но еще как и почему именно так. Для этого уже часто хочется поговорить, но (опять) ездить в офис долго, дорого и обидно, если собеседование закончилось быстро. (Мы верим, что люди хотят постоянно развиваться и, если не прошли собеседование сегодня, могут вернуться завтра с гораздо более глубокими знаниями. Поэтому важно оставлять хорошее впечатление у всех кандидатов).
В итоге мы ввели «предварительное техническое собеседование», но заключается оно не в том, что у вас спросят по телефону «как выйти из vim-а», а поговорят о том, что вы делали на предыдущем месте работы, позадают релевантные вашей квалификации вопросы. И что самое важное: делать это будет разработчик.
Этап 1: HR
На этом этапе мы нашли две проблемы:
- У нас были логические задачки, оторванные от реальности (привет шарам в самолете и канализационным люкам), которые, как показывает практика, не всегда могут раскрыть потенциал кандидата, а вот создают негатив довольно часто. Хуже того, бывало, что кандидат уходил домой только из-за того, что не решил задачки, – это создает плохую репутацию. В общем, логических задач из учебника у нас на собеседовании больше нет: системное мышление и умение нестандартно мыслить мы проверяем на техническом собеседовании задачами, возникающими в реальной жизни.
- Мы вообще не собирали обратную связь кандидата о прохождении собеседования у нас. Теперь собираем, строим метрики и работаем с тем, чтобы candidate experience был хорош.
Этап 2: техническое собеседование
Задачи
Что из себя представляло наше техническое собеседование год назад: вы попадаете в переговорку на 1-1.5 часа с одним из тех. лидов, решаете задачки по php, ООП, mysql. Дальше все – на усмотрение каждого отдельного собеседующего. Согласитесь: если вы senior, странно отвечать на вопрос «чем отличается isset от empty?». А нам еще страннее на основании этих вопросов принимать решение, что кандидат сможет выполнять наши задачи и делать это классно.
Мы подумали: «А что же на самом деле должен знать кандидат, чтобы делать у нас задачи и развиваться?». Ответов было несколько:
- Чтобы просто делать задачи:
- ООП и рефакторинг (Мы за красивые поддерживаемые решения, а еще у нас все еще есть монолит)
- Проектирование API (Тот самый монолит нужно бить на микросервисы, новые задачи мы решаем только на микросервисах. Проектирование хорошего API в сегодняшнем мире – самое важное умение backend-разработчика)
- Уметь работать с внешним API (У нас много разных партнеров с разным уровнем качества API)
- Должен понимать в БД в широком смысле (SQL и разные NoSQL решения)
- Хорошо бы, чтобы что-то знал о unit-тестах (если что, научим) и пользовался правильными инструментами для разработки
- Чтобы классно выполнять свою работу и развиваться:
- Обладать глубокими теоретическими знаниями в своей области
- Уметь эффективно применять теорию на практике
Оказывается, нам не нужно целенаправленно спрашивать ничего о знании языка, и это интересно. Но и это не все! Мы хотим проверить по сути две вещи: обладает ли кандидат нужными нам hard-skills и проверить, есть ли у него потенциал к дальнейшему развитию. Значит, нужно как можно лучше понимать его карьерный путь: с какими ситуациями кандидат уже сталкивался в своих проектах и как их решал. Поэтому в первую очередь мы узнаем о том, что кандидат сделал на предыдущих местах работы. После собеседующий дает задачи из нашей реальной предметной области и проверяет, как кандидат будет с ними справляться. В итоге у нас получился формализованный сценарий технического собеседования, где собеседующий должен дать ответ на определенные вопросы. Интересно, что время собеседования с новыми задачами практически не изменилось – мы по-прежнему тратим в среднем 1.5 часа.
Процесс
В ходе исследования обратной связи оказалось, что сегодня кандидат от собеседующего его технического специалиста уже не ждет простого диалога «задача-ответ» и разговоров только на технические темы. Рынок меняется: кандидатам интересно знать, какие конкретно они будут решать задачи, в какой команде, какие используются технологии и подходы в смежных областях. Теперь у нас каждый собеседующий обязан знать, какие бизнес-задачи решаются в разных командах, примерные планы и текущее состояние технологий, причем не только backend, но и всех остальных ролей команды.
Вишенка на торте
Я решил вынести этот пункт отдельно, потому что он есть практически в любой статье об интервью, но все еще большинство компаний грешат несоблюдением. Мы теперь не заставляем писать код на бумажке. Каждый интервьюер должен принести с собой ноутбук, дальше – выбор за кандидатом.
Этап 3: финал
Здесь изменение было всего одно, но значимое. Теперь на каждую финальную встречу кроме руководителя ходит еще и представитель бизнеса от команды, в которую мы хотим взять кандидата. Мы хотим установить прямой диалог о планах направления и задачах, которые предстоит решить
Этап 4: адаптация
Казалось бы: ну вот же, сотрудник уже в компании, зачем дальше париться? У нас со времени основания компании существует институт наставничества: каждый новый сотрудник получает наставника в своей команде. Но и здесь было, что улучшать. В разных командах разный уровень сложности предметной области, и есть соблазн отправить сотрудника на многодневное обучение прежде, чем он начнет выполнять свою первую задачу. Как показала наша практика, после такого обучения человек обычно практически ничего не запоминает, грустит, и время потрачено зря. Поэтому мы ввели правило: «Сотрудник на третий день обязательно должен взять задачу из спринта». Правило отлично работает в связке с системой обучения, где новичок может почерпнуть нужные знания именно в тот момент, когда они ему нужны.
Также мы стандартизовали процесс обратной связи: каждый месяц у нас есть чек-лист по каждому сотруднику. Результаты обратной связи обязательно доносятся (и хорошие, и плохие). В итоге к концу испытательного срока мы имеем полноценного сотрудника, который умеет решать задачи и интегрирован в команду
Заключение
Что же мы имеем на выходе? Результаты такие:
- Количество откликов на вакансию изменилось с «почти никогда» до «каждый месяц несколько откликов»
- Скорость подбора увеличилась в 4 раза при том же качестве
- Мы имеем стандартный фреймворк технической оценки технических специалистов, который позволяет хорошо понимать, как будущий сотрудник справится с работой
- Оптимизировали свое время и время кандидата
- Нащупали, как лучше проводить адаптацию внутри
Комментарии (47)
peresada
13.02.2019 11:38Мы теперь не заставляем писать код на бумажке. Каждый интервьюер должен принести с собой ноутбук, дальше – выбор за кандидатом.
Жаль, код на бумажке в различных собеседованиях мне нравился, особенно, когда тебя не привязывают к конкретному языку, а можешь писать на псевдоязыке, имхо это больше говорит об опыте кандидата, если он может без зависимостей описать ту или иную логику.nexus478
13.02.2019 11:43+1А чего жаль, если нравится писать на бумажке — пишите на бумажке!
Мы теперь не заставляем писать код на бумажке. Каждый интервьюер должен принести с собой ноутбук, дальше – выбор за кандидатом.
peresada
13.02.2019 11:50Действительно, рассеяно воспринял из-за слова «должен», хоть оно и не относилось к кандидату, спасибо
Ivanko63rus
14.02.2019 09:47Мы теперь не заставляем писать код на бумажке. Каждый интервьюер должен принести с собой ноутбук, дальше – выбор за кандидатом.
Прочитав фразу подумал: Зачем человека заставлять принести ноутбук, в офисе нету?
Тоже предпочитаю написать код на бумаге или объяснить алгоритмы, рисуя схемы на доске (если она есть).
Компьютер нужен когда пишется программа которую предполагается запустить и продемонстрировать работоспособность, но это уже скорее тестовое задание.
Neikist
14.02.2019 10:20Компьютер нужен когда пишется программа которую предполагается запустить и продемонстрировать работоспособность, но это уже скорее тестовое задание.
Имхо, я бы выбрал ПК просто потому что у меня корявый почерк, да и редактор позволяет корректировать текст, вставлять пропущенное, идти «сверху-вниз» набросав сначала каркас а потом детали. Но это в условиях что не нужно компилировать и запускать, потому что совсем в детали погружаться не очень хочется, не говоря уж про крайние случаи всякие.
kenbo
13.02.2019 11:42Согласитесь: если вы senior, странно отвечать на вопрос «чем отличается isset от empty?». А нам еще страннее на основании этих вопросов принимать решение, что кандидат сможет выполнять наши задачи и делать это классно.
Тем не менее некоторые работодатели так и набирают себе команду.Irwin
14.02.2019 16:50Я обычно говорю кандидату, что «для „разогрева“ задам несколько элементарных вопросов, а потом уже перейдем к сложным». Это позволяет и не унизить человека такими вопросами, он немного расслабляется и одновременно покажет знания на типовых вопросах.
К сожалению, примерно четверть кандидатов на сеньора и мидла не могут ответить на элементарные вопросы. И если я вижу, что человек заваливается на таких вопросах, то уже копаю глубже в этом направлении, а уже потом перехожу к сложным.
abbath0767
13.02.2019 11:59+2Честно говоря, подбор шел медленно. Забегая вперед, скажу, что к концу года мы увеличили скорость набора в 4 раза
Ну да, ведь когда нас было трое и взяли четвертого — искали мы полгода, когда искали пятого — искали полтора месяца — очень репрезентативная выборка и хорошие статистические выводы. В контексте 7 человек это выглядит крайне странно на мой взглядCRRaD Автор
13.02.2019 12:17Возможно недостаточно понятно расписал: только в команде Электричек 7 человек. Всего бекендеров у нас сейчас примерно 30, а всех технических специалистов и того больше :)
abbath0767
13.02.2019 12:25Возможно стоит это добавить так как сейчас это выглядит весьма странно, согласитесь)
Так же хотел поинтересоваться раз вы ответили — в этапе 3, финальном, вы совсем кратко описали что с кандидатом общается представитель бизнеса — подозреваю что это продукт овнер. На сколько велико его влияние в выборе кандидата и не было ли у вас с этим проблем?CRRaD Автор
13.02.2019 12:30Я добавил, спасибо. Кстати, еще подумал, что стоит подробнее раскрыть, что такое скорость: это же не только количество, но и SLA на закрытие вакансии – он тоже упал.
Да, на третьем этапе общается РО. Он участвует в принятии решения, конечно, может заблокировать его, потому что ему с этим человеком потом работать. На самом интервью задает обычно гораздо меньше вопросов, чем руководитель. Цель всего процесса – познакомиться поближе с человеком, который будет ставить задачи и понять, что конкретно нужно будет создавать.
Проблемы были на старте: составить ожидания, потренировать ребят задавать вопросы и рассказывать то, что интересно разработчику. В процессе принятия решения острых конфликтов не припомню.
RinatWorld
13.02.2019 12:17А я тут придумал новую фичу для Туту) В предновогоднем дефиците билетов, нашел способ покупать билет, когда все сервисы показывают, что их уже нет:
Например, мне нужен был билет Москва — Амзя (поселок такой), на который билетов собственно и не было. Я открыл маршрут поезда, вкратце он выглядит так Москва-Муром-Казань-Амзя и проверил наличие билетов в промежуточных точках.
Оказалось, что в этом поезде много билетов Москва-Казань и Муром-Амзя, но они не совпадали и поэтому свободного места Москва-Амзя как бы нет.
То есть можно купить два билета в одном и том же поезде и просто перейти из одного вагона в другой на промежуточной станции (или даже с одного места на другое в одном вагоне). Это не просто старый добрый поиск вариантов с пересадкой, тут пассажир не рискует, что не успеет на второй поезд на пересадке, он ведь с самого начала в нужном поезде.
Потом я проверил варианты с пересадкой в других точках, чтобы найти оптимальное сочетание по цене (какой-то участок можно проехать в купе, какой-то в плацкарте, где -то можно не покупать постельное). Кстати эту процедуру не очень удобно проводить вручную, но вот автоматизировать поиск оптимального варианта — отличная идея, имхо.
Кажется, этот способ действительно может выручить многих людей и повысить эффективность перевозки пассажиров. По цифрам сложилось ощущение, что еще несколько десятков человек могут ехать в поезде, билетов в котором «уже нет».
Вот такая идея, как вам, Туту?ShamanR
13.02.2019 13:29О, только начал читать, как понял что за фичу вы предлагаете. Обычно так в Брест из Москвы ездят, с остановками в Орше, но приходится самому руками подбивать билеты. Как бонус — дешевле цена рублей на 500.
user783
13.02.2019 15:05Ну вот можно сказать, благодаря этой статье, еще один кандидат на работу в Туту нашелся :-)
shinkareff
13.02.2019 12:55текст вакансии мало влияет на желание людей у нас работать
Очень влияет. В моём проекте десятки релевантных откликов на вакансии, в месяц. При том, что компания сочинская и никому на российском рынке неизвестна.
И ещё, попробуйте прокачать человека, который проводит первое собеседование. Он должен рассказать о проекте с позиции тимлида (или близко к тому). Рядового HR, если он не готов к такой роли, можно ориентировать на более тщательный отбор резюме, с уточнением деталей в переписке. Так, чтобы к первому собеседованию HR приводил специалиста, который на 75-80% в требуемом технологическом стеке. Время на скрининг резюме потребуется больше, но конвертация в найм вырастет.
И, кстати, идеальная воронка в найме — это цилиндр.
Вообще, самое странное в Вашей статье, это:
о нас мало кто знает, как о технологичной компании
Если не знают о вас, что делать остальным ноунеймам?
VMichael
13.02.2019 13:00+1Как то осталось за кадром.
У меня сложилось ощущение, что если ЗП на вакансию по верху рынка, то количество откликов может вырасти на порядок.
Может вам пора несколько адаптировать ЗП к рынку ;)
Хотя понятно, что у вас в результате проведенных корректирующих мероприятиях при тех же условиях количество откликов выросло в 4 раза.
shinkareff
13.02.2019 13:04И ещё, у Вас не упомянуто о важной части работы с кадрами — я говорю про увольнение. Об увольнении HR должен знать всё и сопровождать этот процесс не только до последнего дня пребывания сотрудника в компании, но и продолжать следить за его дальнейшей карьерой.
Обладая всей полнотой картины, можно понять, что не так в процессе удержания, где провалы в мотивации. И даже в процессе найма это помогает, опосредованно.
Moric
13.02.2019 17:45+2Был у вас на собеседовании. Похоже, что до изменений процессов.
Отпугнуло от вакансии два момента:
* hr, которая опоздала на час, и это час я скучал в переговорке
* тех. специалист, который не смог ответить на простой вопрос — «какой фреймворк используется на фронте?»
Я так понимаю обе проблемы получилось решить?CRRaD Автор
13.02.2019 18:42Помню ваш фидбек (мне его передали почти сразу). Это был важный толчок для нас обучать всех собеседующих знать о продуктовых задачах и базовую информацию о том, что происходит во фронте и мобилке. Спасибо, что помогли нам стать лучше
xPomaHx
14.02.2019 04:42По моему это вообще должно решаться на этапе переписки даже до звонка и договора о собеседовании очном.
vassabi
14.02.2019 09:01«какой фреймворк используется на фронте?»
увы, такое скажут только в небольших командах и когда собеседует кто-то из этой команды.
В жизни бывает всякое — вам могут назвать фреймворк, название которого вы никогда не слышали, там может быть свой самописный, команда может быть в процессе смены\выбора фреймворка, или даже — команда только собирается и вы — будете тем, кто будет должен обосновать свой выбор фреймворка.xPomaHx
14.02.2019 14:10Да знаю, что не хотят говорить, мне приходится клещами вытягивать над чем хотя бы компания работала и что сейчас делает, чтобы самом прикинуть, подхожу я туда или нет, мне то это точно известно себя я хорошо знаю.
geisha
13.02.2019 18:07В итоге мы ввели «предварительное техническое собеседование», но заключается оно не в том, что у вас спросят по телефону «как выйти из vim-а», а поговорят о том, что вы делали на предыдущем месте работы, позадают релевантные вашей квалификации вопросы. И что самое важное: делать это будет разработчик.
Тут недавно статья была о том, каквашипредварительные собеседования с вопросами из резюме задолбали самих соискателей. Т.е. ясно, что в первую очередь соискатель ответственнен за то, чтобы его резюме прочитали и поняли, но я как-то не очень верю в ситуацию, когда вы видите откровенно плохое резюме, потом нанимаете кандидата на конкурентной основе и, внезапно, он оказывается скрытым талантом.vassabi
13.02.2019 19:36ну вот я собеседовал на С++. У каждого был свой стиль написания резюме.
Поэтому я просил на собесе рассказать об одной истории с их участием. Любой, главное — чтобы она им запомнилась больше всего и они принимали в ней участие.
И вот тут-то и начиналось деление: «кто рассказывает как ключики подавал, а кто — нырял».geisha
13.02.2019 23:20По телефону чтоль?
vassabi
14.02.2019 01:12и по телефону и очно.
А что, есть какая-то фундаментальная разница? Я-то обращаю внимание на эмоциональную составляющую, т.е. — насколько увлеченно мне рассказывают, сыпят техническими подробностями, цитируют спеки и т.д. Вы думаете, что телефон этому как-то помешает или поможет?geisha
14.02.2019 02:19Думаю разницы нет, лишь бы выбрали что-то одно, а не и то и другое и придите завтра в субботу потому что тимлид сегодня занят.
vassabi
14.02.2019 09:07придите завтра в субботу потому что тимлид сегодня занят
хаха, а вот это провал!
.
Quolyk
13.02.2019 18:16Ваша компания недавно устраивала event для найма iOS разработчиков. Интересно переняла ли iOS команда ваши техники и как у них прошел «оффер за один день».
CRRaD Автор
13.02.2019 18:44У них не совсем тот «оффер за один день» – это был действительно массовый event. В нашем случае мы просто предлагаем каждому кандидату пройти все собеседования сразу. Процессы найма у нас (пока) отличаются
dominigato
13.02.2019 23:22Как понимаю один из способов повышения узнаваемости это статьи на хабре о том как вы набираете кандидатов? ;)
Neikist
13.02.2019 23:42Кстати работающий способ. Я вот прямо по этой цитате думал, и даже не предполагал что там что то интересное у них происходит.
Сообщество разработчиков о нас думает примерно «Ну это сайт с расписанием электричек – там наверно 3 человека работает в подвале».
Правда справедливости ради я и сервисом не пользуюсь так как домосед.
411
14.02.2019 01:12ездить в офис долго, дорого
Ну а как же предложить соискателю промокод на покупку билета на электричку для собеседования?
Rustacean
14.02.2019 08:17Превосходно! А за вот этот пункт вам отдельный «респект и уважуха»:
Мы за «простую философию человеческих отношений: каждому кандидату вне зависимости от исхода встреч мы даем обратную связь и показываем, что для нас не так и какие навыки прокачать.
(взято с сайта tutu).
А если ещё и будете делать шаги по направлению к распределённой команде, то количество откликов вырастет ещё сильнее. ;-)
Crocodilovich
14.02.2019 08:17Очень хочется поинтересоваться и получить честный ответ. Может ли попасть в вашу команду на позицию junior тридцати летний мужчина? Кроме этого, без соответствующего образования. Другими словами, интересно ваше личное отношение к таким кандидатам и есть ли у них шанс работать в вашей компании. Заранее спасибо.
CRRaD Автор
14.02.2019 08:17Придется постараться, но нет ничего возможного. Можете начать с тестового задания: github.com/tutu-ru/php-interview
pushthebutton
14.02.2019 09:05Ничего не понял: придется постараться конкретно Crocodilovich, ведь ему 30 лет и нет соотв. образования? Другим можно не стараться?
И как понять «нет ничего возможного»? Это такое завуалированное нет?Neikist
14.02.2019 09:10Кстати непонятно почему придется постараться, конечно с php дела не имел, только 1с и kotlin (из того за что платили), но задание выглядит достаточно простым.
CRRaD Автор
14.02.2019 16:56Мой ответ о том, что на основе этой информации нельзя сказать ни «да», ни «нет».
«30летний джун» – это может быть человек, который только недавно решил перейти в профессию. Если у него получается и голова мыслит «правильно», то почему нет? Если это джун уже на протяжении 10 лет, то, конечно, веры в такого кандидата мало.
Придется постараться, потому что мы пока не берем специалистов без опыта. Хорошо выполненное тестовое задание может свидетельствовать, что несмотря на маленький опыт работы, знания у кандидата хорошие.
vassabi
14.02.2019 08:56не скажу за туту.ру, но в моей практике есть два замечательных случая с наймом — когда мы брали в нашу команду джуником девушку 4го курса без профильного образования (но профильное у нее было — радиофизика, управление ракетами) и когда брали джуником дядечку 50+ с промпроизводства (он там делал\сопровождал программы для ЧПУ и местных допотопных АСУ).
Они даже сами немного не верили в себя, но я до сих пор вспоминаю, как они не замыкались на негативе, а энергично разбирались во всем, что нужно было по работе. И в итоге (в итоге работы в нашем отделе. А в жизни — у них все только начиналось :) ) это были два очень успешных синьора-помидора!
nerazzgadannaya
15.02.2019 13:42Саша, а не хотите про процесс адаптации и подход «получить рабочую задачу в спринте через 3 дня» рассказать на конференции KnowledgeConf knowledgeconf.ru/2019? У нас планируется целая группа докладов про онбординг в технических командах и про обмен знаниями с новичками
DickCancer
Немного странно что руководитель разработки пишет HR статьи.