company_banner

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


    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, принимающий запросы от мобильного приложения, он их авторизует, роутит дальше. Есть сервис с заказами – там есть такая база, такие поля, такая рученька, которая дает такие-то данные. Дальше – есть сервис логистики, которому отправляются координаты с приложения, которое есть на руках у курьера». То есть, по сути, мы создаем максимальное приближение к реальности, говорим, что можно изменять, что – нельзя. Допустим, пусть один из сервисов будет написан на экзотическом языке, которого кандидат еще не знает – то есть, менять его нельзя. Или другой сервис – слишком сложный, в него он тоже не готов вносить изменения. Тогда кандидат оказывается ограничен: он не может вносить изменений в эти два сервиса, но может строить любое другое количество сервисов, чтобы решить задачу передачи координат курьера.

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

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

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

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


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



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


    1. Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
    2. Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
    3. Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
    4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
    5. Ашот Оганесян, основатель и технический директор компании DeviceLock — кто ворует и зарабатывает на ваших персональных данных.
    6. Сания Галимова, маркетолог RUVDS — как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
    7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег — как стать тимлидом фронтендеров и как жить после этого.
    8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs — как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
    9. Ричард «Левелорд» Грей, создатель игр Duke Nukem 3D, SiN, Blood — про личную жизнь, любимые игры и о Москве.
    10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем — про игры, их жизненный цикл и монетизацию
    11. Андрей, технический директор GameAcademy — как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
    12. Александр Высоцкий, ведущий PHP-разработчик Badoo — как создаются Highload проекты на PHP в Badoo.

    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Комментарии 19

      +8

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

        +2
        И главное, что такое сеньор?

        Должность в рамках конкретной компании, ничего более.
          0
          А что значит проще и понятнее?
          Паттерны и бест практики используют для будущего расширения и безопасности, а не для простоты. Для простоты можно писать процедурно — будет очень просто и понятно.
            +2

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

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

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

              То, что написано без усилий, читается без удовольствия
              0

              Понятия сеньора, мидла и джуна — это субъективное мнение каждого, у меня градация такая:


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


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

              +2
              А я не увидел конкретного ответа на вопрос, какая же минимальная команда ИТ нужна для работы над внутренним продуктом. Мой список выглядит так:
              1) Руководитель
              2) Аналитик
              3) Программист бэк
              4) Программист фронт
              5) Дизайнер интерфейсов
              6) Тестировщик
              7) Девопс
              8) Админ баз данных
              9) Админ прочей инфраструктуры.

              Позиции 3, 4, 6 можно умножать под нагрузку.

              Верно? или я что-то упустил?
                +3
                Вы не учитываете, что продукт (а внутренний особенно) может например вообще не иметь интерфейсов. Соответственно, 4 и 5 пункты удаляем. Пункты 7-9 совмещаем в одном человеке (или же девопс это разработчик). Пункты 1, 2 и 6 — во втором. Если продукт не очень сложный, такое возможно.

                Итого, руководитель+аналитик+тестировщик, программист+девопс или админ+девопс+DBA. И даже возможно хватает двоих. Более того, программист вполне может выполнять роль аналитика. А если у вас в команде всего двое — нафига вам руководитель?

                То есть, как насчет одного человека? Ну хорошо — трех (все-таки, тестировать код лучше не автору, а отдать другому человеку, со свежим взглядом)?

                Короче, вариантов полно. Все очень сильно зависит от масштабов и сложности.
                  –1
                  3-4 пункты — это просто два фулстека, имхо) Фронт уйдет в отпуск, или бэк заболеет и что делать тогда)
                    0
                    7-8-9 сразу сливаем. И по возможности отдаем 3. Инфраструктура общая на вся компанию. Внутренний проект должен полностью в нее ложиться. Больших или сложных баз в нем тоже вроде как нет.

                    Дизайнер сгодится приходящий. Не так много там дизайнить надо.

                    Аналитик аналогично. Целый человек. Да нет там столько работы.

                    Тестировщик тоже один на несколько проектов. Ну нет там столько работы.

                    Фронта очень хочется подсократить хотя бы наполовину. Но ладно оставлю уже. У внутренних проектов часто ужас с интерфейсами. Отдаем чтобы ужаса не было. Так что пусть будет полный.

                    Итого
                    Руководитель. Он при этом может руководить несколькими командами.
                    Бек
                    Фронт
                    Приходящий тест
                    Приходящий дизайнер
                    Приходящий аналитик

                    Все. 3 человека. До 2 урезается легко. Проект можно делать. Дальше по росту проекта уже.
                    +2

                    У меня одного дежа вю?

                      0
                      Я думал вкладка закешелась, два раза обновил.
                        +3
                        Ну может быть они ещё 50 новых наняли? :)
                      0
                      Спроектировать метод для передачи коррдинат? Пусть даже с миллионом ограничений.

                      Есть курьер. У него приложение отдающее координаты типовым способом для Андроида.
                      Значит эти координаты уже есть в некой БД.
                      У пользователя есть приложение. Надо просто передать эти коррдинаты в это приложение.
                      Связь пользователь-заказ-курьер тоже где-то точно уже есть.

                      Значит или читаем прямо из той БД в которой эти координаты уже есть или через любой не менее типовой транспорт (Кафка ок) перекладываем в соседнюю базу и читаем из нее. Историю не храним, сверх надежности и гарантий не надо. Делаем самый простой at least once. Небольшие потери и погрешности в этом месте нас устроят.

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

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

                      Ужасов с вызыванием других микросервисов стараемся избегать. База получается не очень большой. Миллион заказов в неделю. Пусть с мега ростом миллион в день. Это максимум сотни тысяч активных заказов. С огромным запасом. Ерунда. Все влазит в любую базу и не требует особо железа. Я бы взял Редис, но в общем дело вкуса.
                        +3

                        Повторюсь: никак.

                          +1
                          Был у Андрея на собеседовании когда он еще в Lamoda работал. Остались только позитивные впечатления.
                          Не было глупых вопросов, не было вопросов про знание SOLID, сложности алгоритмов и т.д. Была интересная задача на проектирование.
                          Молодец, что смог масштабировать свой подход.
                            0
                            У нас кросснациональные продуктовые команды

                            Неплохо, но в 2к20 уже не достаточно — внедряйте кроссрассовость и кроссориентационность!

                            По теме: воронка выглядит слегка незаконченно без шага «оффер — согласие».
                              +1

                              Пару вопросов


                              • Какой процент из 50 синьоров прошел испытательный срок?
                              • Сколько нужно синьоров, что бы ресторану было легко и непринужденно добавить исправить блюдо в меню (сталкивался с 2 заведениями которые имели на я.еде 100 позиций в деливери 50 на вопрос почему так были озвучены нехорошие слова о добавлении и изменении меню)
                              • Сколько нужно синьоров, что бы при фокапе на 2 разных заказа в день было выделено 2 разных промкода.
                                0
                                Когда к середине текста устал от бешенных англицизмов не по делу, стал читать про себя голосом Richard Sapogoff. И знаете, веселее пошло

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

                                Самое читаемое