editor_ruvds Aug 15 2020 at 12:12

Как нанять 50 синьоров за 43 дня и быстро включить их в процесс разработки?

17 min

14K

RUVDS.com corporate blogDevelopment of mobile applications*Personnel Management*IT careerKubernetes*

21 июля в наших соцсетях прошел стрим с Андреем Евсюковым, заместителем CTO в Delivery Club. Андрей рассказал, как устроен фреймворк найма в DC и поделился несколькими секретами, как его оптимизировать, чтобы он работал, как часы. Делимся с вами расшифровкой и записью эфира.

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

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

Действительно, профиль немного не мой, я – не предприниматель, а скорее инженер. Если говорить о минимуме состава позиций, то, как мне кажется, должен быть sorter/searcher, который ищет по ключевым словам резюме и кандидатов, должен быть рекрутер для первичного отбора, должен быть кто-то, кто проверяет hardskills людей и их соответствие заявленной позиции, и кто-то, кто принимает финальные решения. Тут важно отметить, что мой профиль отталкивается от компаний, в которых я работал, и всегда присутствует развивающийся технический бренд, который сильно влияет на то, как мы ищет кандидатов. Как мне кажется, это кардинально отличается от, например, кадрового агентства, если мы говорим про бизнес, у которого нет своего технического бренда или продукта, для которого он ищет сотрудников.

Что важнее – академические знание паттернов, алгоритмов, концепций, или возможность человека быстро решать задачи бизнеса?

То есть, если отвалилась форма размещения заказа на сайте, лучше, чтобы человек сидел 2 дня и рефакторил с учетом всех dry/solid-принципов, или чтобы он за 15 минут из Г и палок сделал фикс для важной фичи сайта?

Есть разные типы команд. То есть – feature factory, продукт-команда, empowered product team и так далее. Все зависит от того, на какие зоны должен влиять разработчик. Если он получает задачу, отдает код для review, и на этот моменте компания считает его задачу решенной – это одна история. Другая – если разработчик отвечает еще и за deployment фичи, третья – если он отвечает за выяснение продуктовых требований — у бизнеса, у стейкхолдеров, у продукт-менеджера. Или такая история, когда разработчики участвуют в том, какие инициативы генерируются в изменениях для продукта, знает, как это выглядит в продакшене и как это влияет на пользователя; когда они смотрят на продуктовые метрики, знают бизнес-аналитику – конверсию, retention и так далее; когда они знают, как приложение ведет себя в продакшене, знают технические метрики, умеют работать с Grafana и другими инструментами.

В первом случае человек получает четко описанную задачу, и есть отдельный технический аналитик и project/product-менеджер, которые уже провели несколько этапов работы над задачей и требованиями. Когда он готовит код и отдает его дальше, не сильно заботясь о том, что происходит с задачей после него, то для него действительно важнее технические hardskills.

Если же история более близка к Delivery Club, то разработчики участвуют в выяснении требований, понимают продукт и бизнес-метрики, понимают, как повлиять на конечного пользователя, участвуют в deployment, понимают, как приложение ведет себя в продакшене – тогда и softskills выходят на первый план, и сопутствующие знания важны. В таком случае человек может не знать всех методов сортировки, но при этом он понимает, как работает приложение, понимает чуть больше про архитектуру, про мониторинг приложения на продакшене, про работу бизнеса компании и о том, как это выливается в продуктовые метрики – и какие именно метрики важны для продукта или для той части продукта, которой он занимается. Тогда оценка смещается на другие вещи.

Часто в вакансии на должность условного PHP-разработчика можно увидеть обязательные знания Docker, Kubernetes, Ansible, Prometheus, Grafana, CICD, GoLang – и можно еще Python, Rust, Scala. Так ли это необходимо, или лучше на такие вакансии вообще не подаваться?

Это зависит от того, как построен процесс разработки. И, наверно, от того, на какой стадии находится компания. Если она на стадии роста, когда есть неопределенность, есть культура экспериментов и гипотез, то у нее будет другой профиль набираемых сотрудников. То есть, будут требоваться люди, понимающие, как их работа влияет на конечного пользователя и продукт – и тут не обойтись без знаний Docker/Kubernetes.

