Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Найм

Перевод Вопросы, которые вам следует задать рекрутеру, чтобы успешно пройти телефонное собеседование

19.04.2021 18:14:05 | Автор: admin

В преддверии старта курса "IT-Recruiter" подготовили перевод материала, который содержит рекомендации по подготовке к первичному собеседованию.

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

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

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

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

Вам это кажется знакомым?

Ваш отклик на вакансию прошел этап отбора резюме (поздравляю!). Рекрутер отправляет вам электронное письмо с предложением договориться о вашем первом телефонном собеседовании.

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

Я все время замечаю за своими друзьями такое поведение. Как только они получают электронное письмо от рекрутера с просьбой назначить собеседование, они сразу же начинают бурную деятельность:

Мне нужно выписать КАЖДЙ факт о работе, которой я занимался, и мне нужно ЗАПОМНИТЬ все это!

Мне нужно выучить JAVASCRIPT за ОДНУ НЕДЕЛЮ!

Мне нужно КУПИТЬ НОВЙ ТЕЛЕФОН, чтобы мой голос звучал лучше!

Что вам нужно, так это немного расслабиться и начать задавать вопросы

Рекрутеры ваши союзники, которые могут предоставить полезную информацию.

Команда по подбору персонала с радостью поможет вам сориентироваться в процессе собеседования. Это означает, что вы можете (и должны!) задавать им вопросы о предстоящем интервью.

Выясните, что вам нужно подготовить

  • Кто будет вас собеседовать по телефону? Это hr? Это коллега из команды, к которой вы хотите присоединиться?

  • Какого рода собеседование у вас будет? Это поведенческое интервью? Это кейс-интервью?

  • Какова основная цель этого собеседования? Оно будет сосредоточено на вашем опыте? Или основное внимание будет уделено вашим аналитическим способностям?

  • К каким дополнительным вещам вам следует подготовиться? Стоит ли вам сосредоточиться на новых продуктах, выпущенных компанией? Стоит ли вам узнать больше о финансовых показателях компании?

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

Вы можете задать рекрутеру следующие вопросы.

4 вопроса, которые можно задать рекрутеру перед телефонным собеседованием

1. С кем я буду общаться?

Если ваш рекрутер еще не сказал вам это, задайте этот вопрос. Вы узнаете имя интервьюера и, скорее всего, его должность. Это поможет вам поставить себя на место интервьюера.

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

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

2. Какого типа собеседование мне следует ожидать?

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

Если это аналитика или кейс-интервью, вам могут задать такие вопросы, как как вы оцениваете, сколько бронирований обрабатывает Airbnb за один год? или как бы вы улучшили монетизацию Snapchat?

Если это собеседование, посвященное продукту, вас могут попросить перечислить ваши любимые продукты, объяснить, почему и как вы могли бы их улучшить.

Знание типа собеседования поможет вам определить, какой области следует уделить особое внимание при подготовке.

3. На чем конкретно будет сосредоточено это собеседование?

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

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

4. Стоит ли мне подготовить какую-либо конкретику?

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

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

или

Мы хотим знать, насколько хорошо вы работаете с командой разработки и насколько хорошо вы работаете над техническими проектами.

Рекрутер может помочь вам проявить себя наилучшим образом, это часть его работы!

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

Перевод:

Брэндон:Привет, ###! Меня устраивает! Какого типа собеседование мне следует ожидать? Что конкретно я должен подготовить? Спасибо!

Рекрутер: Привет, ###! Ожидайте, что это будет похоже на разговор с ###. Внимание будет сосредоточено на прошлом опыте и, в данном случае, могут быть вопросы по стратегии и/или анализу. Дайте мне знать, если у вас возникнут дополнительные вопросы, ###.

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

Не распыляйтесь, готовясь к собеседованию. Сосредоточьтесь

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

Просто спросите!

Узнать подробнее о курсе "IT-Recruiter".

Смотреть вебинар Как из человека сделать IT-рекрутера.

Подробнее..
Категории: Интервью , Управление персоналом , Собеседование , Найм , Лайфхак , Блог компании otus , Устройство на работу

Как работать с джуниорами?

08.07.2020 14:22:16 | Автор: admin
Если попробовать ответить на вопрос в заголовке одним предложении, то получится доверять, но проверять. Доверьте джуниорам какую-то работу, проверьте, помогите, повторите цикл. Но это грубое и упрощённое правило, потому что в работе с джунами возникает так много тонкостей, что об этом нужно рассказывать обстоятельно.



Рассказывать будет Серёжа Попов, CEO Лига А. и директор по талантам в HTML Academy. В Лига А. работа с джуниорами поставлена на поток: половина фронтендеров компании это выпускники HTML Academy. Выпускники приходят в компанию на стажировку, где им помогают развиваться, а 95% тех, кто после стажировки ищет другую работу трудоустраивается.

Серёжа уже больше 3 лет выполняет роль наставника для джуниор-фронтендеров и научился работать с ними так, чтобы новички быстро росли до крутых специалистов и приносили пользу компании. Нюансами, принципами, правилами и секретами работы, он поделился в докладе на TeamLead Conf 2020, а мы расшифровали.


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

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

Зачем нужны джуниоры


Перед тем как рассказать о работе с новичками, расскажу, зачем они вообще нужны. Есть несколько причин (или проблем на рынке).

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

Если простую задачу ценой в 1000 рублей выполняет человек со ставкой 2500 рублей в час что-то пошло не так. Поэтому здесь не обойтись без джуниоров они сокращают стоимость производства (продуктов, ПО).

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

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

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

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

Подготовка к джуниору


Чтобы подготовиться, убедитесь, что у вас есть сформированные задачи и ментор.

Сформированные задачи важны (или понимание, как их сформировать), потому что джуниор это работник. Он не талисман, который ходит по офису и всех подбадривает, а сотрудник, который должен работать и выполнять задачи.

Джуниор может выполнять что-то простое:

  • правки;
  • модификации готовых компонент;
  • создание простых компонент;
  • работать по инструкции или документации.

Ребята, которые попадают к нам, делают простые вещи: вносят правки или собирают страницы по UI-kit. Потом растут и выполняют задачи сложнее, например, пишут простую логику.

Когда джуниор будет работать над задачами, ему нужен ментор наставник. В 2018 году я участвовал в ПК FrontendConf. Один из хороших докладов, который не прошел в программу из-за высокой конкуренции, назывался Что делать, если мне подложили джуна? Это то чувство, которое возникает у мидла, когда на него пытаются скинуть наставничество. Когда менторство навязывают против воли сотрудника никто не будет доволен. Важно заранее все обсудить и назначить человека, который будет готов к нагрузке.

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

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

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

Для джуниора должна быть работа и человек, который ее контролирует.

Отбор


Второй и самый важный этап, который все недооценивают. На этом этапе придётся научиться многим вещам:

  • привлекать поток джуниоров;

  • просеивать поток до собеседования;
  • собеседовать;
  • отсеивать тестовым заданием;
  • выбирать кандидатов.

Привлечение


Есть три способа: своими силами, силами образовательных площадок и с помощью своей школы.

Своими силами: размещайте вакансии на специализированных площадках вроде hh.ru или Хабр Карьера. Осознанно подойдите к составлению вакансии от неё зависит сколько нерелевантных откликов вы получите (а получите обязательно).

В описании вакансии не добавляйте лишнего. Если просто взять описание для мидла и заменить там одно слово это не сработает. Джуниоры боятся таких вакансий, когда между словами Привет и Печеньки находится много незнакомых терминов. Поэтому для джуниоров важно указывать реальные задачи и стек, которые будет использовать человек. Если человек должен верстать пишите, что кандидат должен знать HTML и CSS. Если надеетесь, что через полгода освоит React не пишите об этом сейчас, спугнете.

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

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

  • придётся разработать образовательную программу;
  • подготовить онлайн-платформу (или найти помещение, если это не онлайн-школа);
  • записывать видео;
  • тратить часы разработчиков;
  • вкладываться в маркетинг.

Всё для того, чтобы привлечь толпу джуниоров, которые при этом учатся где-то ещё.

Отсев потока


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

8 человек из 10 не дойдет до собеседования.

Это усредненная статистика: по нашему опыту, по вакансиям Центра Карьеры HTML Academy и по статистике других работодателей. Вас тоже ждёт такая воронка, если не хотите брать на работу всех подряд.

Будьте готовы просеивать подготовьте себя и команду к тому, что будет много заявок, но низкая конверсия (как у нас или ещё ниже). У вас должно быть на это время, ресурсы и моральная готовность. После публикации вакансии поток заявок будет нескончаем в какой-то момент придётся обрубить поток.

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

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

Не ждите идеального резюме.

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

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

Собеседования


Это стресс для джуниоров. Например, в Центре Карьеры мы постоянно трудоустраиваем выпускников и каждый день сотрудники начинают со звонков джуниорам, которые трясутся и не могут пойти на собеседование.

Берите людей с запасом. Треть джунов не дойдет до назначенного собеседования: заболела кошка, трамвай сломался, передумал по дороге. У меня был случай, когда я видел из окна, как джуниор дошел до офиса, а у входа развернулся и ушел.

Брать побольше людей придётся и для того, чтобы у вас был выбор. Но выбирать вам придется не между Ламборджини и Феррари, а между Ладой и Москвичом.

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

Именно по этой причине не приходите на собеседование всем отделом. Вы успеете посмотреть на человека, когда он выйдет на работу. Даже мидлов и сеньоров напрягает, когда на собеседование приходит 10 человек из CTO, CMO, CPO и старших разработчиков, а для джуниора это ад. Поэтому лучший формат один на один. Проведите хотя бы первое собеседование в таком формате.

Зовите больше кандидатов, но меньше коллег.

Не давайте тестовое задание на собеседовании. Мы в Лига А. собираем истории от джуниоров о том, как у них проходит трудоустройство. Один из случаев: новичок пришел на собеседование, а интервьюер даёт ноутбук и говорит:

Сверстай по PSD.

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

Но не отказывайтесь от технических вопросов: спросите, что такое HTML, CSS, как работает JavaScript, что такое браузер:) Но только если видите, что человека не трясет и он не упал в обморок.

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

Желание обучаться одна из ценностей компании, по которым мы также отбираем кандидатов. Ещё одна ценность горящие глаза. Горящие глаза подскажут, что человек готов работать. Не сам он горит, а только глаза. Сам он гореть будет, когда устроится на работу.

Тестовое задание


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

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

Трое из четырех джуниоров не возьмутся за сложное тестовое задание.

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

Расписывайте задание максимально подробно и понятно. У джуниоров нет опыта, на который они могут опираться. Они не делали 10 000 тестовых заданий, не знают нюансов и тонкостей. Скорее всего, ваше будет одним из первых и джуниор будет делать то, что видит. Если нужен результат, опишите его максимально подробно.

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

Ставьте сроки из расчёта 2 к 1. Джуниоры выполняют работу примерно в 2 раза медленнее. Если даёте тестовое задание на 2 часа, рассчитывайте, что джуниор выполнит его за 4.

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

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

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

Выбор кандидата


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

Но не берите несколько человек с расчётом на то, что в конце останется только один. Это не игра на выживание.

Берите на перспективу. Джуниор не выдаёт результат здесь и сейчас. Рассчитывайте на то, что он будет приносить пользу через полгода.

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

Хороший способ не нервничать чем-то заняться: почитать о корпоративной культуре, познакомиться с продуктами, изучить code style. Дайте задание до выхода этими и другими способами подготовиться к работе.

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

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

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

Через две закрытые вакансии вы научитесь отбирать джуниоров.

Работа


Работа с джуниором начинается с онбординга введения новичка в коллектив. В онбординге есть несколько критичных правил, которые важны не только для джуниоров.

Онбординг


Не бросайте в мясорубку. Как избавиться от джуниора? Кидаете в него в первый день боевую задачу, например, развернуть окружение, и уходите. У него начинается паника. Приходите через неделю за результатом, а у вас мёртвый джуниор (если он еще не уволился) и невыполненная задача.

Не оставляйте одного. Моя первая работа разработчиком в большой компании проходила в Veeam Software. Тогда мне не нравилось, что меня таскали на дурацкие планёрки: полно народу, все что-то говорят, какие-то странные люди по Skype разговаривают на английском, ничего не понятно, что происходит. Но сейчас я понимаю, что это помогло мне окрепнуть, окунуться в рабочий процесс и стать частью коллектива.

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

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

Когда джуниор привыкнет и успокоится, нагружайте работой. Не затягивайте онбординг на недели. Все-таки вы наняли разработчика он должен работать.

Процесс работы


Прошла неделя, две джуниор окреп и привык. Что изменилось в нашем подходе?

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

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

  • Берите на все командные и рабочие мероприятия даже в качестве слушателя.
  • Возьмите джуна в релиз пусть сидит и смотрит, как все бегают в огне. На третий релиз он начнет помогать.
  • Учите работать в команде. Джуниоры умеют писать код и работать с системой контроля версий, но не в команде. Будьте к этому готовы, учитывайте это и помогайте наладить взаимодействию.
  • Не позволяйте команде обижать джунов. Если у вас есть джуниор, значит он нужен. Следите, чтобы другие разработчики не грубили и не отказывали в помощи.
  • Не позволяйте джунам обижать команду. Когда джуниор не принимает правила работы, вступает в конфликты и споры со старшими специалистами, говорит:Я Дартаньян, а вы нет, и работа с ним превращается в ад меняйте. За дверью стоит очередь из таких же.
  • Не доверяйте. Настраивайте безопасное окружение, отдельные ветки, запрет на коммит в мастер все на уровне системы, а не на честное слово.

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

Джуниор никогда не расспросит о задаче, не уточнит, а будет пытаться все решить сам. Когда джуниор сидит 3 дня над задачей и не задаёт вопросы это обычная ситуация. Многие не умеют и боятся задавать вопрос.

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

В то же время, не беспокойте джуниора слишком часто. Джуниоры работают медленнее в 1,5-2 раза медленнее, по статистике Лига А., HTML Academy и других проектов на выборке в 500 джунов. Учитывайте это при постановке задач и планировании. Если джуниор будет систематически не успевать за вашими сроками, это будет его демотивировать.

Джуниор трепетно относится к результату своей работы. Например, они могут реагировать так:

Как вы посмели провести код-ревью моего кода! Я не привык к тому, что мне указывают на мои ошибки!

Это выдержка из рабочего чата от разгневанного джуниора. Джуниоры не привыкли к разбору их кода, в отличии от опытных разработчиков.

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

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

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

Мотивация


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

Через доверие. Джуниоры знают, как сложно найти работу и начать работать в сфере, поэтому благодарны. Если они у вас, они уже мотивированы. Но доверие нужно развивать и увеличивать.

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

Никто не хочет быть вечным джуном.

Не держите джуна долго в статусе начинающего специалиста, растите внутри компании. Через 3-6 месяцев новичок вырастает в крепкого специалиста.

Но всё это работает при наличии зарплаты. Джунам надо платить деньги. Возможны бесплатные стажировки, но без денег джун долго не протянет.

Что дальше?


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

Не бойтесь джуниоров и процесса их поиска. У них есть плюсы.

  • Горящие глаза и способность давать результат. Если учтете все нюансы и выберете правильного человека, то результат будет.
  • Стартовая зарплата в два-три раза ниже рынка.
  • Трудно мотивировать человека, который работает только за деньги. Джуниоров мотивируют не только деньги.
  • Нет предубеждений относительно рынка и компании. Для большинства джуниоров ваша компания будет первой. У него не будет опыта работы в других компаниях и будет проще их приучить к вашей культуре.

Джунов много.

Будет из кого выбрать. У вас не будет моей ситуации, когда 4 кадровых агентства искали мне сеньора 2,5 года. С джунами проще: заходите в метро, берете первого попавшегося человека это готовый фронтендер-джуниор.

Приготовьтесь к тому, что джуниоры будут:

  • бесить;
  • задавать тупые вопросы;
  • остро реагировать на критику;
  • медленно работать;
  • подвергать сомнению ваше доверие к ним;
  • бесить.

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

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

Вторую TeamLead Conf в этом году мы снова проведем в Москве, 16 и 17 ноября. Это будет очная встреча со всеми атрибутами: спикерами на сцене, кулуарным общением, митапами-воркшопами и кофебрейками.

На осень мы выбрали такие темы: управление командой, бизнес-процессы, трансформационные изменения в людях и командах, коммуникация, работа над собой и личное развитие, развитие осознанности, инструментарий тимлида, работа с командой и новая культура в организации. Если у вас есть, что сказать по этому поводу, присылайте заявку на доклад. Как обычно, чем раньше это сделать, тем больше шансов попасть в программу конференции.
Подробнее..
Категории: Управление проектами , Разработка веб-сайтов , Управление персоналом , Карьера в it-индустрии , Hr , Управление командой , Джуниор , Управление людьми , Найм , Блог компании конференции олега бунина (онтико) , Мидл , Сеньор , Джуниоры , Джуны

Как я ходил на удалённые собеседования JAVA-разработчика, чтобы лучше нанимать людей

16.03.2021 10:10:28 | Автор: admin

Если обычные разработчики ходят на собеседования тренироваться и набирать опыт, то я пошёл выписывать все косяки. Чтобы их не было у меня, потому что я нанимаю людей. Собственно, стало интересно, как устроено в других компаниях и я пошёл собеседоваться. Началось всё c базового набора: аккаунт зума, почта, резюме. Дальше можно пройти за неделю 10-12 собеседований, на что до тотальной удалёнки ушёл бы месяц.


