ИТ-HR не разбираются в ИТ: кто виноват и что делать

В чем успех IT HR, его эффективность? Формула простая: ты должен быть одинаково хорош и в HR, и в IT.

В закладки

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

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

Открыта вакансия финансиста, насёчу и покажу резюме бухгалтеров и налоговиков — одна же сфера, какая разница! Разбираться еще в этих терминах — БДДС, БДР, управленческий учет. Маркетолог нужен — держи пиарщика и SMM-щика в придачу. Как не подходят, разве это не маркетинг?

Глупо звучит, правда?

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

Вообще у меня есть довольно длинный список компетенций — знания, навыки, soft skills, мотивация, ценности. И один из важных пунктов — это знание и понимание предметной области, т.е. IT, разработки в частности. Это понимание ролей в разработке, процессов, технологий, знание определений — что из чего вытекает, что как к чему относится, классификации, отличия, сходства, параллели. Рекрутер должен уметь отделять «зерна от плевел», знать, чем занимаются IT-специалисты, в чем суть каждого участка работы, ценность, какие технологии и инструменты они при этом применяют. Что критично для одного проекта и абсолютно неважно будет для другого. Понимать, в чем отличия крутого спеца от среднестатистического и слабого. Понимать hard skills на уровне теории. Я ведь даже не говорю про практику, оценивать, чистый ли код у разработчика. Хотя бы теорию. Экспертиза должна быть! Но нет, и здесь тоже всё печально.

Раньше я проводила собеседование так: сначала оценивала профессиональные скиллы в рекрутинге или в HR в целом, потом soft skills, мотивацию — и только потом смотрела на знания в IT. Интервью с IT HR я провожу по 1,5-2 часа, чтобы глубоко оценить весь список важных для меня компетенций. И т.к. процент тех, кто шарил в IT был меньше 10%, я решила перенести проверку ИТ-части в начало разговора. Я называю это тех.блицем. И так у меня сократилось время общения максимум до 20 минут с теми, кто тех.блиц не проходит.

Сейчас у меня в работе очередной рекрутинговый проект — я ищу IT HR в единственном лице в небольшую международную софтверную компанию.

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

Чтобы вы понимали, примеры вопросов:

  • В чем отличие бэкенда и фронтенда.
  • С помощью каких технологий можно писать бэк, а с помощью каких — фронт?
  • Чем отличаются язык программирования, фреймворк и библиотека?
  • Назови фреймворки такого-то языка программирования (спрашиваю про языки, на которые рекрутер искал раньше или ищет сейчас).
  • В чем отличия UX/UI.
  • Что такое ООП. Какие принципы ООП.

И так далее.

И вот выдержки из ответов (кроме ответов: «я не знаю») :

  • Библиотека — это там, где код хранят.
  • UX/UI — это бэкенд и фронтенд дизайна.
  • ООП и функциональное программирование отличается с точки зрения «клиентов», т.е. то как пользователи работают с системой.
  • Smoke тестирование — тоже самое, что и нагрузочное.
  • ООП — общие основы программирования.
  • Про Java и JavaScript уже куча легенд и мемов. Но вот еще одно: на Java можно писать и бэк и фронт, а JavaScript — это низкоуровневый язык.

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

  • за 3 года в IT HR им не нужны были эти знания,
  • не было наставника у них,
  • как-то и без этого получалось искать,
  • не знают, где и про что читать.

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

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

Другие кандидаты раздражаются: зачем мне это все знать, глупости какие-то. Я и так прекрасно справляюсь со своими задачами без этих ваших ООП и Java с JavaScript. Какое это имеет отношение к моим обязанностям задачам? — Детка, самое прямое отношение. И если ты этого не понимаешь, удачи. Значит, нам не по пути.

Или заявляют с высоковздернутым носом: я умный/умная, и если надо будет, я разберусь. — Так что ты еще не разобралась/разобрался за 3-5-7 лет, пока работаешь в IT HR? В чем проблема-то, в чем сложность, раз ты умная/умный?