Есть ли смысл давать домашние тестовые задачи на 1-2 часа, если их могут решить за кандидата, и этого не проверить?

Многие программисты и фрилансеры могут не захотеть делать бесплатный тест – принято ли за это платить?

Я отвечу, основываясь на личном опыте и мнении. Во-первых, рынок найма IT-специалистов в России — это высококонкурентный рынок. Мы сделали акцент на то, чтобы сокращать количество точек коммуникации с потенциальными кандидатами для того, чтобы добиться результата, который заявлен в теме стрима. Мы не даем тестовых заданий – по нашему мнению, это слабо проверяет скиллы. Нам важно определить, как человек мыслит в ходе динамики «здесь и сейчас», и для этого нужно присутствовать и смотреть на то, как он работает с возражениями, с изменениями условий – это говорит нам о softskills. Чаще всего кандидаты отваливаются на том этапе, когда им предлагают сделать тестовое задание, поэтому мы этого не практикуем.

Интересно было бы узнать, как у вас с тестированием и какое количество тестеров в такой большой команде? Приложение Rider App – это ваших рук дело?

Приложение Rider App мы сами разрабатываем. Если говорить о тестировании – на данный момент в компании Delivery Club работает 180 IT-специалистов, это порядка 30 команд. У нас кросснациональные продуктовые команды, составленные так, что в каждый команде есть QA-инженер – то есть, их тоже порядка 30. Еще у нас есть роли QA-лидов, которые отвечают за направление и за технологическую стратегию.

Сам процесс тестирования у нас более-менее стандартен по индустрии. Есть JiraFlow и GitFlow, этап, в котором разработчики пишут unit-тесты, функциональные тесты пишут QA-инженеры, они же составляют тест-кейсы, по которым идут. Дальше есть интеграционное тестирование, и после deployment – финальное тестирование.

50 позиций за 43 дня – звучит нереально. Интересен процесс онбординга.

Ввод человека в процесс должен занимать некоторое время – у нас обычно 3-4 недели, при этом нужно усиленное code review. Как справиться с потоком новичков?

Наш процесс онбординга формализован и устоялся за последние 1.5 года. Он проходит от месяца до 3 месяцев – может занимать весь испытательный срок. Он разбит на 3 больших этапа. Первый – это изучение процессов, культуры, технологического стека. На втором этапе (вторая-четвертая неделя) – «полубоевые» задачи, задачи из технического долга, неприоритетные, на которых проще учиться и погружаться в контекст. Настоящий проект человек получает на 3-й месяц или на середине испытательного срока, и мы планируем задействовать 100% его полезного времени – тогда человек показывает, что он изучил за предыдущие два этапа.

Процесс формализован, у нас есть база знаний в Confluence с документами по каждому направлению разработки – по ним немного отличаются адаптация онбординг. Всегда есть непосредственный руководитель, он же – тимлид команды. Кроме того, сейчас мы практикуем культуру «buddy» (человек в команде, который помогает человеку адаптировать и подсказывает, где посмотреть информацию и к кому обратиться). Кроме того, руководитель направления выступает как ментор и помогает тимлиду в форматировании целей для сотрудника. Помимо этого, есть своя команда и другие команды, к которым тоже можно обратиться. У нас много горизонтальных коммуникаций между командами и внутри них, всегда можно обратиться к любому человеку – в том числе, выше по вертикали; это приветствуется.

Сейчас онбординг идет штатно, проблем пока нет.

Как нанять столько senior-ов за такой срок?

Мне кажется, можно либо предложить з/п выше рыночной, либо набрать кого попало и заявить, что они – senior-ы. В первом случае это было бы у всех на слуху (и этот факт был бы частью стратегии).

Зарплата в Delivery Club – средняя по рынку. Что касается скиллов – я скажу, что у нас работают квалифицированные специалисты. Есть несколько техник, которые ускоряют найм; если использовать все доступные техники, то действительно можно сильно ускорить процесс найма и одновременно улучшить его качество. Сейчас мы поговорим об этом подробнее.

Итак, прежде чем рассказывать об ускорении hiring, я расскажу о том, как у нас устроен цикл найма и из каких этапов он состоит – с тем, чтобы потом обратиться к каждому из них и описать, как на каждом из них можно повысить качество и скорость найма.

