Какой толк от HR-ов?
Зачем давать задачи на логику на собеседовании?
Зачем тестировать кандидатов на младшие должности? Ведь можно просто взять на работу и всё увидеть.
Эти и другие вопросы часто возникают у людей, которые не работали в IT-компаниях. Более того: подобные вопросы иногда возникают даже у людей, работающих в IT-компаниях, но не имеющих отношения к найму. Некоторые из них не понимают, зачем им самим на собеседовании задавали те или иные вопросы и предлагали решить те или иные задачи.
Интересно, что это ещё не весь список «непонимающих» и «несогласных» 😁. Дело в том, что даже сотрудники IT-компаний, имеющие прямое отношение к найму, иногда не одобряют или не понимают своих коллег, которые ведут найм по-другому, то есть не так, как они.
Итак, сегодня говорим про найм в IT-компаниях, а если точнее, то не про весь процесс найма целиком, а о его весомой части – собеседованиях. Я поделюсь своим взглядом на эту сложную и увлекательную тему. Буду рад, если в комментариях вы поделитесь своим.
В этот раз в составлении текста мне помогли мои дорогие читатели. В моей предыдущей статье в подробностях описана история одного необычного собеседования. Эта история вызвала энергичный отклик у многих людей. Огромное им спасибо за оставленные комментарии! Именно благодаря этим комментариям мне теперь не нужно думать, какие именно вопросы могут возникать у людей по поводу найма в IT 😁. Уважаемые читатели сами обо всём спросили или поделились своими мнениями. Так что я просто возьму эти комментарии и отвечу на них здесь.
Но начну, пожалуй, не с конкретного коммента, а с цитирования известного физика, нобелевского лауреата:
«Найти что может быть не так – не проблема. Проблема – найти чем это заменить» © Р. Фейнман
Это высказывание Фейнмана относилось к физическим теориям. Смысл в том, что критиковать даже общепринятые физические теории легко, гораздо сложнее предложить что-то взамен. Думаю, что приведённую цитату можно в полной мере отнести и к найму сотрудников. Не существует идеального процесса найма, так же как и не существует идеальной физической теории. Поэтому невозможно гарантировать, что вам удастся нанять идеального сотрудника. Вы можете всё сделать самым лучшим, как вам кажется, образом, и при этом всё равно ошибиться. Инструменты и подходы, использующиеся при найме, не универсальны: какие-то работают в одних ситуациях, но совершенно бесполезны в других. И про любой из этих инструментов и подходов заранее можно сказать, что он неидеален. Критиковать их легко. Но что действительно сложно – так это предложить что-то лучше. При этом всегда найдутся люди, которые будут утверждать, что они выстроили идеальный процесс найма и их подход самый лучший. Что ж, не буду их переубеждать. Вдруг они действительно наняли всех лучших сотрудников на рынке и построили лучшую в мире компанию? 😁
При найме сотрудников каждый крутится как может. Составляет свой собственный набор неидеальных инструментов. В идеале, этот набор создаётся под конкретную ситуацию: конкретную вакансию, которую нужно закрыть, и конкретного кандидата, с которым предстоит общаться. И набор этот может изменяться уже в процессе найма, в зависимости от развития ситуации.
Таков, по крайней мере, мой собственный подход к найму. И именно под этим общим углом я буду отвечать на комментарии. Теперь к комментам…
Зачем тщательно тестировать кандидатов на младшие должности?
Вот комментарии читателей на эту тему:
«М-да. Чего к чуваку пристали. Работа бы показала, что он из себя представляет»
«Взяли бы на работу и увидели бы всё. Шары взвешивать. Стекло сверлить... ох и муета»
«Да на джуна что бы и не взять. По крайней мере память у чела хорошая. Сдались вам эти сортировки и шары» [Примечание: джун – от англ. junior, «младший сотрудник» в данном контексте]
То есть предлагается просто нанять кандидата, а потом уже смотреть, хорошим он окажется сотрудником или нет.
Но во-первых, обычно кандидатов на конкретную позицию – несколько. А нанять нужно только одного. И какого из нескольких нанимать? Хотелось бы выбрать наиболее подходящего.
Во-вторых, цена ошибки при найме неподходящего кандидата довольно высока. Может показаться, что ошибиться с наймом младшего специалиста – это дёшево. Вроде как, младший специалист получает не самые большие деньги, поэтому почему бы просто не попробовать?
В действительности же ошибка в найме младшего специалиста в некоторых случаях может стоить очень дорого. Любой специалист – это зарплата, обустройство для него рабочего пространства, создание учётных записей в электронных системах и настройка оборудования, халявные печеньки в офисе и множество других мелочей… Но! Есть кое-что, что может стоить даже дороже всего этого. И это время старших специалистов. Дело в том, что младших сотрудников нужно обучать. Представьте теперь, что вы наняли сотрудника, который совершенно не самостоятелен, не мотивирован обучаться и которого нужно постоянно «водить за ручку», а также исправлять с ним или за ним многочисленные ошибки. В этом случае вы потратите огромное количество времени старших специалистов, которым придётся всем этим заниматься. Ещё и негативно повлияете на их собственную удовлетворённость работой.
Так что найм неподходящего младшего специалиста – это нифига не дёшево. Да, это выкинутая зарплата за пару-тройку месяцев. Но также это выкинутое время опытных специалистов, которые будут с ним работать.
Про работу «на себя»
Пара комментариев от читателей на эту тему:
«Крутые специалисты, особенно в IT, по собеседованиям не ходят; они успешно работают на иностранные компании или на себя»
«Сейчас не надо ходить в офис за корочкой хлеба, даже с маслицем. Сейчас работой обеспечивает сеть! Никуда ходить не надо, ничего выполнять и ни перед кем ничего из себя изображать не надо. Фриланс закрывает потребность заработка на 250%!! Работайте дома и на себя, с удовольствием!!!»
Что ж… Оба комментария справедливы. Но также справедливо то, что многие крутые специалисты очень охотно работают в больших и малых компаниях. Конкретно у работы в больших компаниях есть множество плюсов:
- масштаб задач. Взять хотя бы такие продукты, как ChatGPT или Photoshop. Будучи фрилансером, работать над проектами такого масштаба, почти наверняка, не получится
- корпоративные «плюшки». Например, медицинская страховка, удобный офис (да, не все балдеют от удалёнки), интересные командировки, бесплатные обеды, специалист по массажу и маникюрный кабинет в офисе и прочее… Понятно, что будучи на фрилансе, многое из этого можно организовать самостоятельно. Однако не все хотят и любят организовывать свой околорабочий быт. Некоторым нравится, когда за них это делают специально обученные люди
- возможность учиться у лучших. Крутейшие в своих областях специалисты, как правило, работают в больших командах и над масштабными задачами. Работа в крупной компании – это шанс поучиться у таких людей
- возможность глубоко погрузиться в предметную область. Все фрилансеры, с которыми я знаком лично, являются специалистами широкого профиля. Их берут на задачи, которые не требуют узкоспециальных знаний. Например, у фрилансера, скорее всего, не будет математических и алгоритмических навыков, которые необходимы для работы над компиляторами, инструментами 3D-дизайна или большими языковыми моделями (которые лежат в основе ChatGPT). Узких специалистов крупные компании, как правило, выращивают сами либо переманивают из других компаний, которые их вырастили. Допускаю, что фрилансеры-узкие специалисты существуют. Но это, скорее, исключение, а не правило.
Компании, в которых мне довелось работать, напрямую с фрилансерами не сотрудничали. Если возникала необходимость в рабочей силе «со стороны», то они прибегали к услугам крупных аутстафферов, вроде EPAM или Luxoft. При этом персонал, законтрактованный через аутстафферов, никогда не привлекался к решению самых сложных задач, для которых требовался высокий экспертный уровень в какой-то узкой тематике.
Фрилансеры, с которыми я знаком лично, работают над относительно небольшими проектами, относительно непродолжительными и не требующими узкой экспертизы.
Но! Всё сказанное выше не отменяет того, что фрилансеры могут зарабатывать очень хорошие деньги. Однако деньги – это не единственная мотивация для IT-специалистов. Есть много других, часть из которых я перечислил выше. При этом штучные специалисты, как правило, работают в крупных компаниях и получают деньги гораздо большие, чем любой из фрилансеров.
Чем занимаются IT-специалисты, работающие на младших должностях?
Вот мнение от подписчика:
«Джуну, которому по-любому навешают рутины, никто ничего анализировать или принимать решения не даст. Для него, скорее, важен навык "не раздолбать" и "лучше спросить перед тем, как ломать"» [Напомню: «джун» – это младший специалист, от английского «junior»]
Да, есть такой подход: «навешивать рутину» на младших специалистов. Но я здесь придерживаюсь противоположного подхода. На мой взгляд, важно давать младшим специалистам творческие задачи. По возможности, даже исследовательские. На мой взгляд, младших специалистов нужно заинтересовать и дать им почувствовать «вкус» к работе. Полагаю, что для этого лучше всего подходит «чистая» работа. С «грязной» работой, вроде исправления багов, легко справляются в фоновом режиме рядовые и старшие специалисты. Впрочем, это не означает, что младших специалистов нужно полностью ограждать от «грязной» работы. Как раз наоборот: следует периодически подкидывать им небольшие инфраструктурные работы или задания по исправлению выявленных в разных частях продукта багов. За счёт этого у сотрудника будет расширяться кругозор, укрепляться знакомство с продуктом, а также он освоит необходимый в работе инструментарий… Важно только делать это дозированно и постепенно, чтобы у человека не создалось впечатление, будто он попал в выгребную яму.
Насколько тщательно «дозволено» тестировать кандидатов?
Ряд читателей посчитали, что с количеством задач и вопросов к кандидату [про которого я рассказал в предыдущей статье] был перебор:
«А чем так хороша Ваша компания, что для устройства к вам на работу необходимо пройти такое дотошное собеседование с разгадкой тестов?»
«Так собеседуют только в очень крутые компании. Например, в Гугл…»
Описанное в предыдущей статье собеседование отнюдь не дотошное, по меркам IT-компаний. И совсем не дотягивает по тщательности до собеседований в Гугле или Амазоне.
Не знаю, как сейчас, а раньше – когда у Гугла был офис разработки в России – Гугл сначала проводил скрининговое собеседование по телефону, а затем приглашал на целый день в свой офис, где было ещё 4 собеседования с четырьмя разными людьми. У Амазона была ещё более сложная схема. Сначала несколько технических собеседований по телефону/Скайпу – ибо офиса разработки в России у них никогда не было. Если всё проходило хорошо, то кандидата приглашали уже на очные собеседования в один из европейских офисов.
Собеседование из предыдущей статьи на шкале «дотошности» располагается, скорее, ближе к левому концу этой шкалы – там, где наименее суровые собеседования. Опять же: по меркам IT-компаний. В других областях могут быть свои представления о «дотошности».
Что HR-директор делал на собеседовании младшего специалиста?
«В серьезной конторе айтишника низшего или низшего +1 уровня собеседуют владелец бизнеса и дир. по персоналу?»
Комментарий этот, возможно, немного хейтерский, ибо человек, вероятно, пытался сказать, что контора-то не очень серьёзная, раз на собеседование младшего специалиста отправили тяжёлую артиллерию. Но мне этот комментарий нравится, ибо человек подметил одну интересную деталь. И это не про владельца бизнеса. Владельца бизнеса на собеседовании, конечно же, не было. В статье он даже не упоминается. Впрочем, выраженного «владельца» у той компании вообще нет. Как и у многих других крупных компаний, там сложная структура владения бизнесом.
Но вот что действительно метко подметил автор комментария – это присутствие на собеседовании директора по персоналу. Действительно, странновато выглядит, не так ли? Но на практике ещё и не такое бывает, ибо нюансы, нюансы, нюансы…
Вот нюансы, которые имели отношение к той конкретной ситуации:
- в головном офисе компании, в котором происходило описанное в статье собеседование, тогда ещё не было отдела рекрутинга. В офисах, которые находились в других городах, такие отделы были. Ибо те офисы комплектовались в основном за счёт поиска кандидатов на открытом рынке. Но вот с головным офисом ситуация тогда была иная… На тот момент с открытого рынка туда почти не нанимали. Вместо этого там занимались переманиванием от конкурентов конкретных специалистов или даже целых команд. И занимались этим не рекрутеры, а директора направлений
- многое зависит от межличностных отношений. Они часто значат больше, чем формальные корпоративные должности. С директором по персоналу у меня были отличные дружеские отношения
- многое зависит от интересов человека. Тот директор по персоналу любит собеседовать людей, если позволяет время и если его по-дружески попросили
- директору по персоналу и мне было поручено сформировать новое направление работы (нанимать предстояло не только младших специалистов). Нас обоих назначили ответственными за это дело. Так что у директора по персоналу была дополнительная мотивация участвовать в найме лично. С него спрашивали за результат
В общем, спасибо автору комментария. Без него мне бы и в голову не пришло обратить внимание на эти нюансы.
Какие задания нужно давать программистам на собеседовании?
Кому-то из читателей не понравился мой выбор вопросов и задач для собеседования:
«Что за бред. Я даю программистам технические задания и вопросы (но такие которые не занимают много времени) именно по профилю работы, без головоломок и прочей ерунды. Кандидат пишет при мне, и всё окей»
Думаю, правда жизни в том, что не существует единого надёжного способа проверки кандидата. Если бы такой способ существовал, все «хорошие» кандидаты были бы давно наняты, а «плохие» никогда бы не нашли работу. В действительности же даже сами понятия «хорошего» и «плохого» кандидата относительные. Один и тот же человек может быть некудышным кандидатом на одну вакансию и отличным – на другую.
То, как можно тестировать кандидата, зависит от конкретной вакансии. Для каких-то вакансий получается подобрать короткие задания, близкие к реальной работе, для других вакансий – нет. Одним из ключевых требований к кандидатам, которых мне приходилось нанимать, были сильные аналитические способности. Это было гораздо важнее технических навыков, которые я мог бы проверить, дав кандидату «линейную» задачу, для решения которой надо что-то «знать», а не что-то «придумать».
Впрочем, задача, приближенная к реальности, в моей предыдущей статье тоже упоминается. Её кандидату было предложено взять на дом. Она подразумевала как демонстрацию аналитических навыков, так технических тоже.
В целом, я думаю, что если кандидата можно надёжно проверить с помощью небольших задач, да ещё и максимально приближенных к реальности, то скорее всего, речь идёт о найме на вакансию, которая не требует постоянного поиска новых творческих подходов к решению рабочих задач. В IT таких вакансий хватает, как и во многих других областях. И такой труд очень важен, но конкретно в описанном мной случае у конторы были другие потребности.
Есть ли смысл в головоломках и алгоритмах из учебников?
«Я не программист и не понимаю, к чему ребусы разгадывать? Тем более, джуну»
«Ну, спору нет, уж про quickSort и бинарный поиск знать, конечно, надо, другой вопрос, что эти знания редко где реально пригождаются»
«Это детские олимпиадные задачи по математике (на взвешивания предметов, на переливание банок, на доставание карандашей, на комбинации монеток и тп) - кто не ходил на олимпиады, тот, скорее всего, их и не видел. Мне интересно, кто решил, что хорошая идея спрашивать их на собеседованиях»
Здесь я бы вернулся к тому, с чего начал эту статью: довольно легко критиковать тот или иной подход к проверке профессионализма кандидатов. Я сам этим регулярно занимаюсь 😁. Проблема в том, чтобы предложить что-то взамен. Каждый занимающийся наймом специалист крутится как может. И под каждую конкретную вакансию он, вообще говоря, может подбирать разные задания и вопросы. Схема проведения собеседований – и найма в целом – в скале не высечена и по-хорошему должна адаптироваться к конкретной ситуации.
Я не могу сказать, что сам в диком восторге от головоломок, олимпиадных задач или базовых алгоритмов… У всех этих типов заданий есть свои недостатки. Но в совокупности задания разных типов ценнее, чем по отдельности. Если на собеседовании вы предложите кандидату множество различных ситуаций, то сможете увидеть с чем он справляется хорошо, а с чем – не очень.
Думаю, очень важно, чтобы кандидат довёл до конца хотя бы одну задачу, с которой раньше не сталкивался. Какая именно это будет задача – не имеет особого значения. Но что если кандидат не решит ни одной? На этот счёт у меня есть небольшая история… Как-то я осуществил найм в контору очень добродушного парня, который на собеседовании не решил ни одной задачи, но при этом не унывал, не вешал нос и всё время демонстрировал позитивный настрой. Я тогда подумал, что с таким настроем он точно сможет доводить начатое до конца. И это несмотря на то, что на собеседовании он не смог довести до конца даже элементарную задачу. В общем, я ошибся… Этот рубаха-парень в дальнейшем не справился ни с одной рабочей задачей. Зато он в очень короткий срок перебухал с топ-менеджерами компании. Когда я, посыпая голову пеплом, решил расстаться с ним ещё до окончания испытательного срока, один из топ-менеджеров мне сказал, что «Нельзя разбрасываться людьми, с людьми надо работать. Не можем мы уволить такого ценного парня». Понятно, что тут возникают вопросы к узурпированию моей области ответственности топ-менеджером… но это уже другая история. Необходимо, чтобы кандидат продемонстрировал на собеседовании возможность доводить задачи до конца. И в этом отношении не очень важно, будет это головоломка или что-то приближенное к реальности. И чем больше разнообразных задач вы дадите кандидату – тем, на мой взгляд, лучше.
Что же касается вопроса о том, пригождаются ли в работе «книжные» знания про сортировку или поиск – это вечный предмет споров среди айтишников… Универсального ответа не существует. Реальная полезность этих знаний зависит от конкретной работы. Где-то пригождаются, где-то – нет… Можно относиться к проверке таких знаний просто как ещё одному методу тестирования кандидата. Это дополнительный способ взглянуть на кандидата с ещё одной стороны. Лично я считаю позитивным сигналом, если кандидат знаком с базовыми алгоритмами и методами оценки сложности вычислений. На мой взгляд, такие знания говорят о широком кругозоре и высоком общем интересе к разработке софта. Думаю, если человек обладает широкими знаниями в какой-то области, то это означает, что ему действительно интересна эта область; и что он пришёл в эту область за самореализацией, а не потому что там «много платят» или «это модно».
Насколько большими могут быть задания?
«Условные 100 строк кода в качестве теста — это не дофига? Насколько мне известно, длина кода в рамках "стандартной задачи" зависит от навыков и опыта человека. Сколько это по времени — часа 4? 10 часов?»
Этот комментарий относится к ситуации, когда я предложил кандидату взять задание на дом и сказал, что от потребуется написать не более 100 строк кода.
В целом я не очень люблю такой показатель как «объем/количество кода». Опытные программисты много думают и мало пишут. Менее опытные программисты для решения тех же самых задач напишут больше кода, при этом он, скорее всего, будет менее качественным, а задачи будут решены не самым оптимальным способом. Так что, если кто-то пишет много кода, это ещё не означает автоматом, что он делает много полезной работы. Впрочем, если кто-то пишет очень мало кода – при этом совершенно корректного! – то это тоже не означает автоматом, что код хорош. Например, он может быть непонятным для других людей, соответственно, с ним будет тяжело работать в дальнейшем. Поэтом сам по себе размер кода ничего не говорит. Код в первую очередь должен быть не «большим» или «маленьким», а должен:
- быть понятным. Для меня это, пожалуй, основное требование к коду. Понятный код можно улучшать и развивать в любом направлении. С непонятным кодом можно только застрелиться. Понятность кода обычно приводит к некоторому росту его количества
- корректно решать поставленную задачу
- по возможности, реализовывать наиболее оптимальное и элегантное из возможных алгоритмических решений. И это уже к вопросу про «много думать и мало писать». Элегантные решения обычно короче неэлегантных, при этом не в ущерб понятности.
Почему же я сказал кандидату, что ему потребуется написать не более 100 строк кода? Ну, чтобы показать ему, что задача не является какой-то супер-масштабной. Ибо кандидат выразил опасение, что давая ему задачу на дом, я пытаюсь решать насущные задачи конторы за бесплатно.
Но всё-таки: 100 строк кода – это много или мало? Зависит от задачи… Если для решения задачи нужно придумать нетривиальный алгоритм, то ценность самого кода уже не так важна. Тут вся ценность будет в проявлении недюжих аналитических способностей, которые позволят получить «концепцию» решения. А написание самого кода будет уже просто техническим моментом. При таком раскладе 100 строчек будет в каком-то смысле «много». Потому что чтобы их написать, нужно будет сначала придумать неочевидный алгоритм.
Если же 100 строчек кодируют линейную последовательность достаточно очевидных действий, то можно условно считать, что это «небольшой» объём кода. В задачах, для которых концепция решения лежит более-менее на поверхности, важен уже не столько алгоритм, сколько корректная обработка частных случаев, граничных условий, ошибочных ситуаций и пр. Я предложил кандидату решить задачу именно такого типа.
Теперь про то, как размер кода соотносится с временем, необходимым для решения задачи… Здесь применимы схожие соображения. Если задача подразумевает «простую» логику решения и не требует изобретения нетривиальных аналитических подходов, то предполагается, что она будет решена достаточно быстро. Сложные же задачи иногда могут решаться, допустим, в 10 строк кода, но при этом нахождение решения может потребовать большого количества времени. Так что «количество строк кода» и «время работы над решением» не особо коррелируют. Всё зависит от задачи.
Можно ли давать задания на дом? Не будет ли «лопухом» тот, кто соглашается брать такие задания?
«Эти тесты на 100 строк предлагать можно только, чтобы убедиться, что если повелся и взялся за такое, а не послал сразу, то такого не брать на работу»
Пожалуй, здесь я не разделяю точку зрения дорогого читателя. Если кандидат согласился взять задачу на дом, значит, он мотивирован получить работу, причём мотивирован работать именно в вашей компании.
Но в раздаче заданий на дом есть нюансы. Предлагая такое, я понимаю, что кандидат может отказаться. Это нормально, осуждать за это я его не буду. Например, старшие разработчики обычно отказываются от заданий на дом. Поэтому им их никто обычно и не предлагает. Однако давать задания на дом младшим разработчикам – вполне себе распространённая практика. У начинающих разработчиков не то чтобы вал предложений работы. У работодателя же, как правило, довольно много кандидатов на начальные позиции.
В целом, практика заданий на дом мне нравится. Как я уже сказал, со старшими сотрудниками в IT это не очень прокатывает, ибо на них обычно довольно высокий спрос. Так что они даже могут позволить себе до какой-то степени диктовать условия работодателю, причём не только в процессе найма. Однако в других областях ситуация может быть иной. Например, одному моему знакомому менеджеру по продукту – очень опытному и квалифицированному – недавно при устройстве на новую работу пришлось делать домашнее задание по разработке продуктовой политики для разных каналов сбыта. Он отнёсся к этому совершенно нормально; пошёл и сделал, несмотря на свою крутость.
Что же касается конкретно случая, описанного мной предыдущей статье, то я искал в компанию мотивированного человека, который может более-менее самостоятельно справляться с небольшими чётко поставленными рабочими задачами. Отсюда и задание на дом, которое позволило бы показать, что человек способен самостоятельно сориентироваться на незнакомой «поляне».
А что с компетенцией директора по персоналу, который участвовал в собеседовании?
В огород HR-директора упало немало камней:
«Коля вовсе не крутой HR»
«… текст… показывает АБСОЛЮТНУЮ бесполезность директора по персоналу Коли…»
«Как бы вскоре вашего Колю не охмурили на несколько млн мошенники. Ну или он воспылал к парню чувствами... По-другому никак не объяснить. Почему Коля до сих пор у вас кадровик?»
В профессиональной жизни – как и в любой другой жизни – человек не познаётся лишь по одной-единственной ситуации. Все совершают ошибки. И Коля совершает, и я совершаю, и любые супер-профессионалы, с которыми я когда-либо пересекался – тоже совершают. Причём другим профессионалам некоторые из этих ошибок могут казаться "детскими". Но! Люди имеют право на ошибку. Даже самые квалифицированные. Там, где цена ошибки слишком высока, часто привлекают больше одного профессионала, чтобы они могли подстраховать друг друга.
И ещё одно... у каждого человека есть свои "тараканы". И когда какая-то ситуация вступает в "резонанс" с этими тараканами, человек особенно склонен совершать ошибки. Повторюсь: даже самые крутые профессионалы. Например, я знаю одного мощного научного журналиста, который активно борется с псевдонаукой и читает лекции о том, как распознавать псевдонаучные публикации. И вот однажды этот журналист публикует хвалебную рецензию на... по-бааам!.. псевдонаучную книжку. Он потерял хватку в этой конкретной ситуации просто потому, что книжка задела в нём определённых "тараканов". Однако это не означает, что сам журналист "плохой". Наоборот: один из лучших и самых популярных в России. Думаю, что с Колей произошло то же самое, что и с этим журналистом. Тот парень, которого мы с Колей собеседовали, задел определённых "тараканов" в Коле. Хорошо зная Колю, я даже могу предположить, каких именно. Но это уже не имеет отношения к делу… Коля крутой специалист, и я это точно знаю по множеству других ситуаций, в которых он проявил себя как профессионал своего дела.
Роль HR-ов в найме сотрудников
«… hr - не просто бесполезная, но вредная "профессия"»
«Вот сколько "хрюш" знаю, ни один (ни одна) не понимает кто, что и как делают на родном предприятии. Они просто клерки»
«Я бы отдел хр вообще не держал: или своих родственников, знакомых принимают, или других нулей. один вред от них»
Вопрос о роли HR-ов оказался самостоятельной большой темой, которая потребовала отдельной статьи. Вот эта статья: За что многие не любят эйчаров? Заслуженно ли?
Кажется, пока всё… А какие мысли по поводу найма новых сотрудников – необязательно в IT – есть у вас?
Даааа! Приглашаю вас в свой небольшой канал с фотками, ведущийся в стиле «японского туриста», то есть «что вижу, то и фоткаю» 😁