И мне очень жаль...

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

Жаль работодателей, потому что от некомпетентности рекрутера страдает HR-бренд. Потому что рекрутер — это лицо компании, первый человек, с кем контактирует кандидат на входе. И ошибка первого контакта может дорого обойтись — потерей классного кандидата.

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

Жаль других рекрутеров, профессиональных и компетентных. Потому что им отголоском достается негатив кандидатов и нежелание с ними общаться, потому что они обобщают некомпетентность рекрутеров. Если я 30 раз столкнулся с тупым эйчаром, почему я тебе должен довериться? О чем с тобой говорить вообще, если ты не шаришь, двух слов в ИТ-терминологии не можешь связать и все равно не поймешь, о чем я тебе говорю. И тут мы кричим (точнее доказываем делом): я не такая, поговори со мной, и ты убедишься (удивишься). И они убеждаются (удивляются) и говорят: «Хэй, а ведь ты шаришь». Обсуждают с нами рабочие проекты, с запалом рассказывают о задачах, проблемах и тонкостях. Еще и друзей нам потом рекомендуют, потому что остались довольны, как с ними пообщались.

Кто виноват и что делать

  • Виноваты сами эйчары

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

С первой категорией все понятно, т.е. безнадеждно, т.к. без мотивации никуда. А со второй категорией можно работать. Но здесь важно, чтобы, кроме «хочу», было еще и «могу», т.е. мозг, способность обучаться новому — особенно технической информации. И вот вы жалуетесь, что учителя нет, разобраться сложно. Если непонятно — гугли! Ты сам себе учитель. Что-то прочитал, и все равно непонятно — гугли еще, спрашивай у своих заказчиков и кандидатов, что это и зачем. Если все равно непонятно, может быть тебе не место в IT HR? Подбирай персонал попроще — продажников, например. Хотя и там нужно, чтобы у тебя отскакивали от зубов этапы продаж, и ты должен уметь оценить навыки выявления потребностей, работы с возражениями и вот это вот всё.

В интернете множество статей, презентаций, видео, докладов на тему IT. В течение года запросто можно попасть на онлайн-конференции IT HR или найти старые записи докладов. HR API, например. Или канал Amazing hiring на Youtube. Запишитесь на оффлайн-курс по ИТ-рекрутменту. Они проходят в основном в Москве. Но съездите, потратьте деньги — оно того стоит. Ведь это инвестиции в вашу собственную экспертизу, профессиональное развитие.

Снимаете заявку у заказчика, загуглите каждое непонятное слово, разберитесь, для чего это и что это значит. Если не смогли разобраться, попросите нанимающего менеджера объяснить на пальцах какие-то понятия, простыми словами. Например, он вам говорит, что для разработчика важно знание и применение ООП или алгоритмическая подготовка. Очевидно, что без этих скиллов заказчик не будет рассматривать кандидатов. Ваша задача показывать релевантных кандидатов. Значит, вам необходимо понять, что это такое, как применяется в задачах на практике, и как вы это можете оценить на своем уровне. Или другой пример: CTO хочет найти React разработчика. Значит, вам остается сложить 2 и 2 — понять, что это front-end разработчик на самом деле, и узнать, а подойдут ли/будут ли интересны кандидаты со знанием других фреймворков? Допустим, да, подойдут. А какие есть другие, опять же вам предстоит выяснить. Vue, Angular — возможно. jQuery — пожалуй, слишком древний. А может быть, менее популярные Backbone и Knockout тоже подойдут? Тогда и NodeJS туда же? — Нет, это для бэкенда.

Все еще считаете, что вам не нужны ИТ-знания?

  • Виноваты работодатели

Да-да. В конце концов, кто берет на работу горе-эйчаров и закрывает потом глаза на их некомпетентность? Да, именно вы — собственники, HRD, руководители подбора (возможно, такие же некомпетентные?). Помните я писала, что все ошибки эйчара влияют на HR-бренд компании. А еще на бизнес-показатели из-за простоя рекрутинга и внутренних ошибок в HR из-за незнания отрасли и ее специфики, процессов, людей итд.