В первую очередь надо упомянуть, что Delivery Club входит в состав Mail.Ru Group. Мы используем несколько функций Mail.Ru – например, эксплуатацию и рекрутмент. То есть, HR-ы у нас от Mail. Всего в том хайринге, который является нашей темой и который происходил во втором квартале 2020 года, участвовало 7 рекрутеров и около 40 хайринг-менеджеров.

Процесс начинается с того, что мы составляем описание вакансии. Описываем требования, описываем проект, обязательно – employee values (то есть, то, ради чего сотруднику стоит работать у нас). Этот текст используется и для первого контакта. Поиск, который ведут рекрутеры – это поиск холодный, через ресурсы, которые у всех на слуху. Составив описание требований и employee values, мы приступаем к этапу sourcing – это поиск контактов и первый контакт. Мы не звоним кандидатам, контактируем через мессенджеры. Человеку дается вся информация, которая есть в описании вакансии. После этого назначается короткая встреча – скрининг, которая длится 15-30 минут. Это следующий этап. Он полностью проводится командой рекрутеров. На этом этапе мы хотим определить, хотим ли мы звать кандидата на следующий – техническое интервью. На этапе скрининга задаются вопросы о работе в команде – это один из самых важных скиллов для работы в Delivery Club, а также про ожидания сотрудника – на какую позицию он апплаится, какая у него материальная и нематериальная мотивация. После того, как мы приняли решение о дальнейшем общении с кандидатом, идут коммуникации через Telegram-чат с рекрутерами и хайринг-менеджерами. Там присутствуют люди, которые проводят технические собеседования, руководители направлений, которые участвуют на финалах, также присутствую я и вся команда рекрутеров. Как только появляется кандидат, они скидывают нам ссылку на Huntflow (там мы ведем базу кандидатов), говорят о том, что есть кандидат, такой-то скилл, на такую-то позицию, и согласуют время – тогда они уже определяют удобные слоты. Кандидату пишут хайринг-менеджеры о том, когда они сами смогут, и назначают техническое интервью.

Техническое интервью представляет собой кейс-собеседование. Мы даем кейсы на проектирование архитектуры; в этом блоке также есть небольшой блок на hardskills программирования – всего 15-30 минут. Большая часть собеседования – это именно кейс-собеседование на проектирование, целиком оно длится 2-2.5 часа, иногда 3, хотя мы стараемся не затягивать их: за такое время кандидат устает, и собеседование становится неэффективным. После технического интервью хайринг-менеджеры пишут фидбек в Huntflow, вписывают туда результаты интервью, проверки по hardskills и softskills. Это также пишется в чат, и принимается решение о том, звать ли кандидата на финал.

Финал длится 30-60 минут, на нем присутствует руководитель направления, к которому принадлежит позиция, а также я, либо технический директор. На финале мы окончательно выясняем ожидания кандидата, рассказываем про проект, который хотим предложить ему, и принимаем окончательное решение – делать кандидату offer либо написать, почему именно мы не готовы сделать ему предложение по работе.

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

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

Это подсказывает нам, что нужно не затягивать с фидбеком. Важно быстро провести все этапы, прокоммуницировать кандидату, какие этапы будут, сколько они будут занимать, и когда он получит фидбек. Исследование показало, что в среднем IT-специалист в России может найти работу за 3 дня – простой даже в 1 день может повлечь потерю кандидата. Наш опыт это подтверждает – у нас были случаи, когда кандидат получал offer из другой компании, пока мы запаздывали с фидбеком по техническому интервью.

Во-первых, важно понимать, как именно мы заинтересуем кандидата – то есть, какие employee values мы предлагаем, чем мы отличаемся от других компаний на рынке. У нас это присутствует в описании вакансий и во всех точках коммуникации: автономность принятия решений, слаженный процесс разработки, четкий карьерный курс, работа с современными технологиями, и наконец – работа в самой быстроразвивающейся и быстрорастущей отрасли e-commerce, в том числе – в компании, которая является лидером этого рынка.