С резюме я захотел проверить гипотезу, что рынок слегка перегрет и теперь можно накидать что-то за три минуты и просто ждать отзывов. Я указал одно место работы и шесть скилов (даже без спринга, но никто этого не заметил).


image


Выложил на HH. Дальше ждать пришлось недолго. Первый час уже несколько откликов и звонок. Всего за сутки было 20 откликов и пять звонков. Предложений много, все с самыми интересными проектами, стеком, ДМС и макбуком (которого пока нет, но обязательно пришлём через месяц-два).


На третий день я набрал примерно 30 проектов, которые были бы мне интересны, если бы я действительно искал работу (пост бы неожиданно закончился здесь, если бы нашёл что-то более интересное, чем уже есть), и начал описывать то, что попало в отсев.


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


Первичный отсев


Что сразу попадало в отсев:


Когда HR пишет или говорит, что проекты классные, но не может сказать, чем они классные. Или хотя бы какие это проекты. Будет что-то там-то это не объяснение. Ещё одна интересная фраза команда 30 человек по скраму, но это не точно. Сразу в мусорник, нам не нужны неудачники.


Когда HR не может ответить на вопросы по существу. Например, какую технику дадите, нужно ли иногда в офис, чем именно я буду заниматься если HR уходил в себя и что-то изобретал, то сразу в мусорник, нам не нужны неудачники.


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


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


Организация


Интересное:


  • Ачивка Самая быстрая рука на Диком Западе 40 минут на собеседование, обратная связь я бы взял и оффер.
  • Ачивка Тяжело, как поцеловать кобру обещанный один этап превратился в два по два часа, потом я получил оффер.
  • HR-специалисты в большинстве своём сами адекватны. Девушек больше, чем парней, но до этого много лет назад парней я вообще не видел на первичных собеседованиях. Почти никто не путал Java и Javascript. Несколько раз делали технический скрининг. Мало кто пытался копаться в моём личном текущей зарплате, сколько у меня детей или домашних животных, чем я занимаюсь в свободное время и так далее. Иногда собирают информацию о текущих офферах. В целом очень положительное впечатление.
  • Во всех отобранных мной вариантах собеседования назначались оперативно, с учётом моих хотелок. На собеседование все пришли вовремя.

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


Проекты формата пошли пилить на нашем классном внутреннем творении я отклонял на самом первом этапе. Это может быть интересно, но редко и не всем.


Везде предлагали белое оформление и всё по ТК.


Что спрашивали


Я шёл с мыслью, что трава может быть действительно зеленее и на рынке прорыв, а я чего-то не знаю, но оказалось всё тривиально:


  • Java 8/11.
  • Spring.
  • Rabbit/Kafka.
  • Camunda.

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


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


Были задачи на алгоритмы, но редко.


По проектам могу сказать, что чаще всего это:


  • T&M.
  • Пресейлы.
  • Продуктовая разработка.
  • Архитектура.

Команды в проектах были от 5 до 30 человек с эджайлом в придачу.


  • Пять человек одна компания.
  • Пятьсемь три компании.
  • Продуктовые команды больше десяти человек десять компаний.
  • По-разному (от 5 до 30) остальные.

Проектный подход в примерно одинаковых долях:


  • Agile в разных вариациях.
  • Waterfall.
  • Всё подряд.

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


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


Результаты


Основными критериями для принятия решения я обозначил:


  • Задачи.
  • Деньги.
  • Стек.
  • Компания (бренд/польза для меня).

Дополнительно при прочих равных:


  • Скорость процесса.
  • Техника.
  • Соцпакет.

image

Выписывал результаты


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


Теперь деньги:


  • Редко, но было, меня пытались ужать по деньгам ещё на этапе HR (непонятно зачем) или давали ровно столько, сколько я попросил изначально.
  • В остальных случаях это +5-25 % к стартовой сумме. Иногда говорили про премию, однозначного ответа хорошо это или плохо нет, но могу отметить, что в случае хорошо работаем работу и наличии квартальных премий вполне можно хорошо заработать, больше чем в предложениях голый оклад, да и психологически приятно получать такую мотивацию время от времени.
  • Иногда говорили сразу про премий не будет, иногда была квартальная за выработку или по другому показателю, иногда годовая от личной эффективности и прибыли компании, иногда небольшие нерегулярные поощрения 1015 тысяч.
  • Ещё был интересный кейс если в проекте остались деньги. Тут я либо должен был поверить, что менеджмент у них просто звёзды, то ли с ходу смириться, что премий не будет.

Дальнейший рост зарплаты и позиции везде обещали. Где-то по формальным признакам, где-то с индивидуальными особенностями.


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


Собственно, после этого обновил свои вакансии и собеседую лучше. Как мне кажется. А вот здесь есть запись митапа, где я про это всё рассказывал вживую.

Подробнее..
Категории: Управление проектами , Карьера в it-индустрии , Hr , Собеседование , Вакансии , Блог компании крок , Найм , Процесс , Java-разработчик , Позиции

Найм Entry LevelJunior QA за и против

01.10.2020 20:16:38 | Автор: admin

Прямо сейчас в OTUS открыт набор на новый поток курса "QA Lead". В связи с этим Анастасия Шарикова - преподаватель курса поделилась с нами своей авторской статьёй. Передаём слово Анастасии:

Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.

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

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

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

Кого мы рассматриваем как начинающих? Это и Entry Level, то есть те, кто вообще не имеет коммерческого опыта, и Junior QA.

Плюсы

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

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

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

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

  • Мотивация и вовлеченность: вспоминаем про модель мотивации Хочу/Могу и понимаем, что большинство молодых специалистов (конечно, если мы не налажали при найме) относятся к категории хочу, но не могу и мотивированы на активное участие в работе и развитие просто потому что они смогли устроиться на работу.

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

  • Вы можете словить настоящий талант: и я совершенно серьезно. Среди сотни соискателей без опыта, которые прочитали Савина и/или закончили курсы встречаются, как я их называю, прирожденные QA, которые находят и документируют баги или пишут тест-кейсы лучше, чем многие специалисты с 3+ лет опыта. Хорошо составленное тестовое задание - наше все в этом случае. И если уж вы нашли такой неограненный алмаз, то при должном усилии вы сможете получить в скором времени преданного крутого сотрудника.

  • Лояльность: несмотря на то, что существует стандартное опасение, что "мол, мы вложим деньги и силы, а человек просто уйдет", можно провернуть и обратное - вырастить крайне лояльного сотрудника, который оценит, что вы ему помогли. Но, конечно, такое бывает не так часто, как хотелось бы.

  • Использование внешнего бекграунда: если вы разрабатываете,допустим, сервис для медицинских работников, то идеальным кандидатом для вас может оказаться не middle/senior, а entry level/junior, который решил поменять профессию, и ушел как раз из нужной вам сферы. Он или она смогут принести вам крайне актуальную экспертизу и взгляд того, кто был погружен в тему.

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

Минусы

И, конечно же, надо рассмотреть часто встречающиеся сложности, связанные с наймом Entry Level/Junior QA:

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

  • Контроль: если на опытного сотрудника довольно скоро после найма можно будет делегировать задачи и доверять самостоятельную работу, с новичками такое провернуть сложнее. Да и 1:1 и подобные встречи придется проводить чаще - стоит ли оно того?

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

  • Testing vs QA: если вам нужно просто протыкать регресс, то проблемы не будет, а вот если в задачи входит не только проверка по ТЗ, но и более глубокое понимание процессов, возможностей к улучшению на всех этапах и подобное, то мягко говоря не каждый начинающий специалист сможет помочь вам с таким. Даже если на курсах его учили основам QA, то опыт тут все равно будет играть важную роль. И уверенность в себе, кстати, тоже.

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

  • Завышенные ожидания: боль всех нанимателей (простите, дорогие джуны, если вы читаете этот текст) - если раньше новички были готовы работать за еду за небольшие деньги, то теперь каждый второй, кто закончил любые курсы сразу просит от 60 тысяч в Москве и от 100 через год опыта, даже если не умеет открывать DevTools и не знает, чем тест-кейс отличается от чеклиста. При этом всем, как ни парадоксально, все чаще заинтересованность начинающих QA в саморазвитии без наставничества сверху крайне низка, а требовательность к работодателю все растет и растет. И я, конечно же, не про базовые гигиенические факторы.

Что делать, если вы все же решились:

  • Разберите бардак на проекте: knowlege managment на базовом уровне полезен даже если у вас нет постоянного найма новых сотрудников, а уж когда надо вводить в курс дела новичков, то он вам точно пригодится. Ну и конечно же стоит наконец завязать с ТЗ по телефону, баг-репортами по переписке, тикетами на бумажках и прочими подобными практиками.

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

  • Признайтесь себе честно, насколько сложные у вас задачи: правда ли вам вообще нужны джуны? Может быть вам стоит попробовать выбить больше денег на ставку Middle QA, а не пытаться затыкать дыры теми, кто просто не справится?

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

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

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

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