Если вам нужны опытные специалисты, проверяйте на входе у кандидатов в HR/рекрутинг их ИТ-прокачанность.

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

Хочет ли.

Узнайте прямым вопросом: «Почему ты хочешь в IT? Какие риски и пллюсы ты видишь при переходе? Почему думаешь, что получится? Что делаешь уже в этом направлении?»

Может ли.

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

В моей практике было много успешных примеров, когда я брала в команду эйчаров с опытом из других сфер — подбор ИТР (это кстати, наиболее близкая сфера к ИТ), узких специалистов бэк-офиса и даже из массподбора. Но были и неудачные примеры, когда у эйчара в итоге ломался мозг, было отторжение информации про IT. И либо они сами уходили, либо я с ними прощалась. Они были нормальными рекрутерами, только не для IT.

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

  • Виноваты нанимающие менеджеры и тимлиды

Если вы только сейчас задумались, а «шарит» ли ваш эйчар в IT. Позадавайте те же самые вопросы на понимание терминологии, процессов, ролей. При обсуждении заявки на подбор, проверьте пару контрольных моментов: вот я тебе сейчас про CI/CD рассказываю, а ты знаешь что это такое? Объясни, как понимаешь. Или: нам нужен разработчик с опытом на высоконагруженных проектах — а что в твоем понимании высокие нагрузки? Или: нам важно, чтобы аналитик применял практики user story и use case — а что это такое и как ты будешь проверять?

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

Если вам вообще неважно, шарит ли он. Или даже, наоборот, вы считаете, что для эйчара вся техническая информация лишняя, и вы специально ей не делитесь. Или ленитесь. Или думаете, что эйчар слишком тупой, чтобы разобраться, и даже не хотите пытаться. Некоторые кандидаты мне жалуются по другому поводу: «Я спрашиваю своего заказчика/тимлида/CTO, пристаю к нему с расспросами: а это что, а как это работает, зачем это? А он лишь отмахивается, на мои вопросы не отвечает, почему тот или иной скилл важен не говорит. На технические интервью меня не пускают, говорят, эйчарам там быть не положено или ты все равно ничего не поймешь». Ребята, помогите своим эйчарам! Дайте им шанс разобраться. Побудьте техническим наставником. Теперь вы знаете, почему это важно и чем чревато отсутствие прокачки в ИТ. В первую очередь пострадаете именно вы как нанимающий менеджер.

От автора. Мой личный опыт

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

Помню, как мне пришла заявка от клиента на ABAP разработчика. Сперва я подумала, что SAP — это самописная программа. Но как только я загуглила, мне самой стало стыдно про себя. Ведь SAP — это крупнейшая ERP-система в мире. И он содержит десятки разных модулей — стала читать и разбираться, чем они отличаются, и что за ABAP такой язык непонятный. Потом была заявка SQL-разработчика с тестовым заданием. И я стала раскапывать ответы на каждый вопрос в тестовом, что такое процедуры, триггеры, запросы в БД, чтобы говорить про это с кандидатами, понимать их ответы и фильтровать. Затем все компании стали требовать от разработчиков знать ООП — значит, и мне надо разобраться, что это такое и в чем заключаются принципы. И так у меня просто стал расширяться кругозор и углубляться знания.

Когда я пришла в СКБ Контур, то мне очень хотелось увидеть на практике то, что я знала в теории. Я просила разработчиков помочь мне и моей команде, показать. Я приходила к ним в комнату, садилась рядом и смотрела, как они пишут код. Мы с рекрутерами увидели, как выглядит Cassandra внутри, а как — Visual Studio, как выглядит код написанный в стиле ООП и функционально, какой синтаксис у JavaScript и C #. Мы читали только что разработанные гайды по UX/UI. Я ничего не знала про ACM и CTF, а такие ребята нам были очень интересны как кандидаты. И Миша Рубинчик, тренер УрФУ по ACM вводил меня в курс дела. Паша Егоров, препод в Контуре и на матмехе, приходил к нашей команде IT HR, показывал нам инструменты, мы обсуждали технические темы, задавали вопросы.

Это было бесценно. И я очень благодарна ребятам за помощь.

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

Я тогда нанимала много ИТ-рекрутеров, команда росла сумасшедшими темпами. Мне хотелось передать свои знания, хотелось, чтобы им было легче погружаться, чем мне в свое время. И у меня родилась база знаний и программа адаптации по IT на 3 месяца. В конце срез знаний на 150 вопросов различной тематики. Так я была уверена, что знания у всех равны, и никто не ударит в грязь лицом ни перед кандидатами, ни перед заказчиками. Я с ней живу уже 5 лет и обновляю время от времени.

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

Часто и я, и мои рекрутеры знают больше самих разработчиков. Например, про ООП. Кто-то из кандидатов не называет ни одного принципа, кто-то только 3, а кто-то из них не может объяснить, что же такое инкапсуляция. Это, конечно, тоже печаль, но уже оборотная сторона — про кандидатов-разработчиков. Но таких кандидатов мы фильтруем, не отправляем заказчикам. Потому что нам нетрудно это оценить, а выигрывают все.

Послесловие

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

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

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

Написать
{ "author_name": "Ксения Окунцева", "author_type": "self", "tags": [], "comments": 44, "likes": 17, "favorites": 36, "is_advertisement": false, "subsite_label": "hr", "id": 109719, "is_wide": false, "is_ugc": true, "date": "Fri, 28 Feb 2020 17:38:16 +0300", "is_special": false }
(function(d, ver) { var s = d.createElement('script'); s.src = 'https://specials-f378ef5.gcdn.co/Covid19Quiz/all.min.js?' + ver; s.async = true; var container = d.getElementById('covid-quiz'); if (container) { s.onload = function() { new Covid19Quiz.Special({ css: 'https://specials-f378ef5.gcdn.co/Covid19Quiz/all.min.css?' + ver, container: container, location: 'article', share: { url: '', title: '', } }); }; } d.body.appendChild(s); })(document, 'cf5c8372');
0
44 комментария
Популярные
По порядку
Написать комментарий...
1

ООП — общие основы программирования... Но таких кандидатов мы фильтруем, не отправляем заказчикам. 

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

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

Ответить
7

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

Ответить
0

Хаха, может, и так. То, что вы написали тоже проблема. Но про работу для джунов - это отдельная тема, кажется. И она больше про рынок. 

Ответить
0

Ох, увы не только для джунов. Многие разработчики с уровнем типа миддл/синьор говорят, что, конечно, ООП - это важно, но принципы не помнят и объяснить не могут. Про  SOLID вообще не слышали. Ну и как?
Не знаю, почему минусуют, и интересно, кто и из какой категории люди. 
Моя предыдущая статья про ошибки в технических собеседованиях набрала кучу плюсов. 
Хотя то, какие ошибки делают тимлиды, должна резать больнее. А на эйчаров жалуются, но с выводами не согласны? Интересно, почему. 
Давайте обсуждать!

Ответить
4

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

Наиболее очевидное ваше затруднение отражено в этом фрагменте:

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

Если вы будете валить в кучу принципы объектно-ориентированного программирования (OOP, Object Oriented Programming), которых действительно 3, и принципы SOLID, которые относятся к объектно-ориентированному проектированию (OOD, Object Oriented Design), у вас всегда будут проблемы. Эта ситуация усугубляется тем, что вам кажется, что вы знаете больше кого-то. В данном случае вы просто запутываете и себя, и собеседника и ставите его в неловкое положение, а себя — в дурацкое. Впрочем, вторая часть попадает в слепое пятно вашего восприятия.

Кто в этом виноват, решайте сами. Что делать — учить матчасть, RTFM наконец-то.

Когда-нибудь вы, возможно, разберетесь:

- чем принципы OOP существенно отличаются от принципов SOLID, а те — в свою очередь, от принципов GRASP;