После того, как мы контактируем с кандидатом, надо быстро найти слоты для собеседования. Для этого мы коммуницируем в Telegram. У нас есть регламент – то есть, когда мы с хайринг-менеджерами готовимся к собеседованию, мы отвечаем в течение 3 часов после того, как рекрутер говорит о том, что есть кандидат и нужно найти время для собеседования. Кроме того, мы пишем фидбек по собеседованию не позже 1 дня – в идеале, в тот же день, максимум – на следующее утро. Промедление может повлечь за собой потерю кандидата.

Итак, у нас есть этап технического собеседования, на который могут ходить разработчики и тимлиды, и мы повысили количество рекрутеров, которые занимаются поиском, и повысили поток входящих кандидатов. После этого нам было важно сделать так, чтобы мы в первую очередь отслеживали softskills. Для нас важны не столько hardskills, сколько совпадение по культурным особенностям, которые у нас в компании есть, то, насколько человек адаптивен и обучаем, насколько он хорошо работает в команде. Был случай, когда человек приходил и апплаился на позицию GoLang-девелопера при том, что до этого он не писал на Go (был опыт на Java), и при этом он прошел техническое собеседование (про кейс-собеседование я расскажу позже), очень круто сделал проектирование сервиса, быстро отвечал, ориентировался, принимал новые вводные и не терялся. В итоге мы его взяли на работу, он довольно быстро освоил Go, сейчас круто справляется с задачами.

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

Когда у вас 40 хайринг-менеджеров, и нужно провести 150 технических собеседований, не получится каждый раз идти к человеку и спрашивать, как прошло собеседование, понравился человек или нет. Вы должны в достаточной мере стандартизировать фидбек – формат отчета, который записывается после проведения технического собеседования. Мы с нашими хайринг-менеджерами провели довольно большую подготовку – я рассказывал о том, какие softskills для нас важны, почему и как они сформированы (забегая вперед – они сформированы из особенностей той сферы бизнеса, в который мы работаем). Мы говорили о построении кейс-собеседования, о том, какие есть ходы, как по нему правильно идти, как выстраивать его контекст, чтобы можно было проверить адаптивность человека и то, как он ориентируется при новых вводных. И, конечно, о том, как отражать все это в отчете по собеседованию, чтобы потом, если человек попадет в финал, можно было посмотреть, как он прошел техническое собеседование. До этого прикладывается также скрининг-отчет, который заполняет рекрутер. В итоге — у меня, как у человека, который проводит финалы, есть вся картина. Там написано, почему человек меняет работы, какая у него мотивация к перемене, что для него является важным в новом месте работы. Далее – отчеты по тому, как он работает в команде, умеет ли он измерять свою эффективность, насколько он адаптивен, насколько хорош в архитектуре, какие у него знания по базам данных, по Go, PHP или смежным языкам.

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

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

Тут был вопрос о том, насколько реально нанять столько людей за такой короткий срок. Нужно отметить то, что это не первая волна найма, которая случается в Delivery Club. Первая была еще в 1-м квартале 2019 года, а последующие – в 3-м квартале и в 1-м квартале 2020.

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

Во-вторых, так как мы работаем в продуктовой компании, и мы начали работать над техническим брендом, это довольно сильно влияет на лояльность людей, которые приходят подаваться на работу. У нас есть такая вещь: когда человек приходит в Mail, он может апплаиться в вакансию любого бизнес-юнита; и мы, после того, как начали качать технический бренд, сталкиваемся с тем, что люди приходят именно ради нас – «мы хотим в Delivery Club, мы посмотрели, как Денис Горев рассказывает о назначении курьеров, мы поняли, что у вас много всего, много систем, сложные кейсы – мы хотели бы попробовать». То есть, прокачка технического бренда рассказами о том, как устроена система, тоже важна для того, чтобы настроить входящий поток кандидатов.

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

Всего мы за второй квартал произвели около 500 контактов с потенциальными кандидатами с помощью рекрутеров, провели около 250 скринов, 150 технических собеседований, 70 финалов, и сделали порядка 58 офферов. На каждом из этапов идет воронка в 50%, примерно; можно сказать, что для того, чтобы нанять порядка 50 сотрудников, надо провести порядка 500 контактов с потенциальными кандидатами – под контактом понимается попытка коммуникации с человеком, найденном на ресурсе. Порядка 350 из этих 500 ответили каким-либо образом, и с 250 из них мы провели первичные скрининги, транспонировавшиеся в 150 технических собеседований. Воронка на этапе финалов и офферов гораздо меньше. На этом этапе, как мне кажется, играет роль именно та работа, о которой я рассказывал – то есть, то, как вы работаете с ожиданиями. Вы помните, с какой мотивацией приходит кандидат: может быть, ему важно развиваться, или изучать технологии, или изучать микросервисы, или чтобы была слаженная команда и ментор. Вы записываете эти вещи в вашей базе кандидатов и отвечаете на эти ожидания – особенно в финале и тогда, когда делаете оффер.

Можете поделиться кейсом из кейс-собеседования? Он один и тот же для всех, или у вас есть набор кейсов?

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

У нас есть несколько кейс-собеседований, мы их используем в зависимости от того, в какой отдел мы потенциально смотрим кандидата. Иногда есть четкая дифференциация по скиллам: например, одно время мы искали именно знающих Python кандидатов для RnD – для них использовали один кейс; когда искали PHP-шников для платформы, кейс был другой, когда Go-шников для consumer-направления, был третий кейс.

В кейсе, в первую очередь, важны условия, контекст, задача. Кейс-собеседования хороши еще и тем, что они приближены к реальности. Снова возвращаемся к тому, что рынок сегодня высококонкурентен: нам очень важно заинтересовать потенциального сотрудника. Когда человек приходит на собеседование, и его начинают анкетировать, он чувствует себя, как на экзамене, или как будто попал на допрос – такие собеседования кандидатам не нравятся, и именно такой фидбек мы получали раньше после собеседований. А вот если человеку дают интересную задачу, приближенную к реальности и призванную рассказать, как именно он работает, как у него построена коммуникация, как он обсуждает архитектуру, как все выглядит изнутри – он в это все становится вовлечен, ему интересно, он более охотно отвечает на это. То есть, нет ничего хуже того, когда человеку дают чисто синтетическую задачу, и он в первую очередь задается вопросом: а может, это можно так не делать? Зачем применять вот этот алгоритм, который вы мне даете? Зачем делать целое приложение, если можно сделать routing в inject? Самое интересное, что нас в продуктовых компаниях, как инженеров, всегда просят мыслить именно так – кроме собеседований, на них обычно надо полностью менять образ мышления. Мы попытались учесть это.

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

«Представь, что ты устроился в компанию Delivery Club. И ты работаешь в команде, которая занимается мобильным приложением, в котором люди заказывают еду. И нужно сделать экран отслеживания курьера после заказа еды. Если ты им раньше пользовался — там есть такая карта, где видно, как он идет по карте. Вот и представь себя как backend-разработчика, которому надо такое спроектировать».

Дальше мы рассказываем контекст. Под контекстом имеется в виду некий environment. Мы говорим: «Есть API-gateway, принимающий запросы от мобильного приложения, он их авторизует, роутит дальше. Есть сервис с заказами – там есть такая база, такие поля, такая рученька, которая дает такие-то данные. Дальше – есть сервис логистики, которому отправляются координаты с приложения, которое есть на руках у курьера». То есть, по сути, мы создаем максимальное приближение к реальности, говорим, что можно изменять, что – нельзя. Допустим, пусть один из сервисов будет написан на экзотическом языке, которого кандидат еще не знает – то есть, менять его нельзя. Или другой сервис – слишком сложный, в него он тоже не готов вносить изменения. Тогда кандидат оказывается ограничен: он не может вносить изменений в эти два сервиса, но может строить любое другое количество сервисов, чтобы решить задачу передачи координат курьера.

Человек оказывается настроен не на то, что он – на собеседовании, а на то, как же построить такую систему. Находятся интуитивные решения, которые можно попробовать применить. Рисуется диаграмма последовательностей. Оказывается, что решение не выходит, потому что не выполнены условия. Человек думает дальше. После того, как он что-то придумал, мы иногда используем небольшую ветку с «ложным путем» — так мы проверяем ту самую адаптивность, про которую я много рассказывал.

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

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

Есть ли у вас на входе тестирование по каким-то стандартным формам? Если есть, как оцениваете его эффективность? Если нет, то почему?

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

Что было ранее

Tags:

Hubs: