Comments 85
Изучить портфолио, примеры кода, открытые репозитории кандидата
А они должны быть в обязательном порядке, да? Например мой enterprise код не является моей собственностью => никаких открытых репозиториев.
Или каждый разраб должен уметь бесплатно «работать за идею»?
А если вас, как собеседующего, попросят показать свой код, вы покажете? Собеседования уже давно идут в две стророны, я бы даже что сказал кандидат собеседует работодателя.
В 2018 году я проходил цикл собеседований и нигде меня не спрашивали «примеры кода». Совпадение? Не думаю.
Лично я тестовое задание передаю через GitHub, как говориться с паршивой овцы хоть шерсти клок.
если работодатели не будут бурно возражать
Если тестовое задание не оплачивается, то:
Ничего личного, это просто бизнес. Аль Капоне.
Бывает, что тестовое выдаётся под NDA
Это где выдаётся под NDA?
Тогда 100% оплаты под минимум 1,5 ожидаемого часового рейта
А что спрашивали? Неужели не было ничего про «покажи как ты пишешь код»?
Я обожаю писать код вне работы. А с другой стороны в личное время мы делаем для себя.
"мы хотим видеть как вы мыслите", а мыслю я так, как мыслит человек, который пилит мод под игру совместно с 2 людьми которые научились программировать вчера, а паре тысяч игроков хотелось бы, чтобы вышел мод в день обновления игры и не ломал то, что они уже делали.
Хорош ли мой код?
Определённо он достаточно хорош для задачи.
Готов ли я дать этот код черт знает кому, чтобы он "оценил, как я мыслю", даже не представляя как мыслит он сам?
Да я скорее сброшусь с моста.
Похожая ерунда с тестовыми заданиями. За редким исключением не попадалось задания, описанного достаточно подробно,
чтобы не тратить существенное количество неоплачиваемого рабочего времени на угадывание критериев оценки неизвестного человека.
Ну и в конце-концов, даже не будь nda, часто в проектах код или архитектура ну очень далеки от того идеально вылизанного чудовища, которое можно воплотить в задании.
Именно поэтому я поставил на первое место способ, где вначале обсуждается задание, имеющее непосредственное отношение к последующей работе в случае найма.
Я обычно, когда сдаю тестовое, если уточнение задачи не предполагалось, делаю README (и дублирую его в письме) с перечнем сделанных предположений, допущений и ограничений. Начиная с банального "задача реализована в "лоб", любые значимые изменения требований потребуют большого рефакторинга" или "задача реализована с учётом изменения требований в стороны такие-то"
Репа на гитхабе — это, по сути, портфолио разработчика. Лебедев (как бы кто к нему не относился) в свое время дал крайне грамотный совет — если вам нечего показать в своем портфолио, то сами придумайте себе заказчика, задание и требования и сделайте его так, как будто вам платят за это хорошие деньги.
Лебедев, рассказывая про липовое портфолио, по сути рассказал как он облапошивал своих первых клиентов.
Мой гитхаб вообще никак не отражает меня как разработчика.
Это говорит лишь о том, что вы не рассматриваете его в качестве портфолио — вот и все. Собственно никто не заставляет.
Как по мне, так куда проще сразу показать "как я умею" (именно это Лебедев и показывал, кстати, а вовсе не "облапошивал"), указав ссылку в резюме. Как минимум не придется тратить время на заранее провальные собеседования. Единственный момент, что чем ниже квалификация соискателя, тем лучше сработает этот фильтр.
1. Многоэтапное тестовое задание
На одном из этих «многих» этапов кандидата уведет конкурент, у которого этапов меньше
7. Изучить портфолио, примеры кода
Вообще не вариант, у меня с работодателем НДА подписано, тот код что я пишу это его собственнось.
Более того, новый работодатель видит как я демонстрирую кому попало код старого работодателя вряд ли захочет на его месте оказаться.
Показать могу только тот код что пишу для развлечения дома, но там показывать особо нечего.
На одном из этих «многих» этапов кандидата уведет конкурент, у которого этапов меньше
Интересно, вы суть прочитали или только заголовок?
ибо, как вы верно заметили, скептицизм начался уже с заголовка.
Это уже выглядит странно — давать кандидату практичесское задание до того как он прошел собеседование.
Меня бы это насторожило и возможно даже отпугнуло, часто попадаются всякие тайм-вейстеры занимающиеся исследованием рынка и прочей бурдой.
Реакция автоматическая — они даже не поговорили со мной а суют какое-то задание, значит они ограничены в ресурсах, возможно потому что пытаются просеять информацию от 100500 кандидатов, а возможно от недостатка финансирования, при любом раскладе это не означает ничего хорошего для меня.
И таки да, это удлинняет ваш отбор потому что одно и то же задание раздается разным кандидатам и вам надо синхронизировать по времени получение и обработку ответов.
Ну так почитать о проекте и потом собеседование. Это же лучше чем собес про ваше видение себя через 5 лет :)
Ну так почитать о проекте и потом собеседование
На мгновение мне показалось что речь шла о выполнении «Многоэтапного тестового задания». «Почитать» никто не предлагал.
Первым этапом тестового задания является ознакомление с задачей, уточнение непонятного, проектирование решения, планирование шагов по решению задачи и оценка времени на выполнение отдельных шагов и всего тестового задания. На выходе я ожидаю документ на 1-2 страницы, где расписан план действий разработчика и оценка времени.
Ознакомиться с задачей и задать вопросы, описать план действий — это выполнение первого этапа. Занимает 20-60 минут, если проект заинтересовал. Программировать не требуется.
Следующим этапом является короткое собеседование. Нам уже есть, о чем поговорить. Кандидат уже примерно представляет себе предметную область проекта, над которым ему предстоит работать. Основная задача этого собеседования – ответить на технические вопросы кандидата и замотивировать его на выполнение основного тестового задания – программирования той части задачи, которую он сам выбрал. Или той части, реализацию которой хотите увидеть вы.
Всегда очень интересно наблюдать какую часть задания разработчик хочет реализовать. Некоторые предпочитают раскатывать структуру проекта, декомпозировать решение на модули и классы, то есть двигаются сверху вниз. Некоторые – выделяют отдельную подзадачу, наиболее важную на их взгляд, не прописывая решение в целом. То есть идут снизу вверх – от самой сложной подзадачи к целому решению.
Задача первого этапа — откинуть самых неадекватных кандидатов. Общаться голосом в кандидатами имеет смысл всегда. Вопрос — о чем? В Яндексе первая беседа голосом — с HR про жизнь и планы на будущее. Я же предлагаю в первой беседе голосом уже обсуждать будущий проект и тестовое задание.
Следующий этап то какой?
1. Знакомитесь с задачей, присылаете план и оценку времени выполнения.
2. Созваниваемся и беседуем про проект и ТЗ (30 мин примерно).
3. Если вы заинтересованы, вы делаете кусок ТЗ, который вам интересен (или нам интересен) — на 1-3 часа работы.
4. Смотрим ваш код и делаем предложение или отказываем.
Все.
Написано же — первый этап — понять суть тестового задания и будущего проекта и задать вопросы, оценить как будешь делать тестовое, а потом собеседование — что может быть проще и приятнее? Собес уже о проекте и если и придётся кодить, то ту часть, которая тебе интересна.
Буквально сегодня тут статья про отбор в яндексе — они просят на бумажке или доске писать при личной встрече. Это же маразм, но народ к ним идёт.
Не поверите, но у каменщиков именно этот проверяют — покажи как будешь выкладывать тот или иной элемент
В статье больше про программиста, а не IT-специалиста. Ведь к ним относятся и сисадмины, и DBA.
П.7 в их случае это просто места и срока предыдущих работ, выполняемые функции, что еще может, кроме описанных в резюме.
Все остальное мимо, т.к. для этого и берут, потому что у работодателя нет компетенций, и так все или уже не работает или вот-вот рухнет с существующими работниками.
Ну нет же. Тестовые задания вполне возможны. Тесты с вариантами.
Ну опять же я утрирую, я же не сказал про всех админов, но про многих. Просто сам уже который раз так устраиваюсь. ))
Не задавать фиксированный "проходной балл", а, например, на следующий этап пустить 10 лучших или 10% лучших.
Вопросы из типичной практики. Составить может непосредственный начальник, лидер команды. Тот, кому придётся оценивать кандидатов и выбирать. У этого человека такие вопросы обычно уже есть и он их задаёт на собеседовании. Ему нужно только переложить их в форму или тест.
На хабре читал про компанию, которая как раз админов тестирует следующим образом — скачиваешь образ виртуальной машины с поломанными сервисами, ищешь причины проблем и чинишь. Свой прогресс документируешь и сдаёшь отчёт — что и где починил. Чем не тестовое задание?
PS. Просто прикольно скачивать несколько десятков гигов образа, если это Винда, на своём не всегда быстром домашнем канале в Интернет.
Если вам нужно придумать тестовые задания в вашу компанию — можем обсудить ваш случай исходя из того, какие навыки вы хотите проверить.
Настроили предполагает поднять сервисы с нуля. А починить предполагает восстановить работу упавших сервисов. Восстановление работы сервиса — это SLA. Время на восстановление включает изучение причин падения, их анализ и принятие решения либо о починки того, что было, либо восстановлении из бекапа, либо поднятии с нуля по имеющемуся плану поднятия сервиса с нуля, если он есть.
Единственный вариант который приходит мне в голову для восстановления того, что упало — это критичные данные не имеющих бекапа, но тогда это работа может занять много времени и зависит от внутренней структуры файлов хранения данных.
Для таких заданий, по моему мнению, важнее не восстановление данных, а алгоритм по которому претендент будет действовать.
Ну вариант: последний бэкап был 59 минут назад, данные в образе критические для бизнеса.
Скорее всего это будет к лучшему и для работодателя. Зачем нужен сотрудник, который убегает в ответ на просьбу изучить задачу и предложить на словах план решения.
В любом случае, перечисленные способы служат для отсева неподходящих кандидатов с малыми затратами усилий. Полноценное собеседование отнимает 1-2 часа времени у квалифицированного сотрудника. Если потенциальный кандидат посмотрел на тестовое задание и даже не готов расписать план действий по выполнению этого задания, то скорее всего (на 99%) он не подойдет и нет смысла планировать с ним собеседование и выделять 2 часа времени на общение с ним. В случае бесполезного собеседования время тратит также и кандидат, поэтому такое тестовое уважает интересы и кандидата.
— кто инициировал общение — я это уже упоминал выше и скорее всего именно это меня и настораживает, а конкретно прилетевшая недавно на почту вакансия где мне даже не представились, но сразу речь про тестовое задание
— что за компания (собственно, с чего началась эта ветка) и насколько я в нее хочу попасть
— насколько у кандидата есть сейчас время и т.п.
Первым этапом для кандидата должно быть — не "познакомитсья с задачей", а объяснение того, зачем ему вообще хотя бы пытаться проходить эти этапы.
Ну, видимо, предполагается, что тестовое проходят те, кто или сам откликнулся на публичную вакансию или те, кого рекрутёры уже как-то заинтересовали. Не "холодная продажа".
Про многоэтапное тестовое задание — мне очень понравилось. Я очень был бы рад, если бы меня так собеседовали — показали задачу из будущего проекта, над которым работать, дали возможность выбрать ту часть, которая интересна.
Многоэтапное тестовое задание
Зачем мне выполнять его? Какой профит? Если интересное — ещё может быть возможно, но в свободное время и когда я это решу делать. А если нет — нафиг мне проходить этап за этапом имея потенциальный риск на любом из этапов равновероятно получить "вы нам не подходите"? Ради тех самых "у нас страховка, и бонусы, и плюшки, и бла-бла-бла"? Ребята, хватит из себя строить Google (который, кстати, по словам некоторых — уже не торт), в который все прям бегут и мечтают попасть.
Когда же до HR дойдёт, что разработчик с опытом — уже давно всем и всё доказал. Посмотри на портфолио разработчика — если он не прыгал по компаниям каждые полгода туда-сюда (потенциальная угроза того, что его увольняли), а достаточно продолжительно работал в 2-3 местах — ОН УЖЕ ПИСАЛ КОД И РЕШАЛ ЗАДАЧИ. Достаточно опроса что он делал и звонка в соответствующие компании, для подтверждения квалификации. Во ВСЕ компании — мало ли он на последнем месте работы поругался с каким нибудь манагером? Вам же не нужно выяснять кто из них адекватный, а кто нет — поэтому чем больше точек обзвонишь — тем объективнее ситуация.
Тесты
Серьёзно? Чтобы получить работу я должен не показать знания и навыки, а сдать тест? А если я знаю ответ на тест шире, чем ответ поставленный в тесте? Допустим на вопрос "что такое PDF" лично я вместо ответа "Portable Document Format", если поднапрягусь — могу вспомнить внутреннюю структуру и требования к оформлению смещений ссылок на страницы внутри PDF как минимум по спецификации 1.5. А как это в тесте показать? Короткой скромной подписью — "знаю чуть больше, но нет места куда вписать ответ"?
На такие тесты очень хочется заявить ответное: А давайте я проверю HR на ошибки — как он нанимает людей? Тест проведу — умеет ли он вообще нанимать? Достоин ли он — нанимать меня? И нет ли рядом какого-нибудь более компетентного HR?
Опросники с открытыми вопросами про опыт
Единственное что более менее разумное, но… "Чтобы отличить собственный ответ кандидата от «нагугленного» нужно разбираться в тематике" — иди ты? Реально? Вот мы и дошли до ситуации, что чтобы нанять разработчика — нужен… другой разработчик. И вся эта катавасия с "опросами, тестами и т.д." это какая-то отсебятина, чтобы… Для чего она? Чтобы показать собственную значимость? Как то сразу становится очевидно, что роль HR на самом деле начинается и заканчивается на "встретить человека и препроводить к компетентному специалисту для профессиональной беседы", а не то, что они себе понапридумывали. Но кушать то — HRам тоже хочется. А за просто "препровождение" — много не заплатят.
Live-Doing (Coding) – решаем простую задачку в реальном времени с расшаренным экраном
Ладно так и быть — это тоже разумная вещь, если бы не одно но: терпеть не могу, когда кто-то смотрит в мой экран из-за спины.
По моему опыту – примерно 90% разработчиков не возражают. Им приятно, что с первого же собеседования начинается общение про программирование
Ну так для этого надо в теме — шарить, а много ли найдётся "шарящих в теме программирования HR"? Я вот за всю свою (с 2004 нанимаюсь) карьеру — не встречал шарящих HR. В лучшем случае — слова знакомые слышали. И единственный реальный профессионализм, который HR показывали — скорость препровождения к нужному лицу для беседы.
Зачем мне выполнять его? Какой профит?
Чтобы вас наняли на позицию, к которой вы проявили интерес (по какой-либо причине, может даже просто из любопытства).
нафиг мне проходить этап за этапом имея потенциальный риск на любом из этапов равновероятно получить «вы нам не подходите»?
Это типичный жизненный риск — всегда и везде можно напороться на такой ответ.
Посмотри на портфолио разработчика — если он не прыгал по компаниям каждые полгода туда-сюда (потенциальная угроза того, что его увольняли), а достаточно продолжительно работал в 2-3 местах
Вы имеете ввиду резюме? Вы можете приукрасить информацию или даже соврать. А вот портфолио в случае программиста — его личный репозиторий — показывает что-то, но такого портфолио у многих кандидатов просто нет.
достаточно продолжительно работал в 2-3 местах — ОН УЖЕ ПИСАЛ КОД И РЕШАЛ ЗАДАЧИ
Вы же не принимаете решение о покупке б/у авто только на том основании, что продавец как-то смог приехать на нем к вам на встречу? Вы же хотите посмотреть, протестировать и убедиться, что у вас не будет проблем в будущем.
Достаточно опроса что он делал и звонка в соответствующие компании, для подтверждения квалификации. Во ВСЕ компании — мало ли он на последнем месте работы поругался с каким нибудь манагером?
Вот этот самый опрос обычно и называется техническим собеседованием, которое в небольших компаниях проводится при участии весьма занятых специалистов и занимает 1 час. А прозвонить в предыдущие места работы — тоже так себе идея. Никто не обязал разговаривать с незнакомым человеком и рассказывать про другого человека, который когда-то у него работал. Да и не факт, что вообще удастся связаться с теми людьми, которые могут вас охарактеризовать. Гораздо проще и быстрее самостоятельно провести проверку ваших навыков. В данном случае вы попытались учить работать других, не имея опыта такой работы.
Чтобы получить работу я должен не показать знания и навыки, а сдать тест?
Совершенно верно. Чтобы получить водительское удостоверение, вы вначале сдаете тест, а только потом вас пускают за руль, чтобы показать свои практически навыки. Тут то же самое. Если вы не готовы сдавать тест — не беда, ищите другого работодателя. А работодатель пригласит другого кандидата — готового вначале сдать тест.
Вот мы и дошли до ситуации, что чтобы нанять разработчика — нужен… другой разработчик.
Не обязательно разработчик. Может и менеджер проекта и достаточно опытный HR и джун-разработчик. Всем этим людям вполне по силам отличить шаблонный ответ из сети от личного мнения кандидата.
Ну так для этого надо в теме — шарить, а много ли найдётся «шарящих в теме программирования HR»?
Этот вариант про Live-Doing для ситуации, когда команда ищет сотрудника и технический специалист общается с кандидатом.
Все эти способы могут применяться для разных ситуаций. Скажем, тесты хороши для начинающих. Live-Doing — для тех, кто не стесняется.
А вам, возможно, лучше подойдет тестовое задание и собеседование.
Я вот начал читать достаточно развёрнутые ответы (кстати спасибо, что не поленились ответить), но вот последняя фраза про "в зависимости от того кого ищет команда начинающего или опытного" — сломала весь мой текст. Пришлось переписывать. Потому что непонятно тогда — критерии, описанные в статье, применяются к каким именно разработчикам — новичкам или более-менее опытным работникам?
Про новичков говорить не буду — им приходится зарабатывать начальную репутацию, но вот насчёт отбора опытных сотрудников — повторю свои собственные слова: ребята из HR, хватит думать, что вы Google.
Это типичный жизненный риск — всегда и везде можно напороться на такой ответ.
Это не "типичный жизненный риск". Это банальная попытка HR — раздуть свою значимость, как отдела. Если игрища с этапами, опросами и тестами всё таки решит пройти серьёзный специалист — для HR отдела это повод побить пяткой в грудь и похваляться "Ай да мы! Ай да какой ресурс отхватили!". Ну а там следуют и увеличение бюджета отдела и премии и другие тому подобные плюшки.
Но вот интересная штука никто в принципе не способен оценить: сколько потенциальных серьёзных специалистов при этом — отказались проходить эти игрища в принципе. Т.е. сколько по вине HR отдела "изобретателей" — компания НЕДОБРАЛА потенциально ценных специалистов, котоыре поговорили по телефону/скайпу их просили что-то написать, потмо назначили первый этап, потом второй, потом пообещали назначить третий и четвёртый… Как много специалистов мысленно сказали "Да ну нафиг!" (но не так цензурно)?
Вы можете приукрасить информацию или даже соврать.
Врать в резюме — это признак крайнего идиотизма. Серьёзные разработчики — знают цену слову и знают то, что ложь легко проверить в первые 3 месяца проверочного срока. Поэтому предпочтут не писать о себе вранья.
Гораздо проще и быстрее самостоятельно провести проверку ваших навыков
Как? Решать шаблонные задачи, скачанные из интернетов? А этим занимается БОЛЬШИНСТВО HR-братии. Типичное "напишите обход бинарного дерева на С++, на вакансию веб программиста"?
Наиболее адекватная проверка навыков — это посадить его за комп, открыть доступ к репозиторию и попросить починить баг. И заплатить за это деньги — потому что это работа. Но, внимание вопрос, кто даст незнакомому человеку доступ к репозиторию энтерпрайз разработки?
Вы же не принимаете решение о покупке б/у авто только на том основании, что продавец как-то смог приехать на нем к вам на встречу?
Действительно — не приму. Но авто — насквозь стандартизировано, его логи — легко прочитать спецоборудованием, а узлы — проверить тестером: подключил и отклонения от нормы — сразу видны. С человеком — так не получится. Нельзя "вскрыть" человека за 1 тест. Даже матёрому психологу/психиатру понадобится не один сеанс.
Чтобы получить водительское удостоверение, вы вначале сдаете тест, а только потом вас пускают за руль, чтобы показать свои практически навыки.
Для вождения автомобиля нужны абсолютно одинаковые знания совершенно стандартизированных ПДД. В программировании даже одинаковых задач, но написанных на разных языках/стэках технологий — есть кардинальные отличия и нюансы. Программисты же в процессе работы часто сталкиваются с непростыми задачами типа "запрограммируй мне то, не знаю что" или "натяни сову на глобус", которые требуют творческого подхода. Абсолютной и объективной оценки творческого подхода — пока ещё не изобрели. Тут скорее сродни сравнению двух картин написанные разными художниками-абстракционистами: и там и там — мазня (с моей субъективной точки зрения), но одну продают за миллионы денег, а вторая — продолжает считаться мазнёй.
менеджер проекта и достаточно опытный HR
Нанять то могут, но оценить навыки — сильно сомневаюсь.
Потому что непонятно тогда — критерии, описанные в статье, применяются к каким именно разработчикам — новичкам или более-менее опытным работникам?
Я рассказал про арсенал средств, которые применяю. Моя цель была — расширить кругозор коллег, так или иначе занимающихся оценкой кандидатов. Что и для чего применять, читатель может решать самостоятельно. Кто-то картошку чистит специальным ножом, а кто-то универсальным — лично дело каждого.
повторю свои собственные слова: ребята из HR, хватит думать, что вы Google
Моя вина — я плохо объяснил в статье исходную ситуацию.
Лично я исхожу вот из чего.
Размещается вакансия и за 2 дня на нее откликнулось 10-12 человек. Чтобы подробно пообщаться с каждым, уделив по 1 часу + синхронизировать начало беседы — у ведущего специалиста уйдет 2 рабочих дня. Наша с ним задача уменьшить количество собеседований, отсеяв наименее интересных кандидатов и свести дело к 3-4-5 собеседованиям. Для этого можно применить вот эти способы из статьи.
сколько потенциальных серьёзных специалистов при этом — отказались проходить эти игрища в принципе
Значит интерес к вакансии был изначально невелик. Про сокращение количества этапов, я рассказывал в предыдущей статье.
Врать в резюме — это признак крайнего идиотизма. Серьёзные разработчики — знают цену слову и знают то, что ложь легко проверить в первые 3 месяца проверочного срока.
Представляете, врут, процентов 20-30 кандидатов врут в резюме и про опыт и навыки и про знания. И я умею таких товарищей выводить на чистую воду. И любой из предложенным мною способов позволяет это сделать с минимальными затратами времени.
Наиболее адекватная проверка навыков — это посадить его за комп, открыть доступ к репозиторию и попросить починить баг. И заплатить за это деньги — потому что это работа. Но, внимание вопрос, кто даст незнакомому человеку доступ к репозиторию энтерпрайз разработки?
В том то и дело, что никто не даст. Поэтому и приходится вначале проверять другими способами.
Решать шаблонные задачи, скачанные из интернетов? А этим занимается БОЛЬШИНСТВО HR-братии. Типичное «напишите обход бинарного дерева на С++, на вакансию веб программиста»?
Редко когда HR сами решают какие задачи давать. Это решение вышестоящего руководства, скорее всего будущего непосредственного начальника. Если вам не нравится тестовая задача, лучше сразу отказаться от общения.
С человеком — так не получится. Нельзя «вскрыть» человека за 1 тест. Даже матёрому психологу/психиатру понадобится не один сеанс.
А нам не требуется его подробно вскрывать, как вы выразились.
Нам вначале нужно проверить, стоит ли тратить 1-2 часа времени на проверку, сможет ли он решать наши задачи. И для этого отлично подходит тест. По аналогии с авто, достаточно проверить, что кузов не бит и не крашен и проехаться 5 минут, потому что все остальное ремонтируется за не такие уж большие деньги.
Абсолютной и объективной оценки творческого подхода — пока ещё не изобрели.
Все дело в точности, допустимой погрешности.
Нанять то могут, но оценить навыки — сильно сомневаюсь
Вооружившись подходящими инструментами с определенной точностью — смогут. Ошибки будут, но не критичные.
Но вот интересная штука никто в принципе не способен оценить: сколько потенциальных серьёзных специалистов при этом — отказались проходить эти игрища в принципе. Т.е. сколько по вине HR отдела "изобретателей" — компания НЕДОБРАЛА потенциально ценных специалистов, котоыре поговорили по телефону/скайпу их просили что-то написать, потмо назначили первый этап, потом второй, потом пообещали назначить третий и четвёртый… Как много специалистов мысленно сказали "Да ну нафиг!" (но не так цензурно)?
Эта оценка может быть важна для тех компаний, которые постоянно набирают программистов по принципу "был бы специалист хороший, а задачи найдутся". Большинство же (субъективно) закрывает конкретные вакансии. У них задача прежде всего не взять неподходящего, а не взять лучшего. В пределе берут первого же подошедшего.
Как то сразу становится очевидно, что роль HR на самом деле начинается и заканчивается на "встретить человека и препроводить к компетентному специалисту для профессиональной беседы"
Вот нет. Роль HR(при личной встрече) как минимум:
а) Убедиться, что соискатель не буйный псих/тихий говнюк и не пришел собеседоваться с торчащим из засаленных трусов чебуреком. Т.е. определить общую адекватность человека.
б) Ответить на вопросы по специфике работы в компании. Ну вот те самые фишки про режим работы, премии, штрафы, отпуска, печеньки и прочую хренотень. Т.е. дать человеку возможность сразу соскочить, не мучая себя и других, если что-то не нравится.
в) Ненавязчиво поспрашивать про предыдущие места работы, почему решил уйти. Т.е. прикинуть, не уйдет ли он через пол года, рассказывая другому HR-овцу, какое говно его бывшая компания.
И только после этого вести к компетентному специалисту, чтобы шансы, что они вдвоем с соискателем потратят пару часов своей жизни(и работы) не в пустую, были повыше.
Поправка принимается. Пункты "а" и "в" у вас — можно в принципе объединить…
Пункт "в" не столько про адекватность человека, сколько про несовместимость его с вашими реалиями. Допустим его прямо бесит, что надо раз в неделю писать отчет о проделанной работе, к которому придираются за грамматические ошибки. Так-то в рамках пункта "в" эта тема может и не подняться, а потом выстрелить — мама не горюй.
Топ-7 способов быстрой проверки компетенций IT-специалистов до собеседования