- что такое pure functions и почему они так важны для функционального программирования;

- где, как и главное, зачем применять функциональное или объектно-ориентированное программирование;

- в назначении и типах рефакторинга;

- в стратегиях и практиках тестирования ПО;

- как читать документацию по этим и другим основополагающим вопросам ИТ.

Возможно, вы когда-то даже посмеетесь над шуткой «там все, как мы любим: лямбда на лямбде и монадой погоняет».

А пока да,

ИТ-HR не разбираются в ИТ

Вот же незадача.

Ответить
1

Не хотела абсолютно соревноваться с вами в знаниях. 
Я говорила о том, что важно попадать в целевую аудиторию и знать ее. Часто рекрутеры пишут разработчикам без разбора, не обращают внимание, а подойдет ли человек под их стек, аналогичными ли задачами он занимается, а интересно ли ему будет. Часто не знают технических деталей по вакансии и не могут ответить на вопросы кандидатов, поэтому ограничиваются общими фразами. И на что это влияет (почему это может быть проблемой) и как с этим быть, я описала в статье. 
Если для кто-то не видит в этом проблему и доволен ситуацией, ок, пусть так. 
Проблемы могут быть и другие в рекрутинг, не только про незнание отрасли, но это уже другая история.
Я также считаю, что экспертизу разработчиков, их скиллы, должны проверять такие же разработчики, а не эйчары. Но на технических собеседованиях часто кандидаты заваливают базовые вопросы. Собеседующие тратят время расстраиваются. А могли бы не тратить. 
В статье я не валила в кучу ООП и SOLID. Я знаю, что это принципы OOD. В объекто-ориентированном программировании.
А в ООП, насколько я знаю, выделяют все же 4 принципа: инкапсуляция, наследование, полиморфизм и абстракция. А кто-то говорит про все 5 - плюс интерфейс. Но большинство помнят про "3 китов". 

Ответить
0

Отличный кейс. С тремя главными принципами все ясно.

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

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

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

Ответить
0

Таки да. Согласна.

Ответить
1

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

Ответить
1

Может, он хотел найти человека, кто знает, чтобы тот пришел и объяснил ему наконец?) 

Ответить
0

Тогда мне следовало бы стать его руководителем, а не наоборот.

Ответить
1

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

Ответить
0

про оценил вероятно будет как в баяне про деталь НВ–46–39–00 
ему и не требуется этим заниматься, максимум - тест от того, кто в теме

Ответить
2

Если ты Java от JavaScript не отличаешь на этапе поиска, то у тебя кандидаты даже не дойдут до того самого теста :/ Вы так не считаете? 

Ответить
0

сейчас в топе новостей купание в бассейне с сухим льдом, базовые и такие  очевидные  вещи настолько важны, что бы их тут обсуждать с теми, кто ищет людей, которые, (среди еще не свалишвших на запад) будет строить наше будущее?

ну что ту сказать... тогда, даже не знаю... жесть.

Ответить
0

Статья хорошая, но немного затянутая и однообразная. Я CTO с бекграундом разработчика, но читать немного устал. 

Ответить
0

Можно поинтересоваться какая ситуация вызвала такой крик души?

Ответить
0

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

Ответить
0

На самом деле у меня есть HR, просто общительный парень с небольшим бекграундом разработки под Andoid. Смог закрыть 12 позиций за неделю ни разу не прибегая к публикации вакансий. Интерес вызывает то, что это не обученный и просто сообразительный человек, но спокойно проводит людей через привью и ведет до тек собеса.

Ответить
0

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

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

И функция HR в данном случае - чистое администрирование. И то, что в вашей компании этот момент не простроен и помогать не хотят, говорит о многом.

Поскольку экономия времени на изучение предметной области (программирования) позволяет HR либо совершенствоваться в своей сфере (мои к примеру психологические портреты нанимаемых людей к примеру были ревалентны почти на 100%). Либо прорабатывать способы обучения персонала, что сейчас для большинства вообще недостижимо, поскольку требуется уровень мышления как у руководителя. И не факт, что наймешь  себе HR-директора, основываясь только на записи в трудовой. Поскольку мышление большинства HR увы как у Вас.

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

Ответить
0

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

А кто сказал, что в нашей компании процесс не простроен и помогать не хотят? 
Мне кажется, вы невнимательно прочитали статью. Она была не об этом. 
Как раз когда я работала в Контуре, все всем помогали - и тимлиды эйчарам с технической оценкой, и эйчары тимлидам - со софт скиллс.
Но я уже не в СКБ Контур и пишу совсем про другое ;)
Она мотивирующего характера для эйчаров и всех участников рекрутинга. Про то, почему не разбираются и как это исправить. Опять же до оценки еще дойти надо. А сначала нужно найти "того самого" спеца.

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

Как же я люблю, когда из контекста слова выдергивают :)

Ответить
1

Я приходила к ним в комнату, садилась рядом и смотрела, как они пишут код

Есть ньюанс - одна и та же прога в зависимости от уровня специалиста может быть написана по-разному, и "умение писать код" вовсе не свидетельствует о компетентности. 

А у вас в компании решение о приеме на работу принимает HR?
Откуда такая печаль, 

ИМХОО: его опция - найти, желательно с помощью накопленной базы резюме (у тех кто в теме), и по возможности переманить...

Ответить
1

Просто по больному :( 
Я раньше работала в консалтинговой компании в узком рынке (не айти), разбиралась во всем сама, знала вообще ВСЕ. С кандидатами говорила на одном языке. Но решила поменять направление и ушла в айти рынок, очень хотелось погрузиться в новое и узнать много технических тонкостей. Я пришла в новую компанию и меня поверг шок :( никто ничего не знает про позицию, никто не разбирается в программировании из рекрутеров. Письма пишут слово в слово, как у вас в статье. Кровь из глазок и боль в сердечке. Никакой персонализации. Очень много негатива со стороны кандидатов на компанию, мол достали спамить. И чтобы вы понимали, это айти компания! 
Я взбунтовалась, а мне говорят, что мои идеи - это executive search, мол для такого подхода нет времени, надо писать всем подряд, а кто откликнется, того запроцессим. 
Переходя в айти рынок, я даже и предположить не могла, что такое бывает. А теперь ищу новую компанию, где будет экспертный сильный айти рекрутмент. 

Ответить
0

Спасибо за комментарий. Рада, что отозвалось. Хотя в этом случае, скорее жаль. Я желаю вам найти свою компанию! На самом деле на рынке много компаний с сильными командами рекрутеров и эйчаров. Ну а с той компанией, я надеюсь, вы попрощались :) Пусть пишут всем подряд, что уж. 

Ответить
0

Рекрутеров жаль? Я вас умоляю

Ответить
0

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

Ответить
0

Вообще конечно направление верное. Но самым лучшим IT-HR будет тот, кто сам поработал в предметной области и знает её изнутри. Про ООП позабавило. Программисты это не преподы, вот эти все нюансы не обязательно постоянно держать в голове. Но при этом код будет написан "как надо". На этапе проектирования ПО - да, важно быть в курсе про всякие SOLID и design patterns, чтобы не понаписать херни.

Ответить
0

Согласна. А как стать отличным IT HR, если ты не работал IT-специалистом? Какие у вас идеи?
Про ООП, увы, это не моя придумка, а требования большинства компаний и собеседующих. Они на технических интервью и про принципы ООП спрашивают, и чем плохо наследование. И много других теоретических вопросов. Это кроме кейсов и практических задачек. Так что кандидат хоть и не препод, но теорию с него будут спрашивать. Такие дела.

Ответить
1

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

Да, на собеседованиях спрашивают теорию в том числе, надо ведь как-то оценивать знания тех кто приходит (я не HR, но в IT-отделах где работал сотни 3 собеседований провёл, и представляю какие бывают кандидаты, и сам составлял опросники и задачки для оценки уровня человека).

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

Ответить
1

Мне прямо очень отзывается ваш коммент! Это действительно хорошая практика, спрашивать, почему тот или иной кандидат понравился. Т.е. не только со знаком минус, но и плюс. 
У меня раньше заказчики удивлялись, типа какая уже разница, понравился ведь :) 
И согласна про отсеивания. С этим нужно аккуратнее, потому что у кандидата и потенциал может быть сильный, и мышление на уровне. У нас бывали случаи, когда ребята не имели алгоритмической подготовки, но на техническом интервью сами придумывали алгоритм для решения задачи. Просто путём размышления. И таких брали на ура.

Ответить
1

Ещё у Лимончелли читал про то, что есть 2 подхода:

1. нанимать людей
2. нанимать навыки

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

Один мой товарищ на должности head of operations (или как там) в очень известной компании вообще говорил, что более приоритетно рассматривает заинтересованность человека, его уверенность в себе, своих способностях. Например, порекомендовал я ему человека, который ранее со мной работал, как спец он норм, middle которому пора переходить в senior, и вот он его не взял именно не по техническим причинам, а потому что человек не был уверен в себе, недооценивал свои возможности.

Ответить
0

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

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

Ответить
0

Нет. Я бы мог вдаваться в детали и тп. Но просто отвечу - нет.

Ответить
0

Столько пафоса, но на Java можно писать front) тот же  vaadin или jsp/jsf.

Ответить
0

Для кандидата, который уже научился отличать Java от JS вопрос "а с помощью каких технологий Java можно писать фронт" будет под звёздочкой, потому что может сломать мозг.
А причем здесь пафос? 

Ответить
0

Большеватая статья для одной простой мысли, затрагивающей проблему экспертности it рекрутмента) 

Ответить
0

Окей, предположим я даже понимаю в том, о чем вы говорили. Даже могу проанализировать код, в плане фронта, понять дурак потенциальный работник или нет, провести тех интервью. Пыталась устроиться HR в небезызвестную Меру. И там девочку, нанимавшую меня, интересовало только где я ищу кандидатов и использую ли я Тиндер для поиска, а также готова ли следовать стилю юбка+блузка! Ей не было интересно, что я понимаю в коде, работаю с git, ну и прочее.

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

Ответить
0

Ох, ну это вам не повезло. Это обратная сторона про работодателей :( 
Тиндер, мда. А может, она, наоборот, не хотела, чтобы вы в Тиндере искали?
Ну а про то, где рекрутер кандидатов ищет, я тоже спрашиваю. И важно, чтобы это был не только hh. Плюс, как ищет, по каким критериям, какие ключевые запросы, фильтры, на что в резюме внимание обращает. Как и что пишет потом. И другое по процессу, этапам рекрутинга.
А почему у них так строго: юбка-блузка? Футболка-джинсы - проф непригодность?

Ответить
0

Видимо про одежду это личное желание HR, я тоже не понимаю дресс кода в IT компаниях) Его наличие обычно указывает на то, что «рыба гниет и гниет усиленно».

Ответить
0

Пост самолюбования и очевидности.

"я просмотрела тысячи резюме ИТ-рекрутеров и IT HR-ов" - их всего в стране порядка 10К

"И вот выдержки из ответов" - а инженеры на интервью не лажают? 

"Детка, самое прямое отношение" - отличный способ тешить свое ЧСВ

"а что в твоем понимании высокие нагрузки?" - а в твоем? Есть порог?

"садилась рядом и смотрела, как они пишут код" - увлекательное занятие, я так в кардиохирургии разобрался. 

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

Ответить
0

Чем и занимаюсь, спасибо. С моей командой все хорошо, молодой человек ;)

Ответить
0

"Часто и я, и мои рекрутеры знают больше самих разработчиков. Например, про ООП."
ну если заменить слово "разработчиков" на "кандидатов", то я ещё поверю :)

Ответить
0

Ну да, это точнее будет, однозначно. Кандидатов :)

Ответить
0

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

Ответить

Прямой эфир