Подробнее..
Категории: Управление персоналом , Тестирование it-систем , Карьера в it-индустрии , Блог компании otus. онлайн-образование , Найм , Qa lead , Junior qa , Персонал

Не нужно делать из фреймворков культ они не настолько сложны, чтобы делить людей на React и Angular разработчиков

06.10.2020 20:18:31 | Автор: admin


Недавно меня позвали гостем в Тяжелое утро с Holy.js, чтобы хорошенько пропесочить за мою статью про глупцов-фронтендеров. Мы обстоятельно поговорили, и один из аргументов был такой если наши js фреймворки жрут неоправданно много на простых задачах просто не используй их. Если тебе просто надо порендерить четыре формы, то тебе не нужен ни реакт, ни тайпскрипт, ни вебпак ничего. Создаешь три файлика .html, .css и .js вот тебе и приложение.

Ничего не надо никуда билдить, никакого стат анализа, и никакой прожорливой и тормозной ноды на твоей машине все быстро и просто. Так можно строить и достаточно большие приложения ведь тот же vs code вполне себе может тайпчекать твой js. Другие проблемы, которые можно решать большими фронтенд инструментами во-первых часто выдуманы их создателями, а во вторых если и создают большую боль то только на действительно больших приложениях.

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

Понятно, что когда ты работал архитектором или руководителем разработки в крутой и известной компании, тебя никто не развернет за незнание редакса. Но я говорю о случае, когда ты условный мидл в условном Томске. Вы можете открыть любой сайт с вакансиями в рф, вбить frontend, указать зп от 150к, и увидеть практически каждая из них требует Отличные практические знания React стека ( Redux, Saga, Reselect, Styled Components ). Наполнение может отличаться у них много фреймворков, которые делают одно и то же. Лучшие компании предлагают не обязательно знать именно их фреймворк достаточно пяти лет опыта работы с парочкой точно таких же.

Это фронтендеры. В C# или Java стеке все ещё хуже у нас есть один основной фреймворк, и все по дефолту считают, что ты его досконально знаешь последнюю версию, и, конечно, ту которая используется именно у них. Они думают, что ты обязан его знать и проверяют это на собеседовании. Хорошо проверяют.

На первый взгляд ну и правильно делают. Ведь ты же придешь такой, склонишь репу, и тебе скажут бахни контроллер. В нашем asp.net core проекте. Чтобы бахнуть надо плюс-минус знать как работает именно asp.net core.

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

Вот есть у нас бекендовая вакансия. Хотят asp.net core, хорошее знание C#, какой-нибудь mssql, и ещё всякой хренотни по мелочи. И есть абстрактный чел, который зачем-то на неё поперся, хотя ни аспнета, ни мускуля он не знает. И тут всего три варианта. Он может быть обманщиком и самозванцем и тогда его надо гнать ссаными тряпками. Может быть большим идиотом ему придётся это объяснить. А ещё он может решить, что вполне себе справится с этим стеком например потому что базы юзал другие, а бек делал на джаве.

Понимаете, человек делал бекенд сложная штука, целая сфера, глубокое понимание которой ключевой скилл для такой позиции. Я понимаю, когда тебя не готовы взять на другой ЯП они тоже очень сложные. Но, Господь Всемогущий, кто-то действительно верит, что asp.net webApi прям так критично отличается от asp.net core? Или в то, что человек, которые пять гребаных лет строил гигантские приложения на условном спринге придет к вам, и такой ну неее, это слишком сложно. Я не могу понять такую сложную систему, ведь там аж три другие невыносимо сложные концепции! База данных совершенно другая. Совсем не такая, как те четыре других, которые я всю жизнь изучал в ней четыре с половиной синтаксических конструкции пишутся по другому.

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

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

Дело в краткосрочной перспективе. Финансовой. Если нанять парня, который знает только чистый js на проект с реактом, он будет плохо перформить пару недель. А потом ещё два месяца время от времени совершать детские ошибки. Если при этом проект ещё и очень сложный эти сроки увеличатся кратно. Поэтому логично делать так брать людей, которые отлично знают именно ваши технологии. Чем быстрее боец зафигачит первого врага, тем лучше.

Вот только есть одна маааленькая проблема.

Знание конкретно ваших инструментов это один из тысяч параметров разработчика. И один из самых неважных.



Если брать двух абсолютно одинаковых разрабов, один из которых знает ваш фреймворк, а второй знает не ваш надо брать первого. Но таких ситуаций не существует. У вас есть два разраба, у одного из которых пять лет опыта, у другого четыре. У одного C#, а у второго C#, Java и OCaml. У одного свой опенсорс проект с тысячей пользователей, а второй очень глубоко знает алгоритмы и структуры данных. Один экстраверт, второй интроверт.

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

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

И это главная причина вакансий в духе React+Redux software developer. Экономия денег на старте это отговорка, чтобы не признаваться себе: мы не умеем собеседовать.



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

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

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

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

Вы вот все жалуетесь, что я прихожу на хабр ныть. Но пока вакансии React Developer не превратятся в Software developer, моё нытье это именно то, что нам нужно.


На правах рекламы


VDSina предлагает мощные и недорогие VPS с посуточной оплатой. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Управление разработкой , Блог компании vdsina.ru — хостинг серверов , Найм

Почему не работают реферальные программы найма в IT?

22.10.2020 10:15:06 | Автор: admin
Почти все IT-компании рано или поздно сталкиваются с недостаточным количеством кандидатов при найме. И рано или поздно это приводит в мысли попробовать замутить реферальную программу, типа приведи друга и получи бонус. На деле условия оказываются значительно более сложными и друзей почему-то не особо приводят. Устроить рефералку пробовали почти все, а нанять через такой канал получалось у единиц. В этой статье я делюсь своим мнением почему рефералки в найме обычно не работают и предлагаю свой протестированный способ, как сделать этот канал работающим.


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


Типичное реферальное предложение выглядит так направьте к нам кандидата, релевантного нашей вакансии, и мы выплатим вам бонус, после того как наймем его. Если кандидат не подойдет, то мы вам ничего не должны. Иногда есть дополнительное условие бонус будет выплачен после того, как нанятый по рекомендации сотрудник пройдет испытательный срок.
Условия похожи на типичные условия договора с кадровыми агентствами с некоторыми отличиями:
1. Кандидатов могут присылать неограниченное количество агентов, договор не эксклюзивный, а по-сути оферта.
2. Сумма вознаграждения обычно существенно меньше, чем типичный гонорар агентства.
3. Отсутствуют какие-либо авансы.
С точки зрения работодателя, схема кажется гениальной, сплошные выгоды!
Беда только в том, что в отличие от привлечения кадрового агентства, данная схема редко дает результат.

Почему такая реферальная схема обычно не работает?


Я считаю, что основные причины следующие:
1. Привлекается внимание незаинтересованных агентов. Обычно предложение размещается на сайте компании, на страницах компании в соцсетях. Предложение видят люди, которые и так уже порекомендовали компанию кому могли или принципиально не хотят рекомендовать вашу компанию. Если компания рекламирует свое предложение и платит за рекламу, то это уже отдельная рекламная деятельность, которая стоит дополнительных усилий, расходов и нужно уметь это делать.
2. Возможные агенты, на которых ориентировано реферальное предложение, часто не являются специалистами в подборе, способными полноценно понять вакансию, грамотно привлечь внимание кандидатов и оценить их навыки. Соответственно, они предлагают вакансию не тем кандидатам, быстро устают от неудач и бросают эту непродуктивную деятельность.
3. Сама награда бонус после найма или даже после испытательного срока слишком далекая, нечеткая и обосновано кажется маловероятной. Слишком много рисков и обстоятельств, на который агент не может повлиять. Слишко много сомнений и страхов. Выберут ли моего кандидата, если также будет другой, немного похуже, но за него не нужно будет платить бонус? Получу ли я бонус, если моему кандидату сейчас будут долго морочить голову, а потом наймут его через полгода-год? Можно ли верить обещаниям этой компании, ведь мы не заключали договор? И так далее. Все это существенно снижает мотивацию потенциальных агентов к поиску кандидатов. Кадровые агентства страхуют эти риски для себя, поэтому могут себе позволить работать в подобных условиях и отчасти поэтому их услуги и стоят недешево.

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

Как можно улучшить практику реферальных предложений в найме?


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

Итак, вот основные черты моей реферальной схемы.

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

Во-вторых, бонус нужно разбить на части и платить за промежуточные результаты. Предположим, вы готовы заплатить 50 т.р. за найм подходящего специалиста. По-моему, стоит разбить эту сумму на такие части:
бонус в 2 тысячи рублей выплачивается агенту по факту состоявшегося собеседования с кандидатом независимо от результата понравился вам кандидат или нет;
бонус в 10-20 тысяч рублей выплачивается в случае успешного найма кандидата;
еще один бонус (если останется бюджет) в 10 тысяч рублей выплачивается после прохождения кандидатом испытательного срока.
Бонус после прохождения испытательного срока имеет мало смысла, так как ваши отношения с кандидатом вообще никак не зависят от агента, но все же одна причина приходит мне в голову. Часто новая работа является стрессом и недавно нанятый сотрудник может захотеть уволиться на испытательном сроке. Агент, предоставивший кандидата и ожидающий дополнительный бонус, если он хороший знакомый кандидата, может помочь вам и уговорить вашего нового сотрудника не принимать поспешных решений.

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

Критика моего способа и мои ответные возражения


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

1. Кандидат может договориться с приятелем и ходить по собеседованиям, при том, что наниматься он не готов, а мы за это все заплатим и потратим свое время.


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

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


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

3. А что если наш HR станет передавать найденных кандидатов через своих друзей, чтобы получать бонусы?


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

4. Идея реферальной программы нам нравится, но мы не хотим платить за процесс, нам нужен результат.


Реферальная система применяется, чтобы нанимать, а не чтобы экономить. Какая радость от экономии, если при этом никого не нанял? Конечно, вы можете оставить все как есть и надеяться, что вам повезет. Никто не может вам запретить так поступать кроме вашего начальника или собственников бизнеса.
Я часто вспоминаю цитату Альберта Эйнштейна: Самая большая глупость это продолжать делать то же самое и надеяться на другой результат.
Это означает, что если вы хотите нанимать, а не ждать чуда, то нужно что-то менять, пробовать делать по-другому. И самое простое, что можно сделать, это дать рекламу своей рефералки в профильных HR-сообществах. Возможно, что у кого-то там уже есть подходящий вам кандидат.

Спасибо, что прочли до конца. Приглашаю яростно комментировать прочитанное!
Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Читальный зал , Найм , Реферальная программа

Почему мы не берём на работу новичков или 5 мифов обучающих платформ

01.12.2020 14:07:50 | Автор: admin

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

  1. Нельзя верить в то, что пишут крупные обучающие площадки. Цитата с крупных площадок, обучающих разрабов: "всего за 3 месяца вы получите возможность работать в ИТ с базовым доходом от 100 т.р.". Я работаю в Москве и джуны, приходящие в компании с этих курсов часто столько и просят, такие суммы для новичков вызывают у меня улыбку.Но обучающая площадка и менторы (для меня стало новостью, что зачастую менторами становятся вчерашние ученики этой же площадки) кричат о том, что джуны получают от 100 т.р.


    Давайте разберёмся на пальцах: 100 000 рублей в месяц - это приблизительно 600 рублей в час на начинающего разработчика. Пока звучит неплохо, но давайте копнём дальше. На каждого джуна по опыту старший разработчик (с условной зарплатой в 250 000 рублей, и стоимостью часа 1500 рублей) тратит от 1 до 4 часов в день, в зависимости от расторопности джуна. Несложные вычисления приводят нас к тому, что в среднем в месяц старший разработчик тратит 40 часов на обучение джуна, что удорожает джуна уже до 160 000 рублей в месяц, а стоимость его часа делает равной 950 рублям. Но и это ещё не всё, ведь есть ещё тимлид (с условной зарплатой 300 000 рублей и стоимостью часа 1800 рублей), который в среднем тратит на джуна по 1-2 часа в неделю, что в месяц превращается примерно в 8 часов. По итогу получаем, что стоимость джуна для компании становится 174 400 рублей, а стоимость часа его работы приближается к отметке 1050 рублей. И тут мы понимаем, что за такую стоимость мы можем поискать уже даже не мидла, а мидла+.


    Кстати, очень хорошо определить адекватность соискателя помогает вопрос "Сколько бы вы хотели получать через год?". И если соискатель отвечает о повышении в пределах 20-30%, то он понимает базовые принципы и может здраво оценивать ситуацию. Самый интересный ответ был "через год я планирую получать 250 000 рублей" (при заявленных зарплатных ожиданиях в 80 тысяч рублей). Амбиции - это круто, но нужно здраво оценивать свои возможности и возможности рынка, рынок не готов дать через год джун+ или мидлу зарплату в 3 раза больше. Как говорит наш тимлид "Это так не работает".

  2. "Я хочу работать на современных технологиях, а все эти ваши основы программирования для динозавров" - это реальное высказывание соискателя на должность фронетнд разработчика после того как ему задали вопрос по базовым знаниям javascript. И это опять же проблема "волшебных курсов", которые не заостряясь на основах, переходят на супер-пупер современные пердящие и смердящие фреймворки. Фреймворки облегчают жизнь разраба, но никак не заменяют базовых знаний. К тому же, даже в крупных и современных банках есть большаячасть легаси кода, которую придётся как минимум поддерживать, а как максимум рефакторить и переносить на "новые рельсы", но не зная основ нельзя просто так взять и понять что написано в коде.


    Лично для меня вопросы по основам дают представление о том с чего начинал соискатель и как хорошо всё у него разложено по полочкам в голове. Я не сторонник вопросов "а что делает вот именно эта функция", но могу спросить "а как бы вы решили вот эту задачу". Если соискатель двинется в правильном логическом направлении - мне будет этого достаточно.

  3. "Я не хочу заниматься рутиной, я хочу работать только над интересными задачами" - очередная цитата с интервью. И всё в ней прекрасно кроме того, что сказана она не матёрым сеньором и даже не закоренелым мидлом, а джуном только что окончившим курсы фронтенд-разработчика. Круто, друг/подруга, но извини, придётся для опыта поверстать лэндосы и сайты, никто не будет ждать пока ты напишешь супер сложный функционал за год. Так или иначе - мы делаем бизнес задачи и иногда они откровенно скучные, а иногда очень даже сложные. Я видел немало нервных срывов у сеньоров, когда работал в околобанковской сфере, из-за того, что они не могли вытянуть нагрузку. Для джуна такой подход может не только убить психику, но и отбить всякое желание кодить.

  4. "Главное устроиться на работу и неважно какие технологии вы там используете". Если вы уверенный мидл или даже сеньор, то такое высказывание не вызовет никаких подозрений, но если вы джун, то в ушах работодателя это звучит как "я ничего не умею и вам придётся меня учить", опять же возвращаемся к расчёту из пункта 1, только умножаем всё на 2, а то и на 3.


    И самое печальное для джуна, который всё-таки устроится в компанию с незнанием "местного" стека - он не сможет сделать в срок. Нет, тимлид и сеньоры не изверги, они не будут говорить с первого дня "ты должен/должна сверстать сайт из 20 страниц за 3 дня", вам скорее всего смогут дать столько времени сколько вы попросите, даже обсудят с вами план и пошагово всю работу над проектом. А ещё оценят задачу в часах "под себя" умножат время на 4 или даже 8 и начнут ждать. Дальше начнётся процесс, который я называю "воронка незнания":


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

    Почему вас увольняют? Да всё элементарно, "это бизнес, ничего личного". Из пункта 1 помним, что час вашей работы стоит 600 рублей. Вам дают задачу на 10 ваших часов. В первую итерацию вы тратите их целиком, во вторую + 5 часов и допустим в третью ещё 3 часа. Итого потрачено 18 часов, то есть задача из 6000 за разработку превратилась для работодателя в 10800 рублей. Дальше, думаю, объяснять не надо.

  5. И последнее, самое сладкое "а какой у вас соцпакет? Ой, у вас ДМС только через 6 месяцев и кофе в кофемашине не самый вкусный, значит я тут работать не смогу". На моей памяти сразу всплыла история из одной очень экологичной компании. Мы тогда искали сильного IOS-разработчика, сроки горели, поэтому бюджет был ограничен только суммой в резюме соискателей. К слову отбор был в несколько этапов: телефонное интервью с hr, очное техническое интервью, тестирование на математические и логические способности (до сих пор не понимаю зачем им это) и наконец проверка службы безопасности. От первого звонка до оффера легко могло пройти от 2-х недель до полутора месяцев. В этом случае всё длилось 2,5 недели. И вот он, наш идеальный кандидат, заходит в наш отдельный кабинет, без окон, садиться за рабочее место и спрашивает "Простите, извините, а где у вас тут кофемашина?". А мы честно отвечаем "Сорри, кофемашины нет". Наступает обед, новый сотрудник выходит за дверь, заходит в отдел кадров, забирает трудовую, отключает телефон и после этого мы его уже не видели.


    Так вот я это к чему, не стоит искать компании ради "плюшек". Я поработал в огромных компаниях с громадным соцпакетом и количеством приятных бонусов превосходящем даже разумные пределы, но новичкам там делать нечего, поскольку там поток. И в этом потоке никто из матёрых программистов не будет вас учить, так как у этих матёрых программистов количество задач такое, что на вас останется пол часа в неделю. Но, с другой стороны, возвращаясь к пункту 1 зарплату в 100 000 рублей вам там смогут дать, вот только не факт, что вы получите опыт, да и скорее всего за эти 100 000 рублей даже там от вас будут ожидать уровень джун+, а не совсем новичка.

Итого: для того чтобы устроиться джуном на работу, получить положительный опыт и спокойно влиться в коллектив нужно обладать всего 3-мя качествами:


1. Адекватность
2. Адекватность
3. Адекватность

Подробнее..
Категории: Управление персоналом , Управление разработкой , Junior , Обучение , Найм

Перевод Как НЕ надо нанимать разработчика софта

07.04.2021 04:04:38 | Автор: admin
image

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

Еще в 2013 году я провел очень успешную компанию по найму на AboutEcho.com, которая привела к найму девяти инженеров высшего звена. Мои русскоязычные читатели могли прочитать об этом здесь.

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

Не стремитесь к лучшему решению


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

Это можно понять в конце концов, у них есть только 45 минут, и они хотят обсудить с вами много вещей.

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

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

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

Не задавайте головоломок


Как проверить, есть ли в связанном списке цикл? Помещается ли одна N-мерная коробка в другую N-мерную коробку? Можете ли вы поменять местами две переменные без третьей? Как найти кратчайшее расстояние между двумя движущимися кораблями? Найти все перестановки из N элементов, выполнив только N-1 перестановок?

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

Однако какими бы забавными они ни были, это всего лишь анекдоты. Свойство головоломки в том, что вы либо знаете ответ на нее, либо нет. Больше это вам ни о чем не говорит. Это не имеет ничего общего с будущими показателями, умением, способностями или чем-то еще. Знание конкретного ответа не означает, что у вас есть аппарат для решения реальных проблем общим и предсказуемым образом. Единственное, о чем это вам говорит, это то, что человек был в этой ситуации и кто-то поделился с ним решением. Ни больше ни меньше. Просто остановитесь уже.

image

Как спаситись, до того как свеча пережгет веревку?

Будьте открыты для альтернатив


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

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

Никто не знает всего. Будьте открыты. Слушать. Размышляйте. Да, даже если вы интервьюируете кого-то.

Будьте терпимы к недостаткам


Единичные ошибки широко признаны одной из самых сложных проблем в CS не зря их делают все. Ошибки это часть жизни программиста, а не то, от чего можно избавиться. Хороший программист просто знает, что с этим делать. Качество программиста НЕ определяется тем, насколько мало ошибок он делает.

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

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

  • простой код,
  • разделяй и властвуй,
  • самопроверки,
  • инварианты,
  • утверждение,
  • компиляция и запуск,
  • тестирование.


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

Позвольте мне проверить!


Серьезно, а что такое написание программы на маркерной доске?

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

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

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

image

Изучайте глубже


Пять коротких интервью? Или два длинных?

С пятью вы получите пять независимых мнений, что лучше, чем два. Но насколько глубоко вы можете погрузиться за 45 минут? Практика показывает, что достаточно написать 20-30 строк кода и задать пару действительно простых вопросов (в чем сложность? Как тестировать?).

Следующий интервьюер просто повторяет тот же процесс, доходя до предыдущего. Что недолго. Совсем недолго.

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

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

А если хотите больше мнений? Посадите в комнату несколько интервьюеров, чтобы они потом спорили.

Изучите предысторию


У меня четырнадцать лет опыта (на момнт написания статьи, 2019). Я был бы счастлив поговорить о функциональном программировании, распределенных системах, консенсусе, репликации, совместном редактировании текста, CRDT, параллельных архитектурах, фреймворках пользовательского интерфейса, командных процессах, дизайне продукта, пользовательском опыте. У меня есть практический и исследовательский опыт во всех этих областях. Все они представляют прямой интерес для более или менее любых интернет-гигантов, у которых я брал интервью.

Меня когда-нибудь спрашивали об этом? Нет.

Я получаю: Представьте, что у вас есть функция, которая принимает список пять раз подряд. Пять задач школьного уровня должны дать вам адекватное представление, о чем? Насколько внимательно я читал Кормена и др.? Честно говоря, о них тоже редко спрашивают.

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

Сделайте процесс плавным


Неправильное направление? Задержанные билеты? Анкета, требующая установки оригинального Adobe Reader специально? Дешевый ультрабук с незнакомой раскладкой клавиатуры и плохим веб-редактором без каких-либо ярлыков, который тормозит даже на локальной машине? Извините, я нахожусь в офисе самой способной IT-компании в мире, не так ли?

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

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

Да, я считаю, что любой может добиться большего.

image

В заключение


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

Хорошего найма!
Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Блог компании нпп итэлма , Собеседование , Найм

Как нанять QA вредные советы

13.04.2021 14:10:30 | Автор: admin

Привет, хабровчане. Подготовили для вас занимательную статью авторства Анастасии Шариковой.

Также приглашаем будущих студентов курса "QA Lead" и всех желающих посетить открытый демо-урок Оценка эффективности тестовой стратегии с помощью тестового покрытия.

На этом вебинаре рассмотрим:

- Оценка эффективности работ по тестированию
- Что такое тестовое покрытие?
- Создание дерева требований
- Структурные методы построения тестовой модели
- Как достигать хорошего покрытия
- Зачем нужны метрики тестового покрытия
Присоединяйтесь!

Всем привет! Меня зовут Анастасия Шарикова, я Technical Project Lead в Bookmate и веду телеграм канал Yet another QA.

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

  • Никто не откликается на вакансию

  • Отклики есть, но почему-то не от тех, кого хотелось бы

  • Никто не может пройти собеседование с HR/Техническое/Любое другое

  • Те, кто получают оффер, его не принимают и не говорят причины

  • На рынке мало экспертов по нужному направлению

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

Что же делать? Конечно, вариантов много, как и статей, где дается миллион советов о том, как нужно делать правильно, например, такие:

  • Будьте лучшими в своей сфере!

  • Расширяйте сетку поиска!

  • Напишите крутое описание вакансии!

И прочие, прочие общие рекомендации. Так что сегодня я решила пойти по другому пути дать вам настоящие советы, которые помогут вам понять, что что-то вы делаете не так. Или расскажут о том, как не надо делать в будущем :)

Подготовка к найму

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

  • Составление профиля должности лишняя трата времени.

  • Нанимаете первого QA в компанию? Что ж, звучит довольно просто, так что можно не консультироваться со специалистом этого профиля, ведь все и так знают, что тестить может любой.

  • Совет для молодых стартапов берите первым тестировщиком Junior QA, лучше сразу после курсов его голова пока не забита ненужными знаниями и он отлично сможет выстроить процессы с нуля.

Вакансия

  • Чем более творческой будет вакансия тем лучше! Ведь что может быть лучше вирального классного текста без конкретных подробностей с ним охват намного выше, так как каждый захочет именно к вам!

  • Конечно же, мы понимаем, что QA без высшего технического профильного образования нонсенс. А как вы себе представляете прохождение ручных регрессов для приложения со списком задач без магистратуры? Так что обязательно пропишите это в требованиях. И не забудьте упомянуть, что выпускники курсов могут вам не писать пусть кто их учил, тот их и нанимает.

  • Название вакансии дело требующее серьезного подхода, да и путаницы не хотелось бы так что будьте проще, так и пишите Тестер или Q&A профессионалы сразу поймут, о чем речь.

  • Не стоит писать подробно о продукте, с которым будущий сотрудник будет иметь дело ведь в вакансии есть название компании, а умение гуглить важный скилл любого QA.

  • Любой, кто составлял текст вакансии, знает, что очень важно написать о рабочих обязанностях, которые надо будет исполнять. Что же написать в случае поиска того, кто будет заниматься качеством? Например, стоит указать что надо будет тестировать продукт, чинить баги, контролировать релизы, составлять отчеты.

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

  • В наше время все больше становится актуальной тема T-shape развития, и для сферы QA это тоже актуально. Так что Senior+ специалисты особенно ценят вакансии, где нужно проводить ручное тестирование, и автоматизированное, и заниматься DevOps циклом, но большее время, конечно, отдавать найму, обучению, менеджменту и консалтингу.

  • Ищите специалистов с как можно бОльшим опытом, и желательно, конечно, мужчин около 25-30 лет. Это лучший выбор, и лучше написать об этом сразу в вакансии, чтобы все поняли серьезность ваших намерений.

Собеседования

  • Основа основ, которую стоит проговорить собеседование, даже первое с HR обязательно должно быть очным. Иначе как вы покажете свой прекрасный офис?

  • Чем больше будет этапов собеседования тем лучше. Это позволит вам выяснить все аспекты профессиональных качеств претендента, к тому же именно многоступенчатое собеседование сейчас в тренде, благодаря таким компаниям, как Яндекс.

  • Чем больше будет человек на собеседовании тем лучше. Это позволит вам понять человека лучше, да и легко совместить со стресс-собеседованием. А вот QA специалиста можно и не звать достаточно получить от него или нее заранее подготовленный список вопросов.

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

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

Организационные процессы

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

  • Нота расслабленности отлично настроит получателя сообщения на правильный лад обратитесь в сообщении к нему или к ней с прикольного обращения или вообще использовав другое имя это сразу обратит внимание на именно вас.

  • Пишите даже тем, кто занимается другим направлением в профессии может быть именно этот лид давно хотел уйти в джуниора-автоматизатора на паскале, и вы найдете друг друга.

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

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

Подведем итоги

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

Узнать подробнее о курсе "QA Lead"

Подробнее..
Категории: Управление персоналом , Тестирование , Найм , Qa lead , Блог компании otus

Как я перестал превращать собес в экзамен оцениваем хард- и софт-скиллы за одно собеседование

19.04.2021 06:22:01 | Автор: admin

На волне последних обсуждений темы собеседований, хочу задать аудитории Хабра вопрос: вы помните, как писали в резюме: "коммуникабельный, инициативный, быстро обучаюсь"?

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

Итак, меня зовут Алексей, я QA Lead одной из команд в Plesk. Хочу поговорить о том, как увеличить пользу от технического собеседования, или что означают софт скиллы, и как они проявляют себя в реальной жизни.

Добро пожаловать под кат.

  1. Про типовой технический собес

  2. А какие есть скрытые резервы в техническом собесе?

  3. А вдруг можно ещё лучше?

  4. Модель STAR(AR)

  5. Что все это дает нам на практике?

Про типовой технический собес

Давайте начнем с того, для чего вообще нужно техническое собеседование.

Самая распространенная версия для оценки технических навыков. И с этим сразу же начинаются проблемы. Если вы ищете не совсем начинающего джуна, то требуемый объем знаний и опыта практически невозможно полноценно оценить за час-полтора. Но как-то это сделать нужно, поэтому собеседование превращается в некоторое подобие экзамена с быстрыми короткими вопросами-ответами. Думаю, мало кому в принципе нравилось сдавать экзамены, а если ещё и экзаменатор вдруг решит на тебе отыграться за невкусный утренний кофе?

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

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

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

С одной стороны, вы скорее всего увидите агрессивного и необщительного человека с нервным тиком; с другой стороны, вас будут считать садистом-маньяком с манией величия. Психотерапевты, прием которых включен в программу медицинского страхования, на этом моменте радостно потирают руки.

Типичное собеседование в компанию "Х"Типичное собеседование в компанию "Х"

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

  • в меру весел,

  • морально неустойчив,

  • есть задел на лидерские качества,

  • при должном стимулировании обучаем,

  • зубы целые,

  • взгляд загадочен.

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

Думаю, основную идею вы уловили собеседование в виде экзамена не помогает ни компании, ни кандидату.

А какие есть скрытые резервы в техническом собесе?

Допустим, вы ищете инженера с опытом администрирования Linux, и вам будет достаточно следующих умений:

  • работать в консоли (команды навигации, работа с файлами);

  • уметь обращаться с логами;

  • менять настройки стандартных системных сервисов.

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

  1. Про стандартные консольные команды навигации и работы с файлами (cd, mkdir, cp, mv . плюс дежурная шутка про то, как выйти из vi);

  2. Про то, где находятся логи разных сервисов (syslog, error_log/error.log .);

  3. Про то, где находятся файлы конфигураций разных сервисов (httpd.conf/apache2.conf, php.ini, my.cnf и т.д.).

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

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

Пользователи вашего проекта на PHP жалуются, что не могут загрузить файлик размера больше двух мегабайт. Расскажите пошагово, как будете исследовать проблему и чинить её?

В ответ есть вероятность услышать что-то вроде:

Включу нужные опции в секции Error handling and logging файла конфига php.ini, там же посмотрю опцию error_log, чтобы найти, где хранятся логи.

В логе найду ошибку о том, что The uploaded file exceeds the upload_max_filesize directive in php.ini, после чего поправлю соответствующую опцию в php.ini, задав нужный разумный предел.

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

Казалось бы, это то, что надо! Но

А вдруг можно ещё лучше?

Давайте зададим кандидату вопрос в следующем ключе:

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

Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?

Пофантазируем, какой рассказ мы могли бы получить в ответ.

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

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

Решение: Путем курения логов наш кандидат выяснил, что виноват не формат файла, а его размер. Поразбирался в настройках php.ini и пришел к решению установить директивы upload_max_filesize = 20M и post_max_size = 20M. Это решило проблему. Поправленные настройки кандидат добавил в инструкции по деплою и настройке продакшн сервера.

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

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

Это ли не чудо?

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

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

Хотите ли вы, чтобы человек с таким набором знаний, умений и качеств работал с вами в команде?

А теперь давайте разберем, как мы это добились.

Модель STAR(AR)

Напомню, вопрос кандидату звучал как:

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

Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?

Для вопроса мы использовали модель STAR(AR). Эта модель состоит из четырех (либо пяти) важных составляющих:

  • Situation (ситуация).

  • Task (задача).

  • Actions (действия).

  • Results (результаты).

  • Alternative Results (альтернативные результаты).

Схема позволяет как задать четкий вопрос, так и предлагает структуру, которая помогает кандидату дать ответ по существу.

Но и это ещё не все! Незаметные глазу нюансы вопрос, обращенный к реальному опыту с большей вероятностью покажет, как кандидат привык действовать в реальной жизни. А это как раз то, с чем вы столкнетесь, когда (и если) он перейдет из категории кандидат в категорию коллега.

Дополнительный приятный бонус скрывается в пункте Alternative Results. Вопрос как бы вы поступили в такой же ситуации сейчас? может показать, чему кандидат научился с тех пор, как рассказанная ситуация случилась в его жизни. А это уже намекнет вам на способность переосмысливать свой опыт, учиться и делать выводы, даже если изначальное решение было неоптимальным, а то и вовсе неправильным.

Давайте представим, как наш кандидат мог бы ответить на этот вопрос, пусть это будет:

Сейчас я бы установил директиву post_max_size = 60M, т.к. сама форма загрузки позволяла загружать до 3 файлов одновременно.

Готово, вы восхитительны! Похоже, что наш кандидат нам подходит.

Что все это дает нам на практике?

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

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

Бонусный уровень

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

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

А как вы оцениваете софт скиллы? Какие техники или методы используете для этого?

Подробнее..
Категории: Управление персоналом , Блог компании plesk , Собеседование , Найм , Star , Star(ar)

Перевод Аарон Шварц Как я нанимаю программистов

31.05.2021 16:13:25 | Автор: admin
imageОб Авторе: Аарон Шварц американский интернет-активист, программист, писатель, хактивист. Умер за свободу информации.

  • В 12 лет создал сайт Info, где каждый мог писать о том, что знает (а другие могли дополнять и комментировать). Это был предвестник Википедии.
  • В 14 лет Шварц стал соавтором спецификации RSS 1.0.
  • Аарон Шварц работал под руководством Тима Бернерса-Ли в составе основной рабочей группы RDF в Консорциуме W3C.
  • Попал на первую программу в Y Combinator со стартапом Infogami, который впоследствии слился с популярным сайтом Reddit.
  • Работал над Open Library и Creative Commons
  • Внес существенный вклад в Markdown.

Пост 2009 года
Когда вы нанимаете программиста (да и вообще кого-либо, если уж на то пошло), перед вами стоят три вопроса. Умный ли он? Способен ли выполнить то, что нужно? Сможете ли вы с ним работать? Тот, кто умён, но неспособен выполнить задание, может быть вашим другом, но не работником. Вы можете обсуждать с ним свои проблемы, тогда как он будет тянуть с выполнением важной работы. Тот, кто способен выполнять задания, но неумён тот неэффективен: неумные люди выполняют работу трудоёмким способом, работа с ними продвигается медленно и полна разочарований. Ну а с тем, с кем вы не можете работать, вы просто не сможете работать.

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

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

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

Но если бы пришлось записать признаки того, почему некто кажется мне умным, я бы сделал акцент на трёх моментах. Во-первых, насколько глубоки его познания? Спросите, о чём он думал в последнее время, и прощупайте его на эту тему. Похоже ли на то, что у него есть детальное понимание предмета? Может ли он понятно объяснить его? (Понятные объяснения признак подлинного понимания.) Знает ли он о предмете то, чего не знаете вы?

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

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

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

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

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

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

Перевод: Вебпланета
Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Найм

Из песочницы Хакатоны можно использовать для найма опыт организатора 35 хакатонов

28.06.2020 22:13:05 | Автор: admin

Если вы задаетесь вопросом, возможно ли использовать хакатоны как инструмент для найма сотрудников, то предлагаем вам уделить 15 минут времени на прочтение этой статьи.


Мы опросили более 400 участников хакатонов, чтобы разобраться в этой теме.


image


Исследование проводилось сразу по двум причинам.


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


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


Есть мнение, что использовать хакатоны для найма попросту неэффективно. Проведя 35 хакатонов, мы поняли: дело не в том, что хакатон плохой иснтрумент, а в том, что им не умеют пользоваться. Часто компании не знают, как именно подсветить свои преимущества, чтобы заинтересовать хакеров.


Это исследование помогло нам сформулировать рекомендации для компаний, которые можно применить на практике.


Мы провели опрос в два этапа:


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

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


В хакатонах участвуют только Junior-разработчики?


Нет, это не так.


По опыту работы хакеры распределились следующим образом:


image


Проанализировав данные с наших хакатонов, удалось оценить примерное распределение по ролям внутри команд-участников:


image


Самыми популярными стэками среди хакеров оказались:


  • Front-end: React, JavaScript, HTML;
  • Back-end: Python, C++, C#, Node.js;
  • Fullstack: Python, HTML, Javascript;
  • Data Science: Python.

Хотят ли хакеры получать офферы после хакатона?


Да, хотят.


image


На вопрос Хотели бы вы получать офферы после хакатона? около половины участников ответили положительно даже при том, что они уже работают. Объяснить это можно желанием оценить себя и понять, как их зарплата соотносится с рыночной.


image


Несмотря на то, что оффер не является самоцелью участия в хакатоне, около 70%(!) малоопытных хакеров хотели бы его получить после ивента.


Что касается более опытных коллег, процент желающих ниже, но все равно он больше 50%.


image


image


Получается, что после хакатона можно не только пригласить на стажировку или нанять хакеров уровня Junior, но и более опытных специалистов.


Как часто хакеры получают офферы после хакатонов?


Выше мы разобрались, что больше половины хакеров хотят получить оффер. Однако всего с 20% участников связываются представители компании для дальнейшего трудоустройства. Здесь мы видим точку роста.


Что же происходит на следующих этапах?


image


Как показало интервью, порядка 4% участников трудоустроились после хакатона. Мало? Мы тоже так думаем и спросили остальных участников, какие проблемы возникают при общении с компаниями.


По их мнению, основные причины несостоявшегося найма следующие:


  • технические специалисты заинтересованы в найме, HR нет;
  • не подошел компании по компетенциям;
  • собеседование прошло напряжно.

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


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


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


На что хакеры обращают внимание при выборе компании?


Топ-4 ответов оказались такими:


image


По ходу интервью мы выяснили, что побудить участников сменить работу может более интересная задача на новом месте. Такой же ответ мы получали и при уточнении, почему участники выбирают тот или иной хакатон. Что же это за интересная задача?


Для хакеров интересная задача это задача:


  • с минимумом рутины и местом для креатива;
  • которую непонятно, как поначалу решать;
  • в ходе решения которой изучаешь новые технологии.

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


Как небольшая компания может конкурировать с IT-гигантом по найму?


Этот вопрос мы и задали хакерам. Топ ответов получился следующим:


  • Обычно небольшие компании делают качественный технологический продукт в узком сегменте, а крупные менее технологический.
  • В таких компаниях больше свободы, гибкости (меньше тестов, согласования).
  • Хакеры получают больше нагрузки и скиллов.
  • Более слаженным коллективом.

Что же тогда делать заказчику хакатона?


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


Внутри компании:


  1. Назначьте рекрутера, ответственного за лиды. Как показал опрос, связываются лишь с 20% участников, а оффер получают 4%. Если поднять долю тех, с кем связались, можно рассчитывать на значительный рост конверсии в оффер.


  2. Привлекайте тимлидов к работе с участниками на хакатоне, поскольку:


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


Вне компании:


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

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


Надеемся, что хакатоны помогут вам в достижении поставленных целей.

Подробнее..
Категории: Хакатоны , Хакатон , Карьера в it-индустрии , Бизнес , Исследования и прогнозы в it , Трудоустройство , Бизнес-модели , It , Найм , Оффер

Зачем тимлиду участвовать в подборе? Потому что ошибки найма упадут на него

09.06.2021 08:18:01 | Автор: admin

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

Про ошибку найма и ответственность

Что я понял на своем опыте: ошибка в найме это большой урон для компании и команды.

Только подумайте: целых две недели уходят на поиски рекрутер тратит свои часы, руководитель и команда отвлекаются от задач, смотрят резюме и ходят на собеседования, команда к нему привыкает, а через месяц оказывается, что вы друг другу не подходите. Или проходят недели и месяцы, а человек все не находится. Это плохо влияет на деньги (зарплата рекрутера, стоимость рекламы для привлечения и пр.), на HR-бренд работодателя, на настроение в команде и нагрузки: задачи, которые пока не выполняются, ложатся на других ребят. Вот тут пора понять, что наём это всегда командный проект.

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

Для себя я это формулирую так: ответственный за подбор я, а рекрутер это мои руки в найме.

Когда рекрутер пинает тимлида и команду разработки это нормально

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

Заявка на подбор скрининг резюме рекрутером согласование кандидатов техническими специалистами интервью с командой тестовое задание (опционально) повторное интервью оффер.

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

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

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

  • как идет процесс

  • кто за что отвечает

  • какие максимальные сроки у нас заложены под каждый этап


Решили, что если накапливается определенное количество нерассмотренных кандидатов, то рекрутер пишет в общий чат и не стесняется нас пинать. Если кандидат нереально хорош, то может отправить прямо ссылкой кандидат горящий, важно не потерять!.

Когда мы это сделали все зависания исчезли. Главное принять, что рекрутер тут пинатель, это его работа и не стоит на него за это злиться.

А еще от зависаний нас спасает сервис из экосистемы hh.ru облачная CRM для рекрутмента Talantix. В ней можно прописать сроки под каждый этап воронки, и, если кандидат начинает подвисать, система сама напомнит. Это удобно не только разработчикам, рекрутер тоже доволен ведь у него куча задач, и иногда можно в суматохе забыть нас дернуть. А тут CRM сама подсказывает, освобождая от части рутины.

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

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

Выбрасываем все лишнее

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

Что может сделать тимлид? Как минимум разумно подойти к тестовым и количеству интервью. Обязательное тестовое у нас только для QA-инженеров, в остальных случаях мы прощупываем уровень кандидата на собеседовании предлагаем кейсы, спрашиваем, как человек решил бы ту или иную задачу. И это здоровый подход, потому что репрезентативное тестовое займет несколько часов, а вы у кандидата не одни. Скорее всего, он выберет компанию, в которой тестовое не нужно. Если после собеседования остались сомнения по кандидату и при этом вы уверены в его мотивации, тестовое можно дать, только по максимуму его сократить.

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

У рекрутеров в ходу есть такой мем;)

Заявка на подбор и текст вакансии это не одно и то же

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

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

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

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

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

Слышал истории о том, что тексты вакансий составляются по схеме: нашли что-то похожее на hh.ru, немного подправили, дописали побольше технологий, опубликовали. При этом список требований у джуниора как для мидла со стажем. Не делайте так! Обязательно возле некритичных требований указывайте в скобках будет плюсом, иначе вы будете очень долго искать человека, и от этого будет нехорошо не только рекрутеру, но и самому отделу.

История из жизни Как мы искали мидл-разработчика

Как-то искали iOS мидла в команду. Откликов мало и находятся вообще не те люди. Сели за круглый стол, все обсудили и поняли: то, что мы готовы предложить, нерелевантно требуемому опыту. Поменяли всего одну цифру (указали 3 года), и процесс пошел. Мой совет: будьте внимательны к каждой строке вакансии одна цифра или фраза могут в несколько раз сузить воронку.

Также полезно анализировать воронку на продвинутом уровне. Я регулярно смотрю в Talantix, все ли у нас хорошо. Сразу видно, на каких этапах срезаются кандидаты. Например, выясняется, что входящих откликов много, а техническое интервью проходят единицы. Что тут может быть? Например, плохо прописали заявку с рекрутером, и он не тех ищет/не те откликаются. Тогда нужно вместе пересмотреть требования и переписать текст вакансии.

Идеальные вопросы для интервью какие они?

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

Совет: идите в ногу со временем и не задавайте вопросы типа Кем вы видите себя через 5 лет или Собираетесь ли вы в декрет. Вряд ли вам ответят правду, зато такие вопросы негативно влияют на ваш HR-бренд. Спросите лучше о мотивации или о том, в каком направлении кандидат хочет развиваться. Это будет корректней и информативней для вас.

История из жизни Как мы проворонили хорошего кандидата

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

Лайфхаки

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

Вот несколько наших секретов:

  • У нас есть общий чат, где прямо во время интервью можно написать Мне кандидат нравится, давайте еще вот это спросим.

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

  • Кандидату по результатам отвечаем не сразу, а на следующий день, чтобы можно было поспать со своим выбором.

  • Попробуйте провести ретроспективу по процессу найма.

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

Вместо заключения

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

Подробнее..
Категории: Карьера в it-индустрии , Управление разработкой , Собеседование , Тимлид , Ошибки управления , Найм , Блог компании headhunter , Разработчики , Рекрутмент в it

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru